- From: Marc Salomon <marc@sfaids.ucsf.edu>
- Date: Fri, 25 Apr 1997 05:47:38 -0700
- To: "grahameg@kestral.com.au" <grahameg@kestral.com.au>, "www-talk@w3.org" <www-talk@w3.org>, "'kdyer@draper.com'" <kdyer@draper.com>
This is the space where authentication and cookies intersect. Authentication is a key, a domain and a scheme looking for a timeout while cookies are a key, a domain and a timeout looking for a scheme. Just as there is a mechanise for a server to swallow a cookie in the protocol, so should a server be able to unset authentication. A 416 return code described below would be useful, but would only work in cases where the user agent were well-connected and if active enough to trigger the cancellation of authorization. This solution does not confront the other big unaddressed authentication security hole: public-area web station scenario where you want the user agent to lose browser-cached authentication information after a short idle time. -marc ---------- From: Kevin J. Dyer Sent: Thursday, April 24, 1997 4:35 AM To: grahameg@kestral.com.au; www-talk@w3.org Subject: Re: Browser authentication On Apr 24, 4:39am, grahameg@kestral.com.au wrote: > Subject: Browser authentication > Is there anyway for a server to clear the authentication field carried in > the HTTP header? > > We wish to time the authentications out, but returning an HTTP 401 > Authorisation failed |[...] | |I made a suggestion late last year to add a 416 return code. The short |of it required the UA to cancel all authentications with the current |domain. This would be for both basic and digest authentication. But |that was for 1.1+. |Kevin J. Dyer
Received on Thursday, 24 April 1997 10:50:03 UTC