1

we have a problem with a multi-step availability test both on Visual Studio 2019 Enterprise and Azure Application Insights.

The first HTTP request works as expected, but the second HTTP request ends with the following exception:

Request failed: The server committed a protocol violation. Section=ResponseStatusLine

I have done the following tests trying to find a solution to this issue:

  1. Tested the same HTTP requests flow with Postman and they works fine;
  2. Tested the same HTTP requests flow with cURL and they works fine;
  3. Tested the same HTTP requests flow with Visual Studio 2019 Enterprise as a webtest project and got the same exception at the second HTTP request call. If i use Fiddler or Burp in the middle of the HTTP calls, I don't get any exception and also the Visual Studio 2019 webtest project run works fine. I managed also (without any proxy in behind) to temporarily use a TLS cipher that permits Wireshark decryption with the private key of the HTTPS server SSL certificate (by temporarily disabling all ciphers that supports the Diffie-Hellman key exchange) and checked the trace of the HTTP requests, but I haven't find any useful information, the HTTP flow seems correct at first glance (HTTP headers are corrects, and also JSON data returned and HTTP status).

Have you any suggestion on how I can better investigate the reason behind this exception?

Just to add another information, we are currently using Dynatrace Synthetic with the same HTTP flow and it works fine, and we are trying to configure Azure Application Insights with the same services in order to evaluate if we can switch from Dynatrace to Azure Application Insights.

Thanks in advance for all your replies!

Valerio Del Sarto
  • 11
  • 2
  • Usually this error is an indication that web application doesn't adhere to HTTP specification (for instance, one cause would be that headers are separated with '\n' and not with '\r\n'). By default .NET stack fails with this error. Though it is possible to configure UseUnsafeHeaderParsing for own code, this is not an option for Multi-Step tests. Question - do you have a repro of this without Multi-Step test (for instance, a single URL which results in this behavior)? – ZakiMa Dec 04 '20 at 23:06
  • Hi, the same HTTP request that fails with this exception within the Multi-Step test works fine if I do only the second request by removing the first from the test, passing manually both the cookie and the token directly into the second call. I've created a copy of the webtest, removed the first HTTP call, added both cookie and token headers manually to the second call (the token was previously calculated by an extraction rule) and the test goes fine without any exception. This is the reason why it seems not to be an issue with the second http call (reply headers are fine ended with '\r\n')... – Valerio Del Sarto Dec 07 '20 at 09:52
  • One way to troubleshoot this - try to see whether the problem repros with HttpClient. https://stackoverflow.com/questions/2482715/the-server-committed-a-protocol-violation-section-responsestatusline-error – ZakiMa Dec 07 '20 at 22:14
  • This might point to what web site returns which .NET stack doesn't like – ZakiMa Dec 07 '20 at 22:15
  • One more question - you're using MultiStep. Single URL supports redirects & tracks cookies correctly. Double checking that whatever you're trying to achieve does require Multi-Step. – ZakiMa Dec 07 '20 at 22:16
  • Unfortunately my flow requires a MultiStep because it needs to perform an app authentication and then use both cookie and token to send further requests in order to check that the application is working properly. We'll try to repro by using custom code with HttpClient, when possible. Thanks! – Valerio Del Sarto Dec 09 '20 at 14:47
  • A little bit offtopic - you mentioned you implemented these tests also in Postman and cURL. Do they require some scripting to express logic you described above? – ZakiMa Dec 09 '20 at 20:35
  • Exactly, but in both Postman and cURL I've done each HTTP request in a consecutive and independent way, by manually adding to the following calls the values that I extracted from the previous call (I mean that I saved the cookie in a local file and used it in the following call, and that I took note of the token value returned from the first call and manually added it into the following calls). But since they worked manually, I suppose that they will work also by creating a sort of flow via Bash script or a Collection Runner. – Valerio Del Sarto Dec 11 '20 at 08:43

1 Answers1

1

This seems to be a .NET "security feature". With default configuration the HttpWebRequest does not accept response status lines without an explicit status description. I haven't tested it but this is most likely the reason for your error message. The default behaviour can be changed through the useUnsafeHeaderParsing property. The name of the property is misleading. It's not just about parsing of headers it covers also the behaviour for parsing the resonse status line. You can try to temporarily disable the property as described in the answer of this question.

Since this disables also some other checks (see the first link from above for a list of all checks) that help to avoid HTTP response split attacks, I would change the default behaviour only to verify that this is definitely the root cause of your error message. For a production setup it is definitely better to add a status description to your status codes. Why Microsoft treats a missing status messages as a potential security issue is unfortunately undocumented and out of my knowledge.

rmunge
  • 3,653
  • 5
  • 19