Re: ISSUE-13: suggest closing

Hi John,

John Kemp wrote:
>> The spec currently says:
>>
>> "HTTP 401 responses that do not include a challenge recognized by the
>>  user agent must be processed as if they had no challenge, e.g. 
>> rendering the entity body as if the response had been 200 OK.
> 
> This feels odd - as if a new HTTP authentication mechanism (ie. as those
> defined in RFC)2617 has been developed, but which is not advertised in
> the response from the server, or is advertised but not understood by the
> user-agent. That seems to defeat the purpose of RFC2617 and the
> requirement that the user-agent MUST "choose to use one of the
> challenges with the strongest auth-scheme it understands".

Could you elaborate where you see a conflict?

> By providing an HTTP 401 with WWW-Authenticate header, a server is
> saying that the user-agent should attempt to authenticate using one of
> the methods supported for that resource. If the user-agent cannot
> understand any one of those methods, then it does not support any of the
> given authentication methods for that resource, and if we follow the
> intentions of the server, the user-agent shouldn't be able to
> authenticate in an RFC2617-compatible manner at all. So I'm imagining

That's true. In practice, most web applications currently use other 
(non-HTTP) authentication mechanisms already. I'd prefer those to be 
compliant with RFC2617, but they aren't.

> that the resource is not "suddenly" an HTML login form (when it was some
> other protected resource when the user-agent first asked for it).

It could be a login form. That would at least deal with the problem that 
non-interactive user agents shouldn't see a status 200 when in reality 
the representation they got is a login form, not the requested resource.

They still wouldn't be able to authenticate, but at least they wouldn't 
get misleading information.

>> User agents may show the entity body of an HTTP 401 response even when 
>> the response do include a recognized challenge, with the option to 
>> login being included in a non-modal fashion, to enable the information 
>> provided by the server to be used by the user before authenticating. 
>> Similarly, user agents should allow the user to authenticate (in a 
>> non-modal fashion) against authentication challenges included in other 
>> responses such as HTTP 200 OK responses,
>>  effectively allowing resources to present HTTP login forms without 
>> requiring their use." -- 
>> <http://dev.w3.org/html5/spec/Overview.html#navigating-across-documents>
>>
>>
>>
>> That doesn't solve the full problem, but at least it clarifies what 
>> User Agents are supposed to do, and will allow future innovation.
> 
> Essentially, we'd allow a user-agent to say "I understand HTTP Basic
> (which was in the WWW-Authenticate header) and the server asked for HTTP
> Basic, but instead of resubmitting my request with the basic credentials
> according to RFC 2617, I'm going to ignore that and present the login
> form which arrived in the entity-body (or worse, perhaps, display both a
> non-modal browser login box, and an HTML login form)".

Yes. I consider that a feature, because the same response would be 
usable in interactive browsers and other clients that do not know about 
HTML. (Today, many servers handle that by User-Agent sniffing, which 
clearly is a bad thing).

> Regarding the issue [1] itself, and your points:
> 
>> Browsers do not display the text/html response body of a HTTP 401 
>> response, instead, they just pop up a modal authentication dialog 
>> (until "cancel" is pressed).
> 
> I regard the above as being correct RFC2617 behaviour. If we want to
> allow form-based login via an RFC2617-compliant mechanism, shouldn't we
> actually define an HTTP authentication mechanism for it?

Yes, we should.

The latest activity on this is Thomas Broyer's 
(<http://hg.ltgt.net/http-cookie-auth/>, 
<http://tools.ietf.org/html/draft-broyer-http-cookie-auth-00>), and it 
would be great if more people would help with that.

>> Servers do not send a meaningful response body with the 401 status as
>> browsers do not display it anyway.
> 
>  From 2616, section 10 [2]:
> 
>> If the 401 response contains the same challenge as the
>>    prior response, and the user agent has already attempted
>>    authentication at least once, then the user SHOULD be presented the
>>    entity that was given in the response, since that entity might
>>    include relevant diagnostic information.
> 
> The user-agent can determine at what point to display the entity given 
> in the response. Is the above text related to your issue? I'm 
> sympathetic to the issue, but I'm not sure the current spec. text is the 
> right way to solve it.
> ...

Clarifying: I'd like a server to handle access to authenticated content 
over HTTP in a uniform way. The two currently defined HTTP Auth 
mechanisms aren't used a lot in practice, both because of their security 
aspects, and their usability (most designers aren't going to accept the 
builtin browser UI).

So we need a way to serve a "you need to authenticate" message to *all* 
clients. It needs to have status code of 401 so it's properly handled by 
clients that won't peek into the response body. But it needs to be able 
to carry a rich HTML-based UI for browsers. Requiring HTML-based UAs to 
display the response-body of a 401 message thus is essential for 
deployment of any new authentication scheme.

BR, Julian

Received on Friday, 21 August 2009 12:10:03 UTC