feat(http): Update some mentions of "payload" -> "content"

files/en-us/_wikihistory.json

@@ -2694,6 +2694,10 @@
     "modified": "2020-09-14T07:48:57.436Z",
     "contributors": ["darby", "roshan0708", "iigmir"]
   },
+  "Glossary/HTTP_Content": {
+    "modified": "2020-12-04T06:44:11.807Z",
+    "contributors": ["chrisdavidmills", "hamishwillee"]
+  },
   "Glossary/HTTP_header": {
     "modified": "2020-11-30T03:35:20.276Z",
     "contributors": [
@@ -3855,10 +3859,6 @@
       "panaggio"
     ]
   },
-  "Glossary/Payload_body": {
-    "modified": "2020-12-04T06:44:11.807Z",
-    "contributors": ["chrisdavidmills", "hamishwillee"]
-  },
   "Glossary/Perceived_performance": {
     "modified": "2019-05-20T13:01:45.834Z",
     "contributors": ["estelle", "sideshowbarker", "andystevensname"]

files/en-us/glossary/content_header/index.md

@@ -0,0 +1,35 @@
+---
+title: Content header
+slug: Glossary/Content_header
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+**Content headers** are the group of [HTTP headers](/en-US/docs/Web/HTTP/Headers) that describe the content of the body of an HTTP message, after any message framing in the body has been removed.
+They specifically describe the properties of the {{Glossary("HTTP Content", "message content")}} that is conveyed in a particular message _as it is transported_, such as the length of the content, the transport encoding, which part of the resource is carried in the data (for multi-part messages), and message integrity checks.
+They differ from the {{Glossary("Representation header", "Representation headers")}}, which describe the encoding, media type, language, and other characteristics of the resource, and allow the underlying data to be interpreted.
+
+These headers were defined as "Payload headers" in {{RFC("7231")}}, but are now referred to as "Content headers" because data contained in HTTP/2 and HTTP/3 frame payloads could be header data, body data, or other control information.
+Later HTTP specifications don't mention "content headers" or expand on the list of relevant headers, but the semantics remain the same, so this way of classifying headers is still useful.
+
+> [!NOTE]
+> There is some overlap between content headers and {{Glossary("Representation header", "representation headers")}}.
+
+These headers may be present in both HTTP request and response messages and include:
+
+- {{HTTPHeader("Content-Encoding")}}
+- {{HTTPHeader("Content-Length")}}
+- {{HTTPHeader("Content-Range")}}
+- {{HTTPHeader("Content-Type")}}
+- {{HTTPHeader("Trailer")}}
+- {{HTTPHeader("Transfer-Encoding")}}
+
+## See also
+
+- [HTTP headers](/en-US/docs/Web/HTTP/Headers)
+- Related glossary terms:
+  - {{Glossary("Representation header")}}
+  - {{Glossary("HTTP Content")}}
+- [RFC 9110, section 6.4.1: Content semantics](https://httpwg.org/specs/rfc9110.html#rfc.section.6.4.1), specifically [Appendix B.3.: Changes from RFC 7231](https://httpwg.org/specs/rfc9110.html#changes.from.rfc.7231)
+- [RFC 7231, section 3.3: Payload Semantics](https://datatracker.ietf.org/doc/html/rfc7231#section-3.3)

files/en-us/glossary/entity_header/index.md

@@ -9,7 +9,7 @@ page-type: glossary-definition
 > [!WARNING]
 > The current HTTP/1.1 specification no longer refers to entities, entity headers or entity-body. Some of the fields are now referred to as {{glossary("Representation header")}} fields.
 
-An entity header is an {{glossary("HTTP_header", "HTTP header")}} that describes the payload of an HTTP message (i.e. metadata about the message body). Entity headers include: {{HTTPHeader("Content-Length")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Expires")}}, etc. Entity headers may be present in both HTTP request and response messages.
+An entity header is an {{glossary("HTTP_header", "HTTP header")}} that describes the {{Glossary("HTTP content", "content")}} of an HTTP message (i.e. metadata about the message body). Entity headers include: {{HTTPHeader("Content-Length")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Expires")}}, etc. Entity headers may be present in both HTTP request and response messages.
 
 In the following example, {{HTTPHeader("Content-Length")}} is an entity header, while {{HTTPHeader("Host")}} and {{HTTPHeader("User-Agent")}} are requests headers:
 

files/en-us/glossary/http_content/index.md

@@ -0,0 +1,51 @@
+---
+title: HTTP Content
+slug: Glossary/HTTP_Content
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+In HTTP messages, the **content** describes the 'information' conveyed in the message body (which follows the header section), after any message framing from HTTP/1.1 chunked transfer encoding has been removed.
+This was referred to as a "payload" in HTTP/1.1, but message "content" distinguishes from frame payloads in HTTP/2 and HTTP/3 where the data in a single frame could be header data, body data, or other control information.
+
+The purpose of message content in HTTP requests and responses depends on the request method and response status code.
+For example, in a {{HTTPMethod("PUT")}} request, the content represents the desired state of the resource, but in a {{HTTPMethod("POST")}} request, it is information to be processed.
+A {{HTTPStatus("200", "200 OK")}} response to a {{HTTPMethod("GET")}} request shows the current state of the resource, while an error response describes the error.
+
+Some responses, like those to {{HTTPMethod("HEAD")}} requests or {{HTTPStatus("204", "204 No Content")}} and {{HTTPStatus("204", "304 Not Modified")}} status codes, do not include content at all.
+
+In the following HTTP/1.1 response, the message body contains the content `Mozilla Developer Network`:
+
+```http
+HTTP/1.1 200 OK
+Content-Type: text/plain
+
+Mozilla Developer Network
+```
+
+In the next HTTP/1.1 response, transfer encoding encodes the data into chunks.
+The content is still `Mozilla Developer Network` in the end, but the message body includes different message data to separate the chunks:
+
+```http
+HTTP/1.1 200 OK
+Content-Type: text/plain
+Transfer-Encoding: chunked
+
+7\r\n
+Mozilla\r\n
+9\r\n
+Developer\r\n
+7\r\n
+Network\r\n
+0\r\n
+\r\n
+```
+
+## See also
+
+- {{HTTPHeader("Content-Location")}}
+- {{HTTPStatus("413", "413 Content Too Large")}}
+- {{Glossary("Content header")}}
+- [RFC 9110, section 6.4: Content](https://httpwg.org/specs/rfc9110.html#rfc.section.6.4) (obsoletes [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-3.3) Payload Semantics)
+  - [Changes from RFC 7231](https://httpwg.org/specs/rfc9110.html#changes.from.rfc.7231)

files/en-us/glossary/representation_header/index.md

@@ -6,11 +6,10 @@ page-type: glossary-definition
 
 {{GlossarySidebar}}
 
-A **representation header** is an {{glossary("HTTP_header", "HTTP header")}} that describes one particular _representation_ of a resource.
+A **representation header** (or 'representation metadata') is an {{glossary("HTTP_header", "HTTP header")}} that describes how to interpret the data contained in the message.
 
-Representations are different forms of a particular resource.
-
-For example, the same data might be formatted as a particular media type such as XML, JSON, HTML or Markdown, or localized to a particular written language or geographical region.
+For example, the content in a particular message might be encoded for transport, the whole resource might be formatted as a particular media type such as XML, JSON, HTML or Markdown, localized to a particular written language or geographical region, and/or compressed using a particular algorithm.
+The representation headers allow the underlying data to be extracted and understood.
 The underlying resource is semantically the same in each case, but its representation is different.
 
 While representations are different forms of resources, representations can themselves also be transmitted in various forms: an HTTP message frames (cf., e.g., HTTP/1.1's {{HTTPHeader("Transfer-Encoding")}}), a particular stream of octets (cf., e.g., {{HTTPHeader("Content-Range")}}) derived from the _selected representation_.
@@ -20,15 +19,27 @@ Clients specify the formats that they prefer to be sent during [Content Negotiat
 Representation headers may be present in both HTTP request and response messages with various methods.
 If sent as a response to a `HEAD` request, they describe the body content representation that _would_ be selected if the resource was requested with a `GET` request.
 
-Representation headers include: {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Language")}}, {{HTTPHeader("Content-Range")}}, {{HTTPHeader("Repr-Digest")}}, and {{HTTPHeader("Digest")}} {{Deprecated_Inline}}.
+Representation headers include:
+
+- {{HTTPHeader("Content-Length")}}
+- {{HTTPHeader("Content-Range")}}
+- {{HTTPHeader("Content-Type")}}
+- {{HTTPHeader("Content-Encoding")}}
+- {{HTTPHeader("Content-Location")}}
+- {{HTTPHeader("Content-Language")}}
+
+- Validators used in [conditional requests](/en-US/docs/Web/HTTP/Conditional_requests), such as:
+  - {{HTTPHeader("Last-Modified")}}
+  - {{HTTPHeader("ETag")}}
+
+Representation headers are not mutually exclusive with {{Glossary("Content header", "content headers")}}.
 
 ## See also
 
 - [RFC 9110, section 3.2: Representations](https://httpwg.org/specs/rfc9110.html#representations)
 - [List of all HTTP headers](/en-US/docs/Web/HTTP/Headers)
 - Related glossary terms:
-  - {{Glossary("Payload header")}}
-  - {{glossary("Entity header")}}
+  - {{Glossary("Content header")}}
 - {{HTTPHeader("Repr-Digest")}}, {{HTTPHeader("Want-Repr-Digest")}}
 - {{HTTPHeader("Content-Digest")}}, {{HTTPHeader("Want-Content-Digest")}}
 - {{HTTPHeader("Digest")}} {{Deprecated_Inline}}, {{HTTPHeader("Want-Digest")}} {{Deprecated_Inline}}

files/en-us/web/http/cors/index.md

@@ -252,7 +252,7 @@ Keep-Alive: timeout=2, max=99
 Connection: Keep-Alive
 Content-Type: text/plain
 
-[Some XML payload]
+[Some XML content]
 ```
 
 #### Preflighted requests and redirects
@@ -331,7 +331,7 @@ Keep-Alive: timeout=2, max=100
 Connection: Keep-Alive
 Content-Type: text/plain
 
-[text/plain payload]
+[text/plain content]
 ```
 
 Although the request's `Cookie` header contains the cookie destined for the content on `https://bar.other`, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}} with value `true`, as demonstrated in this example, the response would be ignored and not made available to the web content.

files/en-us/web/http/headers/content-encoding/index.md

@@ -7,13 +7,16 @@ browser-compat: http.headers.Content-Encoding
 
 {{HTTPSidebar}}
 
-The **`Content-Encoding`** {{Glossary("representation header")}} lists any encodings that have been applied to the representation (message payload), and in what order.
-This lets the recipient know how to decode the representation in order to obtain the original payload format.
-Content encoding is mainly used to compress the message data without losing information about the origin media type.
+The **`Content-Encoding`** {{Glossary("representation header")}} lists any encodings that have been applied to a resource, and in what order.
+This lets the recipient know how to decode the data in order to obtain the original content format described in the {{HTTPHeader("Content-Type")}} header.
+Content encoding is mainly used to compress content without losing information about the original media type.
 
-Note that the original media/content type is specified in the {{HTTPHeader("Content-Type")}} header, and that the `Content-Encoding` applies to the representation, or "coded form", of the data. If the original media is encoded in some way (e.g. a zip file) then this information would not be included in the `Content-Encoding` header.
+Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate.
+Compressing a compressed media type such as a .zip or .jpeg may not be appropriate, as this can make the content larger.
+If the original media is already encoded in some way (e.g., a .zip file) then this information would not be included in the `Content-Encoding` header.
 
-Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate. Compressing a compressed media type such as a zip or jpeg may not be appropriate, as this can make the payload larger.
+When there's a `Content-Encoding` header, other metadata (e.g., {{HTTPHeader("Content-Length")}}) refer to the encoded form of the data, and not the original resource unless explicitly stated.
+Content encoding differs to {{HTTPHeader("Transfer-Encoding")}} in that `Transfer-Encoding` handles how HTTP messages themselves are delivered across the network on a [hop-by-hop basis](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers).
 
 <table class="properties">
   <tbody>

files/en-us/web/http/headers/content-length/index.md

@@ -16,7 +16,7 @@ The **`Content-Length`** header indicates the size of the message body, in bytes
       <td>
         {{Glossary("Request header")}},
         {{Glossary("Response header")}},
-        {{Glossary("Payload header")}}
+        {{Glossary("Content header")}}
       </td>
     </tr>
     <tr>

files/en-us/web/http/headers/content-range/index.md

@@ -16,7 +16,7 @@ a full body message a partial message belongs.
       <th scope="row">Header type</th>
       <td>
         {{Glossary("Response header")}},
-        {{Glossary("Payload header")}}
+        {{Glossary("Content header")}}
       </td>
     </tr>
     <tr>

files/en-us/web/http/headers/trailer/index.md

@@ -23,7 +23,7 @@ digital signature, or post-processing status.
       <td>
         {{Glossary("Request header")}},
         {{Glossary("Response header")}},
-        {{Glossary("Payload header")}}
+        {{Glossary("Content header")}}
       </td>
     </tr>
     <tr>

files/en-us/web/http/headers/transfer-encoding/index.md

@@ -7,9 +7,12 @@ browser-compat: http.headers.Transfer-Encoding
 
 {{HTTPSidebar}}
 
-The **`Transfer-Encoding`** header specifies the form of encoding used to safely transfer the {{Glossary("Payload body","payload body")}} to the user.
+The **`Transfer-Encoding`** header specifies the form of encoding used to transfer messages between nodes on the network.
 
-> **Note:** [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: `"trailers"`. HTTP 2 provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header. Usage of the header in HTTP/2 may likely result in a specific `protocol error` as HTTP/2 Protocol prohibits the use.
+> [!WARNING]
+> HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: `"trailers"`.
+> HTTP/2 and later provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header.
+> Usage of the header in HTTP/2 may likely result in a specific `protocol error` as HTTP/2 Protocol prohibits the use.
 
 `Transfer-Encoding` is a [hop-by-hop header](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers), that is applied to a message between two nodes, not to a resource itself.
 Each segment of a multi-node connection can use different `Transfer-Encoding` values.
@@ -22,7 +25,7 @@ When present on a response to a {{HTTPMethod("HEAD")}} request that has no body,
     <tr>
       <th scope="row">Header type</th>
       <td>
-        {{Glossary("Request header")}}, {{Glossary("Response header")}}, {{Glossary("Payload header")}}
+        {{Glossary("Request header")}}, {{Glossary("Response header")}}, {{Glossary("Content header")}}
       </td>
     </tr>
     <tr>
@@ -66,7 +69,7 @@ Transfer-Encoding: gzip, chunked
 ### Chunked encoding
 
 Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed.
-For example, when generating a large HTML table resulting from a database query or when transmitting large images. \
+For example, when generating a large HTML table resulting from a database query or when transmitting large images.
 A chunked response looks like this:
 
 ```http

files/en-us/web/http/messages/index.md

@@ -19,7 +19,7 @@ HTTP requests, and responses, share similar structure and are composed of:
 3. A blank line indicating all meta-information for the request has been sent.
 4. An optional _body_ containing data associated with the request (like content of an HTML form), or the document associated with a response. The presence of the body and its size is specified by the start-line and HTTP headers.
 
-The start-line and HTTP headers of the HTTP message are collectively known as the _head_ of the requests, whereas its payload is known as the _body_.
+The start-line and HTTP headers of the HTTP message are collectively known as the _head_ of the requests, and the part afterwards that contains its content is known as the _body_.
 
 ![Requests and responses share a common structure in HTTP](httpmsgstructure2.png)
 
@@ -63,7 +63,8 @@ Many different headers can appear in requests. They can be divided in several gr
 
 ### Body
 
-The final part of the request is its body. Not all requests have one: requests fetching resources like `GET` or `HEAD` usually don't need a body. Requests that send data to the server to create a resource, such as `PUT` or `POST` requests, typically require a body with the data used to fulfill the request (for instance, HTML form data).
+The last part of a response is the body.
+Not all responses have one: responses with a status code that sufficiently answers the request without the need to include message {{Glossary("HTTP Content", "content")}} (like {{HTTPStatus("201", "201 Created")}} or {{HTTPStatus("204", "204 No Content")}}) usually don't.
 
 Bodies can be broadly divided into two categories:
 
@@ -99,7 +100,7 @@ Many different headers can appear in responses. These can be divided into severa
 
 ### Body
 
-The last part of a response is the body. Not all responses have one: responses with a status code that sufficiently answers the request without the need for corresponding payload (like {{HTTPStatus("201")}} **`Created`** or {{HTTPStatus("204")}} **`No Content`**) usually don't.
+The last part of a response is the body. Not all responses have one: responses with a status code that sufficiently answers the request without the need to include content (like {{HTTPStatus("201", "201 Created")}} or {{HTTPStatus("204", "204 No Content")}}) usually don't.
 
 Bodies can be broadly divided into three categories:
 

files/en-us/web/http/methods/get/index.md

@@ -7,10 +7,12 @@ browser-compat: http.methods.GET
 
 {{HTTPSidebar}}
 
-The **HTTP `GET` method** requests a representation of the specified resource. Requests using `GET` should only be used to request data (they shouldn't include data).
+The **HTTP `GET` method** requests a representation of the specified resource.
+Requests using `GET` should only be used to request data and shouldn't include {{Glossary("HTTP Content", "content")}}.
 
 > [!NOTE]
-> Sending body/payload in a `GET` request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in `GET` requests.
+> While not strictly prohibited by the specification, the semantics of sending a message body in `GET` requests are undefined.
+> Some systems may reject the request with a {{HTTPStatus("400")}} or another [4XX client error](/en-US/docs/Web/HTTP/Status#client_error_responses).
 
 <table class="properties">
   <tbody>

files/en-us/web/http/methods/index.md

@@ -16,7 +16,7 @@ HTTP defines a set of **request methods** to indicate the desired action to be p
 - [`POST`](/en-US/docs/Web/HTTP/Methods/POST)
   - : The `POST` method submits an entity to the specified resource, often causing a change in state or side effects on the server.
 - [`PUT`](/en-US/docs/Web/HTTP/Methods/PUT)
-  - : The `PUT` method replaces all current representations of the target resource with the request payload.
+  - : The `PUT` method replaces all current representations of the target resource with the request {{Glossary("HTTP Content", "content")}}.
 - [`DELETE`](/en-US/docs/Web/HTTP/Methods/DELETE)
   - : The `DELETE` method deletes the specified resource.
 - [`CONNECT`](/en-US/docs/Web/HTTP/Methods/CONNECT)