Randy
-----Original Message-----
From: Harald Tveit Alvestrand
[SMTP:Harald.Alvestrand@maxware.no]
Sent: Monday, April 20, 1998 6:50 AM
To: Carl-Uno Manros; Turner, Randy; 'ipp@pwg.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
chunking.
Right.
>
>2) All POSTs are initiated by the client, which I assume also
means that
>the client determines whether to use chunking for a particular
HTTP request.
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
does.
>
>4) With the exception of the situation in 3) the client can
always decide
>not to use chunking, but send even long documents in one
request. The
>downside of doing that is that if something goes wrong on the
lower
>protocol layers, the client has to start over and send the
whole document
>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
the latest
>chunk, not the whole document.
Wrong.
Since TCP is a reliable transfer protocol, there is basically
only one
thing that can go wrong: You lose the connection.
There is no defined mechanism in HTTP that allows you to take
advantage
of the chunks you already sent when you retry the operation over
a new
connection.
>5) Again, with the exception of the case in 3), you can in
practise
>actually use HTTP 1.0, which does not support chunking, for
most of your
>IPP transfers.
True. With one caveat:
If you depend on HTTP/1.0 without the Content-length: field to
send
data, you cannot tell the difference between the client crashing
in
mid-stream and the client finishing the document - both will
show up
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,
depending on
your context.
Harald A
--
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no