loadrunner Okay. This is the first time I've encountered...

  • perf-test.com need your contributions to build up a strong repository of performance engineering resources.

A

Ashwin Nair

Guest
Okay. This is the first time I've encountered such an issue. Does the server ever ever fail to send an HTTP response code? I'm executing a web http/html script and I'm facing a 'No HTTP status line detected' error. The funny part though is that the response body is proper with all required information(read dynamic correlation) that I'm looking for. I ran the script with debug log level and I'm able to see the complete http 200 status code, however the script pauses at the same point after throwing above mentioned error. According to the W3 documentation, a server should an will send an http response code from 1xx to 5xx. Does it look like a hiccup with LR(v9.5)? Because it is not able to parse the http response code for some reason. Any help?
 
Here's a thought (I'm not near my computer to look up specifics so this is off the top of my head): You can force LR to continue on error. There are also settings to change error behavior on the fly.
 
If you have a bit of the log data (cleaned up to not show AUT information) that would help. Does this error happen only on this page, only on this app, only to you? Have you tried later versions of LR? I think you need to narrow down when this occurs to rule out possibility of some other oversight. The fact you are smart enough to read and debug logs for a status code tells me you should have success digging further.
 
There will always be a status sent (so long as a header is sent). I have seen some odd ones over the years, such as 000 coming from a CDN when it has lost it's mind and connection back to the origin servers, 420 when the developers thought that the server needed to take a break to enhance its calm, and even a 042 followed by a page of indecipherable gibberish. But in all cases the test tool was picking up the status from the header. Take an explicit look at the headers involved and see if there is something odd in the structure compared to those which are working for the same HTTP status. This may point to a server configuration issue or a code defect when setting status on the part of the developer
 
James, I checked the headers of the request and response and they are exactly how you want them to be. Didnt find any anomlies there. There is an XmlHttpRequest header and a Microsoft ajax header. Apart from that it's pretty much the usual. Erik, I tried setting the continue on error flag to run the script( unsure of its application, as it can cause false positives) , but the script still stalls at the same point. We are currently using LR 9.52 with patches, and currently testing on later LR versions would not be feasible.
 
I would try running the script on 12 as a cross check. You can use the community edition for this loaded in a virtual machine so you don't overwrite your current installation. Using 12 as a control element should help to educate us on an issue which is version specific or an issue common across versions, which would point back to the particular page.
 
Agree with James. While 9.52 was one of my favorite versions ever, it is out of support and could be the problem. You don't want old software being the cause of your issue. Upgrade! At least try the free trial of LR12 in a test machine.
 
Thanks Eric and James. The issue here is I cant set the script to continue on error, because I'm getting a 'warning' that no Http status code detected.(Apologies for not making it clear before). Furthermore, I observed that the server response contains pages of binary data which ends with the status code. Something like - "....\x00\x00HTTP/1.1 200 OK\r\n" This is probably why LR is not able to detect the status code because it's appended. I tried to use different MIME types like *application/octet-stream* for RecContenttype in the request, but with no luck :(
 
Finally I was able to find out why the server was returning binary data, when it really shouldn't be doing so, thus causing the http status code to append itself at the end. What happened was that there was a.preceding request, where a file download is happening and it wasnt getting downloaded completely. As the content header length set by the server is less than the actual size of the file. Thus sending the remainder of the binary data in subsequent request(!!). I removed file download from the script (for debug purposes) and now the response is perfect and LR is able to parse the data and the HTTP response code.
 
Whacky. Sounds like a developer failed to set the content header correctly. Great catch! I would definitely put this one in the defect category
 
Yes. And this defect was never raised during system testing or UAT, as we never face the issue manually through the browser. Whacky indeed.Any way to reproduce this manually?