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

The idea behind 511 was that it's an explicit signal that the response is NOT from the origin.

The payload will be displayed by browsers that don't understand its semantics, and you can use JS or http-equiv redirects if you want to send that user somewhere else.

The real value only comes when a) browsers understand its semantics, and b) a payload format is designed to do something interesting with them.

Cheers,

> On 24 Jun 2017, at 4:53 am, Dave Dolson <ddolson@sandvine.com> wrote:
> 
> Probably all of those codes are used, as well as 200 (with content).
> We could debate which is best, but that's a distraction, since we want portals to stop pretending to be the real end-point.
> (FWIW, I think 301 is a bad idea, since later requests should try the real URI again.)
> 
> My hypothesis is that 511 is an acceptable thing to send an old (pre-RFC6585) device, when there is no expectation of causing user interaction.
> 
> -Dave
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@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 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 first place? Wouldn't it be better to use 301/302 or even 303?
> 
> Best regards, Julian
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

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