Re: #131: Connection limits (proposal)

William A. Rowe, Jr. wrote:
> 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.
>   
but the client in this case - what is the chance of it being a 
human-operated browser?

I've seen cases where the server starts responding with a 503 (google 
maps does this if you scroll around for too long).

If the connection rate is deemed high enough to be a DOS attack, that is 
a different issue - one I'd be reluctant to try and address in HTTP.

If there will be no response to the client, I think all bets are off, 
but which clients are we talking about?  Custom attack clients?  They 
will ignore any requirement they like anyway.

Otherwise if a site blacklists an IP due to bona fide human activity, I 
would argue perhaps the threshold is too low.  People can create other 
problems by setting arbitrary limits, arbitrarily deciding what 
constitutes abuse vs acceptable use etc.

None of these I believe would be solved by a recommendation in HTTP though?

> 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.
>   

I think this could be solved with a status code.  Disconnecting at a 
firewall gives an ambiguous message.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Monday, 19 October 2009 07:08:27 UTC