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

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Feb 20, 2012, 19:51 UTC
Message-ID: <12ec87a8c95ca12c22f05e1ec961d326.squirrel@arekh.dyndns.org>
In-Reply-To: <20120220193006.GA30904@sigill.intra.peff.net>

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

Show 24 quoted lines

> On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:
>
>> > 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/">
>
> Sorry, but
>
>   1. That is in the HTML in the body of the response (by body I don't
>      mean the HTML <body>, but the body of the http request).
>
>   2. I don't see anything in the rfc indicating that there must be a
>      meta tag in the response. They use it in the example of the rfc,
>      but they also have human-readable text with an <a> link.  Do we yet
>      know what will be common among captive portals?
>
> You said you have a non-hypothetical case. Can you show us the response?

Not yet because it's currently non-standard custom redirection mess we're repurposing to follow the ietf spec (got tired of being accused of running a crap non-standard proxy by users, so now it's ll be a crap standard proxy)

The proxy response is totally configurable (a so there's no reason we won't follow the new spec to the letter

-- 
Nicolas Mailhot