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

From: Jeff King <peff@peff.net>
Date: Feb 20, 2012, 19:30 UTC
Message-ID: <20120220193006.GA30904@sigill.intra.peff.net>
In-Reply-To: <72fbd4155349723da1c3c503c1c9c620.squirrel@arekh.dyndns.org>

On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:

Show 10 quoted lines

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

Show 5 quoted lines

> 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).

Even if they didn't call it Location, it would be nice to have some machine-readable format that is understood by non-browser agents that don't know how to parse HTML. But I recognize that is not your decision, so don't feel obligated to defend it.

-Peff