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