From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Mon, 20 Feb 2012 19:24:15 GMT
Subject: Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
Message-ID: <72fbd4155349723da1c3c503c1c9c620.squirrel@arekh.dyndns.org>
In-Reply-To: <20120220191500.GA29228@sigill.intra.peff.net>


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