CODEWITHSUNDEEP
visual-studioazure-application-insights
Valerio Del Sarto
Valerio Del Sarto

Reputation: 11

Exception "Request failed: The server committed a protocol violation. Section=ResponseStatusLine" with multi-step availability test

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!

Upvotes: 1

Views: 2742

Answers (1)

rmunge
rmunge

Reputation: 4248

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.

Upvotes: 1

Related Questions