Sorry for the delay in responding; just back from holiday.
On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: > Julian, > > I'm sure that in your view one sentence is adequate to explain > all the security implications of each status code. However, > you may want to consider that some readers may not have quite > the same deep grasp of the matter that you do. Therefore, > I think it would be wise to provide more explanation. Here's an > example for section 7.2 on status code 429 (Too Many Requests): > > Section 7.2 429 Too Many Requests > > While status code 429 can be helpful in figuring out why a > server is not responding to requests, it can also be harmful. > When a server is under attack or simply receiving a very > large number of requests from a single party, responding > to each of these requests with a 429 status code will consume > resources that could be better used in other ways. Therefore, > a server in such circumstances may choose to send a 429 status > code only the first time a client exceeds its limit and > ignore subsequent requests from this client until its limit > is no longer exceeded. Other approaches may also be employed. > > As you can see, I described security problems that could occur > with this status code and explained how those problems can be > avoided or mitigated. While it's true that these problems > could occur when a more generic status code is used to handle > the case of "too many requests", that does not mean that they > are not relevant to this document. On the contrary, the fact > that this document is providing more detailed status codes > gives us the opportunity and one can argue the obligation to > provide more detailed security analysis relevant to these more > detailed status codes. I'm really not sure I agree; the original text is: Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. If someone implementing a server doesn't understand that, I don't know that using more words really helps; it does, however, make it harder to find the words in the spec that *will* help. -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
