Subject: [Captive-portals] practicality of 511 HTTP status code

From: Erik Kline <[email-masked]>
Date: Sun, 7 May 2017 17:05:53 +0900

I wanted to poll the group's thoughts on the usefulness of the
rfc6585#section-6 511 HTTP status code.

Has anybody tried to serve 511s to clients, and if so what were the results?

Might it be useful to serve an API endpoint (rather than the full-blown
HTML UI)?

I'm trying to get a sense of whether this will be a useful tool to use in
assembling a recommended portal interaction.  If we determine it's not
really going to be a workable component, then that's useful to know too.

---

From: Vincent van Dam <[email-masked]>
Date: Sun, 7 May 2017 18:23:50 +0000

I think the 511 fits one use-case, being the scenario where http traffic is intercepted by the nas and the user is redirected with a http 302/307 status code to a captive portal. The 511 would be, imo, the right status code to use instead of 302/307.

Since the 511 status is an error http status code; it has a higher chance of signalling unaware clients there is something wrong. The goal of the nas for intercepting the http request is to show a captive portal, and only applications that did http requests and are able to present that captive portal (webbrowsers) should gracefully handle this status code.

Since 511 is an error code; I would expect that some application doing e.g. an api call over http or fetching some static configuration file are able to better handle this than being redirected to something that can’t be interpreted (but produced a success status code). If the 511 status code would be used, the response would likely be already considered as an error because. I think it will also improve fetching resources (images/javascripts) in a the captive state, these should fail immediately as well with an error (instead of each resource returning the captive portal markup).

I am also very curious about at least the adoption and support of this status code.

________________________________
Van: Captive-portals [[email-masked]] namens Erik Kline [[email-masked]]
Verzonden: zondag 7 mei 2017 10:05
Aan: [email-masked]
Onderwerp: [Captive-portals] practicality of 511 HTTP status code

I wanted to poll the group's thoughts on the usefulness of the rfc6585#section-6 511 HTTP status code.

Might it be useful to serve an API endpoint (rather than the full-blown HTML UI)?

I'm trying to get a sense of whether this will be a useful tool to use in assembling a recommended portal interaction.  If we determine it's not really going to be a workable component, then that's useful to know too.

---

From: David Bird <[email-masked]>
Date: Sun, 7 May 2017 11:36:24 -0700

I personally do not find it very useful in public access networks, because:
- A legacy 30X response will still be needed for some user-agents
- Returning 511 is still a man-in-the-middle response (nothing changed
there)
- The response contains HTML that should contain the login URL (or a meta
refresh, etc), which isn't a very well structured way to get the URL
- differences in how browsers handle the 'error' and the associated user
experience

There are a couple other oddities:

   Note that the 511 response SHOULD NOT contain a challenge or the
   login interface itself, because browsers would show the login
   interface as being associated with the originally requested URL,
   which may cause confusion.

Why shouldn't it contain a challenge? (the reason given only relates
to the 'login interface itself').

   It is not intended to
   encourage deployment of captive portals -- only to limit the damage
   caused by them.

Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And
perhaps not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline <[email-masked]> wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

---

From: Vincent van Dam <[email-masked]>
Date: Sun, 7 May 2017 19:09:27 +0000

Is that because you don't expect all user-agents (webbrowsers specifically) to support it?

- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL

I agree, it makes more sense that the url would be in a response header instead (like the 30x status).

   It is not intended to

   caused by them.

Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

I agree, apis should use tls. Not every developer might agree though (a rest api containing weather predictions?).
But also, I don't think we can fix the world, fix every api/client that is ever made. We can only at least identify mitm 30x scenarios are implemented, and try to regulate that scenario a bit more, which has been done by introducing the 511.

________________________________
Van: Captive-portals [[email-masked]] namens David Bird [[email-masked]]
Verzonden: zondag 7 mei 2017 20:36
Aan: Erik Kline
CC: [email-masked]
Onderwerp: Re: [Captive-portals] practicality of 511 HTTP status code

I personally do not find it very useful in public access networks, because:
- A legacy 30X response will still be needed for some user-agents
- Returning 511 is still a man-in-the-middle response (nothing changed there)
- The response contains HTML that should contain the login URL (or a meta refresh, etc), which isn't a very well structured way to get the URL
- differences in how browsers handle the 'error' and the associated user experience

Why shouldn't it contain a challenge? (the reason given only relates to the 'login interface itself').

   It is not intended to

Damage? Hm...

In terms of non-browsers accessing apis, they should be using TLS! And perhaps not follow redirects or otherwise add some integrity to their api.

On Sun, May 7, 2017 at 1:05 AM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
I wanted to poll the group's thoughts on the usefulness of the rfc6585#section-6 511 HTTP status code.

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 May 2017 13:27:23 +1000

511 was defined with a fair dash of hope -- that someone would pick it up and run with it. 

It isn't complete; client behaviours need to be defined, probably through new media type(s) and/or HTTP response headers.

The nice thing about it is that its semantics are unambiguous; it's clear that you've got a response from the intervening network, NOT the endpoint you intended. That's helpful, especially for non-browser clients.

Cheers,

> On 7 May 2017, at 6:05 pm, Erik Kline <[email-masked]> wrote:
> 

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

---

From: Erik Kline <[email-masked]>
Date: Mon, 8 May 2017 19:11:19 +0900

If I read this correctly you're saying that if it were deemed useful,
hypothetically, a Location: header could be added to the server response?

On 8 May 2017 at 12:27, Mark Nottingham <[email-masked]> wrote:

> It isn't complete; client behaviours need to be defined, probably through
> new media type(s) and/or HTTP response headers.
>
> The nice thing about it is that its semantics are unambiguous; it's clear
> that you've got a response from the intervening network, NOT the endpoint
> you intended. That's helpful, especially for non-browser clients.
>
> Cheers,
>
>
> > I'm trying to get a sense of whether this will be a useful tool to use
> in assembling a recommended portal interaction.  If we determine it's not

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 May 2017 20:13:26 +1000

511 doesn't define semantics for Location, so not out of the box. You could revise the spec to do so, but it's probably easier just to define a new media type, or a use-case-specific header.

Cheers,

> On 8 May 2017, at 8:11 pm, Erik Kline <[email-masked]> wrote:
> 
> If I read this correctly you're saying that if it were deemed useful, hypothetically, a Location: header could be added to the server response?
>