+ ...
+
+
+The following `103` early hint response indicates a stylesheet `style.css` might be needed by the final response.
+
+http
+
+ 103 Early Hint
+ Link: ; rel=preload; as=style
+
+
+Subsequently the server sends the final response. This includes a link to the stylesheet, which may already have been preloaded from the early hint.
+
+http
+
+ 200 OK
+ Content-Type: text/html
+
+
+ ...
+
+ ...
+
+
+The following example shows the same early hint response but with a `Content-Security-Policy` header included.
+
+http
+
+ 103 Early Hint
+ Content-Security-Policy: style-src: self;
+ Link: ; rel=preload; as=style
+
+
+The early response restricts preloading to the same origin as the request. The stylesheet will be preloaded if the origin matches.
+
+The final response might set the CSP to `none`, as shown below. The stylesheet has already been preloaded, but will not be used when rendering the page.
+
+http
+
+ 200 OK
+ Content-Security-Policy: style-src: none;
+ Content-Type: text/html
+
+
+ ...
+
+ ...
+
+
+### Specifications
+
+Specification
+
+[An HTTP Status Code for Indicating Hints
+\# early-hints](https://httpwg.org/specs/rfc8297.html#early-hints)
+
+[HTML
+\# early-hints](https://html.spec.whatwg.org/multipage/semantics.html#early-hints)
+
+### Browser compatibility
+
+### See also
+
+* [`Link`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Link)
+* [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
+* [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
+* [`rel="preconnect"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect) ([``](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [`rel="preload"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload) ([``](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [`fetchpriority`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link#fetchpriority) ([``](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [Early Hints update: How Cloudflare, Google, and Shopify are working together to build a faster Internet for everyone](https://blog.cloudflare.com/early-hints-performance/) from the Cloudflare blog
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/103](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/103)
diff --git a/content/200.md b/content/200.md
index 15dd27fb..5cc7a219 100644
--- a/content/200.md
+++ b/content/200.md
@@ -1,20 +1,80 @@
## Description
-The HTTP `200 OK` success status response code indicates that the request has succeeded. A 200 response is cacheable by default.
+The HTTP **`200 OK`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that a request has succeeded. A `200 OK` response is cacheable by default.
-The meaning of a success depends on the HTTP request method:
+A `200 OK` response has a different meaning and format depending on the HTTP request method. Here's how they vary for different methods:
-- `GET`: The resource has been fetched and is transmitted in the message body.
-- `HEAD`: The representation headers are included in the response without any message body
-- `POST`: The resource describing the result of the action is transmitted in the message body
-- `TRACE`: The message body contains the request message as received by the server.
+* [`GET`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET): A resource was retrieved by the server and included in the response body.
+* [`POST`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST): An action succeeded; the response has a message body describing the result.
+* [`HEAD`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/HEAD): Identical to `GET`, except there is no message body.
+* [`TRACE`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/TRACE): The response has a message body containing the request as received by the server.
-The successful result of a `PUT` or a `DELETE` is often not a `200 OK` but a `204 No Content` (or a `201 Created` when the resource is uploaded for the first time).
+Although possible, successful [`PUT`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/PUT) or [`DELETE`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/DELETE) requests often do not result in a `200 OK` response. It is more common to see [`201 Created`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201) if the resource is uploaded or created for the first time, or [`204 No Content`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204) upon successful deletion of a resource.
-### See Also
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.200)
-- [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
-- [204 No Content](https://http.cat/status/204)
-- [201 Created](https://http.cat/status/201)
+### Examples
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200)
+In this example, a successful `GET` request to `https://example.com` returns a `200 OK` response. The response includes representation headers and a message body with the HTML content:
+
+http
+
+ HTTP/1.1 200 OK
+ Accept-Ranges: bytes
+ Age: 294510
+ Cache-Control: max-age=604800
+ Content-Type: text/html; charset=UTF-8
+ Date: Fri, 21 Jun 2024 14:18:33 GMT
+ Etag: "3147526947"
+ Expires: Fri, 28 Jun 2024 14:18:33 GMT
+ Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
+ Server: ECAcc (nyd/D10E)
+ X-Cache: HIT
+ Content-Length: 1256
+
+
+
+
+
+Assuming a form exists to send data to an endpoint for managing subscriptions at `http://example.com/subscribe`. A `POST` request to subscribe a user may look like the following:
+
+http
+
+ POST /subscribe HTTP/1.1
+ Host: example.com
+ Content-Type: application/x-www-form-urlencoded
+ Content-Length: 50
+
+ name=Brian%20Smith&email=brian.smith%40example.com
+
+
+In this example, a response with a `200 OK` status could look like this:
+
+http
+
+ HTTP/1.1 200 OK
+ Content-Type: application/json
+
+ {
+ "message": "User subscription pending. A confirmation email has been sent.",
+ "subscription": {
+ "name": "Brian Smith",
+ "email": "brian.smith@example.com",
+ "id": 123,
+ "feed": "default"
+ }
+ }
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.200](https://www.rfc-editor.org/rfc/rfc9110#status.200)
+
+### See also
+
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+* Glossary: [Idempotent](https://developer.mozilla.org/en-US/docs/Glossary/Idempotent)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200)
diff --git a/content/201.md b/content/201.md
index 78e0a120..a860063e 100644
--- a/content/201.md
+++ b/content/201.md
@@ -1,19 +1,55 @@
## Description
-The HTTP `201 Created` success status response code indicates that the request has
-succeeded and has led to the creation of a resource.
+The HTTP **`201 Created`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that the HTTP request has led to the creation of a resource. This status code is commonly sent as the result of a [`POST`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST) request.
-The new resource, or a description
-and link to the new resource, is effectively created before the response is sent back
-and the newly created items are returned in the body of the message, located at either
-the URL of the request, or at the URL in the value of the `Location` header.
+The new resource, or a description and link to the new resource, is created before the response is returned. The newly-created items can be returned in the body of the response message, but must be locatable by the **URL of the initiating request** or by the URL in the value of the [`Location`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Location) header provided with the response.
-The common use case of this status code is as the result of a `POST`
-request.
+### Examples
-### See Also
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.201)
-- [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
+Let's assume there's a REST API for managing users with an endpoint at `http://example.com/users`. In this example, we send a `POST` request with the following body to create a user:
+http
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201)
+ POST /users HTTP/1.1
+ Host: example.com
+ Content-Type: application/json
+
+ {
+ "firstName": "Brian",
+ "lastName": "Smith",
+ "email": "brian.smith@example.com"
+ }
+
+
+After successful user creation, the `201 Created` response will look like this:
+
+http
+
+ HTTP/1.1 201 Created
+ Content-Type: application/json
+ Location: http://example.com/users/123
+
+ {
+ "message": "New user created",
+ "user": {
+ "id": 123,
+ "firstName": "Brian",
+ "lastName": "Smith",
+ "email": "brian.smith@example.com"
+ }
+ }
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.201](https://www.rfc-editor.org/rfc/rfc9110#status.201)
+
+### See also
+
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/201)
diff --git a/content/202.md b/content/202.md
index 87a8d6c8..ad160c7e 100644
--- a/content/202.md
+++ b/content/202.md
@@ -1,19 +1,52 @@
## Description
-The HTTP `202 Accepted`
-response status code indicates that the request has been accepted for processing, but
-the processing has not been completed; in fact, processing may not have started yet.
+The HTTP **`202 Accepted`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that a request has been accepted for processing, but processing has not been completed or may not have started. The actual processing of the request is not guaranteed; a task or action may fail or be disallowed when a server tries to process it.
-The request might or might not eventually be acted upon, as it might be disallowed when
-processing actually takes place.
+A `202` response is non-committal, meaning there is no way to later send an asynchronous HTTP response to indicate the outcome of the processing. This response code is typically used when the request is handled by another process or server, or when requests are processed in batches.
-`202` is non-committal, meaning that there is no way for the HTTP to later send an
-asynchronous response indicating the outcome of processing the request. It is intended
-for cases where another process or server handles the request, or for batch processing.
+### Examples
-### See Also
-- [Spec](https://httpwg.org/specs/rfc9110.html#status.202)
-- [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept), the header that triggers the `202 Accepted` response
+In the following example, we want to kick off an automation process to email dog owners about a pickup task:
+http
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202)
+ POST /tasks HTTP/1.1
+ Host: example.com
+ Content-Type: application/json
+
+ {
+ "task": "emailDogOwners",
+ "template": "pickup"
+ }
+
+
+The response indicates that the request to start a task was accepted for processing. A URL is sent in the response body so the client can track changes to the status of the task:
+
+http
+
+ HTTP/1.1 202 Accepted
+ Date: Wed, 26 Jun 2024 12:00:00 GMT
+ Server: Apache/2.4.1 (Unix)
+ Content-Type: application/json
+
+ {
+ "message": "Request accepted. Starting to process task.",
+ "taskId": "123",
+ "monitorUrl": "http://example.com/tasks/123/status"
+ }
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.202](https://httpwg.org/specs/rfc9110.html#status.202)
+
+### See also
+
+* [`Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept)
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202)
diff --git a/content/203.md b/content/203.md
index 20ad3f43..3b72cc90 100644
--- a/content/203.md
+++ b/content/203.md
@@ -1,18 +1,50 @@
## Description
-The HTTP `203 Non-Authoritative Information` response
-status indicates that the request was successful but the enclosed payload has been
-modified by a transforming proxy from that of the origin
-server's `200 OK` response.
-
-The `203` response is similar to the value `214`,
-meaning `Transformation Applied`, of the `Warning` header
-code, which has the additional advantage of being applicable to responses with any
-status code.
-
-### See Also
-- [Spec](https://httpwg.org/specs/rfc9110.html#status.203)
-- [Proxy server](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)
-- [Warning](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Warning), the header that triggers the `203 Non-Authoritative Information` response
-
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/203)
+The HTTP **`203 Non-Authoritative Information`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that the request was successful, but a _transforming [proxy](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)_ has modified the headers or enclosed content from the origin server's [`200`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200) (`OK`) response.
+
+The purpose of this status code is to allow transforming proxies to notify clients when changes have been applied to successful responses, since this may impact decisions regarding the content later. Transformations to messages can mean modifications of headers to indicate that a resource is from a mirror or a backup, but may also mean modifying content in a way that are presumed to be desirable to the client. These modifications might include malware filtering, format transcoding, privacy filtering, or other hints to the client about future requests.
+
+The `203` response is similar to the [`214`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Warning#warning_codes) `Transformation Applied` value of the deprecated [`Warning`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Warning) header, which may be applicable to responses with any status code.
+
+### Examples
+
+In this example, a user sends a `GET` request for content with ID `123` to `example.com`.
+
+http
+
+ GET /comments/123 HTTP/1.1
+ Host: example.com
+
+
+A proxy has altered the message based on malware filtering rules for known unsafe attachments. The response content has been modified, replacing the `attachment_url` value to a link with information about the filtering in place:
+
+http
+
+ HTTP/1.1 203 Non-Authoritative Information
+ Date: Wed, 26 Jun 2024 12:00:00 GMT
+ Server: Apache/2.4.1 (Unix)
+ Content-Type: application/json
+ Content-Length: 123
+
+ {
+ "comment": "Check out my bio!",
+ "attachment_url": "https://example.com/attachment-unavailable-faq"
+ }
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.203](https://httpwg.org/specs/rfc9110.html#status.203)
+
+### See also
+
+* [`200`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200)
+* [Proxy server](https://developer.mozilla.org/en-US/docs/Glossary/Proxy_server)
+* [`Warning`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Warning)
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/203](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/203)
diff --git a/content/204.md b/content/204.md
index 8aff23f8..378234ad 100644
--- a/content/204.md
+++ b/content/204.md
@@ -1,19 +1,71 @@
## Description
-The HTTP `204 No Content` success status response code
-indicates that a request has succeeded, but that the client doesn't need to navigate away
-from its current page.
+The HTTP **`204 No Content`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that a request has succeeded, but the client doesn't need to navigate away from its current page. A `204` response is cacheable by default, and an [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) header is included in such cases.
+A `204 No Content` in response to these request methods has the following meaning and results:
-This might be used, for example, when implementing "save and continue editing" functionality for a wiki site.
-In this case a `PUT` request would be used to save the page, and the `204 No Content` response
-would be sent to indicate that the editor should not be replaced by some other page.
+* [`DELETE`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/DELETE): The action was successful, and no further information needs to be supplied.
+* [`PUT`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/PUT): The action was successful, and the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) value contains the entity tag for the new representation of that target resource.
-A `204` response is cacheable by default (an `ETag` header is included in such a response).
+A `204` response can be used when implementing "save and continue editing" functionality for applications like wiki sites. In this case, a [`PUT`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/PUT) request could be used to save the page contents, and a `204 No Content` response indicates to the browser that the editor should not be replaced by other content.
-### See Also
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.204)
-- [ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag), the header that allows caches to validate cached responses
-- [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
+Note that the response must not include any content or the [`Content-Length`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length) header (browsers may reject responses that include content).
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204)
+### Examples
+
+In this example, the client sends a request to delete an image using the `DELETE` method. The request includes an [`Authorization`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization) header with a token to authenticate the request:
+
+http
+
+ DELETE /image/123 HTTP/1.1
+ Host: example.com
+ Authorization: Bearer 1234abcd
+
+
+After successfully deleting the image, the server responds with a `204` response with no body, indicating no further information needs to be sent to the client.
+
+http
+
+ HTTP/1.1 204 No Content
+ Date: Wed, 26 Jun 2024 12:00:00 GMT
+ Server: Apache/2.4.1 (Unix)
+
+
+In this example, the client sends a `PUT` request to update a user's profile information. The request includes an [`Authorization`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization) header with a token to authenticate the request:
+
+http
+
+ PUT /users/123 HTTP/1.1
+ Host: example.com
+ Content-Type: application/json
+ Authorization: Bearer 1234abcd
+
+ {
+ "name": "Jane Doe",
+ "email": "jane@example.com"
+ }
+
+
+After successfully updating the user profile, the server responds with a `204` response. The [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) header contains the entity tag for the updated resource:
+
+http
+
+ HTTP/1.1 204 No Content
+ Date: Wed, 26 Jun 2024 12:00:00 GMT
+ ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ Server: Apache/2.4.1 (Unix)
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.204](https://www.rfc-editor.org/rfc/rfc9110#status.204)
+
+### See also
+
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204)
diff --git a/content/205.md b/content/205.md
index 5f28a448..2cf3559d 100644
--- a/content/205.md
+++ b/content/205.md
@@ -1,9 +1,48 @@
## Description
-The HTTP `205 Reset Content` response status tells the client to reset the document view (ie. clear the content of a form, reset canvas state or the UI).
+The HTTP **`205 Reset Content`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates that the request has been successfully processed and the client should reset the document view.
-### See Also
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.205)
-- [204 No Content](https://http.cat/status/204)
+This response is intended to support use cases where the user receives content that supports data entry, submits user-edited data in a request, and the content needs to be reset for the next entry. The instruction to "reset content" can mean clearing the contents of a form, resetting a canvas state, or refreshing a UI; the implementation depends on the client.
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/205)
+**Note:** In web applications that use the `205` status, it's assumed that the client handles resetting content after a `205` response. This is typically done via JavaScript, as resetting content such as forms after a `205` response is not handled natively by browsers.
+
+Note that the response must not include any content or the [`Content-Length`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length) header (browsers may reject responses that include content). The empty response may also be indicated using the [`Transfer-Encoding: chunked`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Transfer-Encoding) header with an empty chunk.
+
+### Examples
+
+The client in this example sends a `POST` request to submit a form with the comment `Hello!`:
+
+http
+
+ POST /submit HTTP/1.1
+ Host: example.com
+ Content-Type: application/x-www-form-urlencoded
+ Content-Length: 15
+
+ comment=Hello!
+
+
+After successfully processing the form submission, the server responds with the following `205` response, indicating that the client should reset the form.
+
+http
+
+ HTTP/1.1 205 Reset Content
+ Content-Type: text/html; charset=utf-8
+ Content-Length: 0
+ Date: Wed, 26 Jun 2024 12:00:00 GMT
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.205](https://www.rfc-editor.org/rfc/rfc9110#status.205)
+
+### See also
+
+* [`204`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204) No Content
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/205](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/205)
diff --git a/content/206.md b/content/206.md
index 01aed722..b660c0b5 100644
--- a/content/206.md
+++ b/content/206.md
@@ -1,22 +1,80 @@
## Description
-The HTTP `206 Partial Content` success status response code
-indicates that the request has succeeded and the body contains the requested ranges
-of data, as described in the Range header of the request.
+The HTTP **`206 Partial Content`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code is sent in response to a [range request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Range_requests). The response body contains the requested ranges of data as specified in the [`Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Range) header of the request.
-If there is only one range, the `Content-Type` of the whole response is
-set to the type of the document, and a `Content-Range` is provided.
+The format of the response depends on the number of ranges requested. If a single range is requested, the [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) of the entire response is set to the type of the document, and a [`Content-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Range) is provided. If several ranges are requested, the [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) is set to `multipart/byteranges`, and each fragment covers one range, with its own [`Content-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Range) and [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) headers describing it.
-If several ranges are sent back, the `Content-Type` is set to
-`multipart/byteranges` and each fragment covers one range, with
-`Content-Range` and `Content-Type` describing it.
+### Examples
-### See Also
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.206)
-- [If-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Range), a header that determines how to send ranges only if they have changed
-- [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range), a header that determines the range request of the body in the response
-- [Content-Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range), a header describing the content of the body
-- [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type), the header that indicates the media type of the resource
+The following is a sample `206` response when a single range of `21010-` (bytes 21010 to the end of file) of an image file is requested. The response contains [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) of `image/gif` and the [`Content-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Range) is provided:
+http
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206)
+ GET /z4d4kWk.gif HTTP/1.1
+ Host: images.example.com
+ Range: bytes=21010-
+
+
+http
+
+ HTTP/1.1 206 Partial Content
+ Date: Wed, 15 Nov 2015 06:25:24 GMT
+ Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+ Content-Range: bytes 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+ ETag: "abc123"
+ Accept-Ranges: bytes
+
+ # 26012 bytes of partial image data…
+
+
+Following is a sample `206` response when two ranges of a PDF file are requested. The response contains the `multipart/byteranges` [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) with a separate [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type) (`application/pdf`) and [`Content-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Range) for each range.
+
+http
+
+ GET /price-list.pdf HTTP/1.1
+ Host: example.com
+ Range: bytes=234-639,4590-7999
+
+
+http
+
+ HTTP/1.1 206 Partial Content
+ Date: Wed, 15 Nov 2015 06:25:24 GMT
+ Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+ Content-Length: 1741
+ Content-Type: multipart/byteranges; boundary=String_separator
+ ETag: "abc123"
+ Accept-Ranges: bytes
+
+ --String_separator
+ Content-Type: application/pdf
+ Content-Range: bytes 234-639/8000
+
+ # content of first range (406 bytes)
+ --String_separator
+ Content-Type: application/pdf
+ Content-Range: bytes 4590-7999/8000
+
+ # content of second range (3410 bytes)
+ --String_separator--
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics
+\# status.206](https://www.rfc-editor.org/rfc/rfc9110#status.206)
+
+### See also
+
+* [`If-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Range)
+* [`Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Range)
+* [`Content-Range`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Range)
+* [`Content-Type`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Type)
+* [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods)
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/206](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/206)
diff --git a/content/207.md b/content/207.md
index 30b44b62..c4fa08af 100644
--- a/content/207.md
+++ b/content/207.md
@@ -1,19 +1,62 @@
## Description
-The HTTP `207 Multi-Status` response code indicates that there might be a mixture of responses.
+The HTTP **`207 Multi-Status`** [successful response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#successful_responses) status code indicates a mixture of responses. This response is used exclusively in the context of Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)).
-The response body is a `text/xml` or `application/xml` HTTP entity with a `multistatus` root element. The XML body will list all individual response codes.
+The response body is a `text/xml` or `application/xml` HTTP entity with a `multistatus` root element that lists individual response codes.
+**Note:** Browsers accessing web pages will never encounter this status code. The ability to return a _collection of resources_ is part of the [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) protocol and is only encountered by web applications that access a WebDAV server.
-
-
- ### See Also
- - [Spec](https://www.rfc-editor.org/rfc/rfc4918#section-11.1)
- - [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)
- - [HTTP request methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)
- - [204 No Content](https://http.cat/status/204)
- - [403 Forbidden](https://http.cat/status/403)
+### Examples
+The following response is an example `207` response that a [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) server sends to a client. There is a `multistatus` root element with details of the individual collections:
- **Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/207](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/207)
+http
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: 1241
+
+
+ Failed to process request in time. Please try again.
+ + + + +### Specifications + +Specification + +[HTTP Semantics +\# status.408](https://httpwg.org/specs/rfc9110.html#status.408) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [`Connection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Connection) +* [`X-DNS-Prefetch-Control`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-DNS-Prefetch-Control) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/408](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/408) diff --git a/content/409.md b/content/409.md index e863ede5..edd83c41 100644 --- a/content/409.md +++ b/content/409.md @@ -1,12 +1,54 @@ ## Description -The HTTP `409 Conflict` response status code indicates a request conflict with the current state of the target resource. +The HTTP **`409 Conflict`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates a request conflict with the current state of the target resource. -Conflicts are most likely to occur in response to a `PUT` request. For example, you may get a `409` response when uploading a file that is older than the existing one on the server, resulting in a version control conflict. +In [WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV) remote web authoring, 409 conflict responses are errors sent to the client so that a user might be able to resolve a conflict and resubmit the request. For example, conflicts occur if a request to create collection `/a/b/c/d/` is made, and `/a/b/c/` does not exist, the request must fail with a 409. Additionally, you may get a 409 response when uploading a file that is older than the existing one on the server, resulting in a version control conflict. -### See Also +In other systems, 409 responses may be used for implementation-specific purposes, such as to indicate that the server has received multiple requests to update the same resource. -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.409) -- [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT) +### Examples -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409) +In the following example, we want to kick off an automation process that performs a common task in the system: + +http + + POST /tasks HTTP/1.1 + Host: example.com + Content-Type: application/json + + { + "task": "emailDogOwners", + "template": "pickup" + } + + +In this implementation, the server disallows two concurrent jobs from running and returns a 409, providing the client an opportunity to check if they meant to perform the action or run a different task: + +http + + HTTP/1.1 409 Conflict + Date: Wed, 26 Jun 2024 12:00:00 GMT + Server: Apache/2.4.1 (Unix) + Content-Type: application/json + + { + "code": "AutomationConflict", + "task": "emailDogOwners", + "message": "Task locked. Cannot start a new automation since job is already running.", + "runningTaskId": "123" + } + + +### Specifications + +Specification + +[HTTP Semantics +\# status.409](https://www.rfc-editor.org/rfc/rfc9110#status.409) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [`PUT`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/PUT) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/409](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/409) diff --git a/content/410.md b/content/410.md index b6328d8f..b7ffc6f7 100644 --- a/content/410.md +++ b/content/410.md @@ -1,14 +1,47 @@ ## Description -The HTTP `410 Gone` client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. +The HTTP **`410 Gone`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates that the target resource is no longer available at the origin server and that this condition is likely to be permanent. A 410 response is cacheable by default. -If you don't know whether this condition is temporary or permanent, a `404` status code should be used instead. +Clients should not repeat requests for resources that return a 410 response, and website owners should remove or replace links that return this code. If server owners don't know whether this condition is temporary or permanent, a [`404`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404) status code should be used instead. - +### Examples -### See Also +The following `GET` request is for a page with promotional content that is no longer valid: -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.410) -- [404 Not Found](https://http.cat/status/404) +http -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/410) + GET /promotions/summer-2023 HTTP/1.1 + Host: example.com + + +http + + HTTP/1.1 410 Gone + Content-Type: text/html + Content-Length: 212 + + + +Promotion no longer active! See current offers.
+ + + + +### Specifications + +Specification + +[HTTP Semantics +\# status.410](https://www.rfc-editor.org/rfc/rfc9110#status.410) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [`404`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404) +* [410 gone](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#410) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/410](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/410) diff --git a/content/411.md b/content/411.md index 3ff4f2d8..1abd2cad 100644 --- a/content/411.md +++ b/content/411.md @@ -1,18 +1,50 @@ ## Description -The HTTP `411 Length Required` client error response code indicates -that the server refuses to accept the request without a defined `Content-Length` header. +The HTTP **`411 Length Required`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates that the server refused to accept the request without a defined [`Content-Length`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length) header. - +**Note:** When sending data in a series of chunks, the `Content-Length` header is omitted, and at the beginning of each chunk, the length of the current chunk needs to be included in hexadecimal format. See [`Transfer-Encoding`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Transfer-Encoding) for more details. -### See Also +### Examples -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.411) -- [Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length) -- [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) +The following request is sent chunked, which is the default method of sending data in some cases, such as when [writing to streams](https://nodejs.org/api/http.html#requestwritechunk-encoding-callback): -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/411) +http + POST /translate/de HTTP/1.1 + Host: api.example.com + Content-Type: application/json + Transfer-encoding: chunked + + 2C + {"text": "Hurry up, Ayşe is hungry!"} + 0 + + +In this case, the server is expecting a request in one part with a [`Content-Length`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length) header and returns a 411 response: + +http + + HTTP/1.1 411 Length Required + Content-Type: application/json + Content-Length: 110 + + { + "message": "Requests must have a content length header.", + "documentation": "http://api/example.com/docs/errors", + } + + +### Specifications + +Specification + +[HTTP Semantics +\# status.411](https://httpwg.org/specs/rfc9110.html#status.411) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [`Content-Length`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length) +* [`Transfer-Encoding`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Transfer-Encoding) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/411](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/411) diff --git a/content/412.md b/content/412.md index d10fd65b..1af605b1 100644 --- a/content/412.md +++ b/content/412.md @@ -1,19 +1,44 @@ ## Description -The HTTP `412 Precondition Failed` client error response code -indicates that access to the target resource has been denied. This happens with -conditional requests on methods other than `GET` or -`HEAD` when the condition defined by the -`If-Unmodified-Since` or `If-None-Match` headers is not -fulfilled. In that case, the request, usually an upload or a modification of a resource, -cannot be made and this error response is sent back. - -### See Also - -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.412) -- [If-Unmodified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Unmodified-Since) -- [If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match) -- [304 Not Modified](https://http.cat/status/304) -- [428 Precondition Required](https://http.cat/status/428) - -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412) +The HTTP **`412 Precondition Failed`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates that access to the target resource was denied. This happens with [conditional requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Conditional_requests) on methods other than [`GET`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET) or [`HEAD`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/HEAD) when the condition defined by the [`If-Unmodified-Since`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Unmodified-Since) or [`If-Match`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Match) headers is not fulfilled. In that case, the request (usually an upload or a modification of a resource) cannot be made and this error response is sent back. + +### Examples + +http + + ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" + ETag: W/"0815" + + +With the help of the `ETag` and the [`If-Match`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Match) headers, you can prevent conflicts or mid-air collisions. For example, when editing some wiki pages, content is hashed and put into an `ETag` in successful responses: + +http + + ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" + + +When saving changes to a wiki page (posting data), the [`POST`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST) request will contain the [`If-Match`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Match) header containing the `ETag` values that the client stored from the last edit to check freshness of the resource on the server: + +http + + If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4" + + +If the hashes don't match, the document has been edited in-between and a `412 Precondition Failed` error is thrown. + +### Specifications + +Specification + +[HTTP Semantics +\# status.412](https://www.rfc-editor.org/rfc/rfc9110#status.412) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [Conditional requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Conditional_requests) +* [`304`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/304) +* [`If-Unmodified-Since`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Unmodified-Since), [`If-Match`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Match) +* [`428`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/428) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/412](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/412) diff --git a/content/413.md b/content/413.md index 2da6ac04..c4aeaf31 100644 --- a/content/413.md +++ b/content/413.md @@ -1,13 +1,53 @@ ## Description -The HTTP `413 Content Too Large` response status code indicates that the request entity is larger than limits defined by server; the server might close the connection or return a `Retry-After` header field. +The HTTP **`413 Content Too Large`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates that the request entity was larger than limits defined by server. The server might close the connection or return a [`Retry-After`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) header field. -Prior to RFC 9110 the response phrase for the status was Payload Too Large. That name is still widely used. +Prior to [RFC 9110](https://datatracker.ietf.org/doc/html/rfc9110) the response phrase for the status was **`Payload Too Large`**. This message is still widely used. -### See Also +### Examples -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.413) -- [Connection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection) -- [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) +The following example shows what the client may send when an [``](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file) element includes an image on form submission with `method="post"`: -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413) +http + + POST /upload HTTP/1.1 + Host: example.com + Content-Type: multipart/form-data; boundary=----Boundary1234 + Content-Length: 4012345 + + ------Boundary1234 + Content-Disposition: form-data; name="file"; filename="myImage.jpg" + Content-Type: image/jpeg + + \xFF\xD8\xFF\xE0\x00...(binary data) + ------Boundary1234-- + + +The server may reject the upload if there is a restriction on the maximum size of files it will process, and the response body includes a `message` with some context: + +http + + HTTP/1.1 413 Content Too Large + Content-Type: application/json + Content-Length: 97 + + { + "error": "Upload failed", + "message": "Maximum allowed upload size is 4MB", + } + + +### Specifications + +Specification + +[HTTP Semantics +\# status.413](https://httpwg.org/specs/rfc9110.html#status.413) + +### See also + +* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) +* [`Connection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Connection) +* [`Retry-After`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) + +**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/413](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/413) diff --git a/content/414.md b/content/414.md index dd8a9f9c..ef76846c 100644 --- a/content/414.md +++ b/content/414.md @@ -1,19 +1,55 @@ ## Description -The HTTP `414 URI Too Long` response status code indicates -that the URI requested by the client is longer than the server is willing to interpret. +The HTTP **`414 URI Too Long`** [client error response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#client_error_responses) status code indicates that a URI requested by the client was longer than the server is willing to interpret. -There are a few rare conditions when this might occur: +There are a few rare conditions when this error might occur: -- when a client has improperly converted a `POST` request to a `GET` request with long query information, -- when the client has descended into a loop of redirection (for example, a redirected -URI prefix that points to a suffix of itself), -- or when the server is under attack by a client attempting to exploit potential -security holes. +* a client has improperly converted a [`POST`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST) request to a [`GET`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET) request with long query information, +* a client has descended into a loop of redirection (for example, a redirected URI prefix that points to a suffix of itself), or +* the server is under attack by a client attempting to exploit potential security holes. -### See Also +Some systems implement `414 URI Too Long` as `414 Request-URI Too Large`. -- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.414) -- [URI](https://developer.mozilla.org/en-US/docs/Glossary/URI) +### Examples -**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/414) +In the following example, an HTML [`