- 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