Missing POST Parameters with proxy servers

we encounter some strange behaviour with our web application. Some POST requests do not have any http body, when they should. content-length is 0. There are no post parameters at all. We traced the network traffic at our loadbalancer and we see that we do not get any request body with some of our POST requests.

All broken POST requests have in common that they arrive via a proxy server.

We already found this question on SO: Why "Content-Length: 0" in POST requests?

We are now using a frame escape javascript routine and it helps a bit. It seems that error rate drops. But we still have POST requests with no data which should never happen in our webapp. These requests does not come from hackers or alike.

Often we saw webwasher as a proxy. But most of the time we do not see which proxy is used.

In this PDF we saw a comment about missing POST parameters with webwasher

WebWasher - Transparent Authentication Guide

Notes on Some Pitfalls

Note that there are some pitfalls that must be taken into account when setting up transparent authentication:

POST requests 开发者_运维知识库will fail if the ICAP server sends an redirect to the authentication server. This affects, however, only the renewal of the mapping since for the browser the request was successful, and the POST body will not be sent again after the final redirect.

We would like to know if there is some workaround other than using only GET instead of POST. We would also here if other sites had problems with missing POST data and which conclusion they made.

Are there any other reasons why POST data is not sent?

I've had issues with Microsoft's proxy server not playing well with web requests.

I've had to resort to forcing HTTP/1.0 and setting the KeepAlive property to false.

There's something about the way NTLM authentication works that causes the body to be sent sporadically.

I've added this to many of my web requests

protected override WebRequest GetWebRequest(Uri uri)
{
    HttpWebRequest webRequest = (HttpWebRequest) base.GetWebRequest(uri);

    webRequest.KeepAlive = false;
    webRequest.ProtocolVersion=HttpVersion.Version10;
    return webRequest;
}

Hope this helps!

Not really an answer, I guess, but I arrived here because we had a similar problem. Initially, we thought it was due to the clients being mobile, as this was a common theme, but we have now realised that the common denominator is proxies.

We now raise a http 400 when it happens.

Here are a few of the proxies, we've had issues with. Posting them to lead the casual googler here:

• 1.1 ACISA02S, 1.1 abc:3328 (squid/2.6.STABLE21)
• 1.1 ipcop00.cat.local:8000 (squid/2.6.STABLE21)
• 1.1 PRXTGLSRV01
• 1.1 ISA

No ones which conform to the spec:

Some HTTP methods MUST cause a cache to invalidate an entity. ... POST

(the HTTP/1.0 spec states 'Applications must not cache responses to a POST request').

But there are is a LOT of badly written code out there.

What headers do you include in replies to POSTs on the URLs?