Subject: [Captive-portals] HTTP 511 status code considered hard to implement

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Nov 2016 12:10:16 +0900

Dear RFC 6585 authors,

the HTTP 511 status code defined in RFC 6586 section 6
<https://tools.ietf.org/html/rfc6585#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
<https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/connectivity/NetworkMonitor.java>,
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.

Cheers,
Lorenzo

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Nov 2016 12:12:36 +0900

Hi Lorenzo,

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.

Cheers,

> On 18 Nov. 2016, at 12:10 pm, Lorenzo Colitti <[email-masked]> 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.
> 
> Cheers,
> Lorenzo

--
Mark Nottingham   https://www.mnot.net/