Hi Martin,
We are updating the original draft as we get more implementation
feedback like yours. I seem to recall that the problem you
encountered was how to reserve buffer space for processing of the
different parts of an icap message when there was no body (and
therefore no body field in the Encapsulated header), and also no
chunking size, since the headers are not chunked.
We updated the grammar of the Encapsulated header to include a
null-body field in case there is no body present. This change would
give you enough info directly from the Encapsulated header to reserve
buffer space before processing the message components. I apologize
you had to change your implementation, but sometimes this is the only
way to detect glitches in the spec :)
Sadly, I don't think we'll be able to finish the new updated draft
with enough time for people to read *before* going to OPES meeting.
We'll certainly do our best though.
Best regards,
-Alberto.
On Fri, 1 Jun 2001, Martin Stecher wrote:
Hi!
Some technical stuff beside the basic standardization question:
When I first read the last sentence of section 5.4 of the specs ("The
encapsulated headers MUST be terminated by a blank line, in order to
make them human readable, and in order to terminate line-by-line HTTP
parsers."), I read this as the implied message that the smarter
implementation will first of all rely on the byte offsets in the
Encapsulated header and will not care too much about the empty lines.
But after I learned that most of you implemented the chunking in that
way that starts the first chunk AFTER the encapsulated headers, I had to
change my code.
Due to the problems in finding the end of the last encapsulated header
without chunk info (as described in my memo three weeks ago), my new
version uses the Encapsulated header information only for checking which
headers I can find in the message. Reading the headers is done by a
simple line-by-line parser. I wouldn't recognize if the byte offsets in
the Encapsulated header are wrong.
I would like to hear your experience with this before next week's
meeting:
Do your icap client or server implementations rely on the byte count
transmitted with the Encapsulated icap header?
Do you use this information (just) to move your HTTP header parser to
the beginning of the section?
How do you find the end of the encapsulated headers? Only looking for
the empty line?
What will happen with your implementation if the other peer sends wrong
byte counts, i.e. the empty line is send before or after the given byte
offset?
I am anxious to read your answer.
Martin
_______________________________________________________________________
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
_______________________________________________________________________