On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote: > The IETF finally set up to fix this problem and defined a standard HTTP error > that lets access control equipments tell the web client authentication or > re-authentication is needed and where the authentication form is located. > > http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt > > → <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status> (the > spec is approved and in the queue for publication as RFC) > > Please add error 511 handling in git, so git users that try to access external > git repositories over http can authenticate on the corporate proxy If I'm reading this right, the process works something like this: 1. Git wants to make a request to http://example.com 2. We make our request to a proxy server which is transparently proxying our traffic (i.e, a "captive portal"). 3. The proxy returns 511 along with some URL (e.g., "http://login.corporatenetwork";), indicating that we need to go to that URL to complete some authentication. As a non-browser client, what should git do? We can't make sense of the content at http://login.corporatenetwork, which is most likely an HTML form asking for credentials (or even money, if the captive portal is something like a public wireless provider). The best we can probably do is die and say "apparently you need to go http://login.corporatenetwork in a browser before making your request". Reading that rfc draft, the man impetus for non-browser clients seems not to get them to do anything useful, but rather to return them a code that is clearly not from the actual site (if it were a redirect, for example, then we would think that example.com is redirecting is, which is simply not true). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html