[squid-dev] Terminating ICAP requests for aborted HTTP requests

[Steve Hill]

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 
cut short.

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
    Technical Director
    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.