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

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



I think the 511 fits one use-case, being the scenario where http traffic is intercepted by the nas and the user is redirected with a http 302/307 status code to a captive portal. The 511 would be, imo, the right status code to use instead of 302/307.


Since the 511 status is an error http status code; it has a higher chance of signalling unaware clients there is something wrong. The goal of the nas for intercepting the http request is to show a captive portal, and only applications that did http requests and are able to present that captive portal (webbrowsers) should gracefully handle this status code. 


Since 511 is an error code; I would expect that some application doing e.g. an api call over http or fetching some static configuration file are able to better handle this than being redirected to something that can’t be interpreted (but produced a success status code). If the 511 status code would be used, the response would likely be already considered as an error because. I think it will also improve fetching resources (images/_javascript_s) in a the captive state, these should fail immediately as well with an error (instead of each resource returning the captive portal markup).


I am also very curious about at least the adoption and support of this status code.



Van: Captive-portals [[email protected]] namens Erik Kline [[email protected]]
Verzonden: zondag 7 mei 2017 10:05
Aan: [email protected]
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 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.