Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)

Le Lun 20 février 2012 16:44, Jeff King a écrit :

In my experience, the captive portal process usually goes like this:

  1. Connect to network.

  2. Try some non-browser command. Wonder why in the world it isn't
     working.

  3. Open a browser and say "Ah, I see. A captive portal".

The 511 proposal makes step 2 a lot better if the protocol is http[1].
But it pretty much makes it better even without non-browser client
support, because at least you will get a 511 error instead of having git
complain that the remote repository is corrupted (which happens if the
captive portal returns a redirect to an html page).

We should already be doing that. Adding more support could make step 3 a
little nicer, but like I said, I'd be more interested in seeing a real
case first. It may even be a feature that would be more appropriate to
curl (which git builds on for http access).

Step 3 is a quite less obvious on a corporate network, where Internet access
is gated by a filtering proxy, that will let some sites pass transparently but
require credentials to let you access others. Worst case, there are several
load-balanced gateways on different physical sites (to avoid spofs in case of
planes falling on the wrong place), that do not share authentication (because
propagating auth across physical sites is hard). So no, just launching a
browser is not sufficient to find the captive portal, you need to actually
access the URL returned by error 511 in meta information. Git should at
minimum report this URL.

(and no this is not an hypothetical scenario and yes there are git users
trying to pass the gateways there)

-- 
Nicolas Mailhot