Well, if there is an authorization failure for a 401-protected resource, the server simply responds with another 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'd say the way to deal with a 407 authorization failure is for the server to respond with a 407 status code despite the fact that the browser has sent authorization information; this shows that the authorization is still needed with the proxy, and implies that there was an authorization failure simply because you're still getting a 407 status code.