On Wed, 28 Sep 2011 16:15:33 +0200, Jan Sievers wrote:
Hi,
I was recently updating squid from version v3.0.STABLE23 to 3.1.15
and noticed, that the handling of PUT-requests with "Expect:
100-continue" header changed.
While with version v3.0.STABLE23 the proxy wrote to the log file
1316481430.883 2303 192.168.0.1 TCP_MISS/200 314 PUT
http://www.example.com/services/submit.php? - DIRECT/192.0.2.1
text/html
what triggered the client to send a request shortly after:
1316481432.180 1294 192.168.0.1 TCP_MISS/200 314 PUT
http://www.example.com/services/submit.php? - DIRECT/192.0.2.1
text/html
Which look to me that the proxy has forwarded at least something to
the
origin server. I don't know if it really reported a 200 to the client
which sounds strange for a PUT-request having a "Expect:
100-continue".
Probably the client (using libcurl 7.16.1) just reached a timeout and
issued another PUT-request without the Expect-header and with a body.
Using version 3.1.15 the proxy wrote to the log file
1317091304.706 0 192.168.0.1 NONE/417 6181 PUT
http://www.example.com/services/submit.php? - NONE/- text/html
No other request comes hereafter. The client user reports the
application says "Error 417".
It seems the client does not repeat the POST-request without
"expectations".
On the other hand squid seems not to ask the origin server which is
HTTP/1.1 aware and sends a 417 on it own, which at least for a
HTTP/1.1
proxy would be wrong.
Or am I missing something?
Squid-3.1 is HTTP/1.1 on the side communicating with servers.
Can I do something about it?
In order of preference:
* report teh problem to teh client software developers. They have
failed to handle all the RFC 2616 requirements of chunked encoding. ie
to retry without HTTP/1.1 when 417 is received.
* ignore_expect_100
Is setting "ignore_expect_100 on" the right thing and without
side-effects?
It is there to resolve this problem if you wish to use it.
There are side effects. Squid now passes HTTP/1.1 to servers, relaying
the Expect: headers and discards the 100-continue if it comes back. This
could make the client wait a long timeout and die anyway.
Amos
