W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

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

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 27 Mar 2011 16:16:41 +0200
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Bryce Nesbitt <bnesbitt@bepress.com>
Message-Id: <20455E3A-4B51-46BC-85F4-B0A5572D7B53@mnot.net>
To: Karl Dubost <karld@opera.com>
I think it's a bit too detailed. How about just changing the first sentence to:

The server is currently unable or unwilling to handle the request due to a temporary overloading, maintenance of the server, or rate limiting of the client.

Cheers,


On 10/02/2011, at 9:02 PM, Karl Dubost wrote:

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

--
Mark Nottingham   http://www.mnot.net/
Received on Sunday, 27 March 2011 14:17:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT