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 -- 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