W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: best status code for bad auth method

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 09 Dec 2011 23:13:36 +1300
Message-ID: <4EE1DF50.3000602@treenet.co.nz>
To: ietf-http-wg@w3.org
On 9/12/2011 8:54 p.m., Adrien de Croy wrote:
>
> my gut tells me responding with a 407 is more likely to result in 
> request looping.
>
> 403 shuts it down (or should).
>
> browser behaviour when you send a 407 back when a client considers 
> auth should be complete, results in the browser popping a login dialog.
>
> But since there are few browsers, and I'm pretty sure they all honour 
> the advertised methods, we won't see this - just headless agents.
>
> Maybe we need a new status code...

Your gut s correct. However there is no avoiding that risk without 
breaking things even more.

What we see in practice is that each browser chooses different 
advertised methods under diffrent conditions. Sometimes even opening the 
transaction with credentials in a method which has never been advertised 
to it (headless agents sending Basic auth on first contact, IE browser 
sending NTLM responses to advertised Negotiate,Basic) sending a 403 on 
auth failure here will not lead to correct behaviour.
  Attempting to record the past advertisements vs current choice runs 
into problems with agents which choose methods out of the advertised 
sequence on thir own preference or support criteria. Some agents try 
NTLM then Basic, or run through a whole sequence of different 
credentials skipping around on the advertised set (even repeating some 
with alternative credentials). All of this flexibility will be broken if 
a 403 appears after an arbitrary failure point.

AYJ

>
>
> On 9/12/2011 8:47 p.m., Daniel Stenberg wrote:
>> On Fri, 9 Dec 2011, Adrien de Croy wrote:
>>
>>> 407 also implicitly says try again, whereas 403 says don't... so I'm 
>>> leaning towards the 403.
>>>
>>> I guess the number of web browsers this will affect is about 0... so 
>>> only un-manned applications will see this
>>
>> Surely 407 is already in wide use for this? I would expect many 
>> proxies to just not care about non-supported auth methods and since 
>> it didn't find a correct auth header, it would respond with a 407.
>>
>> And in regards to it saying the client should try again, I consider 
>> it similar to sending an auth header with bad credentials compared to 
>> no credentials. The client must know what it did before when it gets 
>> a 407 back, and then change it accordingly before it tries again.
>>
>
Received on Friday, 9 December 2011 10:14:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT