Sorry for my (very) bad english ...
The configuration used:
NeoLoad 5.0 GNU / Linux (opensuse 13.2)
The responses seem wrong body decoded when recording action on our test site .. Headers *seem* to be correct for queries and responses ....
Further tests on other websites are correct. So, I guess that these problems are due to errors (implementation?) on our site, but I can not determine which ones?
Firefox debug window shows the correct contents of these bodies (and requests / replies go out by the NeoLoad proxy, ie localhost. 8090).
Http://novaxelcloud.fr:8000/help.html GET HTTP / 1.1
User-Agent: Mozilla / 5.0 (X11; Linux x86_64; rv: 35.0) Gecko / 20100101 Firefox / 35.0
Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8
Accept-Language: en, fr-en; q = 0.8, en-us; q = 0.5, with q = 0.3
Accept-Encoding: gzip, deflate
HTTP / 1.1 200 OK
Server: NovaAppServer-Linux64 / 188.8.131.52
Date: Mon, March 9, 2015 1:35:53 p.m. GMT
Last-Modified: Mon, March 9, 2015 11:31:30 GMT
Content-Type: text / html
Keep-Alive: timeout = 300
But the recorded content resembles the accompanying illustration...
Thank you in advance for your expert advice ...
Have a great day,
It seems that NeoLoad is not able to uncompress the gzip content. Do you get any errors in the NeoLoad log files? You can open them from the menu "Help-->Open logs folder..."
There are maybe some extra data in the response header so NeoLoad cannot recognize the data content.
You could ask NeoLoad to store the response content to a file and see if you can open it with a zip tool.
See the NeoLoad documentation here
Thank you for that answer ...
Indeed, I find messages like this in the logs:
2015/03/09 14:34:26 WARN - neoload.Runtime: Can't uncompress gzip response content java.io.EOFException: Unexpected end of ZLIB input stream
However, if I record the content of this response body in a file like you was suggesting, my favorite compression utility in Linux (ark) opens and displays the content correctly (no error message).
By cons, 7zip Windows does complain that the file is corrupted. But he manages to open and extract the content that is the one expected.
There must therefore be a concern in our compression treatment flow somewhere. I'll watch it on my side.
Thank you again.