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
This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC