Re: Squid w/ ICAP 204s

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)

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 - 09:27:51 MST