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, 15:44 UTC
Message-ID: <20120220154452.GA27456@sigill.intra.peff.net>
In-Reply-To: <e1d3ddd965eb32717163aaa87fa71e17.squirrel@arekh.dyndns.org>

On Mon, Feb 20, 2012 at 04:34:19PM +0100, Nicolas Mailhot wrote:

Show 8 quoted lines

> >> Actually, the best would be to launch something capable of interpreting html
> >> forms on the url given by the error.
> >
> > Doing that portably is near impossible (keep in mind that git runs on
> > things like antique versions of Solaris).
> 
> Can't the you let the user specify a browser command (firefox, elinks w3m) to
> auto-feed the portal page to when needed ?

Yes, that's why I said "we could add a configuration option" in the part that you snipped. But doing it out of the box is not going to be portable.

> The main problem with captive portals is when they shut down the connection
> and the user has no idea how to restore it (and error 511 is intended to fix
> this, but that won't do a lot of good if the user does is not shown the
> captive portal url transmitted with the error)

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

-Peff

[1] Of course it doesn't help at all for git:// or ssh:// (which are
    usually even worse off in the first place, as many captive portals
    will simply drop the packets, making it look like the remote server
    is down).