511 seems a little pointless -- browsers can treat it differently, but if the intermediate gateway intends to be malicious, then it won't return 511 anyway. The only useful thing I can see is avoiding accidents/attacks on the gateway compromising its clients.
It has nothing to do with security, but it's not pointless. It tells the client that this response did not come from the server it attempted to contact. This is especially useful for non-browser clients that will otherwise simply choke on the 302 redirect normally used for this purpose, but it could also be useful for browsers to present a better UI for signing on to the internet.
My only concern is that 511 could be seen as legitimizing the practice of putting silly click-through terms-of-service roadblocks on free wi-fi (making it impossible for devices to connect without a human operating a web browser), but since people are doing it anyway we might as well support it properly.
It'd be interesting to see whether adding authentication/sign on to a protocol like DHCP would fit better. The hijacking of HTTP, while it obviously works well in the default case, seems nasty and this error code fixes the wrong problem. Better to have a DHCP field that tells you to visit a specific website to log in; then the OS could display that website when you connect to the wireless.
A further advantage of putting it into the connectivity protocols is it makes automatic payment and negociation by the client's software possible—for example, connecting to the cheapest wifi in range.
There are some problems worth solving that take longer than 10 years to figure out. Given time, a standard for discovering and connecting to a commercial network will emerge. Cell phones already have something like this with their preferred roaming lists, and AIUI long-haul telecoms will switch call routing and pricing on the fly based on other telecoms' pricing and routing changes. It's a matter of getting the standard designed, ratified (optional step), widely adopted by commercial access point manufacturers, then deployed on end-user devices.
I got bit by this using the Emacs package manager. It follows redirects, so it ended up trying to fetch a package and getting back a bunch of HTML with a 200 response code, which it tried to byte-compile with about as spectacular a failure as you would imagine.
> My only concern is that 511 could be seen as legitimizing the practice of putting silly click-through terms-of-service roadblocks on free wi-fi (making it impossible for devices to connect without a human operating a web browser), but since people are doing it anyway we might as well support it properly.
Filter on User-Agent to only show terms to browser. If non-human agent spoofs browser signature, it’s their own fault.
Changing behavior based on user agent is antithetical to the goals of having a semantic web. The ideal is to allow the user to use whatever software they want to connect to the network and access information.
I don't think 511 is so much for security, I see it as being more focused on usability. For example if you have thick client program that talks to a backend server (perhaps for updates) and it receives a 511 response it can then tell the user that they need to login to the proxy (or just pop up a web browser for them).
Exactly: a good example is how OS X currently works - everytime you connect to a new WiFi hotspot it fires a request to a static page on Apple's server in the background, to determine whether or not you have to sign in. If it detects unexpected content it assumes it's a sign-in page for a WiFi hotspot, and presents it modally.
Under this proposed system the OS can simply check for an appropriate HTTP response code, which makes life a little easier.
