From: Jeff King <peff@peff.net>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: git@vger.kernel.org
Subject: Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
Date: Mon, 20 Feb 2012 10:44:52 -0500 [thread overview]
Message-ID: <20120220154452.GA27456@sigill.intra.peff.net> (raw)
In-Reply-To: <e1d3ddd965eb32717163aaa87fa71e17.squirrel@arekh.dyndns.org>
On Mon, Feb 20, 2012 at 04:34:19PM +0100, Nicolas Mailhot wrote:
> >> 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).
next prev parent reply other threads:[~2012-02-20 15:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 21:03 Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection) Nicolas Mailhot
2012-02-20 1:06 ` Jeff King
2012-02-20 5:38 ` Nicolas Mailhot
2012-02-20 13:56 ` Jeff King
2012-02-20 15:34 ` Nicolas Mailhot
2012-02-20 15:44 ` Jeff King [this message]
2012-02-20 18:27 ` Nicolas Mailhot
2012-02-20 19:15 ` Jeff King
2012-02-20 19:24 ` Nicolas Mailhot
2012-02-20 19:30 ` Jeff King
2012-02-20 19:51 ` Nicolas Mailhot
2012-02-20 19:06 ` Daniel Stenberg
2012-02-20 19:09 ` Jeff King
2012-02-20 20:16 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120220154452.GA27456@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=nicolas.mailhot@laposte.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).