Geek Answers Handbook

Missing POST settings with proxies

we encounter some weird behavior with our web application. Some POST requests do not have any http website when they should. the content length is 0. There are no message parameters. We tracked network traffic on our balancer, and we see that we are not receiving any request with some of our POST requests.

All broken POST requests have one thing in common that they come through a proxy server.

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

Now we are using the javascript escape code routine, and that helps a bit. It seems that the error rate is falling. But we still have POST requests without data, which should never happen in our webapp. These requests do not come from hackers or the like.

Often we saw webwasher as a proxy. But most of the time we don’t see which proxy server is being used.

In this PDF we saw a comment about missing POST options using webwasher

WebWasher - Guide to Transparent Authentication

Some bugs

Please note that when setting up transparent authentication, some errors must be considered:

POST requests will fail if the ICAP server sends a redirect to the authentication server. However, this only affects the display update, since the request was successful for the browser and the POST body will not be sent again after the final redirect.

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

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

+6
proxy
source share
3 answers

I had problems with a Microsoft proxy that does not work well with web requests.

I had to resort to forced HTTP / 1.0 and set the KeepAlive property to false.

There is something about how NTLM authentication works, which causes frequent body messages.

I have 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!

+2
source share

This is actually not the answer, but I came here because we had a similar problem. Initially, we thought that this was due to the fact that customers are mobile, as it was a common topic, but we now realized that a common denominator is a proxy.

Now we raise http 400 when this happens.

Here are some proxies we had problems with. Passing them to lead a random 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
0
source share

There are no those matching spec :

Some HTTP methods MUST cause the cache to deprive you of the right to invalidate the object .... POST

(terms of the HTTP / 1.0 specification "Applications should not cache responses to a POST request").

But there is a lot of badly written code.

What headers do you include in POST responses on URLs?

-1
source share

More articles:


All Articles