From c04ef8e652de3d72aa547063e59aff5277908354 Mon Sep 17 00:00:00 2001
From: Will Hunt <will@half-shot.uk>
Date: Wed, 13 Mar 2024 14:43:24 +0000
Subject: [PATCH] Update content and move ratelimit section.

---
 content/client-server-api/_index.md | 46 ++++++++++++++++-------------
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md
index a2af7971..94d1e682 100644
--- a/content/client-server-api/_index.md
+++ b/content/client-server-api/_index.md
@@ -106,7 +106,7 @@ No resource was found for this request.
 
 `M_LIMIT_EXCEEDED`
 Too many requests have been sent in a short period of time. Wait a while
-then try again.
+then try again. See [Rate limiting section](#rate-limiting)
 
 `M_UNRECOGNIZED`
 The server did not understand the request. This is expected to be returned with
@@ -212,6 +212,28 @@ only read state (e.g.: `/sync`, get account data, etc).
 The user is unable to reject an invite to join the server notices room.
 See the [Server Notices](#server-notices) module for more information.
 
+#### Rate limiting
+
+Homeservers SHOULD implement rate limiting to reduce the risk of being
+overloaded. If a request is refused due to rate limiting, it should
+return a standard error response of the form:
+
+```json
+{
+  "errcode": "M_LIMIT_EXCEEDED",
+  "error": "string",
+  "retry_after_ms": integer (optional, deprecated)
+}
+```
+
+The `retry_after_ms` key SHOULD be included to tell the client how long
+they have to wait in milliseconds before they can try again.
+
+{{% added-in v="1.10" %}}
+
+The `Retry-After` HTTP header SHOULD be specified by the server on any 429
+code response. It SHOULD be preferred by clients, falling back to `retry_after_ms`.
+
 ### Transaction identifiers
 
 The client-server API typically uses `HTTP PUT` to submit requests with
@@ -2523,25 +2545,9 @@ not have to perform extra round trips to query it.
 
 ## Security
 
-### Rate limiting
-
-Homeservers SHOULD implement rate limiting to reduce the risk of being
-overloaded. If a request is refused due to rate limiting, it should
-return a standard error response of the form:
-
-```json
-{
-  "errcode": "M_LIMIT_EXCEEDED",
-  "error": "string",
-  "retry_after_ms": integer (optional)
-}
-```
-
-The `retry_after_ms` key SHOULD be included to tell the client how long
-they have to wait in milliseconds before they can try again.
-
-The `Retry-After` HTTP header MAY be specified by the server. When this header
-is set, it SHOULD be preferred by clients over the `retry_after_ms` value.
+{{% boxes/note %}}
+The rate limiting section is now part of the [API standards section](#rate-limiting).
+{{% /boxes/note %}}
 
 ## Modules