Ignore:
Timestamp:
Sep 18, 2012, 4:52:32 PM (7 years ago)
Author:
fielding@…
Message:

Rewrite the "identifying a representation" and considerations for
new status codes to be more concise and consistent.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1905 r1907  
    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></li>
    588                <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#associating.representation.with.resource">Associating a Representation with its Resource</a></li>
    589                <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
    590                      <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
    591                      <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
    592                      <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
    593                      <li><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
     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>
    594590                  </ul>
    595591               </li>
    596                <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
    597                <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    598                <li><a href="#rfc.section.3.6">3.6</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
    599                      <li><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
    600                      <li><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></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>
     597                  </ul>
     598               </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>
     601               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
     602                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
     603                     <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
    601604                  </ul>
    602605               </li>
     
    897900         the error and what next steps are suggested for resolving it.
    898901      </p>
    899       <p id="rfc.section.3.1.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
     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
    900904         header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
    901905      </p>
     
    924928         </table>
    925929      </div>
    926       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2>
    927       <p id="rfc.section.3.2.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    928       <p id="rfc.section.3.2.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    929       <p id="rfc.section.3.2.p.3">In the common case, an HTTP response is a representation of the target resource (see <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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    930          rules are used (with the first applicable one being selected):
     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:
    931944      </p>
    932945      <ol>
    933          <li>If the response status code is <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.203" class="smpl">203
    934                (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource.
    935          </li>
    936          <li>If the response status code is <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> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
    937          </li>
    938          <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is the same as the effective request URI, the response payload is a representation of the target
    939             resource.
    940          </li>
    941          <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation
    942             of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified
    943             by other means (not defined by HTTP).
    944          </li>
    945          <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
     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>
    946959      </ol>
    947       <p id="rfc.section.3.2.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like
    948             cache invalidation.]</span>
    949       </p>
    950       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    951       <p id="rfc.section.3.3.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
     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
    952962         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.
    953963      </p>
    954       <p id="rfc.section.3.3.p.2">The following header fields are defined as representation metadata:</p>
     964      <p id="rfc.section.3.2.p.2">The following header fields are defined as representation metadata:</p>
    955965      <div id="rfc.table.u.2">
    956966         <table class="tt full left" cellpadding="3" cellspacing="0">
     
    964974               <tr>
    965975                  <td class="left">Content-Type</td>
    966                   <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.3.1</a></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>
    967977               </tr>
    968978               <tr>
    969979                  <td class="left">Content-Encoding</td>
    970                   <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.3.2</a></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>
    971981               </tr>
    972982               <tr>
    973983                  <td class="left">Content-Language</td>
    974                   <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.3.3</a></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>
    975985               </tr>
    976986               <tr>
    977987                  <td class="left">Content-Location</td>
    978                   <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.3.4</a></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>
    979989               </tr>
    980990               <tr>
     
    986996      </div>
    987997      <div id="rfc.iref.c.2"></div>
    988       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h3>
    989       <p id="rfc.section.3.3.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
     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,
    9901000         the media type is that which would have been sent had the request been a GET.
    9911001      </p>
    9921002      <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>
    993 </pre><p id="rfc.section.3.3.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
     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
    9941004      </p>
    9951005      <div id="rfc.figure.u.2"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    996 </pre><p id="rfc.section.3.3.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.5</a>.
     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>.
    9971007      </p>
    9981008      <div id="rfc.iref.c.3"></div>
    999       <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>
    1000       <p id="rfc.section.3.3.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
     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
    10011011         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
    10021012         its underlying media type.
    10031013      </p>
    10041014      <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>
    1005 </pre><p id="rfc.section.3.3.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
     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
    10061016      </p>
    10071017      <div id="rfc.figure.u.4"></div><pre class="text">  Content-Encoding: gzip
    1008 </pre><p id="rfc.section.3.3.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     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
    10091019         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
    10101020         directive is present in the message.
    10111021      </p>
    1012       <p id="rfc.section.3.3.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
     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
    10131023         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
    10141024         would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
     
    10171027         as ..." dialog instead of automatic decompression and rendering of content).
    10181028      </p>
    1019       <p id="rfc.section.3.3.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.
    1020       </p>
    1021       <p id="rfc.section.3.3.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.
    1022       </p>
    1023       <p id="rfc.section.3.3.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).
     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).
    10241034      </p>
    10251035      <div id="rfc.iref.c.4"></div>
    1026       <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h3>
    1027       <p id="rfc.section.3.3.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
     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
    10281038         that this might not be equivalent to all the languages used within the representation.
    10291039      </p>
    10301040      <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>
    1031 </pre><p id="rfc.section.3.3.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
     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
    10321042         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    10331043         field is
    10341044      </p>
    10351045      <div id="rfc.figure.u.6"></div><pre class="text">  Content-Language: da
    1036 </pre><p id="rfc.section.3.3.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
     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
    10371047         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
    10381048         it is intended.
    10391049      </p>
    1040       <p id="rfc.section.3.3.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
     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
    10411051         simultaneously in the original Maori and English versions, would call for
    10421052      </p>
    10431053      <div id="rfc.figure.u.7"></div><pre class="text">  Content-Language: mi, en
    1044 </pre><p id="rfc.section.3.3.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
     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
    10451055         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    10461056         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    10471057      </p>
    1048       <p id="rfc.section.3.3.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
     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.
    10491059      </p>
    10501060      <div id="rfc.iref.c.5"></div>
    1051       <h3 id="rfc.section.3.3.4"><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h3>
    1052       <p id="rfc.section.3.3.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
     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
    10531063         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.
    10541064      </p>
    10551065      <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>
    1056 </pre><p id="rfc.section.3.3.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
     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
    10571067         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.
    10581068      </p>
    1059       <p id="rfc.section.3.3.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
     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
    10601070         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
    10611071         when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
     
    10641074         need for a subsequent GET request.
    10651075      </p>
    1066       <p id="rfc.section.3.3.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
     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
    10671077         server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
    10681078         request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
     
    10721082         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.
    10731083      </p>
    1074       <p id="rfc.section.3.3.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
     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
    10751085         representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
    10761086         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
     
    10801090         latter semantics, it would have applied the PUT directly to the Content-Location URI.
    10811091      </p>
    1082       <p id="rfc.section.3.3.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
     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
    10831093         in other contexts, such as within source links or other metadata.
    10841094      </p>
    1085       <p id="rfc.section.3.3.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
     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
    10861096         to respond to later requests on that Content-Location URI.
    10871097      </p>
    1088       <p id="rfc.section.3.3.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
    1089       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
    1090       <p id="rfc.section.3.4.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
     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
    10911101         the same request had used the method GET and excluded any conditional request header fields.
    10921102      </p>
    1093       <p id="rfc.section.3.4.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
     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
    10941104         in the message for responses to some state-changing methods. The following header fields are defined as selected representation
    10951105         metadata:
     
    11151125         </table>
    11161126      </div>
    1117       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
    1118       <p id="rfc.section.3.5.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     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
    11191129         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
    11201130         the representation metadata header fields.
    11211131      </p>
    1122       <p id="rfc.section.3.5.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:
     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:
    11231133      </p>
    11241134      <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    1125 </pre><p id="rfc.section.3.5.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
     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
    11261136         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
    11271137         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
    11281138         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.
    11291139      </p>
    1130       <p id="rfc.section.3.5.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     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
    11311141         a given representation, with the result that some clients will examine a response body's content and override the specified
    11321142         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
     
    11351145         such "content sniffing" when it is used.
    11361146      </p>
    1137       <p id="rfc.section.3.5.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
     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
    11381148         are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
    11391149         defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
    11401150      </p>
    1141       <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
    1142       <p id="rfc.section.3.6.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
     1151      <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>
     1152      <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
    11431153         processing. Often, the server has different ways of representing the same information; for example, in different formats,
    11441154         languages, or using different character encodings.
    11451155      </p>
    1146       <p id="rfc.section.3.6.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
     1156      <p id="rfc.section.3.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
    11471157         which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
    11481158         provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
    11491159         more than one is available.
    11501160      </p>
    1151       <p id="rfc.section.3.6.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
     1161      <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
    11521162         upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for
    11531163         the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active
     
    11551165         selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    11561166      </p>
    1157       <p id="rfc.section.3.6.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
     1167      <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    11581168         of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    11591169         a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    11601170         to choose from is very large, reactive negotiation might not be appropriate.
    11611171      </p>
    1162       <p id="rfc.section.3.6.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
     1172      <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
    11631173         be considered to be the "same information".
    11641174      </p>
    1165       <h3 id="rfc.section.3.6.1"><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
    1166       <p id="rfc.section.3.6.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
     1175      <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
     1176      <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
    11671177         negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    11681178         language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    11691179         pertaining to the request (such as the network address of the client).
    11701180      </p>
    1171       <p id="rfc.section.3.6.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
     1181      <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
    11721182         to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    11731183         (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    11741184         improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
    11751185      </p>
    1176       <p id="rfc.section.3.6.1.p.3">Proactive negotiation has disadvantages: </p>
     1186      <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p>
    11771187      <ol>
    11781188         <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
     
    11861196         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    11871197      </ol>
    1188       <p id="rfc.section.3.6.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
     1198      <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
    11891199         For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
    11901200         doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
    11911201            (Not Acceptable)</a> response.
    11921202      </p>
    1193       <p id="rfc.section.3.6.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
     1203      <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
    11941204         and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;5.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;5.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;5.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    11951205         within extension header fields not defined by this specification.
    11961206      </p>
    1197       <div class="note" id="rfc.section.3.6.1.p.6">
     1207      <div class="note" id="rfc.section.3.5.1.p.6">
    11981208         <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized.
    11991209         </p>
    12001210      </div>
    1201       <p id="rfc.section.3.6.1.p.7">The <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
    1202       </p>
    1203       <h3 id="rfc.section.3.6.2"><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
    1204       <p id="rfc.section.3.6.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
     1211      <p id="rfc.section.3.5.1.p.7">The <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
     1212      </p>
     1213      <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
     1214      <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
    12051215         an initial response from the origin server. Selection is based on a list of the available representations of the response
    12061216         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     
    12081218         user selecting from a generated (possibly hypertext) menu.
    12091219      </p>
    1210       <p id="rfc.section.3.6.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1220      <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
    12111221         encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    12121222         when public caches are used to distribute server load and reduce network usage.
    12131223      </p>
    1214       <p id="rfc.section.3.6.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
     1224      <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
    12151225         This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    12161226         for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    12171227         and used within HTTP/1.1.
    12181228      </p>
    1219       <p id="rfc.section.3.6.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
     1229      <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
    12201230         proactive negotiation.
    12211231      </p>
     
    14031413      <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>).
    14041414      </p>
    1405       <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.3.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.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    14061416      </p>
    14071417      <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.
     
    20802090         </li>
    20812091      </ul>
    2082       <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.3.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.2.1</a>).
    20832093      </p>
    20842094      <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>
     
    24342444         </li>
    24352445         <li>
    2436             <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.6.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
     2446            <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
    24372447            </p>
    24382448         </li>
     
    24632473      <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    24642474      <p id="rfc.section.6.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information
    2465          (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.6</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
     2475         (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
    24662476         location.
    24672477      </p>
     
    27612771      </p>
    27622772      <div class="note" id="rfc.section.7.1.1.p.9">
    2763          <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.3.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.2.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    27642774            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    27652775         </p>
     
    30573067      </p>
    30583068      <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>
    3059 </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.3.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.2.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    30603070         mechanism will be required to remove the encoding.
    30613071      </p>
     
    30793089      </ul>
    30803090      <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>
    3081       <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.3.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.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.
    30823092      </p>
    30833093      <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> )
     
    32573267      </p>
    32583268      <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;<a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3>
    3259       <p id="rfc.section.9.2.2.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type,
    3260          and currently defined status codes are inadequate, a new status code can be registered.
    3261       </p>
    3262       <p id="rfc.section.9.2.2.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type,
    3263          "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't
    3264          specific to a single application, so that this is clear.
    3265       </p>
    3266       <p id="rfc.section.9.2.2.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status
    3267          code (e.g., combinations of request header fields and/or method(s)), along with any interactions with response header fields
    3268          (e.g., those that are required, those that modify the semantics of the response).
    3269       </p>
    3270       <p id="rfc.section.9.2.2.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
    3271          a zero-length response body. They can require the presence of one or more particular HTTP response header field(s).
    3272       </p>
    3273       <p id="rfc.section.9.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#associating.representation.with.resource" title="Associating a Representation with its Resource">Section&nbsp;3.2</a>; by default, it is anonymous).
     3269      <p id="rfc.section.9.2.2.p.1">When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can
     3270         be registered. HTTP status codes are generic; they are potentially applicable to any resource, not just one particular media
     3271         type, "type" of resource, or application. As such, it is preferred that new status codes be registered in a document that
     3272         isn't specific to a single application.
     3273      </p>
     3274      <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
     3275         a zero-length response body.
     3276      </p>
     3277      <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status
     3278         code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
     3279         (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>).
    32743281      </p>
    32753282      <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>
     
    35313538         double-quotes will likely cause unnecessary confusion.
    35323539      </p>
    3533       <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.3.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.2.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
    35343541         parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
    35353542         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>).
     
    36253632                  <td class="left">http</td>
    36263633                  <td class="left">standard</td>
    3627                   <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;3.3.2</a>
     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>
    36283635                  </td>
    36293636               </tr>
     
    36323639                  <td class="left">http</td>
    36333640                  <td class="left">standard</td>
    3634                   <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;3.3.3</a>
     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>
    36353642                  </td>
    36363643               </tr>
     
    36393646                  <td class="left">http</td>
    36403647                  <td class="left">standard</td>
    3641                   <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;3.3.4</a>
     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>
    36423649                  </td>
    36433650               </tr>
     
    36463653                  <td class="left">http</td>
    36473654                  <td class="left">standard</td>
    3648                   <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;3.3.1</a>
     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>
    36493656                  </td>
    36503657               </tr>
     
    41394146      <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>
    41404147      <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,
    4141          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.3.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.2.4</a>)
    41424149      </p>
    41434150      <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>)
     
    50005007            </li>
    50015008            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    5002                   <li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.6.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>
    5003                   <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">3.6.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.3">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>
    5004                   <li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.6.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li>
    5005                   <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.6.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>
     5009                  <li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.5.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>
     5010                  <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">3.5.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.3">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>
     5011                  <li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.5.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li>
     5012                  <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.5.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>
    50065013                  <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a></li>
    50075014               </ul>
     
    50125019                  <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>
    50135020                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
    5014                   <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.3</a>, <a href="#rfc.iref.c.3"><b>3.3.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>
    5015                   <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.3</a>, <a href="#rfc.iref.c.4"><b>3.3.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>
    5016                   <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.3</a>, <a href="#rfc.iref.c.5"><b>3.3.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.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>
    50175024                  <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>
    5018                   <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.3</a>, <a href="#rfc.iref.c.2"><b>3.3.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.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>
    50195026               </ul>
    50205027            </li>
     
    50545061                        <li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.4</b></a></li>
    50555062                        <li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>8.4</b></a></li>
    5056                         <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.3.2</b></a></li>
    5057                         <li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.3.3</b></a></li>
    5058                         <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.3.4</b></a></li>
    5059                         <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.3.1</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>
    50605067                        <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>7.2.1</b></a></li>
    50615068                        <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>8.1</b></a></li>
     
    51295136            </li>
    51305137            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    5131                   <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</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2</a>, <a href="#rfc.xref.Part1.10">3.3.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.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>
    51325139                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
    51335140                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.3.4</a></li>
     
    51385145                        <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>
    51395146                        <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>
    5140                         <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1</a></li>
     5147                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1.1</a></li>
    51415148                        <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>
    5142                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1</a></li>
     5149                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1.1</a></li>
    51435150                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">9.4.1</a></li>
    51445151                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">9.3.1</a></li>
     
    51505157                        <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>
    51515158                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.1</a></li>
    5152                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3.2</a>, <a href="#rfc.xref.Part1.10">3.3.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.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.23">7</a></li>
    51535160                        <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>
    51545161                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">9.3.1</a></li>
     
    51595166                     </ul>
    51605167                  </li>
    5161                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.4</a>, <a href="#rfc.xref.Part4.2">3.4</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>
    5162                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.4</a></li>
    5163                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.4</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.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>
    51645171                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
    51655172                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
     
    51715178                     </ul>
    51725179                  </li>
    5173                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.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.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>
    51745181                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">6.1</a></li>
    51755182                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
    51765183                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
    51775184                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">7.4</a></li>
    5178                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.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.1.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>
    51795186                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">5.2</a></li>
    51805187                        <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>
    51815188                     </ul>
    51825189                  </li>
    5183                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.3</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.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>
    51845191                        <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.3.3</a></li>
    51855192                        <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>
     
    51895196                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">7.2</a></li>
    51905197                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">6.3.4</a></li>
    5191                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.3</a></li>
     5198                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2</a></li>
    51925199                        <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.10">6.3.4</a></li>
    51935200                     </ul>
     
    52255232                  <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>
    52265233                  <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>
    5227                   <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.5</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>
    5228                         <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.5</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>
    52295236                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
    52305237                     </ul>
     
    52425249                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    52435250                  <li><em>RFC2277</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2277.1">8.3</a>, <a href="#RFC2277"><b>12.2</b></a></li>
    5244                   <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.6</a>, <a href="#RFC2295"><b>12.2</b></a></li>
     5251                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.5</a>, <a href="#RFC2295"><b>12.2</b></a></li>
    52455252                  <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>
    5246                   <li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.3.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
    5247                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.3.4</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>
    52485255                     </ul>
    52495256                  </li>
     
    53015308            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    53025309                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.2.1</b></a></li>
    5303                   <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.4</b></a></li>
     5310                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.3</b></a></li>
    53045311                  <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>
    53055312                  <li>Status Codes Classes&nbsp;&nbsp;
     
    53205327            </li>
    53215328            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    5322                   <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.6.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.3">9.3.2</a>, <a href="#rfc.xref.header.user-agent.4">10.1</a></li>
     5329                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.5.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.3">9.3.2</a>, <a href="#rfc.xref.header.user-agent.4">10.1</a></li>
    53235330               </ul>
    53245331            </li>
    53255332            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    5326                   <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.6.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>
     5333                  <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.5.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>
    53275334               </ul>
    53285335            </li>
Note: See TracChangeset for help on using the changeset viewer.