W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Wed, 29 Feb 2012 20:32:50 +0100
Message-ID: <1330543970.24673.15.camel@home.hno.se>
To: Willy Tarreau <w@1wt.eu>
Cc: Julian Reschke <julian.reschke@gmx.de>, Robert Collins <robertc@squid-cache.org>, Barry Leiba <barryleiba@computer.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
ons 2012-02-22 klockan 15:02 +0100 skrev Willy Tarreau:

> I think that sometimes the server wants to cause the logout (eg: application
> status code) and sometimes the user wants to log off. Many web developers
> working in environments where basic auth is in use are used to open/close
> their browser all the day due to the lack of logoff button.

There is a very simple but confsing method for that: requesting a
resource requiring different credentials in the same realm, and ask the
user to log in there with some well known credentials (i.e. username
logoff, password logoff)

In some browsers even cancelling that login box is sufficient, but most
require the user to login with different credentials to invalidate the
first.

> If we had the browsers provide the logoff button, then the current 403
> is already enough for user-initiated action.

Fully agreed.

> If we want the server to force a logoff, we possibly need to define how
> this is supposed to be
> done. Note that in this case it's a change of authentication, which is
> different from a lack of authorization (eg: return 401 with an empty
> www-authenticate response).

logoff is mostly in the realm of human interaction, so javascript could
do it nicely imho. Document.logoff() or similar.

Not sure there even is a demand for protocol level indicated logoff
where the server at HTTP level tell the client to invalidate the cached
credentials.

Regards
Henrik
Received on Wednesday, 29 February 2012 19:33:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT