Re: best status code for bad auth method

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


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

Received on Friday, 9 December 2011 08:37:14 UTC