Re: Squid w/ ICAP 204s

Hello Christos-

Thank you for your response. Comments inline.

On Fri, Dec 5, 2008 at 1:27 AM, Christos Tsantilas
<christos_at_chtsanti.net> wrote:
> Hi Lisa,
>
>> Posting here as well... This might be a better place than squid-users
>> since it's potentially a bug...
>>
>> ---------- Forwarded message ----------
>>
>> Hello-
>>
>> I've searched through the archives and can't find anything pertaining
>> to this problem, so I hope that someone can help with this.
>>
>> I have a Squid 3.0 installation (a build from November) with the ICAP
>> client running, intercepting responses precache, which then forwards
>> the entire responses to the ICAP server. I have a simple Python ICAP
>> server that does nothing but respond to OPTIONS and sends back 204s
>> otherwise. Preview is not enabled.
>
> From what I can understand you are using 204 responses outside preview. An
> ICAP server can respond with 204 outside preview to an ICAP request only
> if the ICAP client support it for this request. In this case the icap
> client include the "Allow: 204" header in request to inform the server
> that it can handle 204 responses outside preview in the current request.
>
> For squid to support an 204 response outside preview means that squid must
> be able to buffer all http response data locally (single web pages 1-2Kb
> to iso images 1-2 GB) before send them to that ICAP server. If squid can
> not buffer the data (big objects), or squid is not sure (eg unknown
> content length) does not permit 204 responses outside preview.
> Also read the 4.6 paragraph of the ICAP rfc (rfc 3507)

Thank you for reminding me of that section. I had made an assumption
that Squid would send "Allow: 204" in all cases because of the
squid.conf setting. I'll double check the headers and see if Squid is
opting to not send Allow: 204 messages on some cases, no matter the
squid.conf setting.

Has there been any movement on supporting postcache ICAP? All I care
to do is vector the data off the proxy, but still send the data
unmodified to the client, which is why my ICAP server only responds
with 204s...

Thanks!
Lisa

> I think in this case an error message should displayed not a blank page,
> but depends....
>
> Regards,
> Christos
>
>>
>> For *most* webpages, this works fine (e.g. http://www.google.com
>> http://www.mozilla.org), and the webpage is forwarded and all content
>> is rendered properly on the web client.
>>
>> For certain webpages (e.g. http://www.mozillazine.org), the ICAP
>> server receives the content, responds with the 204 as usual, but then
>> the client never receives webpage and thus renders a blank page.
>
>>
>> Looking under the hood, Squid deterministically fails in
>> ICAPModXact::virginContentSize() at the Must(virginConsumed <= start
>> && start <= end) line.
>>
>> I'm deep in the murky waters of debugging, and it seems that there's a
>> quirk in whether or not virginConsumed is reset to 0, such that I get
>> a failure on the above Must assertion, for example (36033 <= 0 && 0 <=
>> 36033) . I wonder if it's related to how
>> virgin.body_pipe->buf().contentSize() is handled in the case of
>> virginBodySending, such that in ICAPModXact::echoMore(), sizeMax is 0,
>> and thus virginBodySending.progress(size) is never called... In the
>> cases that *do* work, virginBodySending.progress(size) is called, but
>> not in the cases that fail. The cases that fail have contentSize
>> zeroed out (because virginBodySending.progress(size) is not called)...
>>
>> Any ideas/experience/advice?
>>
>> Thanks,
>> Lisa
>>
>
>
>
Received on Fri Dec 05 2008 - 15:43:59 MST