IPP Mail Archive: Re: IPP> Bake Off 3 issue 1

IPP Mail Archive: Re: IPP> Bake Off 3 issue 1

Re: IPP> Bake Off 3 issue 1

From: Carl Kugler/Boulder/IBM (kugler@us.ibm.com)
Date: Fri Oct 27 2000 - 15:39:33 EDT

  • Next message: Carl Kugler/Boulder/IBM: "Re: IPP> IPP Bake-Off 3 issue 4"

    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@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@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.
    > >

    This archive was generated by hypermail 2b29 : Fri Oct 27 2000 - 15:49:43 EDT