Does IIS6 truncate HTTP headers at a hard-coded limit?


Question:


Using IIS the HTTP_ACCEPT header server variable received from the client appears to have a hard coded limit of 259 characters. This is causing problems when using a Windows Mobile 5 Smartphone which has a longer string than 259 characters which is getting truncated. The phone then receives a 406 error saying that e.g. HTML content is not acceptable. I can hack the registry on my phone but I would rather there was a fix in IIS to get round this limit so that my site can be used by others with this type of phone. Is there a patch or a hotfix or a service pack level I should know about?


Answer:


I cannot reproduce your claim on either Windows Server 2003 RTM or with Service Pack 1 installed. I think the issue is outside of IIS.


Using WFetch from IIS Diagnostics Toolkit, I am able to successfully send Accept: header of up to ~16K in length (the server-side limit depends on HTTP.SYS settings for MaxRequestBytes [i.e. max size of entire request] and MaxFieldLength [i.e. max size of a given request line, like the Accept: header], both of which default to 16K) as well as retrieve the complete header value using HTTP_ACCEPT in ASP.


Since I accomplished this on a default system, I presume the observed difference is due to non-default configuration of the IIS6 server that you are using. My guess at the issue involves custom ISAPI DLLs running on your server. I tried a couple of popular configurations, like ASP.Net 2.0 ISAPI configured as Wildcard Application mapping as well as my own test ISAPI Filter, and I did not see any issues with large Accept: (or any) header, so I do not believe the ISAPI interface is involved.


Perhaps your managed hosting provider has some 3rd party security ISAPI DLL which intentionally truncates header lengths. For example, ISAPI Filter or ISAPI Extension configured as a Wildcard Application mapping can filter and truncate request headers. Or the intervening network between your client and server imposes a limit on request header length.


At this point, you should probably contact your managed hosting provider regarding their server and network configuration and have them investigate what is going on. Based on my observations and investigation, I do not believe IIS6 truncates HTTP headers like the Accept: header on its own.


//David

