[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/