Re: ISSUE-13: suggest closing

Hi Julian,

Julian Reschke wrote:
> 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?

My understanding of 2617 is that if some number of mechanisms are 
specified in the WWW-Authenticate header (say "cookie, digest, basic") 
and the user-agent knows only "basic" and "digest" schemes it MUST 
choose the strongest of those schemes. It cannot "choose" to follow a 
scheme that it does not know, for example. There is nothing in 2617 that 
suggests the user-agent should simply defer to the user if it doesn't 
understand one mechanism (but understands another) either.

...

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

Yes, that document looks to be a step in the right direction. I will 
take a more detailed look.

I can see that a user-agent wouldn't necessarily need to understand the 
contents of the Cookie challenge in order to give the user the chance to 
authenticate, although it would seem better if the user-agent _did_ 
understand the mechanism rather than blindly presenting the form to the 
user.

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

Yes, I am sympathetic to the issue.

Would the sentence below (a slight relaxation of RFC2616, section 10, 
shown below for comparison)

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

resolve the issue?

"A user-agent SHOULD present to the user any entity body that is 
returned with an HTTP 401 status."

Regards,

- johnk

Received on Friday, 21 August 2009 14:30:14 UTC