[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] practicality of 511 HTTP status code
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 protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals
--
Mark Nottingham https://www.mnot.net/