W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997


From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Tue, 25 Nov 97 12:51:34 EST
Message-Id: <199711251820.AA18669@reston.vmd.sterling.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4821
"Scott Lawrence" <lawrence@agranat.com> writes:

>  As I wrote the proposal, 'discard' can't be combined with other uses
>  of the Authentication-Info header, such as nextnonce; this may have
>  been a mistake.

Just to be clear: You're proposing that a client receiving an
"Authentication-Info: Discard" header in a response should discard the
credentials it supplied on the Authorization header in the request,
correct?  Given everything Fote has been saying about the domain of
credentials over URLs, not to mention realm values, it's entirely
possible for a browser to have a large cache of presumably-valid
credentials.  I don't think you're asking to have them all discarded, or
even some subset of those associated with the origin server, correct?

One more point: Since Authentication-Info is defined by RFC 2069 as
being sent when authentication is successful, this discard response must
be sent with a 2xx or 3xx status code and without a WWW-Authenticate
header.  In other words, an origin server is only allowed to request the
client to discard credentials at a time when they are acceptable to the

And I assume we'd want to support "Proxy-Authentication-Info: Discard"
as well.

I have to say that this is all starting to sound like something we
aren't allowed to do while trying to move HTTP/1.1 from Proposed to
Draft Standard.  As much as the lack of a procedure for invalidating a
client's credentials has hurt my company's products (quite a bit!), we
would nonetheless be opposed to any change that would prevent the rapid
advancement of HTTP/1.1 to Draft Standard.

Ross Patterson
Sterling Software, Inc.
VM Software Division
Received on Tuesday, 25 November 1997 10:21:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC