]> git.ipfire.org Git - thirdparty/squid.git/commit
Do not chunk responses carrying a Content-Range header.
authorAlex Rousskov <rousskov@measurement-factory.com>
Mon, 10 Sep 2012 22:38:09 +0000 (16:38 -0600)
committerAlex Rousskov <rousskov@measurement-factory.com>
Mon, 10 Sep 2012 22:38:09 +0000 (16:38 -0600)
commit4a7eb77ede09ee73286cb12b0c789364a90087fb
tree6143390caaca9921d2082a1d376c735dc0484a8b
parent86660d64fb95f949de9820e44233a273e97ebf91
Do not chunk responses carrying a Content-Range header.

When Squid forwards a response with a Content-Range header,
ClientSocketContext::socketState() detects the end of the response range(s)
and returns STREAM_*COMPLETE to ClientSocketContext::writeComplete().
The latter thinks that the writing of the response to the client must be
over and calls keepaliveNextRequest() instead of writing the last-chunk
(if any). If the to-client response was chunked, the client gets stuck
waiting for that missing last-chunk.

The multipart Range request case was already excluded from chunking (or it
would probably suffer from the same problem). With this change, no
Content-Range responses will be chunked.

N.B. Some servers send Content-Range responses to basic GET requests
without a Range header, so the problem affects more than just Range requests.

TODO: A proper fix would be to rewrite ClientSocketContext::writeComplete()
and other code so that it does not mix internal ClientStream completion with
[possibly chunk-encoded] writing completion. This should probably be done
along with fixing ClientSocketContext::socketState() and other state-checking
code to ignore to-client persistence (flags.proxy_keepalive), which is not
related to the internal ClientStream state.
src/client_side_reply.cc