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"
header:
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.
-Carl
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
additional
> 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
all
> server, it's essentially a no-op, and when I wrote mine I just set it up
to
> 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.
> >