- From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
- Date: Mon, 19 Oct 2009 00:55:56 -0500
- To: Adrien de Croy <adrien@qbik.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote: > >> This does not address my specific concern, which is to beat into the implementors >> heads not to aggressively retry parallel connections where none will be permitted; >> > Do we therefore need some wording on how a client should detect such > cases, and respond? E.g. since there's no specific status code for a > rejection based on number of concurrent connections, it would at best be > an assumption that this is occuring. I agree hammering away would be > problematic. The larger issue is that server implementors (rightfully) do proceed to blacklist the relevant IP addresses as abusive, whether at the firewall/load balancer or http server demarcation. My comment was ment to illustrate that this behavior is correct, and that the client behavior is invalid. We can't implement a server response code to a dropped/refused connection; it is up to the client to determine that a second/third/fourty-fifth connection is unwelcome and stay at level or back off from consuming excessive services.
Received on Monday, 19 October 2009 05:56:34 UTC