This release contains several fixes but also attempts to enhance security. This is the case of System.Web.HttpWebRequest. It now detects if an HTTP reponse split attack might be in progress and raises “The server committed an HTTP protocol violation” error.
For instance, look at this example of HTTP headers returned by some server:
HTTP/1.1 200 OK
Via: 1.1 SOMEPROXY, 1.1 ANOTHERRANDOMPROXY
Date: Fri, 03 Sep 2004 18:02:23 GMT
Last-Modified: Fri, 03 Sep 2004 17:08:42 GMT
Content Length: 51
When presented with this response, the SP1 version of HttpWebRequest will fail because you can’t have a space in a header name. It should really be Content-Length. As you can see, the client application will raise an exception but the server is really at fault here and should be fixed. The client only protect itself by refusing a non-conformant, potentially dangerous response.
This change has already been noticed, mostly by user of .NET based RSS aggregators and they figured out that there is a way to disable the security improvements by altering the appropriate .config file.
<httpWebRequest useUnsafeHeaderParsing=”true” />
This setting is only recognized by .NET 1.1 SP1. If you only have .NET 1.1, your application will fail if it encounters this setting. It might make installers slightly more complex.
Now, let me get on my soap box for a second: I know it is tempting to revert back to the unsafe header parsing to “fix” this but resist the temptation. If you find a site that exposes this behavior, contact them and ask them to fix it.