Re: ISSUE-13: suggest closing

Julian Reschke wrote:
> Maciej Stachowiak wrote:
>> 
>> On Aug 11, 2009, at 12:19 AM, Julian Reschke wrote:
>> 
>>> Maciej Stachowiak wrote:
>>>> http://www.w3.org/html/wg/tracker/issues/13 This was a feature 
>>>> proposal that was never adequately developed into a complete 
>>>> concrete proposal. I suggest that it is too late to consider 
>>>> proposals for new features at this time. I suggest closing this
>>>>  issue. Regards, Maciej
>>> 
>>> Yes and no. I believe the spec now says a few more things about 
>>> 401 then it used to, so I'd like to review and enter a comment so
>>>  that information isn't lost. I do agree that it's too late to 
>>> introduce anything more complicated right now.
>> 
>> Would you be willing to decouple your review from the issue? I'm 
>> sure if you find new concrete problems with the spec text they will
>>  be given due consideration. I'd rather not have this issue sit
>> open forever in the meantime. ...
> 
> 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".

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 the resource is not "suddenly" an HTML login form (when it was some
other protected resource when the user-agent first asked for it).

> 
> 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)".

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?

> 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.

- johnk

[1] http://www.w3.org/html/wg/tracker/issues/13
[2] http://tools.ietf.org/html/rfc2616#section-10.4.2

> 
> So I'm personally ok with closing the issue.
> 
> BR, Julian
>

Received on Thursday, 20 August 2009 15:03:59 UTC