Subject: [Webpush] Provide a method to indicate rate-limit issues

From: Benjamin Bangert <[email-masked]>
Date: Fri, 30 Oct 2015 12:24:04 -0700

It would be nice to have a uniform way to indicate to an Application Server
that its being rate-limited and it should back-off on its sending, in a
separate way than using a 503. 503's are used for a variety of issues,
separate from rate-limiting, perhaps a different status code, and/or a
header indicating when the app-server should resume.

Cheers,
Ben

---

From: Brian Raymor <[email-masked]>
Date: Sat, 31 Oct 2015 22:04:54 +0000

On October 31 2015 at 4:24 AM, Benjamin Bangert <[email-masked]> wrote:

> It would be nice to have a uniform way to indicate to an Application Server that its being rate-limited
> and it should back-off on its sending, in a separate way than using a 503. 503's are used for a variety
> of issues, separate from rate-limiting, perhaps a different status code, and/or a header indicating
> when the app-server should resume.

The earlier proposal from JR - http://www.ietf.org/mail-archive/web/webpush/current/msg00308.html - was to include a reference to 429 with Retry-Header:

https://tools.ietf.org/html/rfc6585

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request.

   For example:

   HTTP/1.1 429 Too Many Requests
   Content-Type: text/html
   Retry-After: 3600

Would this address your requirements? 

...Brian