Why "Content-Length: 0" in POST requests?

Question

A customer sometimes sends POST requests with Content-Length: 0 when submitting a form (10 to over 40 fields).

We tested it with different browsers and from different locations but couldn't reproduce the error. The customer is using Internet Explorer 7 and a proxy.

We asked them to let their system administrator see into the problem from their side. Running some tests without the proxy, etc..

In the meantime (half a year later and still no answer) I'm curious if somebody else knows of similar problems with a Content-Length: 0 request. Maybe from inside some Windows network with a special proxy for big companies.

Is there a known problem with Internet Explorer 7? With a proxy system? The Windows network itself?

Google only showed something in the context of NTLM (and such) authentication, but we aren't using this in the web application. Maybe it's in the way the proxy operates in the customer's network with Windows logins? (I'm no Windows expert. Just guessing.)

I have no further information about the infrastructure.

Answer 1

Are you sure these requests are coming from a "customer"?

I've had this issue with bots before; they sometimes probe sites for "contact us" forms by sending blank POST requests based on the action URI in FORM tags they discover during crawling.

Answer 2

Are the form parameters put in the query string instead? Or are they actually provided as POST data, despite the 0 content length?

Is the Content-Type the usual application/x-www-form-urlencoded or multipart/form-data? Or some other weird type?

Answer 3

Perhaps he has a weird addon to his IE7?

Answer 4

Google also shows this as an IE (some versions, anyway) bug after an https connection hits the keepalive timeout and reconnects to the server. The solution seems to be configuring the server to not use keepalive for IE under https.

Answer 5

I suspect the proxy. My guess is that the browser actually doesn't send a Content-Length header, and that the proxy fills it in with the value it "sees": no value == 0.

Answer 6

Presence and possible values of the ContentLength header in HTTP are described in the HTTP ( I assume 1/1) RFC:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred

See also:

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

Maybe your message is carrying a Transfer-Encoding header?

Later edit: also please note "SHOULD" as used in the RFC is very important and not equivalent to "MUST":

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Ref: http://www.ietf.org/rfc/rfc2119.txt

Answer 7

Internet Explorer does not send form fields if they are posted from an authenticated site (NTLM) to a non-authenticated site (anonymous). This is a security feature (probably to prevent inadvertent/malicious information disclosure) and it has bitten me occasionally as well. However it is reproducible and works as designed.

This behavior occurs every time an HTTP POST is made from a NTLM authenticated (i.e. Intranet) page to a non-authenticated (i.e. Internet) page, or if the non-authenticated page is part of a frameset, where the frameset page is authenticated.

The work-around is either to use a GET request as the form method, or to make sure the non-authenticated page is opened in a fresh tab/window (favorite/link target) without a partly authenticated frameset. As soon as the authentication model for the whole window is consistent, IE will start to send form contents again.

Currently I can't find the Microsoft page describing the problem, but I'm sure that's what you are seeing. I'll look some more and post the link here if I find it.

Definitely related: http://www.websina.com/bugzero/kb/browser-ie.html

Possibly related: KB923155

Answer 8

This is a known problem for Internet explorer 6, but not for 7 that I know of. You can install this fix for the IE6 KB831167 fix.

You can read more about it here.

Some questions for you:

• Do you know which type of proxy?
• Do you know if there is an actual body sent in the request?
• Does it happen consistently every time? Or only sometimes?
• Is there any binary data sent in the request? Maybe the data starts with a \0 and the proxy has a bug with binary data.

Answer 9

There's a good chance the problem is that the proxy server in between implements HTTP 1.0.

In HTTP 1.0 you must use the Content-Length header field: (See section 10.4 here)

A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content.

The request going into the proxy is HTTP 1.1 and therefore does not need to use the Content-Length header field. The Content-Length header is usually used but not always. See the following excerpt from the HTTP 1.1 RFC S. 14.13.

Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4. Any Content-Length greater than or equal to zero is a valid value.

Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given.

