[whatwg] Solving the login/logout problem in HTML

[Thomas Broyer]

On Wed, Nov 26, 2008 at 11:40 PM, Martin Atkins wrote:
> Julian Reschke wrote:
>>
>> You can already handle the case of content that's available
>> unauthenticated, but would potentially differ in case of being authenticated
>> by adding
>>
>>  Vary: Authorization
>>
>> to a response.
>
> According to section 14.8 of the HTTP 1.1 specification, the presence of the
> Authorization header field implies that the response varies by
> Authorization:
>
>    When a shared cache (see section 13.7) receives a request
>    containing an Authorization field, it MUST NOT return the
>    corresponding response as a reply to any other request, unless one
>    of the following specific exceptions holds:
>
>    [some exceptions in the presence of cache-control directives]
>
> My understanding of this is that "Vary: Authorization" is effectively
> implied for all HTTP responses.

What you're quoting applies only to *shared* caches and only to
content cached in response to a requests containing an Authorization
header (i.e. "authenticated requests").
What it says is: do not cache any such responses except if it has a
Cache-Control response header-field that falls in one of those cases;
and if you're then allowed to cache it, you're allowed to serve it in
response to *any other request* (after having revalidated it
eventually), whether it includes an Authorization header or not, and
whatever the Authorization header contains.
This means that an origin server receiving an "authenticated request"
to a page that does *not* vary depending on the user being
authenticated or not (and which user is authenticated) should respond
with a Cache-Control header-field with a "public", "s-maxage" or
"must-revalidate" directive.


Julian is saying that if your page varies depending on the user being
authenticated and/or the client not being authenticated at all, you
(the origin server) should include a "Vary: Authorization".
This means that if a shared cache has cached the response to an
"unauthenticated request" and it receives an "authenticated request"
for the same URI, it must not use the cached page but must relay the
request back to the origin server.

This case is specifically not handled by RFC 2616 AFAICT.


Actually, what's missing from HTTP is a way to ask you to authenticate
but allow anonymous authentication (others have proposed sending a
WWW-Authenticate response header-field with a 200 OK status; AFAICT
HTTP doesn't disallow it (well, the "MUST be included in 401 response
messages" is unclear to me: does it mean a 401 must have a
WWW-Authenticate or the WWW-Authenticate must *only* be with a 401, or
both?).

Here's what Fielding says about cookies, that applies to most of the
use-cases for "content that's available unauthenticated, but would
potentially differ in case of being authenticated":

"""As a result, cookie-based applications on the Web will never be
reliable. The same functionality should have been accomplished via
anonymous authentication and true client-side state. A state mechanism
that involves preferences can be more efficiently implemented using
judicious use of context-setting URI rather than cookies, where
judicious means one URI per state rather than an unbounded number of
URI due to the embedding of a user-id. Likewise, the use of cookies to
identify a user-specific "shopping basket" within a server-side
database could be more efficiently implemented by defining the
semantics of shopping items within the hypermedia data formats,
allowing the user agent to select and store those items within their
own client-side shopping basket, complete with a URI to be used for
check-out when the client is ready to purchase."""

http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3_4_2

-- 
Thomas Broyer