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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html