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: > 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. > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.comReceived on Friday, 9 December 2011 07:54:38 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC