On Mon, Feb 20, 2012 at 08:06:46PM +0100, Daniel Stenberg wrote: > > 3. Open a browser and say "Ah, I see. A captive portal". > > > >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). > > We're already discussing the 511 in the curl camp as well, but with > even more sighs and hands in the air. 511 is clearly intended for > HTML-understanding user agents and curl is not one of those. IMHO, > curl will remain to simply help users to figure out that it is 511 > and leave it at that. Thanks for the input. It sounds like our best bet is to just report the URL from a 511 better, then. Do you have any idea yet how that information will be available to curl library users? > As a git user, I would probably be very surprised if using 'git' > suddenly caused by browser to pop up a captive portal login. I would > prefer git to instead properly explain to me that is being the victim > of a 511 and what I should do to fix it. I agree. Even if the "step 3" in my list is "then the user starts a browser given the URL from git's error message", that is a huge improvement over the current state. And it retains the principle of least surprise. -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