On Mon, Feb 20, 2012 at 07:27:08PM +0100, Nicolas Mailhot wrote: > 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) This is exactly the sort of information I wanted to get from a real-world scenario. From your initial messages, it sounded like a purely hypothetical thing. I think a good first step would be improving the error message for a 511, then. Unfortunately, it seems from the rfc draft you sent that callers are expected to parse the link out of the HTML given in the body of the response. It seems silly that there is not a Location field associated with a 511, similar to redirects. -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