Re: API Rate Limits and HTTP Code [#255]

Le 10 févr. 2011 à 01:06, Mark Nottingham a écrit :
> Back to the original question here; should 503's definition be modified to explicitly allow rate limiting?
> 
> Proposal -- add one paragraph:

Putting the message in context
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-8.5.4

CURRENT TEXT

    8.5.4.  503 Service Unavailable

   The server is currently unable to handle the request due
   to a temporary overloading or maintenance of the server.
   The implication is that this is a temporary condition
   which will be alleviated after some delay. If known, the
   length of the delay MAY be indicated in a Retry-After
   header field. If no Retry-After is given, the client
   SHOULD handle the response as it would for a 500
   response.

|  The meaning of "overloaded" is defined by and specific to
|  the server, and can be selective (e.g., too many requests
|  from a particular user).
   
        Note: The existence of the 503 status code does not
        imply that a server must use it when becoming
        overloaded. Some servers might wish to simply refuse
        the connection.

I would propose (but maybe too detailed for the group?).

PROPOSAL for the additional text

    The meaning of "overloaded" is defined by and specific to
    the server, and can be selective depending on the request
    URI and its associated headers. For example, it doesn't 
    necessary mean a server malfunction but can be a notification 
    to inform the client that the server is used in excess for a 
    specific service (e.g., too many requests from a particular 
    user for an API).

For date, I guess it is ok. As the server should be able to create a date.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-08#section-9.3
    
     2. If the response status code conveys a server error, e.g.
    500 (Internal Server Error) or 503 (Service Unavailable),
    and it is inconvenient or impossible to generate a valid
    Date.


-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

Received on Thursday, 10 February 2011 20:03:32 UTC