<div dir="ltr">Thanks for that Alex.<div><br></div><div>I do have another related question regarding Squid 206 handling.</div><div><br></div><div>I have a RESPMOD icap server that supports Allow:206 in the OPTIONS response.</div><div><br></div><div>I can see that for html webpages, squid sends Allow: 204, 206, trailers in RESPMOD requests, and my server can handle that fine.</div><div>But for files, specifically for zip files, squid sends Allow: trailers , showing no support for 206. Even if I reply with a 206, I get TCP reset and connection is closed.</div><div><br></div><div>Do you know why squid doesn't Allow 206 for files?</div><div>============================</div><div>Here is my configured OPTIONS response.</div><div>ICAP/1.0 200 OK<br>Methods: RESPMOD<br>Service: PyICAP Server 1.0<br>Preview: 0<br>Transfer-Complete: *<br>Max-Connections: 100<br>Options-TTL: 3600<br>Allow: 206<br>ISTag: "CmLYfciETxyLwZW3XYsPwJdCXvVehd"<br>Date: b'Mon', 16 b'Sep' 2019 20:50:52 GMT<br>Server: BaseICAP/1.0 Python/3.7.3<br></div><div><br></div><div>==================================================</div><div><br></div><div>And here is the RESPMOD request.</div><div>RESPMOD icap://<a href="http://127.0.0.1:13440/example">127.0.0.1:13440/example</a> ICAP/1.0<br>Host: <a href="http://127.0.0.1:13440">127.0.0.1:13440</a><br>Date: Mon, 16 Sep 2019 20:51:00 GMT<br>Encapsulated: req-hdr=0, res-hdr=337, res-body=579<br><span style="background-color:rgb(255,255,0)">Allow: trailers</span><br>X-Client-IP: 192.168.0.6<br><br>GET <a href="http://203.0.113.1/file.zip">http://203.0.113.1/file.zip</a> HTTP/1.1<br>User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0<br>Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8<br>Accept-Language: en-US,en;q=0.5<br>Accept-Encoding: gzip, deflate<br>DNT: 1<br>Upgrade-Insecure-Requests: 1<br>Host: 203.0.113.1<br><br>HTTP/1.1 200 OK<br>Date: Mon, 16 Sep 2019 20:51:00 GMT<br>Server: Apache/2.4.6 (CentOS)<br>Last-Modified: Thu, 29 Aug 2019 13:54:58 GMT<br>ETag: "989680-59141d9f0557a"<br>Accept-Ranges: bytes<br>Content-Length: 10000000<br>Content-Type: application/zip<br><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 3:54 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/16/19 2:58 PM, Felipe Arturo Polanco wrote:<br>
<br>
> In our case we don't need to modify the initial 10MB, just scan it for<br>
> virus and if found, send a reset back to squid to not transmit the file.<br>
<br>
Yes, my original response was based on that assumption.<br>
<br>
In summary, you can ask Squid to own the 10MB prefix (i.e. do a huge<br>
ICAP Preview) or you can ask the ICAP server to own the 10MB prefix<br>
(i.e. extend ICAP 206). The choice balances various trade-offs,<br>
including different overheads and different risks related to Squid<br>
development associated with each option. Pick your poison :-).<br>
<br>
Alex.<br>
<br>
<br>
> On Mon, Sep 16, 2019 at 11:54 AM Alex Rousskov wrote:<br>
> <br>
>     On 9/16/19 10:37 AM, Felipe Arturo Polanco wrote:<br>
> <br>
>     > We would like to add some logic to our custom made ICAP server, one of<br>
>     > these logics is to analyze up to 10MB of data of a given file and<br>
>     if the<br>
>     > file is larger than that, squid should not keep sending it to icap,<br>
>     > basically, a 204 message should be returned.<br>
> <br>
>     > squid has a cap of 64K of preview size that limit us in the aspect.<br>
> <br>
>     True.<br>
> <br>
> <br>
>     > Is there a way to extend this limit? Modifying the source code<br>
>     perhaps?<br>
> <br>
>     Yes, of course.<br>
> <br>
> <br>
>     > If so, what are the disadvantages of doing so?<br>
> <br>
>     Simply increasing BodyPipe::MaxCapacity might open you up to<br>
>     difficult-to-find vulnerabilities where some old Squid code still<br>
>     assumes that the buffers are limited by 64KB and crashes/asserts when<br>
>     that assumption becomes false. FWIW, I have not audited all<br>
>     BodyPipe-related code and do not know whether such bad code exists<br>
>     today.<br>
> <br>
>     Increasing BodyPipe::MaxCapacity will also increase Squid RAM<br>
>     requirements if your Squid receives requests (and/or ICAP<br>
>     REQMOD-generated HTTP responses) that exceed 64KB body limit. I am not<br>
>     sure about regular responses -- their accumulation is limited by<br>
>     other/independent restrictions.<br>
> <br>
> <br>
>     > Would it require more RAM per response<br>
> <br>
>     [You should worry about "per message" accumulation -- requests will use<br>
>     the same limit, even if you do not have REQMOD services.]<br>
> <br>
>     Yes, but only for messages that exceed the limit.<br>
> <br>
> <br>
>     > or is RAM dynamically allocated as the file is being received?<br>
> <br>
>     Yes, the RAM in question is allocated dynamically on "as needed" basis.<br>
> <br>
>     YMMV, but Squid may slow down a lot while dealing with the associated<br>
>     reallocations because of the too-small 64KB increment used for each such<br>
>     reallocation.<br>
> <br>
> <br>
>     An alternative solution to consider here is extending ICAP features to<br>
>     allow for splicing of the 10MB prefix (analyzed _and_ returned back by<br>
>     the ICAP server) and the remaining virgin response suffix (paused<br>
>     without excessive accumulation on the Squid side). This would be similar<br>
>     to the existing ICAP 206 use-original-body="10MB" feature[1], but would<br>
>     require additional negotiation and changes to disable storage of the<br>
>     10MB prefix on the Squid side.<br>
> <br>
>     This alternative can be implemented without worrying about hidden 64KB<br>
>     body buffer assumptions, but the implementation will not be trivial.<br>
> <br>
>     [1]<br>
>     <a href="http://www.icap-forum.org/documents/specification/draft-icap-ext-partial-content-07.txt" rel="noreferrer" target="_blank">http://www.icap-forum.org/documents/specification/draft-icap-ext-partial-content-07.txt</a><br>
> <br>
> <br>
>     HTH,<br>
> <br>
>     Alex.<br>
> <br>
<br>
</blockquote></div>