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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf