Changeset 1909


Ignore:
Timestamp:
22/09/12 05:32:51 (11 years ago)
Author:
fielding@…
Message:

(editorial) move payload below representation header fields and representation body sections

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1907 r1909  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 22, 2013";
     451       content: "Expires March 25, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-09-18">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-09-21">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: March 22, 2013</td>
     530               <td class="left">Expires: March 25, 2013</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">September 18, 2012</td>
     535               <td class="right">September 21, 2012</td>
    536536            </tr>
    537537         </tbody>
    … …  
    560560         in progress”.
    561561      </p>
    562       <p>This Internet-Draft will expire on March 22, 2013.</p>
     562      <p>This Internet-Draft will expire on March 25, 2013.</p>
    563563      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    564564      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    585585         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resource">Resource</a></li>
    586586         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
    587                <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a><ul>
    588                      <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
    589                      <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#identifying.payload">Identifying the Payload</a></li>
     587               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
     588                     <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
     589                     <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
     590                     <li><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
     591                     <li><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
    590592                  </ul>
    591593               </li>
    592                <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
    593                      <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
    594                      <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
    595                      <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
    596                      <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
     594               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
     595               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
     596               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a><ul>
     597                     <li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
     598                     <li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#identifying.payload">Identifying the Payload</a></li>
    597599                  </ul>
    598600               </li>
    599                <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
    600                <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    601601               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
    602602                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
    … …  
    883883         (representation body).
    884884      </p>
    885       <div id="rfc.iref.p.1"></div>
    886       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
    887       <p id="rfc.section.3.1.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
    888          only some part(s) of the representation body (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
    889       </p>
    890       <p id="rfc.section.3.1.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
    891          by both the request method and the response status code.
    892       </p>
    893       <p id="rfc.section.3.1.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in
    894          the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
    895          an HTML form.
    896       </p>
    897       <p id="rfc.section.3.1.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
    898          current representation of the target resource after applying the processing. Some responses only contain the representation's
    899          header fields as the payload. Response messages with an error status code usually contain a representation that describes
    900          the error and what next steps are suggested for resolving it.
    901       </p>
    902       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
    903       <p id="rfc.section.3.1.1.p.1">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
    904          header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
    905       </p>
     885      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
     886      <p id="rfc.section.3.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
     887         body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI.
     888      </p>
     889      <p id="rfc.section.3.1.p.2">The following header fields are defined as representation metadata:</p>
    906890      <div id="rfc.table.u.1">
    907891         <table class="tt full left" cellpadding="3" cellspacing="0">
    … …  
    914898            <tbody>
    915899               <tr>
    916                   <td class="left">Content-Length</td>
    917                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    918                </tr>
    919                <tr>
    920                   <td class="left">Content-Range</td>
    921                   <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
    922                </tr>
    923                <tr>
    924                   <td class="left">Transfer-Encoding</td>
    925                   <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
    926                </tr>
    927             </tbody>
    928          </table>
    929       </div>
    930       <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3>
    931       <p id="rfc.section.3.1.2.p.1">When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply,
    932          or the recipient to determine, an identifier for the resource corresponding to that representation.
    933       </p>
    934       <p id="rfc.section.3.1.2.p.2">The following rules are used to determine such a URI for the payload of a request message: </p>
    935       <ul>
    936          <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location
    937             field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP).
    938             The information might still be useful for revision history links.
    939          </li>
    940          <li>Otherwise, the payload is unidentified.</li>
    941       </ul>
    942       <p id="rfc.section.3.1.2.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a
    943          response message:
    944       </p>
    945       <ol>
    946          <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    947          </li>
    948          <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the target resource; as such, the effective request URI might only
    949             act as an identifier for the payload's representation when a request is made via the same chain of intermediaries.
    950          </li>
    951          <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
    952             the effective request URI.
    953          </li>
    954          <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts
    955             that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion
    956             cannot be trusted unless it can be verified by other means (not defined by HTTP).
    957          </li>
    958          <li>Otherwise, the payload is unidentified.</li>
    959       </ol>
    960       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    961       <p id="rfc.section.3.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
    962          body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI.
    963       </p>
    964       <p id="rfc.section.3.2.p.2">The following header fields are defined as representation metadata:</p>
    965       <div id="rfc.table.u.2">
    966          <table class="tt full left" cellpadding="3" cellspacing="0">
    967             <thead>
    968                <tr>
    969                   <th>Header Field Name</th>
    970                   <th>Defined in...</th>
    971                </tr>
    972             </thead>
    973             <tbody>
    974                <tr>
    975900                  <td class="left">Content-Type</td>
    976                   <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.2.1</a></td>
     901                  <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.1.1</a></td>
    977902               </tr>
    978903               <tr>
    979904                  <td class="left">Content-Encoding</td>
    980                   <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.2.2</a></td>
     905                  <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.1.2</a></td>
    981906               </tr>
    982907               <tr>
    983908                  <td class="left">Content-Language</td>
    984                   <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.2.3</a></td>
     909                  <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.1.3</a></td>
    985910               </tr>
    986911               <tr>
    987912                  <td class="left">Content-Location</td>
    988                   <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.2.4</a></td>
     913                  <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.1.4</a></td>
    989914               </tr>
    990915               <tr>
    … …  
    996921      </div>
    997922      <div id="rfc.iref.c.2"></div>
    998       <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h3>
    999       <p id="rfc.section.3.2.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
     923      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h3>
     924      <p id="rfc.section.3.1.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
    1000925         the media type is that which would have been sent had the request been a GET.
    1001926      </p>
    1002927      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
    1003 </pre><p id="rfc.section.3.2.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>. An example of the field is
     928</pre><p id="rfc.section.3.1.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>. An example of the field is
    1004929      </p>
    1005930      <div id="rfc.figure.u.2"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    1006 </pre><p id="rfc.section.3.2.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.4</a>.
     931</pre><p id="rfc.section.3.1.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.3</a>.
    1007932      </p>
    1008933      <div id="rfc.iref.c.3"></div>
    1009       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>
    1010       <p id="rfc.section.3.2.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
     934      <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>
     935      <p id="rfc.section.3.1.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
    1011936         in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
    1012937         its underlying media type.
    1013938      </p>
    1014939      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    1015 </pre><p id="rfc.section.3.2.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;8.4</a>. An example of its use is
     940</pre><p id="rfc.section.3.1.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;8.4</a>. An example of its use is
    1016941      </p>
    1017942      <div id="rfc.figure.u.4"></div><pre class="text">  Content-Encoding: gzip
    1018 </pre><p id="rfc.section.3.2.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     943</pre><p id="rfc.section.3.1.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
    1019944         and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    1020945         directive is present in the message.
    1021946      </p>
    1022       <p id="rfc.section.3.2.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
     947      <p id="rfc.section.3.1.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
    1023948         not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding
    1024949         would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
    … …  
    1027952         as ..." dialog instead of automatic decompression and rendering of content).
    1028953      </p>
    1029       <p id="rfc.section.3.2.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied.
    1030       </p>
    1031       <p id="rfc.section.3.2.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1032       </p>
    1033       <p id="rfc.section.3.2.2.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     954      <p id="rfc.section.3.1.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied.
     955      </p>
     956      <p id="rfc.section.3.1.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     957      </p>
     958      <p id="rfc.section.3.1.2.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
    1034959      </p>
    1035960      <div id="rfc.iref.c.4"></div>
    1036       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h3>
    1037       <p id="rfc.section.3.2.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
     961      <h3 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h3>
     962      <p id="rfc.section.3.1.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
    1038963         that this might not be equivalent to all the languages used within the representation.
    1039964      </p>
    1040965      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    1041 </pre><p id="rfc.section.3.2.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
     966</pre><p id="rfc.section.3.1.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    1042967         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    1043968         field is
    1044969      </p>
    1045970      <div id="rfc.figure.u.6"></div><pre class="text">  Content-Language: da
    1046 </pre><p id="rfc.section.3.2.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
     971</pre><p id="rfc.section.3.1.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
    1047972         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
    1048973         it is intended.
    1049974      </p>
    1050       <p id="rfc.section.3.2.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
     975      <p id="rfc.section.3.1.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
    1051976         simultaneously in the original Maori and English versions, would call for
    1052977      </p>
    1053978      <div id="rfc.figure.u.7"></div><pre class="text">  Content-Language: mi, en
    1054 </pre><p id="rfc.section.3.2.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
     979</pre><p id="rfc.section.3.1.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    1055980         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    1056981         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    1057982      </p>
    1058       <p id="rfc.section.3.2.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
     983      <p id="rfc.section.3.1.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
    1059984      </p>
    1060985      <div id="rfc.iref.c.5"></div>
    1061       <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h3>
    1062       <p id="rfc.section.3.2.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
     986      <h3 id="rfc.section.3.1.4"><a href="#rfc.section.3.1.4">3.1.4</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h3>
     987      <p id="rfc.section.3.1.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
    1063988         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
    1064989      </p>
    1065990      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
    1066 </pre><p id="rfc.section.3.2.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     991</pre><p id="rfc.section.3.1.4.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    1067992         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    1068993      </p>
    1069       <p id="rfc.section.3.2.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
     994      <p id="rfc.section.3.1.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
    1070995         payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
    1071996         when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
    … …  
    1074999         need for a subsequent GET request.
    10751000      </p>
    1076       <p id="rfc.section.3.2.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
     1001      <p id="rfc.section.3.1.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
    10771002         server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
    10781003         request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
    … …  
    10821007         the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future.
    10831008      </p>
    1084       <p id="rfc.section.3.2.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
     1009      <p id="rfc.section.3.1.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
    10851010         representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
    10861011         providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
    … …  
    10901015         latter semantics, it would have applied the PUT directly to the Content-Location URI.
    10911016      </p>
    1092       <p id="rfc.section.3.2.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
     1017      <p id="rfc.section.3.1.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
    10931018         in other contexts, such as within source links or other metadata.
    10941019      </p>
    1095       <p id="rfc.section.3.2.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
     1020      <p id="rfc.section.3.1.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
    10961021         to respond to later requests on that Content-Location URI.
    10971022      </p>
    1098       <p id="rfc.section.3.2.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
    1099       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
    1100       <p id="rfc.section.3.3.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if
     1023      <p id="rfc.section.3.1.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
     1024      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
     1025      <p id="rfc.section.3.2.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if
    11011026         the same request had used the method GET and excluded any conditional request header fields.
    11021027      </p>
    1103       <p id="rfc.section.3.3.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
     1028      <p id="rfc.section.3.2.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
    11041029         in the message for responses to some state-changing methods. The following header fields are defined as selected representation
    11051030         metadata:
    11061031      </p>
    1107       <div id="rfc.table.u.3">
     1032      <div id="rfc.table.u.2">
    11081033         <table class="tt full left" cellpadding="3" cellspacing="0">
    11091034            <thead>
    … …  
    11251050         </table>
    11261051      </div>
    1127       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
    1128       <p id="rfc.section.3.4.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     1052      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
     1053      <p id="rfc.section.3.3.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
    11291054         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
    11301055         the representation metadata header fields.
    11311056      </p>
    1132       <p id="rfc.section.3.4.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
     1057      <p id="rfc.section.3.3.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
    11331058      </p>
    11341059      <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    1135 </pre><p id="rfc.section.3.4.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
     1060</pre><p id="rfc.section.3.3.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
    11361061         body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
    11371062         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
    11381063         of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
    11391064      </p>
    1140       <p id="rfc.section.3.4.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     1065      <p id="rfc.section.3.3.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
    11411066         a given representation, with the result that some clients will examine a response body's content and override the specified
    11421067         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
    … …  
    11451070         such "content sniffing" when it is used.
    11461071      </p>
    1147       <p id="rfc.section.3.4.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
     1072      <p id="rfc.section.3.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
    11481073         are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
    11491074         defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
    11501075      </p>
     1076      <div id="rfc.iref.p.1"></div>
     1077      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
     1078      <p id="rfc.section.3.4.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
     1079         only some part(s) of the representation body (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
     1080      </p>
     1081      <p id="rfc.section.3.4.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
     1082         by both the request method and the response status code.
     1083      </p>
     1084      <p id="rfc.section.3.4.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in
     1085         the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
     1086         an HTML form.
     1087      </p>
     1088      <p id="rfc.section.3.4.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
     1089         current representation of the target resource after applying the processing. Some responses only contain the representation's
     1090         header fields as the payload. Response messages with an error status code usually contain a representation that describes
     1091         the error and what next steps are suggested for resolving it.
     1092      </p>
     1093      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
     1094      <p id="rfc.section.3.4.1.p.1">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
     1095         header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
     1096      </p>
     1097      <div id="rfc.table.u.3">
     1098         <table class="tt full left" cellpadding="3" cellspacing="0">
     1099            <thead>
     1100               <tr>
     1101                  <th>Header Field Name</th>
     1102                  <th>Defined in...</th>
     1103               </tr>
     1104            </thead>
     1105            <tbody>
     1106               <tr>
     1107                  <td class="left">Content-Length</td>
     1108                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1109               </tr>
     1110               <tr>
     1111                  <td class="left">Content-Range</td>
     1112                  <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td>
     1113               </tr>
     1114               <tr>
     1115                  <td class="left">Transfer-Encoding</td>
     1116                  <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>
     1117               </tr>
     1118            </tbody>
     1119         </table>
     1120      </div>
     1121      <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3>
     1122      <p id="rfc.section.3.4.2.p.1">When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply,
     1123         or the recipient to determine, an identifier for the resource corresponding to that representation.
     1124      </p>
     1125      <p id="rfc.section.3.4.2.p.2">The following rules are used to determine such a URI for the payload of a request message: </p>
     1126      <ul>
     1127         <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location
     1128            field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP).
     1129            The information might still be useful for revision history links.
     1130         </li>
     1131         <li>Otherwise, the payload is unidentified.</li>
     1132      </ul>
     1133      <p id="rfc.section.3.4.2.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a
     1134         response message:
     1135      </p>
     1136      <ol>
     1137         <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     1138         </li>
     1139         <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the target resource; as such, the effective request URI might only
     1140            act as an identifier for the payload's representation when a request is made via the same chain of intermediaries.
     1141         </li>
     1142         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
     1143            the effective request URI.
     1144         </li>
     1145         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts
     1146            that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion
     1147            cannot be trusted unless it can be verified by other means (not defined by HTTP).
     1148         </li>
     1149         <li>Otherwise, the payload is unidentified.</li>
     1150      </ol>
    11511151      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
    11521152      <p id="rfc.section.3.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
    … …  
    14131413      <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.1</a>).
    14141414      </p>
    1415       <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1415      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    14161416      </p>
    14171417      <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
    … …  
    20902090         </li>
    20912091      </ul>
    2092       <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.2.1</a>).
     2092      <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1</a>).
    20932093      </p>
    20942094      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
    … …  
    27712771      </p>
    27722772      <div class="note" id="rfc.section.7.1.1.p.9">
    2773          <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;3.2.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     2773         <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;3.1.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    27742774            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    27752775         </p>
    … …  
    30673067      </p>
    30683068      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#imported.abnf" class="smpl">token</a>
    3069 </pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.2.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
     3069</pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.1.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    30703070         mechanism will be required to remove the encoding.
    30713071      </p>
    … …  
    30893089      </ul>
    30903090      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    3091       <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;3.2.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation.
     3091      <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;3.1.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation.
    30923092      </p>
    30933093      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
    … …  
    32783278         code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
    32793279         (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to
    3280          specify expected cache behavior (e.g., cacheability and freshness criteria, as described in <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying the Payload">Section&nbsp;3.1.2</a>).
     3280         specify expected cache behavior (e.g., cacheability and freshness criteria, as described in <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying the Payload">Section&nbsp;3.4.2</a>).
    32813281      </p>
    32823282      <h3 id="rfc.section.9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>
    … …  
    35383538         double-quotes will likely cause unnecessary confusion.
    35393539      </p>
    3540       <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;3.2.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
     3540      <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;3.1.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    35413541         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    35423542         it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>).
    … …  
    36323632                  <td class="left">http</td>
    36333633                  <td class="left">standard</td>
    3634                   <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;3.2.2</a>
     3634                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;3.1.2</a>
    36353635                  </td>
    36363636               </tr>
    … …  
    36393639                  <td class="left">http</td>
    36403640                  <td class="left">standard</td>
    3641                   <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;3.2.3</a>
     3641                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;3.1.3</a>
    36423642                  </td>
    36433643               </tr>
    … …  
    36463646                  <td class="left">http</td>
    36473647                  <td class="left">standard</td>
    3648                   <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;3.2.4</a>
     3648                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;3.1.4</a>
    36493649                  </td>
    36503650               </tr>
    … …  
    36533653                  <td class="left">http</td>
    36543654                  <td class="left">standard</td>
    3655                   <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;3.2.1</a>
     3655                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;3.1.1</a>
    36563656                  </td>
    36573657               </tr>
    … …  
    41464146      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    41474147      <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
    4148          and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.2.4</a>)
     4148         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4</a>)
    41494149      </p>
    41504150      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>)
    … …  
    50195019                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.7"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">9.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
    50205020                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
    5021                   <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.2</a>, <a href="#rfc.iref.c.3"><b>3.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li>
    5022                   <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.2</a>, <a href="#rfc.iref.c.4"><b>3.2.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>
    5023                   <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.iref.c.5"><b>3.2.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
     5021                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.1</a>, <a href="#rfc.iref.c.3"><b>3.1.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li>
     5022                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.1</a>, <a href="#rfc.iref.c.4"><b>3.1.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>
     5023                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.5"><b>3.1.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
    50245024                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.9">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
    5025                   <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.iref.c.2"><b>3.2.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li>
     5025                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.iref.c.2"><b>3.1.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li>
    50265026               </ul>
    50275027            </li>
    50285028            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    5029                   <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.1</a>, <a href="#rfc.xref.header.date.2">7.2</a>, <a href="#rfc.iref.d.2"><b>7.2.1</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a></li>
     5029                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.xref.header.date.2">7.2</a>, <a href="#rfc.iref.d.2"><b>7.2.1</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a></li>
    50305030                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.3">8.4</a></li>
    50315031                  <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.1"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">9.1.3</a></li>
    … …  
    50465046            </li>
    50475047            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    5048                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.1</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.6"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a></li>
     5048                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.4</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.6"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a></li>
    50495049                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    50505050                     <ul>
    … …  
    50615061                        <li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.4</b></a></li>
    50625062                        <li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>8.4</b></a></li>
    5063                         <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.2.2</b></a></li>
    5064                         <li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.2.3</b></a></li>
    5065                         <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.2.4</b></a></li>
    5066                         <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.2.1</b></a></li>
     5063                        <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.1.2</b></a></li>
     5064                        <li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.1.3</b></a></li>
     5065                        <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.1.4</b></a></li>
     5066                        <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.1</b></a></li>
    50675067                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>7.2.1</b></a></li>
    50685068                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>8.1</b></a></li>
    … …  
    51365136            </li>
    51375137            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    5138                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.1</a>, <a href="#rfc.xref.Part1.8">3.1.1</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>
     5138                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.4</a>, <a href="#rfc.xref.Part1.8">3.4.1</a>, <a href="#rfc.xref.Part1.9">3.4.1</a>, <a href="#rfc.xref.Part1.10">3.4.2</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>
    51395139                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    51405140                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.3.4</a></li>
    … …  
    51455145                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a></li>
    51465146                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>
    5147                         <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1.1</a></li>
     5147                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.4.1</a></li>
    51485148                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.29">9.1.2</a></li>
    5149                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1.1</a></li>
     5149                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.4.1</a></li>
    51505150                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">9.4.1</a></li>
    51515151                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">9.3.1</a></li>
    … …  
    51575157                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a></li>
    51585158                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.1</a></li>
    5159                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.23">7</a></li>
     5159                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.4</a>, <a href="#rfc.xref.Part1.10">3.4.2</a>, <a href="#rfc.xref.Part1.23">7</a></li>
    51605160                        <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.43">C</a></li>
    51615161                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">9.3.1</a></li>
    … …  
    51665166                     </ul>
    51675167                  </li>
    5168                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
    5169                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3</a></li>
    5170                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li>
     5168                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
     5169                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.2</a></li>
     5170                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li>
    51715171                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
    51725172                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
    … …  
    51785178                     </ul>
    51795179                  </li>
    5180                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
     5180                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.4.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
    51815181                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">6.1</a></li>
    51825182                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
    51835183                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
    51845184                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">7.4</a></li>
    5185                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>
     5185                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.4.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>
    51865186                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">5.2</a></li>
    51875187                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.5">5.1</a></li>
    51885188                     </ul>
    51895189                  </li>
    5190                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
     5190                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.1</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
    51915191                        <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.3.3</a></li>
    51925192                        <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a></li>
    … …  
    51965196                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">7.2</a></li>
    51975197                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">6.3.4</a></li>
    5198                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2</a></li>
     5198                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.1</a></li>
    51995199                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.10">6.3.4</a></li>
    52005200                     </ul>
    … …  
    52105210                     </ul>
    52115211                  </li>
    5212                   <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.1</a></li>
    5213                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.1</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">9.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li>
    5214                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li>
     5212                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.4</a></li>
     5213                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.4</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">9.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li>
     5214                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.4</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li>
    52155215               </ul>
    52165216            </li>
    … …  
    52325232                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li>
    52335233                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#RFC2045"><b>12.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li>
    5234                   <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.4</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
    5235                         <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.4</a></li>
     5234                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.3</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
     5235                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.3</a></li>
    52365236                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
    52375237                     </ul>
    … …  
    52515251                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.5</a>, <a href="#RFC2295"><b>12.2</b></a></li>
    52525252                  <li><em>RFC2388</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2388.1">8.5.2</a>, <a href="#RFC2388"><b>12.2</b></a></li>
    5253                   <li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.2.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
    5254                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.2.4</a></li>
     5253                  <li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
     5254                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.1.4</a></li>
    52555255                     </ul>
    52565256                  </li>
    … …  
    53085308            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    53095309                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.2.1</b></a></li>
    5310                   <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.3</b></a></li>
     5310                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.2</b></a></li>
    53115311                  <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">9.3.2</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>
    53125312                  <li>Status Codes Classes&nbsp;&nbsp;

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1907 r1909  
    305305</t>
    306306
     307<section title="Representation Header Fields" anchor="representation.header.fields">
     308  <x:anchor-alias value="representation-header"/>
     309<t>
     310   Representation header fields define metadata about the representation data
     311   enclosed in the message body or, if no message body is present, about
     312   the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
     313   response to a simultaneous GET request with the same effective request URI.
     314</t>
     315<t>
     316   The following header fields are defined as representation metadata:
     317</t>
     318<texttable align="left">
     319  <ttcol>Header Field Name</ttcol>
     320  <ttcol>Defined in...</ttcol>
     321
     322  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
     323  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
     324  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
     325  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
     326  <c>Expires</c> <c>&header-expires;</c>
     327</texttable>
     328
     329<section title="Content-Type" anchor="header.content-type">
     330  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
     331  <x:anchor-alias value="Content-Type"/>
     332<t>
     333   The "Content-Type" header field indicates the media type of the
     334   representation. In the case of responses to the HEAD method, the media type is
     335   that which would have been sent had the request been a GET.
     336</t>
     337<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
     338  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
     339</artwork></figure>
     340<t>
     341   Media types are defined in <xref target="media.types"/>. An example of the field is
     342</t>
     343<figure><artwork type="example">
     344  Content-Type: text/html; charset=ISO-8859-4
     345</artwork></figure>
     346<t>
     347   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
     348</t>
     349</section>
     350
     351<section title="Content-Encoding" anchor="header.content-encoding">
     352  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
     353  <x:anchor-alias value="Content-Encoding"/>
     354<t>
     355   The "Content-Encoding" header field indicates what content-codings
     356   have been applied to the representation beyond those inherent in the media
     357   type, and thus what decoding mechanisms have to be applied in order to obtain
     358   the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
     359   Content-Encoding is primarily used to allow a representation to be
     360   compressed without losing the identity of its underlying media type.
     361</t>
     362<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
     363  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
     364</artwork></figure>
     365<t>
     366   Content codings are defined in <xref target="content.codings"/>. An example of its use is
     367</t>
     368<figure><artwork type="example">
     369  Content-Encoding: gzip
     370</artwork></figure>
     371<t>
     372   The content-coding is a characteristic of the representation.
     373   Typically, the representation body is stored with this
     374   encoding and is only decoded before rendering or analogous usage.
     375   However, a transforming proxy &MAY; modify the content-coding if the
     376   new coding is known to be acceptable to the recipient, unless the
     377   "no-transform" cache-control directive is present in the message.
     378</t>
     379<t>
     380   If the media type includes an inherent encoding, such as a data format
     381   that is always compressed, then that encoding would not be restated as
     382   a Content-Encoding even if it happens to be the same algorithm as one
     383   of the content-codings.  Such a content-coding would only be listed if,
     384   for some bizarre reason, it is applied a second time to form the
     385   representation.  Likewise, an origin server might choose to publish the
     386   same payload data as multiple representations that differ only in whether
     387   the coding is defined as part of <x:ref>Content-Type</x:ref> or
     388   Content-Encoding, since some user agents will behave differently in their
     389   handling of each response (e.g., open a "Save as ..." dialog instead of
     390   automatic decompression and rendering of content).
     391</t>
     392<t>
     393   A representation that has a content-coding applied to it &MUST; include
     394   a Content-Encoding header field that lists the content-coding(s) applied.
     395</t>
     396<t>
     397   If multiple encodings have been applied to a representation, the content
     398   codings &MUST; be listed in the order in which they were applied.
     399   Additional information about the encoding parameters &MAY; be provided
     400   by other header fields not defined by this specification.
     401</t>
     402<t>
     403   If the content-coding of a representation in a request message is not
     404   acceptable to the origin server, the server &SHOULD; respond with a
     405   status code of 415 (Unsupported Media Type).
     406</t>
     407</section>
     408
     409<section title="Content-Language" anchor="header.content-language">
     410  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
     411  <x:anchor-alias value="Content-Language"/>
     412<t>
     413   The "Content-Language" header field describes the natural
     414   language(s) of the intended audience for the representation. Note that this might
     415   not be equivalent to all the languages used within the representation.
     416</t>
     417<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
     418  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
     419</artwork></figure>
     420<t>
     421   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
     422   Content-Language is to allow a user to identify and differentiate
     423   representations according to the user's own preferred language. Thus, if the
     424   body content is intended only for a Danish-literate audience, the
     425   appropriate field is
     426</t>
     427<figure><artwork type="example">
     428  Content-Language: da
     429</artwork></figure>
     430<t>
     431   If no Content-Language is specified, the default is that the content
     432   is intended for all language audiences. This might mean that the
     433   sender does not consider it to be specific to any natural language,
     434   or that the sender does not know for which language it is intended.
     435</t>
     436<t>
     437   Multiple languages &MAY; be listed for content that is intended for
     438   multiple audiences. For example, a rendition of the "Treaty of
     439   Waitangi", presented simultaneously in the original Maori and English
     440   versions, would call for
     441</t>
     442<figure><artwork type="example">
     443  Content-Language: mi, en
     444</artwork></figure>
     445<t>
     446   However, just because multiple languages are present within a representation
     447   does not mean that it is intended for multiple linguistic audiences.
     448   An example would be a beginner's language primer, such as "A First
     449   Lesson in Latin", which is clearly intended to be used by an
     450   English-literate audience. In this case, the Content-Language would
     451   properly only include "en".
     452</t>
     453<t>
     454   Content-Language &MAY; be applied to any media type &mdash; it is not
     455   limited to textual documents.
     456</t>
     457</section>
     458
     459<section title="Content-Location" anchor="header.content-location">
     460  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
     461  <x:anchor-alias value="Content-Location"/>
     462<t>
     463   The "Content-Location" header field supplies a URI that can be used
     464   as a specific identifier for the representation in this message.
     465   In other words, if one were to perform a GET on this URI at the time
     466   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
     467   contain the same representation that is enclosed as payload in this message.
     468</t>
     469<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
     470  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
     471</artwork></figure>
     472<t>
     473   The Content-Location value is not a replacement for the effective
     474   Request URI (&effective-request-uri;).  It is representation metadata.
     475   It has the same syntax and semantics as the header field of the same name
     476   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
     477   However, its appearance in an HTTP message has some special implications
     478   for HTTP recipients.
     479</t>
     480<t>
     481   If Content-Location is included in a response message and its value
     482   is the same as the effective request URI, then the response payload
     483   &SHOULD; be considered a current representation of that resource.
     484   For a GET or HEAD request, this is the same as the default semantics
     485   when no Content-Location is provided by the server.  For a state-changing
     486   request like PUT or POST, it implies that the server's response contains
     487   the new representation of that resource, thereby distinguishing it from
     488   representations that might only report about the action (e.g., "It worked!").
     489   This allows authoring applications to update their local copies without
     490   the need for a subsequent GET request.
     491</t>
     492<t>
     493   If Content-Location is included in a response message and its value
     494   differs from the effective request URI, then the origin server is
     495   informing recipients that this representation has its own, presumably
     496   more specific, identifier.  For a GET or HEAD request, this is an
     497   indication that the effective request URI identifies a resource that
     498   is subject to content negotiation and the selected representation for
     499   this response can also be found at the identified URI.  For other
     500   methods, such a Content-Location indicates that this representation
     501   contains a report on the action's status and the same report is
     502   available (for future access with GET) at the given URI.  For
     503   example, a purchase transaction made via a POST request might
     504   include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
     505   response; the Content-Location value provides an identifier for retrieving
     506   a copy of that same receipt in the future.
     507</t>
     508<t>
     509   If Content-Location is included in a request message, then it &MAY;
     510   be interpreted by the origin server as an indication of where the
     511   user agent originally obtained the content of the enclosed
     512   representation (prior to any subsequent modification of the content
     513   by that user agent).  In other words, the user agent is providing
     514   the same representation metadata that it received with the original
     515   representation.  However, such interpretation &MUST-NOT; be used to
     516   alter the semantics of the method requested by the client.  For
     517   example, if a client makes a PUT request on a negotiated resource
     518   and the origin server accepts that PUT (without redirection), then the
     519   new set of values for that resource is expected to be consistent with
     520   the one representation supplied in that PUT; the Content-Location
     521   cannot be used as a form of reverse content selection that
     522   identifies only one of the negotiated representations to be updated.
     523   If the user agent had wanted the latter semantics, it would have applied
     524   the PUT directly to the Content-Location URI.
     525</t>
     526<t>
     527   A Content-Location field received in a request message is transitory
     528   information that &SHOULD-NOT; be saved with other representation
     529   metadata for use in later responses.  The Content-Location's value
     530   might be saved for use in other contexts, such as within source links
     531   or other metadata.
     532</t>
     533<t>
     534   A cache cannot assume that a representation with a Content-Location
     535   different from the URI used to retrieve it can be used to respond to
     536   later requests on that Content-Location URI.
     537</t>
     538<t>
     539   If the Content-Location value is a partial URI, the partial URI is
     540   interpreted relative to the effective request URI.
     541</t>
     542</section>
     543</section>
     544
     545<section title="Selected Representation Header Fields" anchor="selected.representation">
     546<t><iref primary="true" item="selected representation"/>
     547   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
     548   the current representation of a target resource that would have been
     549   selected in a successful response if the same request had used the
     550   method GET and excluded any conditional request header fields.
     551</t>
     552<t>
     553   Additional header fields define metadata about the selected
     554   representation, which might differ from the representation included
     555   in the message for responses to some state-changing methods.
     556   The following header fields are defined as selected representation
     557   metadata:
     558</t>
     559<texttable align="left">
     560  <ttcol>Header Field Name</ttcol>
     561  <ttcol>Defined in...</ttcol>
     562
     563  <c>ETag</c> <c>&header-etag;</c>
     564  <c>Last-Modified</c> <c>&header-last-modified;</c>
     565</texttable>
     566</section>
     567
     568<section title="Representation Data" anchor="representation.data">
     569  <x:anchor-alias value="representation-data"/>
     570<t>
     571   The representation body associated with an HTTP message is
     572   either provided as the payload body of the message or
     573   referred to by the message semantics and the effective request
     574   URI.  The representation data is in a format and encoding defined by
     575   the representation metadata header fields.
     576</t>
     577<t>
     578   The data type of the representation data is determined via the header fields
     579   <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
     580   These define a two-layer, ordered encoding model:
     581</t>
     582<figure><artwork type="example">
     583  representation-data := Content-Encoding( Content-Type( bits ) )
     584</artwork></figure>
     585<t>
     586   <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
     587   which defines both the data format and how that data &SHOULD; be processed
     588   by the recipient (within the scope of the request method semantics).
     589   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     590   Content-Type header field defining the media type of the associated
     591   representation unless that metadata is unknown to the sender.
     592   If the Content-Type header field is not present, it indicates that
     593   the sender does not know the media type of the representation;
     594   recipients &MAY; either assume that the media type is
     595   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     596   or examine the content to determine its type.
     597</t>
     598<t>
     599   In practice, resource owners do not always properly configure their origin
     600   server to provide the correct Content-Type for a given representation,
     601   with the result that some clients will examine a response body's content
     602   and override the specified type.
     603   Clients that do so risk drawing incorrect conclusions, which might expose
     604   additional security risks (e.g., "privilege escalation").  Furthermore,
     605   it is impossible to determine the sender's intent by examining the data
     606   format: many data formats match multiple media types that differ only in
     607   processing semantics.  Implementers are encouraged to provide a means of
     608   disabling such "content sniffing" when it is used.
     609</t>
     610<t>
     611   <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
     612   codings applied to the data, usually for the purpose of data
     613   compression, that are a property of the representation.  If
     614   Content-Encoding is not present, then there is no additional
     615   encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
     616</t>
     617</section>
     618
    307619<section title="Message Payload" anchor="payload">
    308620<iref item="payload"/>
    … …  
    407719</t>
    408720</section>
    409 </section>
    410 
    411 <section title="Representation Header Fields" anchor="representation.header.fields">
    412   <x:anchor-alias value="representation-header"/>
    413 <t>
    414    Representation header fields define metadata about the representation data
    415    enclosed in the message body or, if no message body is present, about
    416    the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
    417    response to a simultaneous GET request with the same effective request URI.
    418 </t>
    419 <t>
    420    The following header fields are defined as representation metadata:
    421 </t>
    422 <texttable align="left">
    423   <ttcol>Header Field Name</ttcol>
    424   <ttcol>Defined in...</ttcol>
    425 
    426   <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    427   <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
    428   <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    429   <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    430   <c>Expires</c> <c>&header-expires;</c>
    431 </texttable>
    432 
    433 <section title="Content-Type" anchor="header.content-type">
    434   <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
    435   <x:anchor-alias value="Content-Type"/>
    436 <t>
    437    The "Content-Type" header field indicates the media type of the
    438    representation. In the case of responses to the HEAD method, the media type is
    439    that which would have been sent had the request been a GET.
    440 </t>
    441 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
    442   <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
    443 </artwork></figure>
    444 <t>
    445    Media types are defined in <xref target="media.types"/>. An example of the field is
    446 </t>
    447 <figure><artwork type="example">
    448   Content-Type: text/html; charset=ISO-8859-4
    449 </artwork></figure>
    450 <t>
    451    Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    452 </t>
    453 </section>
    454 
    455 <section title="Content-Encoding" anchor="header.content-encoding">
    456   <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
    457   <x:anchor-alias value="Content-Encoding"/>
    458 <t>
    459    The "Content-Encoding" header field indicates what content-codings
    460    have been applied to the representation beyond those inherent in the media
    461    type, and thus what decoding mechanisms have to be applied in order to obtain
    462    the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
    463    Content-Encoding is primarily used to allow a representation to be
    464    compressed without losing the identity of its underlying media type.
    465 </t>
    466 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
    467   <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
    468 </artwork></figure>
    469 <t>
    470    Content codings are defined in <xref target="content.codings"/>. An example of its use is
    471 </t>
    472 <figure><artwork type="example">
    473   Content-Encoding: gzip
    474 </artwork></figure>
    475 <t>
    476    The content-coding is a characteristic of the representation.
    477    Typically, the representation body is stored with this
    478    encoding and is only decoded before rendering or analogous usage.
    479    However, a transforming proxy &MAY; modify the content-coding if the
    480    new coding is known to be acceptable to the recipient, unless the
    481    "no-transform" cache-control directive is present in the message.
    482 </t>
    483 <t>
    484    If the media type includes an inherent encoding, such as a data format
    485    that is always compressed, then that encoding would not be restated as
    486    a Content-Encoding even if it happens to be the same algorithm as one
    487    of the content-codings.  Such a content-coding would only be listed if,
    488    for some bizarre reason, it is applied a second time to form the
    489    representation.  Likewise, an origin server might choose to publish the
    490    same payload data as multiple representations that differ only in whether
    491    the coding is defined as part of <x:ref>Content-Type</x:ref> or
    492    Content-Encoding, since some user agents will behave differently in their
    493    handling of each response (e.g., open a "Save as ..." dialog instead of
    494    automatic decompression and rendering of content).
    495 </t>
    496 <t>
    497    A representation that has a content-coding applied to it &MUST; include
    498    a Content-Encoding header field that lists the content-coding(s) applied.
    499 </t>
    500 <t>
    501    If multiple encodings have been applied to a representation, the content
    502    codings &MUST; be listed in the order in which they were applied.
    503    Additional information about the encoding parameters &MAY; be provided
    504    by other header fields not defined by this specification.
    505 </t>
    506 <t>
    507    If the content-coding of a representation in a request message is not
    508    acceptable to the origin server, the server &SHOULD; respond with a
    509    status code of 415 (Unsupported Media Type).
    510 </t>
    511 </section>
    512 
    513 <section title="Content-Language" anchor="header.content-language">
    514   <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
    515   <x:anchor-alias value="Content-Language"/>
    516 <t>
    517    The "Content-Language" header field describes the natural
    518    language(s) of the intended audience for the representation. Note that this might
    519    not be equivalent to all the languages used within the representation.
    520 </t>
    521 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
    522   <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
    523 </artwork></figure>
    524 <t>
    525    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    526    Content-Language is to allow a user to identify and differentiate
    527    representations according to the user's own preferred language. Thus, if the
    528    body content is intended only for a Danish-literate audience, the
    529    appropriate field is
    530 </t>
    531 <figure><artwork type="example">
    532   Content-Language: da
    533 </artwork></figure>
    534 <t>
    535    If no Content-Language is specified, the default is that the content
    536    is intended for all language audiences. This might mean that the
    537    sender does not consider it to be specific to any natural language,
    538    or that the sender does not know for which language it is intended.
    539 </t>
    540 <t>
    541    Multiple languages &MAY; be listed for content that is intended for
    542    multiple audiences. For example, a rendition of the "Treaty of
    543    Waitangi", presented simultaneously in the original Maori and English
    544    versions, would call for
    545 </t>
    546 <figure><artwork type="example">
    547   Content-Language: mi, en
    548 </artwork></figure>
    549 <t>
    550    However, just because multiple languages are present within a representation
    551    does not mean that it is intended for multiple linguistic audiences.
    552    An example would be a beginner's language primer, such as "A First
    553    Lesson in Latin", which is clearly intended to be used by an
    554    English-literate audience. In this case, the Content-Language would
    555    properly only include "en".
    556 </t>
    557 <t>
    558    Content-Language &MAY; be applied to any media type &mdash; it is not
    559    limited to textual documents.
    560 </t>
    561 </section>
    562 
    563 <section title="Content-Location" anchor="header.content-location">
    564   <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
    565   <x:anchor-alias value="Content-Location"/>
    566 <t>
    567    The "Content-Location" header field supplies a URI that can be used
    568    as a specific identifier for the representation in this message.
    569    In other words, if one were to perform a GET on this URI at the time
    570    of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
    571    contain the same representation that is enclosed as payload in this message.
    572 </t>
    573 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
    574   <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
    575 </artwork></figure>
    576 <t>
    577    The Content-Location value is not a replacement for the effective
    578    Request URI (&effective-request-uri;).  It is representation metadata.
    579    It has the same syntax and semantics as the header field of the same name
    580    defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
    581    However, its appearance in an HTTP message has some special implications
    582    for HTTP recipients.
    583 </t>
    584 <t>
    585    If Content-Location is included in a response message and its value
    586    is the same as the effective request URI, then the response payload
    587    &SHOULD; be considered a current representation of that resource.
    588    For a GET or HEAD request, this is the same as the default semantics
    589    when no Content-Location is provided by the server.  For a state-changing
    590    request like PUT or POST, it implies that the server's response contains
    591    the new representation of that resource, thereby distinguishing it from
    592    representations that might only report about the action (e.g., "It worked!").
    593    This allows authoring applications to update their local copies without
    594    the need for a subsequent GET request.
    595 </t>
    596 <t>
    597    If Content-Location is included in a response message and its value
    598    differs from the effective request URI, then the origin server is
    599    informing recipients that this representation has its own, presumably
    600    more specific, identifier.  For a GET or HEAD request, this is an
    601    indication that the effective request URI identifies a resource that
    602    is subject to content negotiation and the selected representation for
    603    this response can also be found at the identified URI.  For other
    604    methods, such a Content-Location indicates that this representation
    605    contains a report on the action's status and the same report is
    606    available (for future access with GET) at the given URI.  For
    607    example, a purchase transaction made via a POST request might
    608    include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
    609    response; the Content-Location value provides an identifier for retrieving
    610    a copy of that same receipt in the future.
    611 </t>
    612 <t>
    613    If Content-Location is included in a request message, then it &MAY;
    614    be interpreted by the origin server as an indication of where the
    615    user agent originally obtained the content of the enclosed
    616    representation (prior to any subsequent modification of the content
    617    by that user agent).  In other words, the user agent is providing
    618    the same representation metadata that it received with the original
    619    representation.  However, such interpretation &MUST-NOT; be used to
    620    alter the semantics of the method requested by the client.  For
    621    example, if a client makes a PUT request on a negotiated resource
    622    and the origin server accepts that PUT (without redirection), then the
    623    new set of values for that resource is expected to be consistent with
    624    the one representation supplied in that PUT; the Content-Location
    625    cannot be used as a form of reverse content selection that
    626    identifies only one of the negotiated representations to be updated.
    627    If the user agent had wanted the latter semantics, it would have applied
    628    the PUT directly to the Content-Location URI.
    629 </t>
    630 <t>
    631    A Content-Location field received in a request message is transitory
    632    information that &SHOULD-NOT; be saved with other representation
    633    metadata for use in later responses.  The Content-Location's value
    634    might be saved for use in other contexts, such as within source links
    635    or other metadata.
    636 </t>
    637 <t>
    638    A cache cannot assume that a representation with a Content-Location
    639    different from the URI used to retrieve it can be used to respond to
    640    later requests on that Content-Location URI.
    641 </t>
    642 <t>
    643    If the Content-Location value is a partial URI, the partial URI is
    644    interpreted relative to the effective request URI.
    645 </t>
    646 </section>
    647 </section>
    648 
    649 <section title="Selected Representation Header Fields" anchor="selected.representation">
    650 <t><iref primary="true" item="selected representation"/>
    651    We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    652    the current representation of a target resource that would have been
    653    selected in a successful response if the same request had used the
    654    method GET and excluded any conditional request header fields.
    655 </t>
    656 <t>
    657    Additional header fields define metadata about the selected
    658    representation, which might differ from the representation included
    659    in the message for responses to some state-changing methods.
    660    The following header fields are defined as selected representation
    661    metadata:
    662 </t>
    663 <texttable align="left">
    664   <ttcol>Header Field Name</ttcol>
    665   <ttcol>Defined in...</ttcol>
    666 
    667   <c>ETag</c> <c>&header-etag;</c>
    668   <c>Last-Modified</c> <c>&header-last-modified;</c>
    669 </texttable>
    670 </section>
    671 
    672 <section title="Representation Data" anchor="representation.data">
    673   <x:anchor-alias value="representation-data"/>
    674 <t>
    675    The representation body associated with an HTTP message is
    676    either provided as the payload body of the message or
    677    referred to by the message semantics and the effective request
    678    URI.  The representation data is in a format and encoding defined by
    679    the representation metadata header fields.
    680 </t>
    681 <t>
    682    The data type of the representation data is determined via the header fields
    683    <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
    684    These define a two-layer, ordered encoding model:
    685 </t>
    686 <figure><artwork type="example">
    687   representation-data := Content-Encoding( Content-Type( bits ) )
    688 </artwork></figure>
    689 <t>
    690    <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
    691    which defines both the data format and how that data &SHOULD; be processed
    692    by the recipient (within the scope of the request method semantics).
    693    Any HTTP/1.1 message containing a payload body &SHOULD; include a
    694    Content-Type header field defining the media type of the associated
    695    representation unless that metadata is unknown to the sender.
    696    If the Content-Type header field is not present, it indicates that
    697    the sender does not know the media type of the representation;
    698    recipients &MAY; either assume that the media type is
    699    "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    700    or examine the content to determine its type.
    701 </t>
    702 <t>
    703    In practice, resource owners do not always properly configure their origin
    704    server to provide the correct Content-Type for a given representation,
    705    with the result that some clients will examine a response body's content
    706    and override the specified type.
    707    Clients that do so risk drawing incorrect conclusions, which might expose
    708    additional security risks (e.g., "privilege escalation").  Furthermore,
    709    it is impossible to determine the sender's intent by examining the data
    710    format: many data formats match multiple media types that differ only in
    711    processing semantics.  Implementers are encouraged to provide a means of
    712    disabling such "content sniffing" when it is used.
    713 </t>
    714 <t>
    715    <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
    716    codings applied to the data, usually for the purpose of data
    717    compression, that are a property of the representation.  If
    718    Content-Encoding is not present, then there is no additional
    719    encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
    720 </t>
    721721</section>
    722722
Note: See TracChangeset for help on using the changeset viewer.