[squid-users] What is the proper way to close an ICAP transaction?

[Alex Rousskov]

On 11/27/19 1:42 PM, Felipe Arturo Polanco wrote:
> Can you describe the process of option 2?
> 
> Terminate Squid-to-client transmission while indicating (to that same
> client) that the HTTP response body was cut short (i.e. that the
> delivery of the response was aborted). 

For HTTP responses where the body size is determined by the
Content-Length header, this option is already supported by the ICAP
protocol: The ICAP service can send the last-chunk at any time after
sending the HTTP header. A last-chunk sent before the last response body
byte indicates a truncated response. I have not tested Squid support for
this use case, but either Squid already closes the TCP client-to-Squid
connection after delivering the already trickled data, or Squid can be
modified to do that.

For all the other HTTP responses (including chunked), an ICAP extension
would be required to trigger the desired behavior in Squid. That ICAP
extension can be implemented as a chunk extension, similar to the
"use-original-body" chunk extension defined in ICAP 206 Partial Content
responses[1].

[1]
http://www.icap-forum.org/documents/specification/draft-icap-ext-partial-content-07.txt

I would consider reusing the "ieof" spelling for this new extension
because the semantics of this new ICAP extension is equivalent to the
standard ieof semantics (only their use cases/scope differ). Support for
this "ieof response" extension would need to be signaled by ICAP clients
via the Allow header, similar to how support for ICAP 206 Partial
Content responses is signaled in [1].

Squid will need to be modified to honor response ieof by closing the
corresponding client-to-Squid TCP connection. With a bit more effort,
the ieof response extension can be adjusted to also signal that Squid
does not need to finish sending any buffered response data, but that
enhancement is optional.


If ieof response extension is supported, then there is no need to treat
"HTTP responses where the body size is determined by the Content-Length
header" (discussed as a special use case in the beginning of this email)
specially -- the ICAP service should use ieof for all truncated
responses. I documented that special use case because you do not need
ieof response support if all blocked responses in your use case fall
into that "body size is determined by the Content-Length header"
category; you may still need to modify Squid to abort the TCP
client-to-Squid connection though.


Quality pull requests adding support for the ieof response extension to
Squid (or their sponsorships) are welcomed. Same for fixing Squid
behavior when reacting to a truncated embedded HTTP response (if such a
fix is needed).

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F


HTH,

Alex.


> What TCP Flag or ICAP header should the ICAP server send in order to
> inform connection aborted?? 
> 
> On Wed, Nov 27, 2019 at 12:44 PM Alex Rousskov wrote:
> 
>     On 11/27/19 11:01 AM, Felipe Arturo Polanco wrote:
> 
>     > How can we then terminate an ICAP 200 OK transaction to squid without
>     > sending the complete body back to it? We don't want squid to mark an
>     > ICAP failure on us if we just close the TCP connection.
> 
>     To properly answer your question, I have to come back to the question I
>     asked earlier: What do you want Squid to do when your ICAP service finds
>     a virus after trickling a few virgin HTTP body bytes to the HTTP client?
> 
>     The "we want Squid to send an HTTP 307 redirect to the client" desire
>     you responded with earlier was ruled impossible to satisfy in your
>     trickling environment. A few realistic options remain though, including:
> 
>     1. Terminate Squid-to-client transmission as if the whole virgin HTTP
>     response body was sent to the client.
> 
>     2. Terminate Squid-to-client transmission while indicating (to that same
>     client) that the HTTP response body was cut short (i.e. that the
>     delivery of the response was aborted).
> 
>     3. #2 plus annotate the transaction specially in Squid access.log and/or
>     detect this special outcome using Squid ACLs.
> 
>     Alex.
>