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

[Amos Jeffries]

On 12/07/18 03:46, Alex Rousskov wrote:
> On 07/11/2018 07:54 AM, Steve Hill wrote:
> 
>> 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?
> 
> As far as ICAP is concerned, Squid should give the service everything
> Squid has. Whether Squid continues to download the object is subject to
> various factors such as object cachability and quick_abort_pct settings.
> After giving everything, Squid should indicate a premature message
> termination (as discussed below).
> 
> 
>> 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.
> 
> Using last-chunk for aborted body termination is a bug. If Squid
> terminates the body, it should not use the standard last-chunk. Like you
> suggested below, Squid should either (half-)close the connection or
> negotiate the use of a chunk extension, both indicating a premature body
> termination.

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.

HTTP Transfer-Encoding messages are a problem though. In absence of a
proper ICAP signal we should probably abort the ICAP connection at the
end of what Squid has (or intends to deliver, in the case the server
connection is also being dropped rather than response absorbed).

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.

Amos