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

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 <ek@google.com> wrote:

> 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.
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>