From: Bob Van Andel [SMTP:email@example.com]
Sent: Friday, April 17, 1998 10:01 AM
Subject: RE: IPP> IPP, independently of HTTP, Requires
Here is my understanding of what we are seeing in testing. (Peter,
correct me if I'm wrong).
IPP is a request-response protocol that sits on top of HTTP (a
request-response protocol) that sits on top of TCP (a connection
TCP provides the end-to-end message integrity including packet
lost or mis-ordered transmissions.
HTTP 1.0 uses a single TCP connection for each request-response
transaction. In many cases, this is because the only way to signal
end-of-data is by closing the connection. (HTTP 1.0 is described in
Informational RFC 1945)
HTTP 1.1 provides persistent connections (connections that stay
multiple request-response transactions for the same client-server).
technique for signalling end-of-data for objects whose length may
known at the beginning of the transmission is chunked encoding. In
1.1, you may still signal end-of-data by closing the connection, but
is not recommended, since you will then lose the benefits of the
connection. (HTTP 1.1 is currently described in the Standards Track
2068, but there will be a new RFC shortly reflecting implementation
At 12:31 PM 4/16/98 , 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.
Yes, but all transactions do not need to use chunked encoding.
>2) All POSTs are initiated by the client, which I assume also means
>the client determines whether to use chunking for a particular HTTP
All transactions may use chunked encoding in either direction. The
requesting client determines whether to use it for POST or PUT
and the responding server determines whether to use it for
>3) The only situation where chunking is absolutely necessary for
>the case where the client does not know the document length when it
>sending the document.
Strictly speaking, this is not a requirement, in that the client
close the connection to signal end-of-data.
>4) With the exception of the situation in 3) the client can always
>not to use chunking, but send even long documents in one request.
>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
>again from the beginning. The main advantage of using chunking is
>you get an error on the lower layers, you only have to resend the
>chunk, not the whole document.
This is not correct. Lower layer transmission errors will be
the TCP layer regardless of whether chunked encoding is used.
>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
Our current implementation of IPP transaction support requires that
1.1 support be turned on. In practice, Peter overrode this
is successfully running IPP over HTTP 1.0 regardless of whether job
known at the beginning.
Bob Van Andel
Allegro Software Development Corporation
43 Waite Road
Boxborough, MA 01719
(978) 266-2839 fax
Information on the RomPager embedded web server toolkit is at