Comments (12)

  1. SJB says:

    I’ve seen a similar thing a couple years back which turned out to be the load balancer before the web farm.   It ended up being a  bug in the load balancer code.

  2. RuudE says:

    I have the same  problem using my SPV C600 smartphone on a very standard IIS server (tested several W2K – IIS5.0).

    The HTTP_ACCEPT headers are truncated at 259 characters.

    Due to this I get 406 errors on all graphics.

    Other headers like

     HTTP_X_WAP_PROFILE:"http://www.htcmms.com.tw/gen/st21-1.0.xml"

     HTTP_UA_OS:Windows CE (Smartphone) – Version 5.1

    are shown every second call.

    This also happens when I browse to a preset bookmark: http://www.microsoft.com/windowsmobile

    Pictures from this site are not shown in the browser.

    Non IIS servers do not seem to have this problem.

    Anymore idea’s?

  3. David.Wang says:

    RuudE – I suggest tracing through the network between the client and server to determine where the truncation and missing header happens.

    Having custom headers show up every other request is definitely not an IIS behavior.

    I have seen many people *swear* it is IIS that is the problem, even by showing that another web server does not have the same issue, but they all ended up being user mistakes of some sort, custom server applications/modifications they were not aware of, or even the network doing odd things depending on the server.

    A network trace at the client and server end quickly shows where the issue is originating.

    //David

  4. RuudE says:

    David,

    Thanks for your quick response.

    What about the microsoft site having the same problems?

    I got this phone for testing brandnew this afternoon, so there should be no problems in the phone/IE setup (I think).

    Tracing the phone will be a problem, I will try to do a trace on the server/switches/firewall tomorrow. I will write back the results on that.

    Ruud

  5. RuudE says:

    David, (and hopefully Jim who started this discussion)

    I have been testing a bit more. Using a sniffer on my server I found out the 259 is everything there is on the TCPIP stack.

    This rules out IIS :-)

    I made a small testpage on my webserver at home (running php) and found out that I got the same header (259 bytes only) on that server.

    I am connecting through a mobile carrier GPRS gateway (Orange NL), and now I suspect that thing to be causing the problem.

    If Jim is also following this topic, I am very curious how he connects and what operator he is using.

    We will try to connect the phone through a different GPRS gateway, and see what happens then.

    The IIS "problem" now is this.

    IIS is sending a HTTP 406 error when it needs to serve a .gif or .jpg file. The HTTP_ACCEPT header didn’t include these types, so he is allowed to do so.

    In this case IIS might be a bit too strict. Other servers still send the data, even if the useragent didn’t tell them they are able to accept or display it.

    Do you know if there is any hack (or normal function) to switch this off in IIS?

    Thanks for thinking with me 😉

    Ruud

  6. David.Wang says:

    Ruud – RFC2616 says:

    If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

    Since it is a SHOULD, the server is free to do whatever. IIS chose to follow the RFC, which assumes the client knows what they want and IIS does not want to impose on the client. Seems perfectly reasonable to me.

    If you want to alter server behavior, that is also allowed by the RFC, and you can write an ISAPI Filter to do so. Figure out which requests you want to have this altered behavior, and have the filter add a */* to the Accept request header, and IIS static file handler will gladly serve that response.

    But no, there is no switch in IIS to toggle this behavior, and I doubt it will ever exist – RFC does not mandate it, and one can easily obtain the other behavior.

    //David

  7. Jim Hunt says:

    Hiya

    Simple test page running on my IIS 6.0 server.  If I attempt to access this from a PocketPC running Windows Mobile 5.0 this works fine.  However if I attempt to access this from my C600 then I also receive error 406.  Why does IE work on the PocketPC build of WM 5.0 but not the SmartPhone build?

    The same is true when I run the test page locally on my XP (SP2) development machine.  Of course there may be restrictions in using IIS 5.1 granted but this does seem to be a very odd issue in that it only happens on a WM5.0 SmartPhone.

    Did anybody come up with a resolution for this?

    Jim

  8. JJam says:

    Same for me, Qtek 200… IIS 6.0, I get 406 error for .css, .gif, .jpg etc. No firewall/router in front of the server. PocketPC works fine, WM2003 works fine, too.

    Some other (*nix-based) servers works just fine, so it is kinda issue with IIS+MobileExplorerSmathphone edition configuration.

    Please help…

  9. David.Wang says:

    Jim, JJam – Assuming your request is handled by the IIS Static File Handler (if it is not, then it can be arbitrary behavior and all bets are off), IIS returns a 406 for static files if the Accept Header received by the server does NOT match that of the MIME Type of the resource.

    This can be diagnosed by installing Network Monitor from Add/Remove Programs on the IIS6 server and capturing the incoming network data. If the Accept header received by IIS6 contains the right MIME Type of the resource, then we can diagnose further as a possible IIS issue. Otherwise, it is a network-infrastructure or client-side issue, outside of IIS.

    In Jim’s case, requests through the SmartPhone are probably routed through the mobile carrier’s gateway, which may be truncating the Accept request header, much like RuudE identified, and that would be no fault of IIS.

    In JJam’s case, lack of firewall/router in front of the server does NOT eliminate the network between the Qtek and IIS6 from doing any truncations. Also, as identified earlier, other *nix-based servers work fine by NOT following HTTP RFC… so the hypothesis of IIS+MobileExplorerSmartphone issue is quite premature.

    I mean, it looks like customers complain when Microsoft does not follow the RFC but also when Microsoft follows the RFC…

    Anyways, network sniff at the IIS6 server should tell everything.

    //David

  10. Jim says:

    Thanks for the response David.

    I think you missed the point though :-

    I didn’t connect to the server using the operator.  I connected to the Internet through my computer when the device was attached to my PC (through MS ActiveSync).  I think I pointed out previously that I used exactly the same connection method for another Windows Mobile device.  Actually in all I tried with the following:

    A Windows Mobile 5.0 PocketPC – no problem

    A Windows Mobile 2003 (SE) PocketPC – no problem

    A Windows Mobile 2003 (SE) SmartPhone – no problem.

    A Windows Mobile 5.0 SmartPhone – Error 406

    Incidently I also connected to the server using a Nokia Series 60 mobile phone (a 7610) over my WASP/GPRS connection given to me by my operator with no problem.  Also I should mention that all devices were hard reset (meaning reset back to factory settings) before testing this.

    I think something has changed with Windows Mobile 5.0 for SmartPhone that is truncating the headers (I saw someone say something about that when they used a network sniffer).

    Please don’t get me wrong I’m not pointing the finger at Microsoft and shouting – but there clearly is an issue here; it’s just not certain whether this should be looked at by the IIS or Windows Mobile team.

    Jim

  11. David.Wang says:

    Jim – A network sniff at the IIS6 server of the problematic request will determine who should look at the issue.

    //David

  12. JJam says:

    David, thanks for quick reply. In no way I’m blaming at Microsoft, personally I like the way it goes and way it does :)

    In this case, it would be great to have something like AcceptNonRFCHTTPHeaders or ChangeClientAcceptHeaderTo (REG_SZ)  ‘*/*’ in registry/whereever to workaround this issue. Anyway, I found a quick "fix", pretty bad imho but it at least it works. I’m short on time right now to go with network analyzis.

    So, map .gif, .jpg, .css etc under Site Props -> Home directory -> Configuration -> Application extentions. Make ASP DLL [..inetsrvasp.dll] to handle these files.

    Pros: Works IE6, IE7beta2, FF, Opera, MobileExplorer [PDA/Smartphone]

    Cons: Increased server load, files get "text/html’ http content-type header, other i guess…