J
Joe Linux
Hi,
This is not a question : this is a possible answer on a problem you may
have.
I you use httpclient and you set the content-length header incorrectly
while you post an application/x-www-form-urlencoded form (it's the
default), httpclient won't fix it for you - there are good reasons for
this.
In the case you post, say, 100 bytes
(variable=value&variable2=value2&...) and set the content-length header
to 101, the server will wait untill it reach a timetout for the 101st
byte.
It may seem obvious but in the case i saw, for a reverse proxy, a
particuliar client post a value and urlencoded the dash "-" as %2d -
The reverse proxy "silently" urldecoded this as "-", and so modified
the length of the posted string without modifying the content-length
which it forwarwed to the proxyied servers untouched. And these one
blocked, waiting for 2 other bytes that never came.
Hope this helps someone...
Denis Valdenaire
This is not a question : this is a possible answer on a problem you may
have.
I you use httpclient and you set the content-length header incorrectly
while you post an application/x-www-form-urlencoded form (it's the
default), httpclient won't fix it for you - there are good reasons for
this.
In the case you post, say, 100 bytes
(variable=value&variable2=value2&...) and set the content-length header
to 101, the server will wait untill it reach a timetout for the 101st
byte.
It may seem obvious but in the case i saw, for a reverse proxy, a
particuliar client post a value and urlencoded the dash "-" as %2d -
The reverse proxy "silently" urldecoded this as "-", and so modified
the length of the posted string without modifying the content-length
which it forwarwed to the proxyied servers untouched. And these one
blocked, waiting for 2 other bytes that never came.
Hope this helps someone...
Denis Valdenaire