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

[Steve Hill]

On 11/07/18 17:16, Amos Jeffries wrote:

> But the chunking here means end of *ICAP* message. Not end of HTTP message.
> 
> The ICAP server should use the HTTP message headers to know the HTTP
> message sizes when possible. eg Content-Length and Content-Range values
> indicate whether the HTTP delivered is complete or not.

Indeed, but many responses omit these headers, and it is therefore often 
not possible for the ICAP server to know whether it has seen the whole 
content.  Even HTTP responses that don't use a chunked transfer-encoding 
can omit these headers so long as the connection is closed at the end of 
the response.

I'm certainly not suggesting that Squid is "wrong" in the technical 
sense - it does follow the ICAP protocol specification.  Unfortunately 
the ICAP specification doesn't address aborted HTTP requests at all, so 
I'm wondering what a sensible way of addressing this is.

> If there *is* an ICAP signal then Squid should of course use that in all
> cases of early halted HTTP content. Even when it uses the last-chunk to
> say where the ICAP message ends and the next may begin.

As far as I'm aware, there is no ICAP signal for an aborted HTTP request 
- the spec does not address this at all.  Could be something for an 
updated ICAP RFC in the future though. :)

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