Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
- From
Jeff King <peff@peff.net>
- Date
- Feb 20, 2012, 19:09 UTC
- Message-ID
- <20120220190939.GA29158@sigill.intra.peff.net>
- In-Reply-To
- <alpine.DEB.2.00.1202202002330.28090@tvnag.unkk.fr>
On Mon, Feb 20, 2012 at 08:06:46PM +0100, Daniel Stenberg wrote:
Show 12 quoted lines
> > 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