Re: ISSUE-13: suggest closing

John Kemp wrote:
> 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.

Yes, correct and understood. Is the current text in conflict with that?

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

As a change in RFC 2616, thus draft-ietf-httpbis-p7-auth?

I'd personally like that, but it really doesn't reflect reality (so we 
would be adding a new normative requirement that we know is not 
universally supported).

BR, Julian

Received on Friday, 21 August 2009 14:46:48 UTC