Truncate too-long HTTP response bodies to match their Content-Length header.
Sometimes a broken server sends more than Content-Length bytes in the
response. For example, a 302 redirect message with "Content-Length: 0"
header may include an HTML body. Squid used to send "everything" it read
to the client, even if it read more than the Content-Length bytes. That
may have helped in some cases, but I think we should be more
conservative when dealing with broken servers to combat message
smuggling attacks and other bad side-effects for clients.
We now do not forward more than the advertised content length and
declare the connection with a broken server non-persistent.
Chunked responses (that Squid should not receive and that must not have
a Content-Length header) are not truncated because RFC 2616 says we MUST
ignore their Content-Length header.
TODO: simply truncating read content would not work for pipelined
responses. We should preserve extra content for the next transaction on
a pconn.
---------------
The attached patch is against Squid 3.0 and has been tested in
production. More testing is welcomed. I will port to trunk if needed if
the change is accepted.
Thank you,
Alex.
This archive was generated by hypermail 2.2.0 : Mon Jun 29 2009 - 12:00:05 MDT