Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4041: http header Retry-After for http code 429 #4041

Merged
merged 12 commits into from
Feb 19, 2024
50 changes: 50 additions & 0 deletions proposals/4041-retry-after-header-rate-limiting.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# MSC4041: Use http header Retry-After to enable library-assisted retry handling

The current Matrix Client-Server API (v1.7) recommends that home servers should protect themselves from
being overloaded by enforcing rate-limits to selected API calls.
If home servers limit access to an API they respond with an http error code 429 and a response body
that includes a property `retry_after_ms` to indicate how long a client has to wait before retrying.

Some http libraries (like [Ky](https://github.com/sindresorhus/ky), [got](https://github.com/sindresorhus/got
and [urllib3](https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry)) ease
the burden of handling retries by honoring the http header `Retry-After`. As explained in
[RFC 9119 - HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110#field.retry-after) this header is optional
and contains either a (relative) value for the delay in seconds or an (absolute) date.

The current Matrix Client Server API specification does not take this header into account. This wastes the
potential that current http libraries offer in terms of automated retry handling.

## Proposal

In order to allow developers to make use of the automated retry handling capabilities of http libraries
home servers shall use the http header `Retry-After` in case they respond with an http error 429.
The value of `Retry-After` (in __seconds__) is meant to be a delay after receiving the response and must be
calculated in order to comply with the specification in [RFC 9119 - HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110#field.retry-after).

With the introduction of the http header `Retry-After` the usage of the existing `retry_after_ms` property in the response body becomes deprecated.

ThomasHalwax marked this conversation as resolved.
Show resolved Hide resolved
## Potential issues

In order to maintain backward compatibility with existing client libraries home servers shall use both the `Retry-After` header and the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In order to maintain backward compatibility with existing client libraries home servers shall use both the `Retry-After` header and the
In order to maintain backward compatibility with existing client libraries homeservers shall use both the `Retry-After` header and the

minor nitpick: homeserver is one word

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a couple of other occurrences of the incorrect spelling as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will apply manually after merging - can't edit the PR itself.

`retry_after_ms` property in the response body.

Client libraries shall use the values in this order:

1) `Retry-After` http header.
2) `retry_after_ms` property in the response body.

## Alternatives

N/A

## Security considerations

N/A

## Unstable prefix

Since this MSC is using a standard HTTP header, it will not use a unstable prefix.

## Dependencies

N/A
Loading