Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)

Le Lun 20 février 2012 02:06, Jeff King a écrit :

On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:

quoted

The IETF finally set up to fix this problem and defined a standard HTTP
error
that lets access control equipments tell the web client authentication or
re-authentication is needed and where the authentication form is located.

http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt

→ <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status>
(the
spec is approved and in the queue for publication as RFC)

Please add error 511 handling in git, so git users that try to access
external
git repositories over http can authenticate on the corporate proxy

If I'm reading this right, the process works something like this:

  1. Git wants to make a request to http://example.com

  2. We make our request to a proxy server which is transparently
     proxying our traffic (i.e, a "captive portal").

  3. The proxy returns 511 along with some URL (e.g.,
     "http://login.corporatenetwork"), indicating that we need
     to go to that URL to complete some authentication.

As a non-browser client, what should git do? We can't make sense of the
content at http://login.corporatenetwork, which is most likely an HTML
form asking for credentials (or even money, if the captive portal is
something like a public wireless provider). The best we can probably do
is die and say "apparently you need to go http://login.corporatenetwork
in a browser before making your request".

Actually, the best would be to launch something capable of interpreting html
forms on the url given by the error. But short of that, that depends on how
good git is at resuming work later. Error 511 can occur at any time, not just
on initial connection (because credentials can expire at any time). So pausing
may be better than dying.

However without going there: the portal page will usually be pretty simple, a
standard basic auth form, can't git handle this? If simple web clients such as
git have specific constrains on what can appear or not on this page, can you
not define them and send them ietf-side so they can document them in a later
rfc revision?

Reading that rfc draft, the man impetus for non-browser clients seems
not to get them to do anything useful, but rather to return them a code
that is clearly not from the actual site (if it were a redirect, for
example, then we would think that example.com is redirecting is, which
is simply not true).

The main impetus from my point of view is that captive portal/proxy auth is a
mess, because they try to trick web clients into displaying something they are
not prepared to and don't want to do, and this spec is replacing trick with
explicit request, which is nice.

Best regards,

-- 
Nicolas Mailhot