Subject: RE: IPP> IPP, independently of HTTP, Requires Chunking?

From: "Turner, Randy" <[email-masked]>
Date: Fri, 17 Apr 1998 07:25:42 -0700

One caveat with Bob's text. I am seeing that some HTTP 1.1 servers do
not recognize chunked encodings for PUT operations. Aside from that,
this is a pretty complete description of how transactions are occuring
with IPP over HTTP.

Randy

> -----Original Message-----
> From:	Bob Van Andel [SMTP:[email-masked]]
> Sent:	Friday, April 17, 1998 7:01 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	RE: IPP> IPP, independently of HTTP, Requires Chunking?
> 
> All,
> 
> Here is my understanding of what we are seeing in testing.  (Peter,
> please
> 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
> protocol).
> 
> TCP provides the end-to-end message integrity including packet retries
> for
> 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
> the
> end-of-data is by closing the connection.  (HTTP 1.0 is described in
> the
> Informational RFC 1945)
> 
> HTTP 1.1 provides persistent connections (connections that stay intact
> for
> multiple request-response transactions for the same client-server).
> The
> technique for signalling end-of-data for objects whose length may not
> be
> known at the beginning of the transmission is chunked encoding.  In
> HTTP
> 1.1, you may still signal end-of-data by closing the connection, but
> this
> is not recommended, since you will then lose the benefits of the
> persistent
> connection. (HTTP 1.1 is currently described in the Standards Track
> RFC
> 2068, but there will be a new RFC shortly reflecting implementation
> experience)
> 
> 
> 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
> that
> >the client determines whether to use chunking for a particular HTTP
> request.
> >
> 
> All transactions may use chunked encoding in either direction.  The
> requesting client determines whether to use it for POST or PUT
> requests,
> and the responding server determines whether to use it for responses.
> 
> >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.
> 
> Strictly speaking, this is not a requirement, in that the client could
> close the connection to signal end-of-data.
> 
> >
> >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.
> 
> This is not correct.  Lower layer transmission errors will be handled
> at
> 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
> your
> >IPP transfers.
> >
> 
> Our current implementation of IPP transaction support requires that
> HTTP
> 1.1 support be turned on.  In practice, Peter overrode this constraint
> and
> is successfully running IPP over HTTP 1.0 regardless of whether job
> size is
> known at the beginning.
> 
> Bob
> 
> 
> 
> ----------------------------------------
> Bob Van Andel
> Allegro Software Development Corporation
> 43 Waite Road
> Boxborough, MA  01719
> (978) 266-1375
> (978) 266-2839 fax
> 
> Information on the RomPager embedded web server toolkit is at
> <http://www.allegrosoft.com/>
>

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 17 Apr 1998 10:45:08 -0400 (EDT)

> this is a pretty complete description of how transactions are occuring

  That is just a bug is the server - receiving chunked encoding is a
MUST for any 1.1 implementation.

> > close the connection to signal end-of-data.

  That doesn't work for a request because then there is no connection on
which to send the response.

---

From: Bob Van Andel <[email-masked]>
Date: Fri, 17 Apr 1998 12:45:54 -0400

>which to send the response.

That would be the "no response required" mode of operation.  :.)