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

Question

The client sometimes sends POST requests with Content-Length: 0 when submitting the form (from 10 to more than 40 fields).

We tested it with different browsers and from different places, but could not reproduce the error. The client uses Internet Explorer 7 and proxies.

We asked them to let their system administrator see the problem on their part. Performing some tests without a proxy, etc.

In the meantime (six months later and there is still no answer), I am curious if anyone knows about similar problems with the Content-Length: 0 request. Perhaps from within some Windows network with a special proxy for large companies.

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

Google just showed something in the context of NTLM (and such) authentication, but we do not use it in a web application. Maybe this is how the proxy works in a network of clients with Windows logins? (I'm not a Windows expert, just guessing.)

I do not have additional infrastructure information.

UPDATE: In December 2010, this could be reported to one administrator, including. links from the answers here. The contact was caused by another problem caused by the proxy. Since then no reviews. And error messages still exist. I laugh so as not to cry.

UPDATE 2: This issue has existed since mid-2008. Every few months, the client is annoyed and wants him to be fixed as soon as possible. We send them all the old emails again and ask them to contact their administrators to either fix or perform additional tests. In December 2010, we were able to send some information to one administrator. No reviews. The problem is not fixed, and we do not know if they even tried. And in May 2011, the client writes again and wants this to be fixed. The same person who has all the information since 2008.

Thanks for all the answers. You have helped many people, as I see from some of the comments here. It is a pity that the real world is grotesque for me.

UPDATE 3: May 2012, and I was wondering why we did not receive another request to fix this (see UPDATE 2). I looked at the error log that reports this single error every time it happens (about 15 per day). This ended the end of January 2012. No one said anything. They must have done something with their network. It's all right now. From the summer of 2008 to January 2012. Too bad, I can’t tell you what they did.

UPDATE 4: September 2015. The website had to collect some data and deliver it to the client’s main site. There was an API with an account. Whenever a problem arose, they contacted us, even if the problem was clearly on the other side. Within a few weeks we cannot send their data. Account is no longer available. They had a reboot, and I can no longer find the pages that used the data from our site. The error report did not respond and no one complained. I think they just finished this project.

UPDATE 5: March 2017. The API stops working in the summer of 2015. The client seems to continue to pay for the site and is still accessing it in February 2017. I assume they use this as an archive. They no longer create or update data, so this error will probably not appear after the mysterious fix in January 2012. But that would be another problem. I'm leaving.

Answer 1

Internet Explorer does not send form fields if they are sent from an authenticated site (NTLM) to a site without authentication (anonymous).

This is a feature for response situations (NTLM or Kerberos-protected websites), where IE can expect the first POST request to immediately lead to HTTP authentication 401 Required response (which includes the call), and only the second POST request ( which includes answering the call) will actually be accepted. In these situations, IE does not load, possibly a large request object with the first request for performance reasons. Thanks to EricLaw for posting this piece of information in the comments.

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

A workaround is to either use a GET request as a form method, or to make sure that a page that does not authenticate opens in a new tab / window (target object / link) without a partially authenticated set of frames. Once the authentication model for the entire window has been agreed, IE will again begin to submit the contents of the form.

---

• Definitely related: http://www.websina.com/bugzero/kb/browser-ie.html
• Perhaps related: KB923155
• Full explanation : IEInternals Blog - Request Authentication and Queue Duration

Answer 2

This is easy to reproduce using MS-IE and an NTLM server-side authentication filter. I have the same problem with JCIFS (1.2.), Struts 1., and MS-IE 6/7 on XP-SP2. Finally it has been fixed. There are several ways to solve the problem.

• Change the form method from POST (default setting) to GET. For most small form pages, it works well. Unfortunately, I have perhaps more than 50 entries for sending an HTTP stream back to the server. IE has a GET limit of 2038 bytes (not the length of the parameter, but the entire length of the URL). So this is a quick workaround, but not applicable for me.

• send a GET before performing the POST action. This has been recommended in MS-KB. My project has a lot of outdated procedures, and I would not risk it at the right time. I have never tried this because additional authentication processing is still required when the GET is obtained by the filter layer based on my understanding from MS-KB, and I would not want to change the behavior with other browsers, for example. Firefox, Opera.

• detecting if the POST was sent with zero content length (you can get it from the hash structure of the header properties using your structure). If so, start the NTLM authentication loop to get the calling code from the DC or cache and wait for an NTLM response. When an NTLM type2 msg message is received and the session is still valid, you do not need to authenticate the user, but simply redirect it to the expected action if the length of the POST content is not zero. By the way, this will increase network traffic. Therefore, before setting the plz change, check the cache lifetime setting and the soTimeOut SMT session setting. Or, more simply, you can simply send 401 unauthorized status to MS-IE, and the browser will send back a POST request with the data in response.

• MS-KB provided a fix with KB-923155 (I could not post multiple links due to the low reputation number: {), but it does not seem to work. Will someone post workable fixes? Thanks :) Here is a link for reference, http://www.websina.com/bugzero/kb/browser-ie.html

Answer 3

We have a client in our system with exactly the same problem. We connected it to the proxy server. Microsoft IAS It robs the POST body and sends the content length: 0. Not so much that we can do to work, but also want to use GET requests, as this provides usernames / passwords, etc. In the URL bar. There are almost 7,000 users in our system, and only one problem ... and only one of them uses Microsoft IAS, so it should be like that.

Answer 4

There is a good chance that the proxy between them implements HTTP 1.0.

In HTTP 1.0, you should use the Content-Length: header field ( see section 10.4 here )

Allowed content length is required for all HTTP / 1.0 POST requests. The HTTP / 1.0 server should respond 400 (bad request) if it cannot determine the length of the request for the message content.

The request sent to the proxy server is HTTP 1.1 and therefore you do not need to use the Content-Length header field. The Content-Length header is usually used, but not always. See the following excerpt from HTTP 1.1 RFC S. 14.13 .

Applications SHOULD use this field to indicate the transmission length of the message body, unless 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 message body length if Content-Length is not specified.

Thus, the proxy server does not see the Content-Length header, which it assumes is absolutely necessary in HTTP 1.0, if there is a body. Therefore, it takes 0, so the request will eventually reach the server. Remember that the proxy does not know the rules of the HTTP 1.1 specification, so it does not know how to handle a situation when there is no Content-Length header.

Are you 100% sure your request indicates a Content-Length header? If he uses another tool, as defined in section 4.4, because he considers the server to be 1.1 (since he does not know about proxy 1.0 between them), then you will have the problem you described.

Perhaps you can use HTTP GET instead of workaround.

Answer 5

This is a known issue for Internet explorer 6, but not for 7, which I know of. You can install this hotfix to fix IE6 KB831167 .

You can read about it here .

Some questions for you:

• Do you know what type of proxy server?
• Do you know if the body is really sent in the request?
• Does this always happen every time? Or just sometimes?
• Is there any binary data in the request? Perhaps the data starts with \ 0, and the proxy server has an error with binary data.

Answer 6

If a user uses an ISA proxy that uses NTLM authentication, then this sounds like this problem that has a solution (patch for ISA proxy)

http://support.microsoft.com/kb/942638
POST requests that do not have a POST body can be sent to the web server published to ISA Server 2006

Answer 7

Are you sure these requests come from the "customer"?

I had a problem with bots; they sometimes check sites for Contact Us forms by sending empty POST requests based on the action URI in the FORM tags that they detect during the crawl.

Answer 8

The 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 MUST be sent whenever the length of the message can be determined before transmission

See also:

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

Perhaps your message has a Transfer-Encoding header?

Further edit: also note that “SHOULD” as used in the RFC is very important and not equivalent to “MUST”:

3. SHOULD This word or the adjective “RECOMMENDED” means that there may be reasonable reasons in certain circumstances to ignore a specific paragraph, but all consequences should be understood and carefully weighed before choosing another course. Link: http://www.ietf.org/rfc/rfc2119.txt

Answer 9

Google also shows this as an IE error (some versions, anyway) after the https connection falls into the keepalive timeout and reconnects to the server. The solution seems to configure the server to not use keepalive for IE under https.

Answer 10

Microsoft hotfix for KB821814 may set Content-Length to 0:

The hotfix described in this article implemented a code change in Wininet.dll:

• Finding a RESET condition in a POST request.
• Save the data to be published.
• Repeat the POST request with a content length of 0. This prevents a RESET from occurring and allows the authentication process to complete.
• Repeat the initial POST request.

Answer 11

We had a client who used the same site in anonymous mode and in NTLM mode (on different ports). We found that in our case, 401 was associated with the Riverbed Steelhead application used to optimize http. The first signal to indicate this direction was the X-RBT-Optimized-By header. The problem was the function of the Gratuitous 401:

This function can be used for each request as well as for each authentication connection, but it is most effective when using authentication with a request. With authentication by request, each request must be authenticated on the server before the server will serve the object to the client. However, most browsers do not cache the server response requiring authentication, and therefore, it will be for each GET request. With Gratuitous 401, the client side of the Steelhead appliance will cache the server’s response and when the client sends a GET request without any authentication headers, it will respond locally with a -401 Unauthorized‖ message and, therefore, save both ways. Please note that the HTTP module is not involved in the actual authentication. What the HTTP module does is tell the client that the server requires authentication, without requiring it to squander one trip round trip.

Answer 12

curl sends PUT/POST requests with Content-Length: 0 when configured to use an HTTP proxy. This is a trick to overcome the required buffering in case of the first unauthorized PUT/POST to the proxy server. In the case of GET/HEAD requests, curl simply repeats the request. The scheme for PUT/POST looks like this:

• Send the first PUT/POST from Content-Length to 0.

• Get an answer. An HTTP 407 status code means we must use an authorization proxy. Prepare proxy authentication headers for sending the request.

• Send the request again with the headers filled in for proxy authentication and real data on POST / PUT.

Answer 13

I also had a problem where requests from IE 11 client browser had Content-Length: 0 and did not include the expected POST content. When a client used Firefox or Chrome, the expected content was included in the request.

I decided that the client used the HTTP URL instead of the HTTPS URL (e.g. http://... , not https://... ) and our application uses HSTS. It seems that in IE 11 there may be an error that when updating a request for HTTPS due to HSTS, the contents of the request are lost.

Getting the client to adjust the https://... URL led to the content being included in the POST request and resolving the problem.

I have not yet investigated whether this is really a bug in IE 11 at this point.