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

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

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

Attachment: smime.p7s