From: Harald Tveit Alvestrand
Sent: Monday, April 20, 1998 6:50 AM
To: Carl-Uno Manros; Turner, Randy; 'firstname.lastname@example.org'
Subject: RE: IPP> IPP, independently of HTTP, Requires
Chunking ? Was: Mi
At 12:31 16.04.98 PDT, Carl-Uno Manros wrote:
>Randy et al.,
>Here is my take on the use of chunking for IPP:
>1) Each HTTP 1.1 implementation is mandated to support
>2) All POSTs are initiated by the client, which I assume also
>the client determines whether to use chunking for a particular
Right, as far as it goes.
And the server determines whether to use it for the response.
>3) The only situation where chunking is absolutely necessary
for IPP, is
>the case where the client does not know the document length
when it starts
>sending the document.
For the generation: Right.
For reception: Wrong. You're dependent on what the other guy
>4) With the exception of the situation in 3) the client can
>not to use chunking, but send even long documents in one
>downside of doing that is that if something goes wrong on the
>protocol layers, the client has to start over and send the
>again from the beginning. The main advantage of using chunking
is that if
>you get an error on the lower layers, you only have to resend
>chunk, not the whole document.
Since TCP is a reliable transfer protocol, there is basically
thing that can go wrong: You lose the connection.
There is no defined mechanism in HTTP that allows you to take
of the chunks you already sent when you retry the operation over
>5) Again, with the exception of the case in 3), you can in
>actually use HTTP 1.0, which does not support chunking, for
most of your
True. With one caveat:
If you depend on HTTP/1.0 without the Content-length: field to
data, you cannot tell the difference between the client crashing
mid-stream and the client finishing the document - both will
as a "connection close".
<RT> This is not true in all cases. I seem to remember that some socket
and TLI API implementations allow you to detect the difference between a
remote endsystem crashing and a normal connection "close". This should
be especially possible if the client had data in transit at the time the
remote endsystem crashed.
This can be annoying-but-harmless or relatively harmful,
Harald Tveit Alvestrand, Maxware, Norway