W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

FW: How can an HTTP 1.1 client force a challenge

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Fri, 24 Aug 2001 12:12:52 -0700
To: "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <AMEPKEBLDJJCCDEJHAMIOEGFDFAA.ejw@cse.ucsc.edu>
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:PZehler@crt.xerox.com]
Sent: Friday, August 24, 2001 10:26 AM
To: 'w3c-dist-auth@w3.org'
Cc: 'slawrence@virata.com'; 'ejw@cse.uscs.edu'; 'bartman@process.com'
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: PZehler@crt.xerox.com
				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
Received on Friday, 24 August 2001 15:16:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT