Subject: FW: How can an HTTP 1.1 client force a challenge

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 24 Aug 2001 12:12:52 -0700

Accidentally caught by the spam filter. I have added Peter to the accept2
list, so future emails from him will go straight through to the list.

- Jim

-----Original Message-----
From: Zehler, Peter [mailto:[email-masked]]
Sent: Friday, August 24, 2001 10:26 AM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: [Moderator Action] How can an HTTP 1.1 client force a challenge

All,

Sorry to post this HTTP 1.1 question to your DL but the official HTTP 1.1 DL
is no longer active.  The IETF Working Group for the Internet Printing
Protocol (IPP).  (IPP is described in rfc2910, rfc2911)  We have the
following issue and solution and would like your opinion.  From an HTTP 1.1
standpoint is the solution valid?

ISSUE: How can a client force an HTTP server to issue a challenge before the
client sends a POST body containing a lot of data?

BACKGROUND: IPP v1.1 is carried over HTTP 1.1 via a POST.  The IPP operation
Print-Job carries the desired printing instructions (e.g. two-sided,
stapled) followed by the print data in the same HTTP request.  In some
instances the job may be large.  In other cases the print data is being
generated on the fly and cannot be easily regenerated.   The IPP
Implementer's Guide needs to recommend how IPP Clients and Printers should
use the HTTP 1.1 protocol  to provide an interoperable IPP operation that
accommodates security challenges.

SOLUTION:
     1.  The client sends an HTTP request header containing the
"Expect:100-continue" header field, but waits before transmitting the
request body.
     2.  The Printer (i.e. server) examines the HTTP header and decides
whether or not to accept the HTTP request.
     3a.  If the Printer accepts the HTTP request, it sends a 100(Continue)
response and continues to read from the input stream. Go to 4a.
     3b   If the Printer requires authentication, it rejects the request
with 401 (Unauthorized) status and a "WWW-Authenticate" header field
containing at least one challenge. Go to 4b.
     4a.  If the client receives a 100 (Continue) response, it now has a
reasonable expectation that the HTTP request will succeed.  The client now
transmits the request body which contains the IPP printing instructions and
print data. Go to 5.
     4b. If the client receives a challenge, it sends a new HTTP request
header containing an "Authorization" header field and an "Expect:
100-continue" header field. Go to 3a.
     5.  After the Printer receives and processes the HTTP request body, it
sends a final HTTP status code in response.

Thanks for any guidance you can offer.

				Peter Zehler
				XEROX
				Xerox Architecture Center
				Email: [email-masked]
				Voice:    (716) 265-8755
				FAX:      (716) 265-8792
				US Mail: Peter Zehler
				        Xerox Corp.
				        800 Phillips Rd.
				        M/S 128-69E
				        Webster NY, 14580-9701

---

From: "Larry Masinter - [email-masked]" <[email-masked]>
Date: Fri, 24 Aug 2001 16:32:55 -0700

# Sorry to post this HTTP 1.1 question to your DL but the official HTTP 1.1
DL
# is no longer active.  ....

The HTTP 1.1 DL (mailing list) is still active:

       [email-masked]

archived at
         http://groups.yahoo.com/group/http-wg/

and (somewhat unreliably) at
    http://www.ics.uci.edu/pub/ietf/http/hypermail/

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 27 Aug 2001 11:49:51 -0700

We have run across this issue with clients wanting to get a challenge before
sending the body of a large PUT request.

> "Expect:100-continue" header field, but waits before transmitting the

IMO, this is the preferred solution.  The only drawback I can see is that
some of the fielded IPP servers might not support the Expect header. Thus,
you might want to have some kind of discovery mechanism available for
clients to determine if a printer supports Expect.

> whether or not to accept the HTTP request.

I think that this approach would depend too much on the semantics of client
stacks.  Does a client stack check for responses as it is sending out a
large request body? This may not be under the control of a user-space client
(i.e., if the client hands a pointer to the kernel and says "ship these
bytes" then I believe the ability to detect an early reply depends on the
implementation of the tcp stack in the kernel).

> response and continues to read from the input stream. Go to 4a.

Assuming the client can handle a 100 response -- you would need to check the
installed base of IPP clients to see if this would work.

- Jim