Re: #78: Relationship between 401, Authorization and WWW-Authenticate

On 25/07/11 13:29, Adrien de Croy wrote:
>
>
> On 25/07/2011 6:31 a.m., Mark Nottingham wrote:
>> On 24/07/2011, at 2:11 PM, Willy Tarreau wrote:
>>
>>> On Sun, Jul 24, 2011 at 02:06:17PM -0400, Mark Nottingham wrote:
>>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/78>
>>>>
>>>> Proposal:
>>>>
>>>> 1) Clarify that WWW-Authenticate can appear on any response, and
>>>> that when it appears on any other than a 401, it means that the
>>>> client can optionally present the request again with a credential.
>>> Does this mean it's only for other 4xx or for any status ? It might have
>>> implications with non-idempotent requests if a client can repost a
>>> request
>>> that led to a 200 for instance.
>> Any status. Good point about non-idempotent requests; we'll need to
>> make clear it's not about automatically retrying requests, but instead
>> that sending the same request with credentials might have a different
>> affect.
>
> isn't this redundant?
>
> I see requests with credentials all the time, when no previous
> WWW-Authorize had been sent in any response.

I disagree on the redundant. This clarifies and documents the existing 
behaviour which must be handled by implementers to improve 
compatibility. Not all of us see these same requests you do.

>
> So clients are already taking any liberties they like to send
> credentials when they please. I don't know that it adds anything to HTTP
> to explicitly tell them they may do this in protocol. They are doing it
> anyway.
>
> Otherwise are we going to prohibit the sending of creds when no
> WWW-Authorize had been sent?

Prohibiting that would be a bad idea. It is possible for the client 
agent to use non-HTTP means to verify the connection security 
requirements before sending credentials over it.

Likewise the mere presence of a WWW-Authorize challenge means nothing 
about the security of the channel. Despite NTLM assumptions to the contrary.

A mention in the security considerations should be enough there.


AYJ

Received on Monday, 25 July 2011 03:13:11 UTC