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. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
