Re: #131: Connection limits (proposal)

Mark Nottingham wrote:
> ...
> My .02 - both of these proposed requirements are quite vague and can't 
> be tested. I'd put forth that client authors know full well whether 
> they're being abusive, and a few sentences in HTTP isn't going to 
> convince them not to be. At the most, we might add something like
> 
> """
> Note that servers might reject traffic that they deem abusive, including 
> an excessive number of connections from a client.
> ""
> ...

OK, proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/131/131.diff>

Full text including context:

7.1.4.  Practical Considerations

    Servers will usually have some time-out value beyond which they will
    no longer maintain an inactive connection.  Proxy servers might make
    this a higher value since it is likely that the client will be making
    more connections through the same server.  The use of persistent
    connections places no requirements on the length (or existence) of
    this time-out for either the client or the server.

    When a client or server wishes to time-out it SHOULD issue a graceful
    close on the transport connection.  Clients and servers SHOULD both
    constantly watch for the other side of the transport close, and
    respond to it as appropriate.  If a client or server does not detect
    the other side's close promptly it could cause unnecessary resource
    drain on the network.

    A client, server, or proxy MAY close the transport connection at any
    time.  For example, a client might have started to send a new request
    at the same time that the server has decided to close the "idle"
    connection.  From the server's point of view, the connection is being
    closed while it was idle, but from the client's point of view, a
    request is in progress.

    This means that clients, servers, and proxies MUST be able to recover
    from asynchronous close events.  Client software SHOULD reopen the
    transport connection and retransmit the aborted sequence of requests
    without user interaction so long as the request sequence is
    idempotent (see Section 7.1.2 of [Part2]).  Non-idempotent methods or
    sequences MUST NOT be automatically retried, although user agents MAY
    offer a human operator the choice of retrying the request(s).
    Confirmation by user-agent software with semantic understanding of
    the application MAY substitute for user confirmation.  The automatic
    retry SHOULD NOT be repeated if the second sequence of requests
    fails.

    Servers SHOULD always respond to at least one request per connection,
    if at all possible.  Servers SHOULD NOT close a connection in the
    middle of transmitting a response, unless a network or client failure
    is suspected.

    Clients (including proxies) SHOULD limit the number of simultaneous
    connections that they maintain to a given server (including proxies).

    Previous revisions of HTTP gave a specific number of connections as a
    ceiling, but this was found to be impractical for many applications.
    As a result, this specification does not mandate a particular maximum
    number of connections, but instead encourages clients to be
    conservative when opening multiple connections.

    In particular, while using multiple connections avoids the "head-of-
    line blocking" problem (whereby a request that takes significant
    server-side processing and/or has a large payload can block
    subsequent requests on the same connection), each connection used
    consumes server resources (sometimes significantly), and furthermore
    using multiple connections can cause undesirable side effects in
    congested networks.

    Note that servers might reject traffic that they deem abusive,
    including an excessive number of connections from a client.

Also, in the Changes Section:

    Remove hard limit of two connections per server.  (Section 7.1.4)

Best regards,

Julian

Received on Tuesday, 20 October 2009 08:55:38 UTC