- From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Date: Tue, 25 Nov 97 12:51:34 EST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
"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 server. 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