Explicitly Dealing with HTTP Redirect Requests in Load runner

By default, Load Runner does not show Redirect requests in the script, though it take care of redirects during replay. This becomes an issue during transaction analysis, because all redirect requests and corresonding responses are combined into one step and shows up as one transaction in the results report.

The web_url/web_custom_request/web_submit_data functions automatically detects a 302 response from the server and redirects to the location specified in the response header.

The problem with automatic redirection in LoadRunner is that you will NOT be able to figure out the amount of time it takes for each redirected request. Redirects are invisible to the user in LoadRunner. But in few test requirements you would want to know the break up of response timings between primary hit and the redirected server hits. The bigger problem comes in when you are dealing with recursive redirects.

To make an explicit redirect request you will first have to turn off automatic following of redirect instructions. This can be accomplished by setting MaxRedirectionDepth to ’0′. The key thing to remember is to identify redirected location by analyzing “Location: http://” line item in the HTTP response header of the request in question.

Example:
//In your action file
Place this in the beginning of the action file

web_set_option("MaxRedirectionDepth", "0", LAST ); //This is the key

recursiveRedirect_open();
web_url("url_which_gets_redirected","http://sampleredirect.com/",LAST);
recursiveRedirect_close();


Here is how you do it:

//place this in global.h

int HttpRetCode;
int i=0;
char depthVal[10];
char cTransactName[20000];

recursiveRedirect_open()
{
web_set_max_html_param_len("10000");

web_reg_save_param("cRedirectUrl",
"LB=Location: ",
"RB=\r\n",
"notfound=warning",
"Search=Headers",
LAST);

web_reg_save_param("cTransactionName",
"LB=https://Domain.com/",
"RB=\r\n",
"Search=Headers",
"notfound=warning",
LAST);

web_reg_save_param("httpCode",
"LB=HTTP/1.1 ",
"RB= ",
"Search=Headers",
"ORD=1",
"notfound=warning",
LAST);
}

recursiveRedirect_close()
{

HttpRetCode = atoi(lr_eval_string("{httpCode}"));
lr_output_message("xReturnCode=%d", HttpRetCode);

if(HttpRetCode == 302)//If redirect
{
i++;
web_reg_save_param("cRedirectUrl",
"LB=Location: ",
"RB=\r\n",
"Search=Headers",
"notfound=warning",
LAST);

web_reg_save_param("cTransactionName",
"LB=https://https://Domain.com/",
"RB=\r\n",
"Search=Headers",
"notfound=warning",
LAST);
web_reg_save_param("httpCode",
"LB=HTTP/1.1 ",
"RB= ",
"ORD=1",
"notfound=warning",
LAST);
sprintf(cTransactName, "Redirect_depth_%d_%s", i,lr_eval_string("{cTransactionName}"));
lr_start_transaction(cTransactName);
web_url(cTransactName, "URL={cRedirectUrl}", "Mode=HTTP", LAST);
lr_end_transaction(cTransactName, LR_AUTO);
HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);
recursiveRedirect_close();

}
else
{
return;
}

}
The above code automatically generates new transactions for each unique follow redirect request’s made by the script. It keeps a track of the HTTP response code of each request and exits from recursion state when the response code is not 302.

The first challenge is to find the requests in the script which has URL redirections. If you find it hard to identify the locations where redirects are performed in the script, run the script after including web_set_option(“MaxRedirectionDepth”, “0″, LAST ); with standard log enabled. After the script completes executing, check the logs for “redirection depth exceeded” message, because whenever a web server prompts for a redirection of the resource, it sends back a 302 HTTP code with the new location, but since MaxRedirectionDepth is set to 0 in LoadRunner it will not explicitly hit the new URL. This is where the above script comes into play. Now, double click on that line, and Vugen will highlight the step where the redirection was attempted. Now place the recursiveRedirect_open() and recursiveRedirect_close() function call at the start and end of the concerned step/request and you should be good to go!