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

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 <ek@google.com> 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?
> 
> On 8 May 2017 at 12:27, Mark Nottingham <mnot@mnot.net> wrote:
> 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 <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
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

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