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

; Mark Nottingham Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] practicality of 511 HTTP status code On 2017-06-27 16:56, Dave Dolson wrote: > Mark, thanks for the info about 511. > > But to the working group, I think this discussion about HTTP status codes is > a distra

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

On Tue, Jun 27, 2017 at 8:55 AM, Julian Reschke wrote: > On 2017-06-27 16:56, Dave Dolson wrote: > >> Mark, thanks for the info about 511. >> >> But to the working group, I think this discussion about HTTP status codes >> is a distraction. >> >> I think the ICMP approach

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

On 2017-06-27 16:56, Dave Dolson wrote: Mark, thanks for the info about 511. But to the working group, I think this discussion about HTTP status codes is a distraction. I think the ICMP approach is a superior solution that doesn't require modification of transport-layer data. Redirection of

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

network. -Dave -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Friday, June 23, 2017 9:32 PM To: Dave Dolson Cc: Julian F. Reschke; Vincent van Dam; David Bird; Erik Kline; captive-portals@ietf.org Subject: Re: [Captive-portals] practicality of 511 HTTP status code

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

ne > Cc: captive-portals@ietf.org > Subject: Re: [Captive-portals] practicality of 511 HTTP status code > > On 2017-06-23 20:11, Dave Dolson wrote: >> It seems 511 is probably better than 30x for non-browser >> requests-clearly an error instead of redirecting to something

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

[mailto:julian.resc...@gmx.de] Sent: Friday, June 23, 2017 2:34 PM To: Dave Dolson; Vincent van Dam; David Bird; Erik Kline Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] practicality of 511 HTTP status code On 2017-06-23 20:11, Dave Dolson wrote: It seems 511 is probably better than 30x

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

; Erik Kline Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] practicality of 511 HTTP status code On 2017-06-23 20:11, Dave Dolson wrote: > It seems 511 is probably better than 30x for non-browser > requests-clearly an error instead of redirecting to something unexpected. >

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

On 2017-06-23 20:11, Dave Dolson wrote: It seems 511 is probably better than 30x for non-browser requests—clearly an error instead of redirecting to something unexpected. Is 511 likely to be OK for old IoT devices? Probably a better outcome than 307. ... FWIW, why is *307* desirable in the

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

: zondag 7 mei 2017 20:36 Aan: Erik Kline CC: captive-portals@ietf.org Onderwerp: 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

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

Onderwerp: [Captive-portals] practicality of 511 HTTP status code 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

[Captive-portals] practicality of 511 HTTP status code

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