<div dir="ltr">Thanks for the detailed response Alex.<div><br></div><div>In our case we don't need to modify the initial 10MB, just scan it for virus and if found, send a reset back to squid to not transmit the file.</div><div><br></div><div>Do you have any additional recommendation for such case?</div><div><br></div><div>Thanks,</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 11:54 AM 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 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 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 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 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>
</blockquote></div>