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
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.
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:
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
I also had a problem where requests from a customer's IE 11 browser had Content-Length: 0
and did not include the expected POST content. When the customer used Firefox, or Chrome the expected content was included in the request.
I worked out the cause was the customer was using a HTTP URL instead of a HTTPS URL (e.g. http://...
, not https://...
) and our application uses HSTS. It seems there might be a bug in IE 11 that when a request gets upgraded to HTTPS due to HSTS the request content gets lost.
Getting the customer to correct the URL to https://...
resulted in the content being included in the POST request and resolved the problem.
I haven't investigated whether it is actually a bug in IE 11 any further at this stage.
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.
curl
sends PUT/POST
requests with Content-Length: 0
when configured to use HTTP proxy. It's trick to overcome required buffering in case of first unauthorized PUT/POST
request to proxy. In case of GET/HEAD
requests curl
simply repeats the query. The scheme for PUT/POST
is like:
Send first PUT/POST
request with Content-Length
set to 0.
Get answer. HTTP status code of 407 means we have to use proxy authorization. Prepare headers for proxy authentication for send request.
Send request again with filled headers for proxy authentication and real data to POST/PUT.