IPP> Bake Off 3 issue 1

IPP> Bake Off 3 issue 1

IPP> Bake Off 3 issue 1

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Fri Oct 27 15:39:33 EDT 2000

It was a completely bungled part of the HTTP/1.1 spec.  If you go back
through the revisions of HTTP/1.1, you can see that it changed many times,
and eventually was rendered completely useless in order to ensure backward
compatibility.  On the client side, you can't count on anything about the
behavior of 100 Continue responses.  It's best just to completely ignore
them, as you do.

On the Printer side, though, you MUST deal with the "Expect: 100-Continue"

   Requirements for HTTP/1.1 origin servers:

   ·  Upon receiving a request which includes an Expect request-header
   field with the "100-continue" expectation, an origin server MUST either
   respond with 100 (Continue) status and continue to read from the input
   stream, or respond with a final status code. The origin server MUST NOT
   wait for the request body before sending the 100 (Continue) response. If
   it responds with a final status code, it MAY close the transport
   connection or it MAY continue to read and discard the rest of the
   request. It MUST NOT perform the requested method if it returns a final
   status code.
   ·  An origin server SHOULD NOT send a 100 (Continue) response if the
   request message does not include an Expect request-header field with the
   "100-continue" expectation, and MUST NOT send a 100 (Continue) response
   if such a request comes from an HTTP/1.0 (or earlier) client. There is
   an exception to this rule: for compatibility with RFC 2068, a server MAY
   send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST
   request that does not include an Expect request-header field with the
   "100-continue" expectation. This exception, the purpose of which is to
   minimize any client processing delays associated with an undeclared wait
   for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to
   requests with any other HTTP-version value.
   ·  An origin server MAY omit a 100 (Continue) response if it has already
   received some or all of the request body for the corresponding request.
   ·  An origin server that sends a 100 (Continue) response MUST ultimately
   send a final status code, once the request body is received and
   processed, unless it terminates the transport connection prematurely.
   ·  If an origin server receives a request that does not include an
   Expect request-header field with the "100-continue" expectation, the
   request includes a request body, and the server responds with a final
   status code before reading the entire request body from the transport
   connection, then the server SHOULD NOT close the transport connection
   until it has read the entire request, or until the client closes the
   connection. Otherwise, the client might not reliably receive the
   response message. However, this requirement is not be construed as
   preventing a server from defending itself against denial-of-service
   attacks, or from badly broken client implementations.


Mike Bartman <bartman at p...> wrote:
> I thought that was part of the IPP 1.0 spec?  Perhaps it was just
> interpreted by some client implementers to mean that it could optionally
> arrive after a request, but not at other times?  If so, a little
> clarification might be good.  Since having one arrive doesn't require any
> action on the part of the client, and it's not guaranteed to arrive from
> server, it's essentially a no-op, and when I wrote mine I just set it up
> ignore it whenever it arrived.
>   -- Mike "if that's wrong, please let me know!" Bartman --
> > -----Original Message-----
> > From: Zehler, Peter [mailto:Peter.Zehler at u...]
> > Sent: Thursday, October 26, 2000 2:41 PM
> > To: IPP Discussion List (E-mail)
> > Subject: IPP> Bake Off 3 issue 1
> >
> >
> > All,
> > BO3-1: IPP Client failed when an unexpected HTTP "100 continue" was
> > received.  Some printers sent a "100 continue" even before
> > the Client sent a
> > request.
> >       Proposed Resolution: An IPP Client must accept
> > and handle an
> > HTTP "100 continue" whenever it is encountered.
> >

More information about the Ipp mailing list