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
_______________________________________________________________________