Re: ICAP REQMOD handling of 200 Ok response

From: sichent <sichent_at_mail.ru>
Date: Wed, 12 Jan 2011 13:17:28 +0100

Thank you Alex!

What will be the correct response of ICAP server to Squid (REQMOD) if
specified Preview windows is fully filled, Squid waits for a reply and I
would like to adapt the request?

1. 200 OK + Adapted request, hoping that Squid would transfer the
remainder of the request to ICAP server, which in turn resends the data
back to Squid (pipelining)?

2. First send 100 OK Continue and then do the 1st step.

P.S. the ICAP rfc is not fully clear about this as it says in 4.5
Message Preview (see the >>> mark below).

It makes me think that e.g. if I see that the URL of the request has to
be adapted and message has a body with preview, then I upon getting the
preview I just adapt the URL and pipeline the request back to squid
(with 200 and *NOT* 100 response)... but debugging the Squid code it
seems that I am incorrect here and an intermediate 100 Continue is
required...

citation from RFC 3507:

After sending the preview, the ICAP client will wait for a response
    from the ICAP server. The response MUST be one of the following:

    - 204 No Content. The ICAP server does not want to (or can not)
       modify the ICAP client's request. The ICAP client MUST treat this
       the same as if it had sent the entire message to the ICAP server
       and an identical message was returned.

>>> - ICAP reqmod or respmod response, depending what method was the
       original request. See Section 4.8.2 and 4.9.2 for the format of
       reqmod and respmod responses.

    - 100 Continue. If the entire encapsulated HTTP body did not fit
       in the preview, the ICAP client MUST send the remainder of its
       ICAP message, starting from the first chunk after the preview. If
       the entire message fit in the preview (detected by the "EOF"
       symbol explained below), then the ICAP server MUST NOT respond
       with 100 Continue.

Thanks in advance,
sich

>
>> Well, what I see in ModXAct.cc(789) the 200 Ok response coming from ICAP
>> server MUST have an encapsulated HTTP response headers... but actually
>> when we adapt the HTTP request we may just have tweaked for example some
>> of its parameters... say URL or Cookie or whatever... leaving everything
>> other intact.
>
> Using REQMOD, you can tweak almost any aspect of the HTTP request,
> including request headers and request body, if any. If you do, you must
> send the complete adapted request back to Squid using an ICAP 200 OK
> response.
>
>> Does it mean that it is a bug of Squid or just that I overlooked something?
>
>> bool Adaptation::Icap::ModXact::validate200Ok()
>> {
>> ... skipped ...
>>
>> if (ICAP::methodReqmod == service().cfg().method) {
>> if (!gotEncapsulated("res-hdr")&& !gotEncapsulated("req-hdr"))
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>> return false;
>
> This reads "for REQMOD, if there are no encapsulated response headers
> and no encapsulated request headers, then return false because it is an
> invalid ICAP 200 OK response".
Received on Wed Jan 12 2011 - 12:17:45 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 13 2011 - 12:00:04 MST