This leads me to my next question: What is the transition sequence for the cases in which an HTTP/1.1 client that normally uses chunking wants to make a request of a server that is HTTP/1.0 and/or doesn't understand chunking?
Does this scenario look correct?:
1. Client requests HTTP/1.1, Transfer-Encoding: chunked
2. Server responds HTTP/1.0 501 (Unimplemented), and closes the connection
3. Client opens new connection and requests HTTP/1.0, Content-Length
Also, don't some HTTP/1.0 implementations understand Transfer-Encoding as an extension? We have some client situations where we can't avoid chunking, so it would be nice if even the HTTP/1.0 servers understood chunked transfer coding. (Presumably all HTTP/1.1 applications are able to receive and decode the “chunked” transfer coding.)
>You might find that some implementations dont support chunking.
> > -----Original Message-----
> > From: Randy Turner [SMTP:firstname.lastname@example.org]
> > Sent: Friday, July 24, 1998 10:05 AM
> > To: Carl Kugler
> > Cc: email@example.com
> > Subject: Re: IPP> Implementation question re.: chunking
> > At 04:51 PM 7/24/98 +0000, you wrote:
> > >draft-ietf-ipp-protocol-06.txt says the client and server MUST support
> > the
> > "chunked" transfer encoding when receiving. My question is: Can we count
> > on this? I.e., if our client always transmits requests using the
> > "chunked"
> > transfer encoding, will we be able to interoperate with the vast majority
> > of IPP server implementations?
> > >
> > > -Carl
> > There are no vast majority of IPP server implementations (yet). I think
> > the
> > only worry is if someone plans to deploy IPP behind a generic web server
> > that doesn't support chunking. However, Apache and most other of the more
> > popular HTTP/1.1 servers will support this. It should definitely be a
> > bullet item (checkoff item) at the upcoming bake-off, however.
> > Randy
> > >