search

mastodon / fediverse_auxiliary_service_provider_specifications

Specifications for Fediverse Auxiliary Service Providers
33 stars 2 forks source link

Rate limiting should use standard headers #21

Closed ThisIsMissEm closed 3 weeks ago

ThisIsMissEm commented 1 month ago

If rate limits are imposed, FASP MUST return the HTTP status code 429 (Too Many Requests) on rate-limited responses and provide a Retry-After HTTP header with the number of seconds the fediverse server needs to wait before it can retry this particular request.

Whilst Retry-After is a Mastodon specific header, it would likely be best to suggest using the HTTP API Rate Limit header which is currently being defined (it's apparently "expired" at the moment, but I believe it's moving forwards): https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-07.html

oneiros commented 1 month ago

Whilst Retry-After is a Mastodon specific header

Um, no it is not: https://datatracker.ietf.org/doc/html/rfc9110#name-retry-after

I am happy to use whatever people are most comfortable with. I only had to implement this in a client once that I can remember and I am pretty sure this was with a Retry-After header. I know other headers exist for a similar purpose, but went with what I knew here.

I also purposely omitted the Retry-After header's other variant where it can give an HTTP-date, because I think that number of seconds is easier to implement.

But if other headers are more popular and/or easier to implement in popular frameworks, then by all means we should use those.

ThisIsMissEm commented 1 month ago

Oh! I must've missed that, I'm guessing this could be why the aforementioned internet draft stalled.

In which case, I think we'd be well served to reference that RFC when talking about the header so everyone knows exactly what is to be expected