Subject: best status code for bad auth method

From: Adrien de Croy <[email-masked]>
Date: Fri, 09 Dec 2011 14:57:13 +1300

Hi all

hopefully a quick question...

what is the best response code for a proxy that receives a request with 
a Proxy-Authorization header that specifies a method that is not 
acceptable to the proxy?

another 407?
403?  We don't want the client to repeat the request as is...

or do we need a new status code for "auth method not allowed".

Regards

Adrien de Croy

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Dec 2011 13:02:19 +1100

I think that'd be a 407; this basically says "here is the list of accepted auth methods" and the client can put two and two together...

Cheers,

On 09/12/2011, at 12:57 PM, Adrien de Croy wrote:

> what is the best response code for a proxy that receives a request with a Proxy-Authorization header that specifies a method that is not acceptable to the proxy?
> 
> another 407?

--
Mark Nottingham   http://www.mnot.net/

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 09 Dec 2011 15:03:52 +1300

that was my initial though too, but in this case we'd already sent a 407 
with advertised methods, so the client already got it wrong once...

Regards

Adrien

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 09 Dec 2011 15:09:22 +1300

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

regards

Adrien

On 9/12/2011 3:03 p.m., Adrien de Croy wrote:
>
> that was my initial though too, but in this case we'd already sent a 
> 407 with advertised methods, so the client already got it wrong once...
>
> Regards
>
> Adrien
>
>
>> I think that'd be a 407; this basically says "here is the list of 
>> accepted auth methods" and the client can put two and two together...
>>
>> Cheers,
>>
>>
>>> what is the best response code for a proxy that receives a request 
>>> with a Proxy-Authorization header that specifies a method that is 
>>> not acceptable to the proxy?
>>>
>>> another 407?

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 9 Dec 2011 08:47:56 +0100 (CET)

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.

-- 

  / daniel.haxx.se

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 09 Dec 2011 20:54:05 +1300

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

On 9/12/2011 8:47 p.m., Daniel Stenberg wrote:
> 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.
>

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 09 Dec 2011 17:35:05 +0900

I think it should be 407 without including the requested method, definitely.

401 and 407 status are said to be "try-again" response, but
any clients should not repeat the request unless they have
a change to make it successful (e.g. new method, new password,
or under some methods [e.g. Digest] with a new session).
Note that 4XX statuses mean that client have erred
and there is no way for the "same" request to be accepted,
at least temporarily at the same moment of time.

RFC 2616 says for 407:

> The client MAY repeat the request with a suitable
> Proxy-Authorization header field (section 14.34).

Repetition of rejected (thus not suitable) credentials
is not supported by this clause.

I don't think any new status is required for this purpose,
because 407's semantics is really clear and implementable.
Non-inclusion of the requested auth. method in 407 clearly
indicates that the same method is unconditionally unacceptable.
We do not have the similar one for 401, too.

It the client does repeats the proxy request for the
same end-point resource without any changes from those
rejected by previous 407, there's a bug.

# Exceptions are when the user has provided the same password
# as if it were new, or just hit the "reload" button.

403 should not be used for this purpose, as client will treat
it as a response from the final server, not from the proxy.

One possible addition relating to this is a 503-equivalent
specific for proxies (currently 503 seems to be mostly fit
for both proxies and final servers).  But it should not be
used for replacing 407, as 503 roughly means that "if you
want, after a fair amount of time for situation change,
you should repeat the same request to see what happens".

On 2011/12/09 10:57, Adrien de Croy wrote:
> what is the best response code for a proxy that receives a request with a
> Proxy-Authorization header that specifies a method that is not acceptable to the
> proxy?
> 
> another 407?

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 09 Dec 2011 23:13:36 +1300

On 9/12/2011 8:54 p.m., Adrien de Croy wrote:
> browser behaviour when you send a 407 back when a client considers 
> auth should be complete, results in the browser popping a login dialog.
>

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Dec 2011 12:43:53 +1100

If we created a new status code to address every brain-dead client behaviour, we'd fast run out.

Regards,

On 09/12/2011, at 6:54 PM, Adrien de Croy wrote:

> 
> my gut tells me responding with a 407 is more likely to result in request looping.
> 
> 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.
> 
>>> 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.
>> 
> 
> --

---

From: Dale Anderson <[email-masked]>
Date: Sat, 10 Dec 2011 00:19:12 -0800

That most definitely did not occur to us dude

Actually I just had to make a Big Lebowski reference on httpbis to save my
life.

I will say that my intuition is that the 407 would come bearing some
response header indicative of what the client was supposed to make for a
next attempt, that would suffice at least for implementations I am
imagining?

Dale

2011/12/8 Adrien de Croy <[email-masked]>

> Proxy-Authorization header that specifies a method that is not acceptable
> to the proxy?
>
> another 407?
> WinGate 7 is released! - http://www.wingate.com/**getlatest/<http://www.wingate.com/getlatest/>
>
>
>