Answered by:
VSTS Load Test: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

Question
-
Hello,
I am getting an error that seems to have happened previously but unfortunately the answers offered do not fix the issue. I have a load test setup in VSTS and is run using the azure load generators. When running it in the cloud I get the following error message:
The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
I've been informed this is due to incapsula on our servers /load balancer and so its returning a header which can't be handled. The fixes I've read about are the following:
add the following if you're running localy "vstesthost.exe.config" and one if you're on an Agent "qtagent.exe.config".
<httpWebRequest useUnsafeHeaderParsing="true" />
And the other is to add Header to the request Keep-Alive = false
Has anyone come across this issue when running in VSTS/ Azure
Any information would be greatly apprecaited.
Kind Regards
Tuesday, March 13, 2018 11:32 AM
Answers
-
Hi Judy,
I can confirm this was due to Incapsula running on our servers. Yes I was getting the same error when running on my local machine as I was when running via Azure. Our servers saw the request as a bot and so was returning something in the response to give the error. We had to get the provider to allow our tests to pass for this to work.
Kind Regards
Tuesday, April 3, 2018 2:42 PM
All replies
-
Hi Pir.Rab,
Welcome to the MSDN forum.
How about the result when you run your load test setup On-Premises? This could help us know whether this test only failed in the server.
>> The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
After my research, someone say’s this issue is often caused by dynamic data that has not been handled. Visual Studio detects and looks after many types of dynamic data but web page (web site) designers do all sorts of clever things that Visual Studio cannot detect.
Maybe you could record two version of the short test, make them as nearly identical as you can. Then compare the two recordings. That should reveal the places that may have dynamic data that needs to be handled. Sometimes it is worth recording a third test that is as nearly identical to the first two as possible except that a different user logs in. Compare this third test against the first two.
Other members also encounter this kind of issue before, please have a look at following threads:
Regards,
Judyzh
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.Wednesday, March 14, 2018 8:38 AM -
Hi Judyzh,
Unfortunately this fails on local run too. I've read the answer about unhandled dynamic data and believe its something to do with Incapsula which we have on our system and thats returning headers which webtest doesn't seem to be able to handle correctly. I've had varying success with adding KeepAlive or Keep-Alive headers. But this doesn't work 100% of the time.
Kind Regards
Wednesday, March 14, 2018 9:06 AM -
Hi Pir.Rab,
>> Unfortunately this fails on local run too.
Do you get the same error when it fails on local?
Please run the request in browser to observer whether has the same issue. This could help us to judge whether this issue only occurs in web test.
Please clean the cache and use the default IE settings in your computer, and then playback it again, check the result.
In addition, please have a look at this thread might helpful for you:
Regards,
Judyzh
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.Thursday, March 15, 2018 6:52 AM -
Hi Judy,
I can confirm this was due to Incapsula running on our servers. Yes I was getting the same error when running on my local machine as I was when running via Azure. Our servers saw the request as a bot and so was returning something in the response to give the error. We had to get the provider to allow our tests to pass for this to work.
Kind Regards
Tuesday, April 3, 2018 2:42 PM -
Hi Pir.Rab,
Glad you have find the reason of your issue.
And, thanks for you share the information here, could you please mark your reply as an answer, this will help other community members who encounter the same issue with you.
Thanks for your understanding and cooperation.
Regards,
Judyzh
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.Wednesday, April 4, 2018 6:48 AM