Loadrunner replay http response returns different return_uri than when performed manually from the browser - https

Question

I have started using HP Loadrunner as part of a performance testing project.
We are trying to hit an initial URL which redirects to an identity server and then redirects to the web portal login screen.
For now I am trying in parallel to see the message exchange in both loadrunner log and browser log (just to compare the two request response messages). For some reason even though the initial HTTP GET message seems to be the same as the browser one the response coming back from the web portal is not the same. So at the location property when i get the rediction url the path is missing the port number at the redirect_uri point (...../url:portnumber2/.....). that creates an issue with the second redirection as instead of getting me to the proper redirection url it takes me to the error page redirection.
so the message exchange in browser looks like below:
Request URL:https://urladdress:portnumber1/
Request Method:GET
Status Code:302
Remote Address:10.33.5.83:4020
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-length:0
date:Fri, 25 Aug 2017 06:50:47 GMT
location:/connect/authorize?client_id=...&redirect_uri=https%3A%2F%2Furladdress%3Aportnumber%2F....sign........
server:.......
set-cookie:.AspNetCore.OpenIdConnect........
set-cookie:.AspNetCore.........
status:302
x-powered-by:ASP.NET
x-ua-compatible:IE=Edge,chrome=1
Request Headers
:authority:urladdress:portnumber1
:method:GET
:path:/
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
upgrade-insecure-requests:1
user-agent:.......
second redirection
Request URL:https://urladdress:portnumber2/connect/authorize?......
Request Method:GET
Status Code:302
Remote Address:ipaddress:portnumber2
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-length:0
date:Fri, 25 Aug 2017 06:50:47 GMT
location:https://urladdress:portnumber2/account/login?.......
server:......
status:302
x-powered-by:ASP.NET
Request Headers
:authority:urladdress:portnumber2
:method:GET
:path:/connect/authorize?......
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
cookie:.AspNetCore.......
upgrade-insecure-requests:1
user-agent:..........
and the message exchange in loadrunner looks the same with the only difference of not including the portnumber2 after the end of the return_uri property.
That results in being redirected to an error page instead of the second redirection.
The script we are using is shown below:
web_set_sockets_option("SSL_VERSION", "TLS1.2");
web_cleanup_cookies();
web_cache_cleanup();
web_add_auto_header("Accept-Encoding","gzip, deflate, br");
web_add_auto_header("Accept-Language","en-US,en;q=0.8");
web_add_auto_header("Accept","text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8");
web_add_auto_header("Upgrade-Insecure-Requests","1");
web_add_auto_header("User-Agent","Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36");
web_set_option("MaxRedirectionDepth","0",LAST);
web_set_max_html_param_len("10000000");
web_reg_save_param_ex("ParamName=url1",
"LB=Location: ",
"RB=\r\n",
LAST);
web_url("urladdress:portnumber1",
"URL=https://urladdress:portnumber1",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Mode=HTTP",
LAST);
lr_message("redirected address 1 = %s " ,lr_eval_string("{url1}"));
web_reg_save_param_ex("ParamName=url2",
"LB=Location: ",
"RB=\r\n",
LAST);
web_url("connect",
"URL={url1}",
"Resource=0",
"RecContentType=text/html",
"Referer=https://urladdress:portnumber1",
"Mode=HTTP",
LAST);
return 0;
I need to know why the port number on a url is not fetched by the http response message( perhaps there is a configuration I need to create).
Any other comments that might help would be much appreciated.

Answer 1

Have you considered that having a double redirection, particularly ones which are temporary, are going to extract a large performance hit. You have two double handshakes in a row. This is bad magic, independent of the testing tool being used. It is poor architecture on the part of your designers/developers. Cite the defect - Go for a max redirect level of one.