So the proxy server does not see the Content-Length header, which it assumes is absolutely needed in HTTP 1.0 if there is a body. So it assumes 0 so that the request will eventually reach the server. Remember the proxy doesn't know the rules of the HTTP 1.1 spec, so it doesn't know how to handle the situation when there is no Content-Length header.

Are you 100% sure your request is specifying the Content-Length header? If it is using another means as defined in section 4.4 because it thinks the server is 1.1 (because it doesn't know about the 1.0 proxy in between) then you will have your described problem.

Perhaps you can use HTTP GET instead to bypass the problem.

Answer 10

We have a customer on our system with exactly the same problem. We've pin pointed it down to the proxy/firewall. Microsoft's IAS. It's stripping the POST body and sending content-length: 0. Not a lot we can do to work around however, and down want to use GET requests as this exposes usernames/passwords etc on the URL string. There's nearly 7,000 users on our system and only one with the problem... also only one using Microsoft IAS, so it has to be this.

Answer 11

Microsoft's hotfix for KB821814 can set Content-Length to 0:

The hotfix that this article describes implements a code change in Wininet.dll to:

• Detect the RESET condition on a POST request.
• Save the data that is to be posted.
• Retry the POST request with the content length set to 0. This prevents the reset from occurring and permits the authentication process to complete.
• Retry the original POST request.

Answer 12

@stesch

Hi, did you solve the problem? I'm getting the same error and I think I can exclude all the possible causes that were suggested in the past comments.

Thanks in advance, Andrea

Answer 13

This is easy to reproduce with MS-IE and an NTLM authentication filter on server side. I have the same issue with JCIFS (1.2.), struts 1. and MS-IE 6/7 on XP-SP2. It was finally fixed. There are several workarounds to make it up.

1. change form method from POST (struts default setting) to GET. For most pages with small sized forms, it works well. Unfortunately i have possibly more than 50 records to send in HTTP stream back to server side. IE has a GET URL limit 2038 Bytes (not parameter length, but the whole URL length). So this is a quick workaround but not applicable for me.

2. send a GET before POST action executing. This was recommended in MS-KB. My project has many legacy procedures and i would not take the risk at the right time. I have never tried this because it still needs some extra authentication processing when GET is received by filter layer based on my understanding from MS-KB and I would not like to change the behavior with other browsers, e.g. Firefox, Opera.

3. detecting if POST was sent with zero content-length (you may get it from header properties hash structure with your framework). If so, trigger an NTLM authentication cycle by get challenge code from DC or cache and expect an NTLM response. When the NTLM type2 msg is received and the session is still valid, you don't really need to authenticate the user but just forward it to the expected action if POST content-length is not zero. BTW, this would increase the network traffics. So check your cache life time setting and SMB session soTimeOut configuration before applying the change plz. Or, more simple, you may just send a 401-unauthorized status to MS-IE and the browser shall send back POST request with data in reply.

4. MS-KB has provided a hot-fix with KB-923155 (I could not post more than one link because of a low reputation number :{ ) , but it seems not working. Would someone post a workable hot-fix here? Thanks :) Here is a link for reference, http://www.websina.com/bugzero/kb/browser-ie.html

Answer 14

Ysth, There are no data caught in network traffic. You may try to check the traffic with ieHTTPHeader plugin or Wireshark tool :)

Answer 15

So glad I found this, having the exact same problem with customers of ours. We were debugging this by sending out all Server.Variables via email to us and I noticed this only seemed to happen with IE7 and now I can see Microsoft ISA:

Via: 1.1 TTSXXXX-ISA1 Content-Length: 0 Content-Type: application/x-www-form-urlencoded

Answer 16

If the user is going through an ISA proxy that uses NTLM authentication, then it sounds like this issue, which has a solution provided (a patch to the ISA proxy)

http://support.microsoft.com/kb/942638
POST requests that do not have a POST body may be sent to a Web server that is published in ISA Server 2006