These all seem immediately practical status codes that add semantics I've been wanting. Great! In particular I am happy about the 429 Too Many Requests header, as every time I've done rate throttling I've had to quibble over what code to actually send back.
New HTTP Codes
21–30 of 84 posts
Re: New HTTP Codes
#22I wish HTTP requests submitted time zone information.
1995 - shot down because (paraphrasing) "I don't need this so neither should you": http://www.hpl.hp.com/personal/ange/archives/archives-95/htt...
The general consensus seems to be that since this can never be all things to all people, we can't ever implement it. To me it seems like this is crying out for a Worse is Better solution.
Re: New HTTP Codes
#23Re: New HTTP Codes
#24These all seem immediately practical status codes that add semantics I've been wanting. Great! In particular I am happy about the 429 Too Many Requests header, as every time I've done rate throttling I've had to quibble over what code to actually send back.
What code did you use? I've typically used a 408 in a throttling use case but it never seemed to fit well (our client handled this response from our server with an exponential back off so we were not relying on another client to handle it correctly).
Re: New HTTP Codes
#25Summary: 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 511 Network Authentication Required I've been using 414 Request-URI Too Long for 431 and 503 Service Temporarily Unavailable for 429
Re: New HTTP Codes
#26Earlier quoted context omitted.
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, w…
Re: New HTTP Codes
#27511 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…
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.
Re: New HTTP Codes
#28Re: New HTTP Codes
#29I wish HTTP requests submitted time zone information.
http://groups.google.com/group/mozilla.dev.platform/browse_t...
It offers reasons why it's a bad idea, and an alternative (in HTML5 instead of HTTP).
Re: New HTTP Codes
#30Earlier quoted context omitted.
What code did you use? I've typically used a 408 in a throttling use case but it never seemed to fit well (our client handled this response from our server with an exponential back off so we were not relying on another client to handle it correctly).
503 seems the most appropriate of the current codes ("The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.")
A new error code is definitely needed.