Thread (13 messages) flat view 13 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:53:06

On Mon, Feb 20, 2012 at 08:24:15PM +0100, Nicolas Mailhot wrote:
quoted
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?
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help