Add representation header and replace Entity header where appropriate

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

@@ -5,11 +5,12 @@
   - Glossary
   - WebMechanics
 ---
-<div class="notecard note">
-<p>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 representation header fields (<a href="https://datatracker.ietf.org/doc/html/rfc7231#section-3" rel="noopener">RFC 7231, section 3: Representations</a>).</p>
+<div class="notecard warning">
+  <h4>Warning</h4>
+  <p>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.</p>
 </div>
 
-<p>An entity header is an {{glossary("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.</p>
+<p>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.</p>
 
 <p>In the following example, {{HTTPHeader("Content-Length")}} is an entity header, while {{HTTPHeader("Host")}} and {{HTTPHeader("User-Agent")}} are requests headers:</p>
 
@@ -18,10 +19,8 @@
 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
 Content-Length: 128</pre>
 
-<h2 id="Learn_more">Learn more</h2>
-
-<h3 id="Technical_knowledge">Technical knowledge</h3>
+<h2 id="see_more">See also</h2>
 
 <ul>
-  <li> <a href="/en-US/docs/Web/HTTP/Headers"> List of all HTTP headers </a> </li>
+  <li>{{Glossary("Representation header")}}</li>
 </ul>

files/en-us/glossary/http_header/index.html

@@ -13,7 +13,7 @@
 <ul>
  <li>{{Glossary("Request header")}}: Headers containing more information about the resource to be fetched or about the client itself.</li>
  <li>{{Glossary("Response header")}}: Headers with additional information about the response, like its location or about the server itself (name, version, …).</li>
- <li><strong>Representation metadata header</strong>: metadata about the resource in the message body (e.g. language, length, media type, etc.).</li>
+ <li>{{Glossary("Representation header")}}: metadata about the resource in the message body (e.g. encoding, media type, etc.).</li>
 </ul>
 
 <div class="notecard note">
@@ -69,10 +69,9 @@
  <li><a href="/en-US/docs/Glossary">Glossary</a>
   <ol>
    <li>{{Glossary("HTTP header")}}</li>
-   <li>{{Glossary("General header")}}</li>
    <li>{{Glossary("Request header")}}</li>
    <li>{{Glossary("Response header")}}</li>
-   <li>{{Glossary("Entity header")}}</li>
+   <li>{{Glossary("Representation header")}}</li>
    <li>{{Glossary("Forbidden header name")}}</li>
    <li>{{Glossary("Forbidden response header name")}}</li>
    <li>{{Glossary("CORS-safelisted request header")}}</li>

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

@@ -0,0 +1,23 @@
+---
+title: Representation header
+slug: Glossary/Representation_header
+tags:
+  - Glossary
+  - WebMechanics
+---
+
+<p>A <strong>representation header</strong> is an {{glossary("HTTP_header", "HTTP header")}} that describes the particular <em>representation</em> of the resource sent in an HTTP message body.</p>
+
+<p>Representations are different versions of a particular resource that might be returned from a request. For example, the same data resource might be formatted as XML or JSON, and that resource might then be encoded in one or more compressed formats for sending. Clients specify the formats that they prefer during content negotiation (using <code>Accept-*</code> headers), and the representation headers tell the client the format of the representation they actually received.</p>
+
+<p>Representation headers may be present in both HTTP request and response messages. If sent as a response to a <code>HEAD</code> request, they describe the body content that <em>would</em> be sent if the resource was actually requested.</p>
+
+<p>The representation headers include {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Language")}}, and {{HTTPHeader("Content-Location")}}.</p>
+
+<h2 id="see_also">See also</h2>
+
+<ul>
+  <li><a href="/en-US/docs/Web/HTTP/Headers">List of all HTTP headers</a></li>
+  <li><a href="https://datatracker.ietf.org/doc/html/rfc7231#section-3">RFC 7231, section 3: Representations</a></li>
+  <li>{{glossary("Entity header")}}</li>
+</ul>

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

@@ -2,27 +2,26 @@
 title: Content-Encoding
 slug: Web/HTTP/Headers/Content-Encoding
 tags:
-- HTTP
-- Headers
-- Reference
+  - HTTP
+  - Headers
+  - Reference
+browser-compat: http.headers.Content-Encoding
 ---
 <div>{{HTTPSidebar}}</div>
 
-<p>The <strong><code>Content-Encoding</code></strong> entity header is used to compress
-  the media-type. When present, its value indicates which encodings were applied to the
-  entity-body. It lets the client know how to decode in order to obtain the media-type
-  referenced by the <code>Content-Type</code> header.</p>
+<p>The <strong><code>Content-Encoding</code></strong> {{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.</p>
 
-<p>The recommendation is to compress data as much as possible and therefore to use this
-  field, but some types of resources, such as jpeg images, are already compressed.
-  Sometimes, using additional compression doesn't reduce payload size and can even make
-  the payload longer.</p>
+<p>Note that the original media/content type is specified in the {{HTTPHeader("Content-Type")}} header, and that the <code>Content-Encoding</code> 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 <code>Content-Encoding</code> header.</p>
+
+<p>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.</p>
 
 <table class="properties">
   <tbody>
     <tr>
       <th scope="row">Header type</th>
-      <td>{{Glossary("Entity header")}}</td>
+      <td>{{Glossary("Representation header")}}</td>
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>
@@ -59,7 +58,7 @@ <h2 id="Directives">Directives</h2>
     because of a patent issue (it expired in 2003).</dd>
   <dt><code>deflate</code></dt>
   <dd>Using the <a href="https://en.wikipedia.org/wiki/Zlib">zlib</a>
-    structure (defined in <a       href="http://tools.ietf.org/html/rfc1950">RFC 1950</a>) with the <a       href="https://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> compression
+    structure (defined in <a       href="https://tools.ietf.org/html/rfc1950">RFC 1950</a>) with the <a       href="https://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> compression
     algorithm (defined in <a       href="https://datatracker.ietf.org/doc/html/rfc1951">RFC 1951</a>).</dd>
   <dt><code>br</code></dt>
   <dd>A format using the <a href="https://en.wikipedia.org/wiki/Brotli">Brotli</a>
@@ -94,10 +93,6 @@ <h2 id="Specifications">Specifications</h2>
     </tr>
   </thead>
   <tbody>
-    <tr>
-      <td>{{RFC("7932", "Brotli Compressed Data Format")}}</td>
-      <td>Brotli Compressed Data Format</td>
-    </tr>
     <tr>
       <td>{{RFC("7231", "Content-Encoding", "3.1.2.2")}}</td>
       <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td>
@@ -106,17 +101,16 @@ <h2 id="Specifications">Specifications</h2>
       <td>{{RFC("2616", "Content-Encoding", "14.11")}}</td>
       <td>Content-Encoding</td>
     </tr>
+    <tr>
+      <td>{{RFC("7932", "Brotli Compressed Data Format")}}</td>
+      <td>Brotli Compressed Data Format</td>
+    </tr>
   </tbody>
 </table>
 
 <h2 id="Browser_compatibility">Browser compatibility</h2>
 
-<p class="hidden">The compatibility table in this page is generated from structured data.
-  If you'd like to contribute to the data, please check out <a
-    href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>
-  and send us a pull request.</p>
-
-<p>{{Compat("http.headers.Content-Encoding")}}</p>
+<p>{{Compat}}</p>
 
 <h2 id="See_also">See also</h2>
 

files/en-us/web/http/headers/content-language/index.html

@@ -8,7 +8,7 @@
 ---
 <div>{{HTTPSidebar}}</div>
 
-<p>The <strong><code>Content-Language</code></strong> {{Glossary("entity header")}} is used to <strong>describe the language(s) intended for the audience</strong>, so that it allows a user to differentiate according to the users' own preferred language.</p>
+<p>The <strong><code>Content-Language</code></strong> {{Glossary("representation header")}} is used to <strong>describe the language(s) intended for the audience</strong>, so that it allows a user to differentiate according to the users' own preferred language.</p>
 
 <p>For example, if "<code>Content-Language: de-DE</code>" is set, it says that the document is intended for German language speakers (however, it doesn't indicate the document is written in German. For example, it might be written in English as part of a language course for German speakers. If you want to indicate which language the document is written in, use the <a href="/en-US/docs/Web/HTML/Global_attributes/lang"><code>lang</code> attribute</a> instead).</p>
 
@@ -18,7 +18,7 @@
  <tbody>
   <tr>
    <th scope="row">Header type</th>
-   <td>{{Glossary("Entity header")}}</td>
+   <td>{{Glossary("Representation header")}}</td>
   </tr>
   <tr>
    <th scope="row">{{Glossary("Forbidden header name")}}</th>

files/en-us/web/http/headers/content-location/index.html

@@ -25,7 +25,7 @@
   <tbody>
     <tr>
       <th scope="row">Header type</th>
-      <td>{{Glossary("Entity header")}}</td>
+      <td>{{Glossary("Representation header")}}</td>
     </tr>
     <tr>
       <th scope="row">{{Glossary("Forbidden header name")}}</th>

files/en-us/web/http/headers/content-type/index.html

@@ -20,7 +20,7 @@
  <tbody>
   <tr>
    <th scope="row">Header type</th>
-   <td>{{Glossary("Entity header")}}</td>
+   <td>{{Glossary("Representation header")}}</td>
   </tr>
   <tr>
    <th scope="row">{{Glossary("Forbidden header name")}}</th>

files/en-us/web/http/headers/index.html

@@ -13,15 +13,14 @@
 
 <p><span class="seoSummary"><strong>HTTP headers</strong> let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (<code>:</code>), then by its value.</span> {{Glossary("Whitespace")}} before the value is ignored.</p>
 
-<p>Custom proprietary headers have historically been used with an <code>X-</code> prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in <a href="https://datatracker.ietf.org/doc/html/rfc6648">RFC 6648</a>; others are listed in an <a href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a href="https://datatracker.ietf.org/doc/html/rfc4229">RFC 4229</a>. IANA also maintains a <a href="http://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP headers</a>.</p>
+<p>Custom proprietary headers have historically been used with an <code>X-</code> prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in <a href="https://datatracker.ietf.org/doc/html/rfc6648">RFC 6648</a>; others are listed in an <a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a href="https://datatracker.ietf.org/doc/html/rfc4229">RFC 4229</a>. IANA also maintains a <a href="https://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP headers</a>.</p>
 
 <p>Headers can be grouped according to their contexts:</p>
 
 <ul>
- <li>{{Glossary("General header", "General headers")}} apply to both requests and responses, but with no relation to the data transmitted in the body.</li>
  <li>{{Glossary("Request header", "Request headers")}} contain more information about the resource to be fetched, or about the client requesting the resource.</li>
  <li>{{Glossary("Response header", "Response headers")}} hold additional information about the response, like its location or about the server providing it.</li>
- <li>{{Glossary("Entity header", "Entity headers")}} contain information about the body of the resource, like its <a href="/en-US/docs/Web/HTTP/Headers/Content-Length">content length</a> or <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a>.</li>
+ <li>{{Glossary("Representation header", "Representation headers")}} contain information about the body of the resource, like its <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME type</a>, or encoding/compression applied.</li>
 </ul>
 
 <p>Headers can also be grouped according to how {{Glossary("Proxy_server", "proxies")}} handle them:</p>
@@ -41,7 +40,7 @@
  <dt id="e2e">End-to-end headers</dt>
  <dd>These headers <em>must</em> be transmitted to the final recipient of the message: the server for a request, or the client for a response. Intermediate proxies must retransmit these headers unmodified and caches must store them.</dd>
  <dt id="hbh">Hop-by-hop headers</dt>
- <dd>These headers are meaningful only for a single transport-level connection, and <em>must not</em> be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the {{httpheader("Connection")}} general header.</dd>
+ <dd>These headers are meaningful only for a single transport-level connection, and <em>must not</em> be retransmitted by proxies or cached. Note that only hop-by-hop headers may be set using the {{httpheader("Connection")}} header.</dd>
 </dl>
 
 <h2 id="Authentication">Authentication</h2>
@@ -124,9 +123,9 @@ <h2 id="Conditionals">Conditionals</h2>
  <dt>{{HTTPHeader("If-None-Match")}}</dt>
  <dd>Makes the request conditional, and applies the method only if the stored resource <em>doesn't</em> match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one already exists.</dd>
  <dt>{{HTTPHeader("If-Modified-Since")}}</dt>
- <dd>Makes the request conditional, and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.</dd>
+ <dd>Makes the request conditional, and expects the resource to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.</dd>
  <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt>
- <dd>Makes the request conditional, and expects the entity to be transmitted only if it has not been modified after the given date. This ensures the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.</dd>
+ <dd>Makes the request conditional, and expects the resource to be transmitted only if it has not been modified after the given date. This ensures the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.</dd>
  <dt>{{HTTPHeader("Vary")}}</dt>
  <dd>Determines how to match request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.</dd>
 </dl>
@@ -140,8 +139,10 @@ <h2 id="Connection_management">Connection management</h2>
  <dd>Controls how long a persistent connection should stay open.</dd>
 </dl>
 
-<h2 id="Content_negotiation"><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content negotiation</a></h2>
 
+<h2 id="Content_negotiation">Content negotiation</h2>
+
+<p><a href="/en-US/docs/Web/HTTP/Content_negotiation">Content negotiation</a> headers.</p>
 <dl>
  <dt>{{HTTPHeader("Accept")}}</dt>
  <dd>Informs the server about the {{Glossary("MIME_type", "types")}} of data that can be sent back.</dd>
@@ -327,9 +328,9 @@ <h2 id="Security">Security</h2>
  <dd>Enables cross-site scripting filtering.</dd>
 </dl>
 
-<h3 id="HTTP_Public_Key_Pinning_GlossaryHPKP">HTTP Public Key Pinning ({{Glossary("HPKP")}})</h3>
+<h3 id="HTTP_Public_Key_Pinning_GlossaryHPKP">HTTP Public Key Pinning (HPKP)</h3>
 
-<p>HTTP Public Key Pinning has been deprecated and removed in favor of Certificate Transparency and {{HTTPHeader("Expect-CT")}}.</p>
+<p>{{Glossary("HPKP", "HTTP Public Key Pinning (HPKP)")}} has been deprecated and removed in favor of Certificate Transparency and {{HTTPHeader("Expect-CT")}}.</p>
 
 <dl>
  <dt>{{HTTPHeader("Public-Key-Pins")}}</dt>
@@ -370,7 +371,7 @@ <h2 id="Transfer_coding">Transfer coding</h2>
 
 <dl>
  <dt>{{HTTPHeader("Transfer-Encoding")}}</dt>
- <dd>Specifies the form of encoding used to safely transfer the entity to the user.</dd>
+ <dd>Specifies the form of encoding used to safely transfer the resource to the user.</dd>
  <dt>{{HTTPHeader("TE")}}</dt>
  <dd>Specifies the transfer encodings the user agent is willing to accept.</dd>
  <dt>{{HTTPHeader("Trailer")}}</dt>