<<<<<<<<<<<<<
Issue 3.1: AGREED
IPP Client failed when an unexpected HTTP "100 continue" was received.
Some printers sent a "100 continue" even before the Client sent a
request.
Issue 3.2: OPEN
Some IPP Clients issues a zero length HTTP Post. The Client assumed
that this would force a challenge if security is enabled on the
Printer. The Client would have a problem if a subsequent print
operation were challenged.
>>>>>>>>>>>>>>
It occurs to me that these two issues are related, and that issue 3.1
contains the solution to issue 3.2.
The crux of the 3.2 problem is this: for Digest Authentication, the client
wants to provoke a challenge so it can get the "nonce" it needs in order to
form the authentication-info for a request. It wants to get this challenge
BEFORE it sends the document data to the printer; otherwise, the request
will be rejected (Unauthorized) and will have to be resent with
authentication-info.
This is exactly the type of problem that the "100-Continue" mechanism is
designed to solve! If a request includes an "Expect: 100-Continue"
header, the Printer MUST either respond with 100 (Continue) status and
continue to read from the input stream, or reject the request with a final
status code. The Printer MUST NOT wait for the request body before sending
the 100 (Continue) response.
Problem 3.2 is solved if a client sends an HTTP request containing the
"Expect: 100-Continue" header and waits for a 100 (Continue) response
before sending the request body. When a request includes the 100-Continue
expectation, and security is enabled on a Printer, the Printer will respond
with 401 (Unauthorized) and include a WWW-Authenticate header containing
the challenge, instead of sending 100 (Continue). This response MUST be
sent after the Printer processes the HTTP headers, without waiting for the
request body. At this point, the client can form the appropriate
WWW-Authenticate request-header, and retry the request. This time it
should receive 100 (Continue), indicating it should proceed to send the
request body.
So the client has successfully provoked a challenge BEFORE sending its
Print-Job request, using only standard mechanisms that already are
required.
-Carl
This archive was generated by hypermail 2b29 : Tue Jan 16 2001 - 17:33:15 EST