[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] HTTP 511 status code considered hard to implement
Yes, we left it intentionally vague, with the idea that more detail (e.g., headers, payload formats) could be defined by future efforts.
In that sense, it was "hope-based" standardisation (but at least it was fairly inexpensive).
If we can get implementers (especially OS captive portal detection vendors) to honour such a thing, it would be great.
> On 18 Nov. 2016, at 12:10 pm, Lorenzo Colitti <[email protected]> wrote:
> Dear RFC 6585 authors,
> the HTTP 511 status code defined in RFC 6586 section 6 would be useful for operating system captive portal detection because it provides a clear signal that this is a portal However, it's hard to implement because it's not possible to get the login URL without parsing the HTML to find the <meta http-equiv="refresh" tag. Some common implementations (at least the Android implementation, maybe others) do not do this, preferring instead to look for a "location" header.
> Is there a reason why the RFC did not require a location header for this status code?
> I'm wondering if we can/should declare it a best practice that a location header (or other header) SHOULD be provided for every 511 response.
Mark Nottingham https://www.mnot.net/