Hi Paul, hi Andre, hi all,
before starting to explain my understanding, I like to mention that it
is essential for icap to find a common understanding very soon. No
matter which version will become the official one - it's very bad for an
icap server to have two kinds of implementations to support different
icap clients. I tried to do this but it is very ugly code!
I (still) vote for transfering the encapsulated header data in chunked
encoding as well.
My reasons:
1. The encapsulated header section belongs to the icap message body and
a change of the encoding scheme at some point inside of the body
complicates the protocol specs.
2. Not using chunks for the encapsulated headers is nowhere mentioned in
the draft. (The note about header sets in a single chunk even strengths
the chunk version). Yes, the chunk header line is missing in the samples
but the examples are not 100 percent correct anyway: The examples have
wrong values here and there as in section 5.5 where the chunk size
should be 512 bytes but the chunk header just prints hex 100 instead of
200!
3. Implementing the icap server is not more complicated with the chunked
encoding, it can even simplify the implementation or can make it more
efficient:
a) For implementations using just line parsing
Just a few additional lines of code are needed: Read the chunk header
line before calling the line parser for the HTTP headers. If HTTP body
data is expected next, substract the byte offset of the "Encapsulated"
header from the chunk size. If it gets zero the body data will follow in
a new chunk.
b) For implementations really following the "Encapsulated" header data
it is important to have the chunked encoding of the HTTP headers. I did
this implementation first and like the efficient way to fill an internal
buffer with the header data that the parser will get. It's just nice
that the "Encapsulated" header tells me how big my buffer must be and
how much data I need to receive before calling the parser without the
need to search for line endings inside the received data (before calling
the parser).
But now: If no HTTP body data is given, I have no value in the
"Encapsulated" header that tells me how long the last HTTP header is.
But with the important sentence of the draft saying: "Note that chunking
MUST NOT break header sets into multiple chunks", I can just use the
chunk size to learn about the size needed for my internal buffer.
Best Regards
Martin
-----Original Message-----
From: Paul Eastham [mailto:eastham(_at_)netapp(_dot_)com]
Sent: Freitag, 4. Mai 2001 22:29
To: Andre Beck
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: ICAP issues
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
_______________________________________________________________________
Dipl.-Inform. Tel. : + 49 / 52 51 / 5 00 54 - 25
Martin Stecher Fax : + 49 / 52 51 / 5 00 54 - 11
Director Development Email :
martin(_dot_)stecher(_at_)webwasher(_dot_)com
Vattmannstrasse 3
D-33100 Paderborn
Germany
Keep Your Web Clean http://www.webwasher.com
_______________________________________________________________________