Hi Andre,
Regarding the chunking of headers, you are not alone in your
confusion. Apparently there was some discussion of this back when the
ICAP teleconferences were being held. I am told (I wasn't involved in
ICAP at the time) that the people who were pushing for chunking at all
never wanted any headers to be chunked, but this was miscommunicated
to the people doing the editing of the draft, and the examples and
surrounding text got corrupted in this way and never fixed.
The main motivation for doing/mandating any chunking at all is to
enable efficient pipelining of large amounts of data. This doesn't
seem to apply so much to headers, so the motivation for chunking it is
unclear to me.
And some additional reasoning for specifically excluding headers, I
think, is that it complicates the implementation of an ICAP server...
a stated goal is to keep the server as simple as possible.
Especially for simple request modification, especially if you attempt
to handle headers broken into many chunks. You already have offset
information from the Encapsulated header. There is the case (REQMOD)
where you have no response-body to tell you where the response-header
ends...I am trying to find a workaround that complies with the draft
for that one.
As for 2XX, that sounds like a reasonable improvement for the next
time the draft gets updated...
Regards,
Paul
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