HTTP.SYS rejection of request lines not terminated by CRLF

I recently got the following question about an HTTP.SYS behavior in Windows Server 2003.

Question:

Hi David,

I have a major problem switching to W2K3 and IIS6 currently.

Major handsets in the market (e.g. Nokia) send WRONG HTTP requests - nothing to do against it! Wrong means not seperated with "\r\n".

I've seen your post: https://www.webservertalk.com/archive120-2004-2-132028.html

We are a leading provider for mobile multipayer games - and the only service based on .NET technology. Using IIS6 and W2K3 is important for us.

Is there any solution in the mean time?

greetings from Hamburg/Germany,

Answer:

I hope this illustrates the nasty problem when clients and/or servers do not follow public specifications like HTTP correctly - customers get caught in the middle and usually the server-side has to budge since there are millions more clients than servers to fix. However, realize that budging the server-side simply emboldens the clients to be even more broken in the future, destroying the underlying benefit of a public specification and endangering public communication protocols as we know it.

Now, the behavior being described is the default behavior for HTTP.SYS on W2K3. Due to customer pressure, HTTP.SYS added some features that allowed more relaxed HTTP parsing (i.e. hacks that allowed various broken clients to work). One of them includes allowing request lines to be terminated by only \r or \n instead of the spec-mandated \r\n.

None of these hacks are enabled by default. You must enable them separately yourself. I am inquiring the HTTP.SYS team about any KB articles similar to https://support.microsoft.com/?id=820129 which will describe these new settings and recommendations, and when I get an answer I will post it as follow-up. Stay tuned.

//David

FYI: You can also post questions like this to the microsoft.public.inetserver.iis newsgroup using a standalone news reader or a web news reader like https://www.microsoft.com/communities/default.mspx .