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

We send this mail from a law firm.
We are not interested in receiving emails advertising.
Under Law 34/2002 of 11 July, Services of information society and electronic commerce, you are notified about the responsibility that you may incur if you keep sending emails.
We want that our data are deleted from its database
Sincerely.

EVIAL ASESORES
Juan M. Sierra Lebrón
jsierra@economistes.com 
C/ Pau Claris, 190 - 2º 1ª  -  08037 Barcelona
Telf. 935 157 234 -  Fax 934 873 677

Cláusula confidencial
El contenido de este mensaje y cualquier documento adjunto al mismo son confidenciales. Tienen el sólo propósito de su uso por el individuo o entidad designado como receptor. Si recibe este mensaje por error, se le informa, que su lectura, divulgación, copia o distribución está estrictamente prohibida y le rogamos nos lo notifique por e-mail a (jsierra@economistes.com).
 Antes de imprimir este e-mail, piense bien si es necesario hacerlo.


-----Mensaje original-----
De: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] En nombre de Willy Tarreau
Enviado el: viernes, 29 de octubre de 2010 7:59
Para: Eric J. Bowman
CC: Mark Nottingham; Karl Dubost; HTTP Working Group
Asunto: Re: API Rate Limits and HTTP Code [#255]

On Thu, Oct 28, 2010 at 07:45:16PM -0600, Eric J. Bowman wrote:
> Mark Nottingham wrote:
> > 
> > a) Clarify that 503 can be used for rate limiting, or
> > 
> 
> +1
> 
> I just came across this issue, too, but didn't bookmark -- Twitter's
> Fail Whale is a 503; now cute rate-limit responses are proliferating,
> but not everybody agrees on what status code to use, which surprises me.
> I always assumed rate-limiting was kinda the whole point of 503.

I agree that 503 could match this purpose but I have a problem with using
503. It's commonly tracked in logs to look for service faults (eg: unavailable
server/service). Reusing it as a "normal error" can make this tracking a lot
more complex. In my opinion, 503 really means the service is down (possibly
for a limited time as reported with Retry-After) while here we're more likely
saying "I have a limited capacity, please take your ticket and wait a bit",
which is more about congestion control. Perhaps a new 5xx would fit ?

I'm even thinking we might also like an equivalent in the 1xx response codes,
with the connection remaining open, in the same vein we have 100 Continue.
We could imagine something like "102 please hold the line" once in a while,
indicating that the service is not dead, finally followed by the real
response. It would be really nice for traffic serialization.

Willy

Received on Friday, 29 October 2010 07:54:40 UTC