ietf-openproxy
[Top] [All Lists]

Alternate Transfer Protocol for next iCAP-Version

2001-06-09 15:38:57

I refer to the idea that I drafted on my last slide of the presentation at
the Interium Meeting.
It was an idea that came into my mind while writing down my implementation
and interop test experiences with the current draft.

Byte size and offset values in the Encapsulated and Preview headers of an
iCAP message generate
ambiguities between their values and the position of empty lines in the
data. They somehow
interfere with chunked encoding, so that the chunk information has been
removed from the encapsulated
headers in the current icap/1.0 draft.

I propose to use the other way arround for a next version. This should make
the implementation for
iCAP servers and clients easier and safer against errors.

To do:
Remove the Encapsulated and Preview iCAP header
Transfer the complete message in chunked encoding
Use chunk extension to mark encapsulated headers and the last preview chunk
Each encapsulated header has to be transfered in its own and in exactly one
chunk

The iCAP header will then be followed by an iCAP message body which is
completly transfered in
chunked encoding (as stated in the first draft of 1.0)
The sender does not have to calculate the byte size of the encapsulated
headers before sending
them. The receiver only needs to understand chunked encoding. If a chunk is
read completly into
memory before further processing, no extra offset counting code is
necessary. An internal buffer
can always be filled with the exactly the information needed.
By marking the last preview chunk it is always clear when the client waits
for an answer of the
server. No more special cases, if the preview size is smaller or just equal
to the message size.
Communication ends with a single zero last chunk.
Chunk-Extensions: Use req-hdr, res-hdr, last-preview to indicate the sub
parts of the icap message
body

Example (I hope that I counted the chunk sizes correctly)
---------------------------------------------------------
RESPMOD icap://my-icap-server:1344/respmod ICAP/1.0
Host: my-icap-server

2E; req-hdr
GET http://www.origin-server.com/ HTTP/1.0

27; res-hdr
HTTP/1.0 200 OK
Content-Length: 102

1A
This is first preview data
19; last-preview
 followed by more preview.
33
Here we see the rest of the origin server response.
0

---------------------------------------------------------
What do you think about that?

Regards
Martin


<Prev in Thread] Current Thread [Next in Thread>
  • Alternate Transfer Protocol for next iCAP-Version, Martin Stecher <=