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

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

On Mon, Feb 20, 2012 at 07:27:08PM +0100, Nicolas Mailhot wrote:

quoted

Step 3 is a quite less obvious on a corporate network, where Internet access
is gated by a filtering proxy, that will let some sites pass transparently
but
require credentials to let you access others. Worst case, there are several
load-balanced gateways on different physical sites (to avoid spofs in case
of
planes falling on the wrong place), that do not share authentication
(because
propagating auth across physical sites is hard). So no, just launching a
browser is not sufficient to find the captive portal, you need to actually
access the URL returned by error 511 in meta information. Git should at
minimum report this URL.

(and no this is not an hypothetical scenario and yes there are git users
trying to pass the gateways there)

This is exactly the sort of information I wanted to get from a
real-world scenario. From your initial messages, it sounded like a
purely hypothetical thing.

I think a good first step would be improving the error message for a
511, then. Unfortunately, it seems from the rfc draft you sent that
callers are expected to parse the link out of the HTML given in the body
of the response. It seems silly that there is not a Location field
associated with a 511, similar to redirects.

The URL is not lost in the HTML text, it's in the url meta field

<meta http-equiv="refresh"
       content="0; url=https://login.example.net/">

As for while there is no Location field, I think it's because otherwise it
could behave like a redirect, and browser people made it plain they didn't
want redirects of https accesses (but I wasn't there when the spec was
written, and only skimmed the workgroup archives, so there may have been other
reasons for this choice. I'm pretty sure it's deliberate anyway).

Regards,

-- 
Nicolas Mailhot