[squid-dev] Terminating ICAP requests for aborted HTTP requests
steve at opendium.com
Wed Jul 11 13:54:08 UTC 2018
The ICAP spec doesn't make any comment on what a proxy should do if an
HTTP client aborts part way through a rewritten response.
i.e. the HTTP client had made a request which has been forwarded onto
the web server, the web server has started responding, Squid is sending
the response body to the RESPMOD ICAP service and is forwarding the
modified body to the client. Part way through the download, the client
(or maybe even the server?) drops the TCP connection. What should Squid do?
My testing shows that the response body that is being sent to the ICAP
server is cut short by Squid, by terminating it with a zero-length
chunk. This is also how fully successful ICAP requests are terminated
and as the request has been terminated "normally", the ICAP connection
can then be used for a new, unrelated, ICAP request.
But what if the ICAP server is doing some caching? It has no way to
know whether it has seen the complete object, or if the object has been
So, my question is: is Squid doing the right thing here, and if so how
should the ICAP server know whether or not it has seen the complete
object from the web server? If the web server includes a Content-Length
header then that could be compared to the final length of the body that
the ICAP server has received, but this header is not mandatory and many
requests do not include it.
The solutions that spring to my mind are:
1. Squid could just terminate the ICAP connection if the HTTP request is
aborted. The ICAP server would then be able to see that the connection
was chopped before it received the terminating zero length chunk. There
may be a performance impact since Squid would need to establish a new
connection for the next request.
2. Squid could add an "aborted" extension to the terminating chunk
header. i.e. in the same way that "0; ieof" is allowed, "0; aborted"
could be used. However, this is not part of the ICAP RFC and would
therefore be non-standard behaviour that could break clients that have
less robust parsers.
- Steve Hill
Opendium Online Safety / Web Filtering http://www.opendium.com
Enquiries: sales at opendium.com +44-1792-824568
Support: support at opendium.com +44-1792-825748
Opendium Limited is a company registered in England and Wales.
Company No. 5465437
Highfield House, 1 Brue Close, Bruton, Somerset, BA10 0HY, England.
More information about the squid-dev