Well, if there is an authorization error for a resource with 401 protection, the server simply responds to the other 401:
Request URL:https://mysite.com/myresource/ Request Method:GET Status Code:401 Authorization Required Request Headers Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8 Authorization:Digest username="gjggj", realm="apps", nonce="75602afa895d26f9796f3c9174cf83f3", uri="/misc/apps/", algorithm=MD5, response="9e113b10d3e95b590bdef0fc7c7c617b", qop=auth, nc=00000001, cnonce="61f73b73f6b33ea2" Cache-Control:max-age=0 Connection:keep-alive Host:game-point.net User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17 Response Headers Cache-Control:no-cache Connection:close Content-Length:534 Content-Type:text/html Date:Wed, 13 Feb 2013 11:07:26 GMT Pragma:no-cache Server:Cherokee/1.0.8 (Debian GNU/Linux) WWW-Authenticate:Digest realm="apps", nonce="75602afa895d26f9796f3c9174cf83f3", qop="auth", algorithm="MD5"
So, I would say that the way to deal with 407 authorization failure is that the server responds with a 407 status code, despite the fact that the browser has sent authorization information; this shows that authorization is still necessary with the proxy server and implies that the authorization failed just because you still get the 407 status code.
source share