Strict HTTP Parsing

mflasko — Wed, 02 Nov 2005 22:37:00 GMT

In version 2.0 of the .Net Framework, we (System.Net) changed how we parse HTTP traffic. The change has gone to a more strict parsing model. One example, is we now require a CRLF (carriage return, line feed) at the end of each line. While these changes were done to improve the security of our HTTP stack, it has the negative effect of causing some applications to see exceptions thrown where they didn't previously. If you find the parsing of the HTTP headers to be too strict, you can revert the strictness of our parsing to improve app compatibility. This is done via an application configuration file setting as shown below

Hierarchy:
<configuration> Element
<system.Net> Element (Network Settings)
<settings> Element (Network Settings)
<httpWebRequest> Element (Network Settings)

<httpWebRequest
maximumResponseHeadersLength="size"
maximumErrorResponseLength="size"
maximumUnauthorizedUploadLength="size"
useUnsafeHeaderParsing="true|false"
/>

Additional note about UnSafeHeaderParsing:

By default, the .NET Framework strictly enforces RFC 2616 for URI parsing. Some server responses may include control characters in prohibited fields, which will cause the System.Net.HttpWebRequest.GetResponse method to throw a WebException. If useUnsafeHeaderParsing is set to true, System.Net.HttpWebRequest.GetResponse will not throw in this case; however, your application will be vulnerable to several forms of URI parsing attacks. The best solution is to change the server so that the response does not include control characters.

System.Net now registers a default FtpWebRequest implementation

mflasko — Mon, 12 Sep 2005 08:53:00 GMT

Prior to the .NET Framework version 2.0, applications could register a component to handle FTP requests using System.Net’s extensible pluggable protocol framework. Components for handling different web requests are registered by associating the component with a specific URI prefix. Any web request that matches that prefix would then be handled by that component. In version 2.0 of the .NET Framework, System.Net now supports an FtpWebRequest component that is registered by default for the “ftp:” prefix. Any applications that are registering for this prefix (prior to this release) could now be broken because the prefix (FTP) is already taken.

There is a workaround for this issue. It is as follows:

Update the application configuration file to remove the default FTP pluggable protocol prior to registering your own FTP component:

<system.net>

</webRequestModules>

</system.net>

I hope this information helps to make your applications transition to Whidbey smooth as silk :).

Mike Flasko's Blog : Changes in Whidbey from Everett

Strict HTTP Parsing

System.Net now registers a default FtpWebRequest implementation