ietf-openproxy
[Top] [All Lists]

Re: ICAP issues

2001-05-04 12:58:45
Such issues will be discussed at the upcoming workshop as well.
At 02:42 PM 5/4/2001 -0500, Andre Beck wrote:
We have come across a couple of issues in the current ICAP 1.0 draft and
were wondering how others think about them.

At some point in the draft it says:

"All ICAP messages MUST be transmitted using the chunked transfer-coding
described in Section 3.6.1 of [4]."

and also:

"Note that chunking MUST NOT break header sets into multiple chunks".

According to the examples given in the draft this seems to imply that
chunked encoding is not to be used for the section of the ICAP message
body that contains the HTTP request/response headers. Consider the
following example from the draft:

=====================================================
REQMOD icap://icap-server.net/server ICAP/1.0  <-+
Host: icap-server.net                            | ICAP header
Encapsulated: req-hdr=0, req-body=138          <-+


POST /origin-resource/form.pl HTTP/1.1         <-+
Host: www.origin-server.com                      | unchunked
Accept: text/html, text/plain                    | HTTP request
Accept-Encoding: compress                        | header
Pragma: no-cache                               <-+

1f                                             <-+ chunked HTTP
I am posting this information.                   | request body
0                                              <-+
=====================================================

Is there a good reason for not encoding the header sections into one big
chunk so that the entire ICAP message body is chunked encoded? How have
others implemented this?

Secondly, the draft mandates the following:

"If the return code is a 2XX, the ICAP client SHOULD continue its normal
execution of the request. [...] For other
return codes that indicate an error, the proxy SHOULD return these
directly to downstream client."

While this makes sense for error messages generated by ICAP services,
how much sense does it make to return ICAP server error messages to the
client. For instance, if an ICAP server returns a 404 response because a
certain service cannot be found on the particular ICAP server, should
the client really ever see this error message? Doesn't it make more
sense to hide this error condition from the client and simply return the
requested Web object to the user? Maybe we should differentiate between
ICAP service and ICAP server generated error messages...

-Andre

Michael W. Condry
Director, Network Edge Technology


<Prev in Thread] Current Thread [Next in Thread>