Opened 7 years ago

Closed 5 years ago

#255 closed design (fixed)

Clarify status code for rate limiting

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: 18
Component: p2-semantics Severity: Active WG Document
Keywords: status-code rate-limit Cc:

Description

I have seen a few times blog post (example [1]) over API Rate Limits and HTTP response code. People designing APIs have difficulties it seems to find the appropriate HTTP response code. That led me a few weeks ago to look at what was done at a few services (not a complete survey, just curiosity)

There is no common practice around that. Should the HTTP specification have a specific code for this, or is there already everything appropriate?

Attachments (1)

255.diff (1.7 KB) - added by julian.reschke@… 5 years ago.
Proposed patch backing out [1310]

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by mnot@…

  • Owner set to mnot@…

Proposal: change first sentence of 503 definition 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.

comment:2 Changed 6 years ago by mnot@…

  • Milestone changed from unassigned to 14

Editorial input from Adrien de Croy:

Why not just say something like

"The server is currently unable or unwilling to handle the request."

Then give some explanatory text such as:

"The server may be prepared to handle the request if resubmitted after a delay. This is intended to be used for conditions including:

  • temporary overloading
  • server maintenance
  • client rate limiting
  • any case where service is temporarily unavailable.

the point I'm trying to make is if we define too narrowly the reasons why the code should be used, it will just invite issues later on when people search for an appropriate code to use for their new application which we didn't think about. where really the code just means "not right now".

comment:3 Changed 6 years ago by julian.reschke@…

  • Milestone changed from 14 to 15

comment:4 Changed 6 years ago by julian.reschke@…

From [1310]:

slightly expand the scope of 503 to include scenarios like rate limiting (see #255)

comment:5 Changed 6 years ago by julian.reschke@…

  • Resolution set to incorporated
  • Status changed from new to closed

comment:6 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:7 Changed 6 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:8 Changed 6 years ago by mnot@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

reopening, as I said I was going to.

comment:9 Changed 6 years ago by julian.reschke@…

  • Milestone changed from 15 to unassigned

comment:10 Changed 6 years ago by mnot@…

  • Priority changed from normal to later

Waiting to see the disposition of http-new-status; if it gets taken up by APPSAWG, we'll need to back this out.

comment:11 Changed 5 years ago by stpeter@…

http-new-status has been taken up as an AD-sponsored draft. Does that have implications for this ticket?

Changed 5 years ago by julian.reschke@…

Proposed patch backing out [1310]

comment:12 Changed 5 years ago by mnot@…

  • Milestone changed from unassigned to 18
  • Priority changed from later to normal

comment:13 Changed 5 years ago by julian.reschke@…

From [1486]:

take out new text for 503 covering rate limiting [1310] (because of status 429 defined in http://tools.ietf.org/html/draft-nottingham-http-new-status-03#section-4) (see #255)

comment:14 Changed 5 years ago by julian.reschke@…

  • Resolution set to incorporated
  • Status changed from reopened to closed

comment:15 Changed 5 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:16 Changed 5 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.