[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


> On 24 Jun 2017, at 4:53 am, Dave Dolson <[email protected]> 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:[email protected]] 
> Sent: Friday, June 23, 2017 2:34 PM
> To: Dave Dolson; Vincent van Dam; David Bird; Erik Kline
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals

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