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

["Nicolas Mailhot" <nicolas.mailhot@laposte.net>]

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:
>
>> 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