Truncated POST requests in IE 10 - In Response to NTLM Authentication RRS feed

  • Question

  • In Internet Explorer 10, the browser is incorrectly truncating HTTP POST requests and submitting unsolicited NTLM negotiate headers with a  HTTP Content-Length of Zero Bytes.  This results in HTTP POST parameters failing to be submitted to the server.

    Assume the following web application with a context root of:

    Secure cookies for this site are established at the context root of this application.

    To reproduce this issue, a secure session is established at a protection space deeper than the root context of the web app:

    After establishing a secure session with the web application, some client side artifacts are retrieved from a web proxy at a higher protection space:

    Subsequent HTTP POST requests to a deeper protection space will result in IE incorrectly attempting to pass an unsolicited NTLM negotiate header to the server side, and the HTTP POST request will be truncated with a Zero Content-Length header:

    The result is that the HTTP POST parameters submitted to the last URL will be lost.

    This is reproducible against IE6 and IE10.  It does not reproduce against IE8, or any non-Microsoft browser which all behave in a sane manner. 

    My Questions:

    Why is IE behaving this way?

    What can I do to make IE behave properly?  Please don't suggest that I change the entire structure of my company's website to overcome this kind of silly bug in IE.

    Is there a planned fix to correct this behavior back to the proper implementation observed in IE8?

    Additional details about this problem are documented by an IE Internals blogger at the following url:


    Sunday, June 29, 2014 6:30 PM

All replies

  • Hi Michael,

    have you investigated the remedies at the IE Internals blog.

    What might unexpectedly trigger the bodyless POST optimization? Most common cases are due to server configuration errors. For instance, if the user visits (without the trailing slash), the server might mistakenly return a 401 first, instead of immediately returning a 301 to /privateupload/. If this happens, the protection space will be considered to be the root folder*, causing all POSTs to any path anywhere on the server to trigger the bodyless POST optimization.

    A similar problem occurs when the user never directly visits a page within the root folder, but a page within a subfolder issued a request to the root that resulted in an authentication challenge. A common case is the download of FavIcon.ico, for instance.

    To avoid problems with the bodyless POST optimization, ensure that either all paths are configured to require authentication, or that only very specific subpaths require credentials and that all files within the protection space are configured to require authentication.

    The fiddler tool may help you...



    • Marked as answer by Karen HuModerator Tuesday, July 15, 2014 2:28 AM
    • Unmarked as answer by jmshaver Monday, September 22, 2014 10:53 PM
    Tuesday, July 1, 2014 1:34 AM
  • Hi Michael,

    thinking about this....

    MSIE browsers look for a favicon link tag when the source is parsed... If none is found it will fire a request to the domain root for favicon.ico

    I think the solution is to add a favicon file to each of your https folders and add the following to the <head> of each page.

    <link rel="shortcut icon" href="myicon.ico" />

    Note: that the href is relative so that the favicon is requested from the same https folder as the page, so you don't get any 'Mixed content' errors.

    you should also configure your server to serve .ico files as image/icon and not image/



    • Marked as answer by Karen HuModerator Tuesday, July 15, 2014 2:28 AM
    • Unmarked as answer by jmshaver Monday, September 22, 2014 10:50 PM
    Tuesday, July 1, 2014 2:57 AM
  • Yes, I have read that blog post in detail.  All of the comments from Microsoft on this issue suggest making intrusive changes to the web application side to work around this "optimization".  This is not an acceptable answer.  This is clearly a bug in IE.  Evidence to support that this is a bug is that the behavior within IE's own browsers is not consistent; IE6 and IE10 will reproduce this issue, IE7 and IE8 will not. 

    I don't understand your suggestion; "ensure all paths are configured to require authentication".  This is not a reasonable expectation for any normal web app.  Our application does require authentication on all paths. However, when the first authentication request goes through, a HTTP Session is established.  Any subsequent request to that domain will not and should not be re-authenticated.  IE making assumptions about the authentication requirements of a server side application is incorrect.  

    Further, even if i did re-challenge the browser for credentials on every path, regardless of whether a session is established or not, how would I handle the requirement to serve client side artifacts from a web proxy within that secure domain?  Am I expected to force my web proxy to require an NTLM header to serve up a CSS file?  That is just silly.

    You also suggested that my application might be incorrectly returning a 401.  I can assure you, that is not the case.  The flow is this:

    Perform a signon to the application and retrieve some client side artifacts required by the splash page 401 + www-negotiate response header browser provides a ntlm token, user is logged in, session is started 200 response code, no challenge from the server side

    Splash page is loaded; user submits a POST request POST request fails because IE truncates the request and attaches an NTLM negotiate header with Zero Byte content length.  This is an unsolicited negotiate header from IE.

    Honestly, it really irritates me when people suggest we should change our entire application structure to accommodate IE bugs or "features" that are completely outside of the HTTP spec. I understand RFC4559 states that a browser MAY initiate a request to a server which includes an unsolicited negotiate header, but it doesn't say anything about truncating the contents of that request. 

    No other browsers exhibit this behavior, and even the behavior within Microsoft's own product is not consistent.  It is insanely frustrating as a web developer trying to deal with all of IE's little nuances. 

    Is there anyway this can be turned off via a registry entry?  Is there any plan to fix this in a future release? 
    Monday, September 22, 2014 10:53 PM
  • It's been 2 years and this post is still relevant. I am equally frustrated with this. I hope someone at MS reads this and realizes how self-entitled they must be to assume they can play around with RFC spec.

    Matt g

    Friday, September 9, 2016 2:33 PM