Changeset 1650


Ignore:
Timestamp:
Mar 30, 2012, 9:42:29 AM (8 years ago)
Author:
julian.reschke@…
Message:

Step 13 of p2/p3-merge (see #351)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1647 r1650  
    12231223                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12241224</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1225          the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1225         the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12261226      </p>
    12271227      <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining
     
    14181418      <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    14191419      </p>
    1420       <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1420      <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    14211421      </p>
    14221422      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to
     
    17251725      </p>
    17261726      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1727       <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix F.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1727      <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    17281728         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    17291729         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
     
    21872187      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21882188      <ul>
    2189          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.11</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    2190          </li>
    2191          <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
     2189         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2190         </li>
     2191         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    21922192         </li>
    21932193      </ul>
     
    25342534         <li>Pointer to specification text</li>
    25352535      </ul>
    2536       <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2536      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    25372537      </p>
    25382538      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
     
    37583758                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">8.6</a></li>
    37593759                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li>
    3760                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>
    3761                         <li><em>Section 7.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3762                         <li><em>Section 7.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>
     3760                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>
     3761                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
     3762                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     3763                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>
    37633764                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    3764                         <li><em>Appendix F.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
    37653765                     </ul>
    37663766                  </li>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1649 r1650  
    500500      <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
    501501      <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E">
    502       <link rel="Appendix" title="F THE TEXT FORMERLY KNOWN AS PART3" href="#rfc.section.F">
    503502      <link href="p1-messaging.html" rel="prev">
    504503      <link href="p3-payload.html" rel="next">
     
    714713         <li>7.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
    715714               <li>7.1&nbsp;&nbsp;&nbsp;<a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li>
     715               <li>7.2&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
     716               <li>7.3&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    716717            </ul>
    717718         </li>
     
    821822            </ul>
    822823         </li>
    823          <li>F.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.F">THE TEXT FORMERLY KNOWN AS PART3</a><ul>
    824                <li>F.1&nbsp;&nbsp;&nbsp;<a href="#representation3">Representation</a><ul>
    825                      <li>F.1.1&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
    826                      <li>F.1.2&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    827                   </ul>
    828                </li>
    829             </ul>
    830          </li>
    831824         <li><a href="#rfc.index">Index</a></li>
    832825      </ul>
     
    23712364         safe and proper transfer of the message.
    23722365      </p>
     2366      <div id="rfc.iref.r.1"></div>
    23732367      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    2374       <p id="rfc.section.7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
     2368      <p id="rfc.section.7.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
     2369         that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
     2370         at some point in the future (e.g., in a PUT request).
     2371      </p>
     2372      <p id="rfc.section.7.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
     2373         identified by the effective request URI). The precise semantics of a representation are determined by the type of message
     2374         (request or response), the request method, the response status code, and the representation metadata. For example, the above
     2375         semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
     2376         response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
     2377         the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
     2378         URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
     2379         next steps are suggested for resolving it.
     2380      </p>
     2381      <p id="rfc.section.7.p.3">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
    23752382         of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed
    2376          in an HTTP message, it is referred to as the payload of the message.
    2377       </p>
    2378       <p id="rfc.section.7.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
    2379          to ensure safe and proper transfer of the message.
     2383         in an HTTP message, it is referred to as the payload of the message. <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: #351]</span>
     2384      </p>
     2385      <p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
     2386         to ensure safe and proper transfer of the message. <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: #351]</span>
    23802387      </p>
    23812388      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
     
    24032410      <p id="rfc.section.7.1.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
    24042411            cache invalidation.]</span>
     2412      </p>
     2413      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
     2414      <p id="rfc.section.7.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
     2415         body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
     2416         with the same effective request URI.
     2417      </p>
     2418      <p id="rfc.section.7.2.p.2">The following header fields are defined as representation metadata:</p>
     2419      <div id="rfc.table.u.5">
     2420         <table class="tt full left" cellpadding="3" cellspacing="0">
     2421            <thead>
     2422               <tr>
     2423                  <th>Header Field Name</th>
     2424                  <th>Defined in...</th>
     2425               </tr>
     2426            </thead>
     2427            <tbody>
     2428               <tr>
     2429                  <td class="left">Content-Encoding</td>
     2430                  <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;9.6</a></td>
     2431               </tr>
     2432               <tr>
     2433                  <td class="left">Content-Language</td>
     2434                  <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;9.7</a></td>
     2435               </tr>
     2436               <tr>
     2437                  <td class="left">Content-Location</td>
     2438                  <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;9.8</a></td>
     2439               </tr>
     2440               <tr>
     2441                  <td class="left">Content-Type</td>
     2442                  <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;9.9</a></td>
     2443               </tr>
     2444               <tr>
     2445                  <td class="left">Expires</td>
     2446                  <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     2447               </tr>
     2448            </tbody>
     2449         </table>
     2450      </div>
     2451      <p id="rfc.section.7.2.p.3">Additional header fields define metadata about the selected representation, which might differ from the representation included
     2452         in the message for responses to some state-changing methods. The following header fields are defined as selected representation
     2453         metadata:
     2454      </p>
     2455      <div id="rfc.table.u.6">
     2456         <table class="tt full left" cellpadding="3" cellspacing="0">
     2457            <thead>
     2458               <tr>
     2459                  <th>Header Field Name</th>
     2460                  <th>Defined in...</th>
     2461               </tr>
     2462            </thead>
     2463            <tbody>
     2464               <tr>
     2465                  <td class="left">ETag</td>
     2466                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     2467               </tr>
     2468               <tr>
     2469                  <td class="left">Last-Modified</td>
     2470                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     2471               </tr>
     2472            </tbody>
     2473         </table>
     2474      </div>
     2475      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
     2476      <p id="rfc.section.7.3.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     2477         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
     2478         the representation metadata header fields.
     2479      </p>
     2480      <p id="rfc.section.7.3.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
     2481         a two-layer, ordered encoding model:
     2482      </p>
     2483      <div id="rfc.figure.u.23"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
     2484</pre><p id="rfc.section.7.3.p.4">Content-Type 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
     2485         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
     2486         to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
     2487         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.3"><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.
     2488      </p>
     2489      <p id="rfc.section.7.3.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     2490         a given representation, with the result that some clients will examine a response body's content and override the specified
     2491         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
     2492         escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
     2493         match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
     2494         such "content sniffing" when it is used.
     2495      </p>
     2496      <p id="rfc.section.7.3.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
     2497         that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
     2498         that defined by the Content-Type.
    24052499      </p>
    24062500      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
     
    24652559         </p>
    24662560      </div>
    2467       <p id="rfc.section.8.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
     2561      <p id="rfc.section.8.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
    24682562      </p>
    24692563      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
     
    24972591         for an in-line image.
    24982592      </p>
    2499       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
     2593      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
    25002594 
    25012595  <a href="#header.accept" class="smpl">media-range</a>    = ( "*/*"
     
    25202614      </div>
    25212615      <p id="rfc.section.9.1.p.6">The example</p>
    2522       <div id="rfc.figure.u.24"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
     2616      <div id="rfc.figure.u.25"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    25232617</pre><p id="rfc.section.9.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    25242618         quality".
     
    25302624      </p>
    25312625      <p id="rfc.section.9.1.p.10">A more elaborate example is</p>
    2532       <div id="rfc.figure.u.25"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
     2626      <div id="rfc.figure.u.26"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    25332627          text/x-dvi; q=0.8, text/x-c
    25342628</pre><p id="rfc.section.9.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
     
    25382632         to a given type, the most specific reference has precedence. For example,
    25392633      </p>
    2540       <div id="rfc.figure.u.26"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
     2634      <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
    25412635</pre><p id="rfc.section.9.1.p.15">have the following precedence: </p>
    25422636      <ol>
     
    25492643         which matches that type. For example,
    25502644      </p>
    2551       <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     2645      <div id="rfc.figure.u.28"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    25522646          text/html;level=2;q=0.4, */*;q=0.5
    25532647</pre><p id="rfc.section.9.1.p.18">would cause the following values to be associated:</p>
    2554       <div id="rfc.table.u.5">
     2648      <div id="rfc.table.u.7">
    25552649         <table class="tt full left" cellpadding="3" cellspacing="0">
    25562650            <thead>
     
    25982692         that capability to a server which is capable of representing documents in those character encodings.
    25992693      </p>
    2600       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
     2694      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
    26012695                         [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    26022696</pre><p id="rfc.section.9.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;5.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
    26032697         example is
    26042698      </p>
    2605       <div id="rfc.figure.u.29"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     2699      <div id="rfc.figure.u.30"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    26062700</pre><p id="rfc.section.9.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere
    26072701         in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly
     
    26192713         no encoding is preferred.
    26202714      </p>
    2621       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
     2715      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    26222716  <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*"
    26232717</pre><p id="rfc.section.9.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
    26242718      </p>
    26252719      <p id="rfc.section.9.3.p.4">For example,</p>
    2626       <div id="rfc.figure.u.31"></div><pre class="text">  Accept-Encoding: compress, gzip
     2720      <div id="rfc.figure.u.32"></div><pre class="text">  Accept-Encoding: compress, gzip
    26272721  Accept-Encoding:
    26282722  Accept-Encoding: *
     
    26622756         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;5.6</a>.
    26632757      </p>
    2664       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> =
     2758      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> =
    26652759                    1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    26662760  <a href="#header.accept-language" class="smpl">language-range</a>  =
     
    26692763         languages specified by that range. The quality value defaults to "q=1". For example,
    26702764      </p>
    2671       <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     2765      <div id="rfc.figure.u.34"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    26722766</pre><p id="rfc.section.9.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    26732767      </p>
     
    26972791         is strictly to inform the recipient of valid request methods associated with the resource.
    26982792      </p>
    2699       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.40"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>
     2793      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.40"></span>  <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>
    27002794</pre><p id="rfc.section.9.5.p.3">Example of use:</p>
    2701       <div id="rfc.figure.u.35"></div><pre class="text">  Allow: GET, HEAD, PUT
     2795      <div id="rfc.figure.u.36"></div><pre class="text">  Allow: GET, HEAD, PUT
    27022796</pre><p id="rfc.section.9.5.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    27032797      <p id="rfc.section.9.5.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
     
    27122806         identity of its underlying media type.
    27132807      </p>
    2714       <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.41"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
     2808      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.41"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    27152809</pre><p id="rfc.section.9.6.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;5.4</a>. An example of its use is
    27162810      </p>
    2717       <div id="rfc.figure.u.37"></div><pre class="text">  Content-Encoding: gzip
     2811      <div id="rfc.figure.u.38"></div><pre class="text">  Content-Encoding: gzip
    27182812</pre><p id="rfc.section.9.6.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
    27192813         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
     
    27272821         response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
    27282822      </p>
    2729       <p id="rfc.section.9.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;9.6</a>) that lists the content-coding(s) applied.
     2823      <p id="rfc.section.9.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;9.6</a>) that lists the content-coding(s) applied.
    27302824      </p>
    27312825      <p id="rfc.section.9.6.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.
     
    27392833         that this might not be equivalent to all the languages used within the representation.
    27402834      </p>
    2741       <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.42"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
     2835      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.42"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    27422836</pre><p id="rfc.section.9.7.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;5.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    27432837         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    27442838         field is
    27452839      </p>
    2746       <div id="rfc.figure.u.39"></div><pre class="text">  Content-Language: da
     2840      <div id="rfc.figure.u.40"></div><pre class="text">  Content-Language: da
    27472841</pre><p id="rfc.section.9.7.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
    27482842         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
     
    27522846         simultaneously in the original Maori and English versions, would call for
    27532847      </p>
    2754       <div id="rfc.figure.u.40"></div><pre class="text">  Content-Language: mi, en
     2848      <div id="rfc.figure.u.41"></div><pre class="text">  Content-Language: mi, en
    27552849</pre><p id="rfc.section.9.7.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    27562850         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
     
    27662860         would contain the same representation that is enclosed as payload in this message.
    27672861      </p>
    2768       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
     2862      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    27692863</pre><p id="rfc.section.9.8.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.49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[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
    27702864         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.
     
    28072901         the media type is that which would have been sent had the request been a GET.
    28082902      </p>
    2809       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
     2903      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
    28102904</pre><p id="rfc.section.9.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;5.5</a>. An example of the field is
    28112905      </p>
    2812       <div id="rfc.figure.u.43"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    2813 </pre><p id="rfc.section.9.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Appendix&nbsp;F.1.2</a>.
     2906      <div id="rfc.figure.u.44"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
     2907</pre><p id="rfc.section.9.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;7.3</a>.
    28142908      </p>
    28152909      <div id="rfc.iref.d.3"></div>
     
    28192913         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;5.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    28202914      </p>
    2821       <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
     2915      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.45"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
    28222916</pre><p id="rfc.section.9.10.p.3">An example is</p>
    2823       <div id="rfc.figure.u.45"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
     2917      <div id="rfc.figure.u.46"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    28242918</pre><p id="rfc.section.9.10.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:
    28252919      </p>
     
    28472941      <h2 id="rfc.section.9.11"><a href="#rfc.section.9.11">9.11</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    28482942      <p id="rfc.section.9.11.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>
    2849       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
     2943      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a>
    28502944 
    28512945  <a href="#header.expect" class="smpl">expectation</a>  = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ]
     
    28592953      </p>
    28602954      <p id="rfc.section.9.11.p.4">The only expectation defined by this specification is:</p>
    2861       <p id="rfc.section.9.11.p.5"><span id="rfc.iref.133"></span><span id="rfc.iref.e.2"></span> 100-continue
     2955      <p id="rfc.section.9.11.p.5"><span id="rfc.iref.134"></span><span id="rfc.iref.e.2"></span> 100-continue
    28622956      </p>
    28632957      <ul class="empty">
     
    28752969      <p id="rfc.section.9.12.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    28762970      </p>
    2877       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
     2971      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
    28782972 
    28792973  <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt;
    28802974</pre><p id="rfc.section.9.12.p.3">An example is:</p>
    2881       <div id="rfc.figure.u.48"></div><pre class="text">  From: webmaster@example.org
     2975      <div id="rfc.figure.u.49"></div><pre class="text">  From: webmaster@example.org
    28822976</pre><p id="rfc.section.9.12.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    28832977         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
     
    28962990      <p id="rfc.section.9.13.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
    28972991      </p>
    2898       <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
     2992      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    28992993</pre><p id="rfc.section.9.13.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
    29002994         the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
     
    29032997         then the original URI's fragment identifier is added to the final value.
    29042998      </p>
    2905       <div id="rfc.figure.u.50"></div>
     2999      <div id="rfc.figure.u.51"></div>
    29063000      <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p>  <pre class="text">  Location: /pub/WWW/People.html#tim
    29073001</pre>  <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p>
    2908       <div id="rfc.figure.u.51"></div>
     3002      <div id="rfc.figure.u.52"></div>
    29093003      <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p>  <pre class="text">  Location: http://www.example.net/index.html
    29103004</pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p>
     
    29183012      </p>
    29193013      <div class="note" id="rfc.section.9.13.p.9">
    2920          <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     3014         <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    29213015            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    29223016         </p>
     
    29283022         to trace a request which appears to be failing or looping mid-chain.
    29293023      </p>
    2930       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
     3024      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    29313025</pre><p id="rfc.section.9.14.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    29323026      <p id="rfc.section.9.14.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
     
    29343028      <p id="rfc.section.9.14.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.
    29353029      </p>
    2936       <div id="rfc.iref.r.1"></div>
     3030      <div id="rfc.iref.r.2"></div>
    29373031      <div id="rfc.iref.h.16"></div>
    29383032      <h2 id="rfc.section.9.15"><a href="#rfc.section.9.15">9.15</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
     
    29483042         non-HTTP URIs (e.g., FTP).
    29493043      </p>
    2950       <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
     3044      <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    29513045</pre><p id="rfc.section.9.15.p.5">Example:</p>
    2952       <div id="rfc.figure.u.54"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
     3046      <div id="rfc.figure.u.55"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    29533047</pre><p id="rfc.section.9.15.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
    29543048      </p>
    2955       <div id="rfc.iref.r.2"></div>
     3049      <div id="rfc.iref.r.3"></div>
    29563050      <div id="rfc.iref.h.17"></div>
    29573051      <h2 id="rfc.section.9.16"><a href="#rfc.section.9.16">9.16</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
     
    29613055      </p>
    29623056      <p id="rfc.section.9.16.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
    2963       <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
     3057      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    29643058</pre><div id="rule.delta-seconds">
    29653059         <p id="rfc.section.9.16.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
    29663060      </div>
    2967       <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
     3061      <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    29683062</pre><p id="rfc.section.9.16.p.6">Two examples of its use are</p>
    2969       <div id="rfc.figure.u.57"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
     3063      <div id="rfc.figure.u.58"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    29703064  Retry-After: 120
    29713065</pre><p id="rfc.section.9.16.p.8">In the latter example, the delay is 2 minutes.</p>
     
    29773071         identifying the application.
    29783072      </p>
    2979       <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.57"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
     3073      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.57"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    29803074</pre><p id="rfc.section.9.17.p.4">Example:</p>
    2981       <div id="rfc.figure.u.59"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
     3075      <div id="rfc.figure.u.60"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    29823076</pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    29833077      </p>
     
    30073101         doing so makes the field value more difficult to parse.
    30083102      </p>
    3009       <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.58"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
     3103      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.58"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )
    30103104</pre><p id="rfc.section.9.18.p.7">Example:</p>
    3011       <div id="rfc.figure.u.61"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     3105      <div id="rfc.figure.u.62"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    30123106</pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    30133107      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="method.registration" href="#method.registration">Method Registry</a></h2>
     
    33673461                  <td class="left">http</td>
    33683462                  <td class="left">standard</td>
    3369                   <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;9.6</a>
     3463                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;9.6</a>
    33703464                  </td>
    33713465               </tr>
     
    33743468                  <td class="left">http</td>
    33753469                  <td class="left">standard</td>
    3376                   <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;9.7</a>
     3470                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;9.7</a>
    33773471                  </td>
    33783472               </tr>
     
    33813475                  <td class="left">http</td>
    33823476                  <td class="left">standard</td>
    3383                   <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;9.8</a>
     3477                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;9.8</a>
    33843478                  </td>
    33853479               </tr>
     
    33883482                  <td class="left">http</td>
    33893483                  <td class="left">standard</td>
    3390                   <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;9.9</a>
     3484                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;9.9</a>
    33913485                  </td>
    33923486               </tr>
     
    38133907         MIME environments.
    38143908      </p>
    3815       <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.59"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
     3909      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.59"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
    38163910</pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this
    38173911         document and not the MIME specification.
    38183912      </p>
    38193913      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
    3820       <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;5.5.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
     3914      <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;5.5.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
    38213915         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    38223916         over HTTP.
     
    39214015      <p id="rfc.section.C.p.23">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    39224016         servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
    3923          relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;9.8</a>)
     4017         relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
    39244018      </p>
    39254019      <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
     
    39284022      </p>
    39294023      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    3930       <div id="rfc.figure.u.63"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     4024      <div id="rfc.figure.u.64"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    39314025 OWS media-range [ accept-params ] ] ) ]
    39324026<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
     
    40754169
    40764170<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    4077 </pre> <div id="rfc.figure.u.64"></div>
     4171</pre> <div id="rfc.figure.u.65"></div>
    40784172      <p>ABNF diagnostics:</p><pre class="inline">; qvalue UNDEFINED
    40794173; Accept defined but not used
     
    41254219      <p id="rfc.section.E.2.p.2">Other changes: </p>
    41264220      <ul>
    4127          <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.11"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>
     4221         <li>Move definitions of 304 and 412 condition codes to <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>
    41284222         </li>
    41294223      </ul>
     
    46534747      <h2 id="rfc.section.E.41"><a href="#rfc.section.E.41">E.41</a>&nbsp;<a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h2>
    46544748      <p id="rfc.section.E.41.p.1">None yet.</p>
    4655       <h1 id="rfc.section.F"><a href="#rfc.section.F">F.</a>&nbsp;THE TEXT FORMERLY KNOWN AS PART3
    4656       </h1>
    4657       <div id="rfc.iref.r.3"></div>
    4658       <h2 id="rfc.section.F.1"><a href="#rfc.section.F.1">F.1</a>&nbsp;<a id="representation3" href="#representation3">Representation</a></h2>
    4659       <p id="rfc.section.F.1.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
    4660          that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
    4661          at some point in the future (e.g., in a PUT request).
    4662       </p>
    4663       <p id="rfc.section.F.1.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
    4664          identified by the effective request URI). The precise semantics of a representation are determined by the type of message
    4665          (request or response), the request method, the response status code, and the representation metadata. For example, the above
    4666          semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
    4667          response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
    4668          the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
    4669          URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
    4670          next steps are suggested for resolving it.
    4671       </p>
    4672       <h3 id="rfc.section.F.1.1"><a href="#rfc.section.F.1.1">F.1.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h3>
    4673       <p id="rfc.section.F.1.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
    4674          body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
    4675          with the same effective request URI.
    4676       </p>
    4677       <p id="rfc.section.F.1.1.p.2">The following header fields are defined as representation metadata:</p>
    4678       <div id="rfc.table.u.6">
    4679          <table class="tt full left" cellpadding="3" cellspacing="0">
    4680             <thead>
    4681                <tr>
    4682                   <th>Header Field Name</th>
    4683                   <th>Defined in...</th>
    4684                </tr>
    4685             </thead>
    4686             <tbody>
    4687                <tr>
    4688                   <td class="left">Content-Encoding</td>
    4689                   <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;9.6</a></td>
    4690                </tr>
    4691                <tr>
    4692                   <td class="left">Content-Language</td>
    4693                   <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;9.7</a></td>
    4694                </tr>
    4695                <tr>
    4696                   <td class="left">Content-Location</td>
    4697                   <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a></td>
    4698                </tr>
    4699                <tr>
    4700                   <td class="left">Content-Type</td>
    4701                   <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;9.9</a></td>
    4702                </tr>
    4703                <tr>
    4704                   <td class="left">Expires</td>
    4705                   <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    4706                </tr>
    4707             </tbody>
    4708          </table>
    4709       </div>
    4710       <p id="rfc.section.F.1.1.p.3">Additional header fields define metadata about the selected representation, which might differ from the representation included
    4711          in the message for responses to some state-changing methods. The following header fields are defined as selected representation
    4712          metadata:
    4713       </p>
    4714       <div id="rfc.table.u.7">
    4715          <table class="tt full left" cellpadding="3" cellspacing="0">
    4716             <thead>
    4717                <tr>
    4718                   <th>Header Field Name</th>
    4719                   <th>Defined in...</th>
    4720                </tr>
    4721             </thead>
    4722             <tbody>
    4723                <tr>
    4724                   <td class="left">ETag</td>
    4725                   <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    4726                </tr>
    4727                <tr>
    4728                   <td class="left">Last-Modified</td>
    4729                   <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    4730                </tr>
    4731             </tbody>
    4732          </table>
    4733       </div>
    4734       <h3 id="rfc.section.F.1.2"><a href="#rfc.section.F.1.2">F.1.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h3>
    4735       <p id="rfc.section.F.1.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
    4736          to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
    4737          the representation metadata header fields.
    4738       </p>
    4739       <p id="rfc.section.F.1.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
    4740          a two-layer, ordered encoding model:
    4741       </p>
    4742       <div id="rfc.figure.u.65"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    4743 </pre><p id="rfc.section.F.1.2.p.4">Content-Type 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
    4744          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
    4745          to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
    4746          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.4"><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.
    4747       </p>
    4748       <p id="rfc.section.F.1.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
    4749          a given representation, with the result that some clients will examine a response body's content and override the specified
    4750          type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
    4751          escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
    4752          match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
    4753          such "content sniffing" when it is used.
    4754       </p>
    4755       <p id="rfc.section.F.1.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
    4756          that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
    4757          that defined by the Content-Type.
    4758       </p>
    47594749      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    47604750      <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>
     
    47644754            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    47654755                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.21"><b>4.3.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li>
    4766                   <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.133"><b>9.11</b></a></li>
     4756                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.134"><b>9.11</b></a></li>
    47674757                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.22"><b>4.3.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li>
    47684758               </ul>
     
    48334823                  <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">10.1</a>, <a href="#rfc.xref.CONNECT.2">C</a></li>
    48344824                  <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1.1</a></li>
    4835                   <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.iref.c.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.2">9.6</a>, <a href="#rfc.xref.header.content-encoding.3">10.3</a>, <a href="#rfc.xref.header.content-encoding.4">F.1.1</a></li>
    4836                   <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.1">10.3</a>, <a href="#rfc.xref.header.content-language.2">F.1.1</a></li>
    4837                   <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.iref.c.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.2">9.13</a>, <a href="#rfc.xref.header.content-location.3">10.3</a>, <a href="#rfc.xref.header.content-location.4">C</a>, <a href="#rfc.xref.header.content-location.5">F.1.1</a></li>
     4825                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.c.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.6</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li>
     4826                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.c.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li>
     4827                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc.iref.c.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.3">9.13</a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
    48384828                  <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.11">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
    4839                   <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.iref.c.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.4">10.3</a>, <a href="#rfc.xref.header.content-type.5">F.1.1</a></li>
     4829                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.c.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li>
    48404830               </ul>
    48414831            </li>
     
    49354925                        <li>Accept-Language&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.xref.header.accept-language.2">8.1</a>, <a href="#rfc.iref.h.5"><b>9.4</b></a>, <a href="#rfc.xref.header.accept-language.3">10.3</a></li>
    49364926                        <li>Allow&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.6"><b>9.5</b></a>, <a href="#rfc.xref.header.allow.3">10.3</a>, <a href="#rfc.xref.header.allow.4">C</a></li>
    4937                         <li>Content-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.iref.h.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.2">9.6</a>, <a href="#rfc.xref.header.content-encoding.3">10.3</a>, <a href="#rfc.xref.header.content-encoding.4">F.1.1</a></li>
    4938                         <li>Content-Language&nbsp;&nbsp;<a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.1">10.3</a>, <a href="#rfc.xref.header.content-language.2">F.1.1</a></li>
    4939                         <li>Content-Location&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.2">9.13</a>, <a href="#rfc.xref.header.content-location.3">10.3</a>, <a href="#rfc.xref.header.content-location.4">C</a>, <a href="#rfc.xref.header.content-location.5">F.1.1</a></li>
     4927                        <li>Content-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">5.4</a>, <a href="#rfc.xref.header.content-encoding.2">7.2</a>, <a href="#rfc.iref.h.7"><b>9.6</b></a>, <a href="#rfc.xref.header.content-encoding.3">9.6</a>, <a href="#rfc.xref.header.content-encoding.4">10.3</a></li>
     4928                        <li>Content-Language&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">7.2</a>, <a href="#rfc.iref.h.8"><b>9.7</b></a>, <a href="#rfc.xref.header.content-language.2">10.3</a></li>
     4929                        <li>Content-Location&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.xref.header.content-location.2">7.2</a>, <a href="#rfc.iref.h.9"><b>9.8</b></a>, <a href="#rfc.xref.header.content-location.3">9.13</a>, <a href="#rfc.xref.header.content-location.4">10.3</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
    49404930                        <li>Content-Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.iref.h.21">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
    4941                         <li>Content-Type&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.iref.h.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.4">10.3</a>, <a href="#rfc.xref.header.content-type.5">F.1.1</a></li>
     4931                        <li>Content-Type&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">5.5</a>, <a href="#rfc.xref.header.content-type.4">7.2</a>, <a href="#rfc.iref.h.10"><b>9.9</b></a>, <a href="#rfc.xref.header.content-type.5">10.3</a></li>
    49424932                        <li>Date&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.11"><b>9.10</b></a>, <a href="#rfc.xref.header.date.2">10.3</a></li>
    49434933                        <li>Expect&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.h.12"><b>9.11</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a>, <a href="#rfc.xref.header.expect.4">C</a></li>
     
    50165006                     </ul>
    50175007                  </li>
    5018                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.10">4.5</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.11">E.2</a>, <a href="#rfc.xref.Part4.12">F.1.1</a>, <a href="#rfc.xref.Part4.13">F.1.1</a><ul>
    5019                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.13">F.1.1</a></li>
    5020                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.12">F.1.1</a></li>
     5008                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.10">4.5</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#Part4"><b>13.1</b></a>, <a href="#rfc.xref.Part4.13">E.2</a><ul>
     5009                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
     5010                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.11">7.2</a></li>
    50215011                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a></li>
    50225012                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">3.2</a></li>
     
    50385028                     </ul>
    50395029                  </li>
    5040                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.12">4.4.4</a>, <a href="#rfc.xref.Part6.13">4.4.4</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a>, <a href="#rfc.xref.Part6.18">8.1</a>, <a href="#Part6"><b>13.1</b></a>, <a href="#rfc.xref.Part6.19">F.1.1</a><ul>
     5030                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.12">4.4.4</a>, <a href="#rfc.xref.Part6.13">4.4.4</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a>, <a href="#rfc.xref.Part6.18">7.2</a>, <a href="#rfc.xref.Part6.19">8.1</a>, <a href="#Part6"><b>13.1</b></a><ul>
    50415031                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">2.3.4</a></li>
    50425032                        <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a></li>
     
    50455035                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">3.3</a></li>
    50465036                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">4.4.4</a></li>
    5047                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.19">F.1.1</a></li>
    5048                         <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.18">8.1</a></li>
     5037                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.18">7.2</a></li>
     5038                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.19">8.1</a></li>
    50495039                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.13">4.4.4</a></li>
    50505040                     </ul>
     
    50665056            </li>
    50675057            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    5068                   <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>9.15</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li>
    5069                   <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.3">F.1</a></li>
    5070                   <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.2"><b>9.16</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
     5058                  <li>Referer header field&nbsp;&nbsp;<a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.2"><b>9.15</b></a>, <a href="#rfc.xref.header.referer.2">10.3</a>, <a href="#rfc.xref.header.referer.3">C</a></li>
     5059                  <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">7</a></li>
     5060                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.3"><b>9.16</b></a>, <a href="#rfc.xref.header.retry-after.3">10.3</a></li>
    50715061                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">5.1</a>, <a href="#rfc.xref.RFC1123.2">5.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul>
    50725062                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">5.1</a></li>
     
    50815071                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">10.4</a>, <a href="#RFC1952"><b>13.1</b></a></li>
    50825072                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#RFC2045"><b>13.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li>
    5083                   <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">5.5</a>, <a href="#rfc.xref.RFC2046.2">5.5.2</a>, <a href="#RFC2046"><b>13.1</b></a>, <a href="#rfc.xref.RFC2046.3">A.2</a>, <a href="#rfc.xref.RFC2046.4">F.1.2</a><ul>
    5084                         <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.4">F.1.2</a></li>
     5073                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">5.5</a>, <a href="#rfc.xref.RFC2046.2">5.5.2</a>, <a href="#rfc.xref.RFC2046.3">7.3</a>, <a href="#RFC2046"><b>13.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
     5074                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">7.3</a></li>
    50855075                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.2">5.5.2</a></li>
    50865076                     </ul>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1649 r1650  
    25872587
    25882588<section title="Representation" anchor="representation">
     2589<iref item="representation"/>
     2590<t>
     2591   A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
     2592   communicated from one party to another.  A resource representation
     2593   is information that reflects the state of that resource, as observed
     2594   at some point in the past (e.g., in a response to GET) or to be
     2595   desired at some point in the future (e.g., in a PUT request).
     2596</t>
     2597<t>
     2598   Most, but not all, representations transferred via HTTP are intended
     2599   to be a representation of the target resource (the resource identified
     2600   by the effective request URI).  The precise semantics of a representation
     2601   are determined by the type of message (request or response), the request
     2602   method, the response status code, and the representation metadata.
     2603   For example, the above semantic is true for the representation in any
     2604   200 (OK) response to GET and for the representation in any PUT request.
     2605   A 200 response to PUT, in contrast, contains either a representation
     2606   that describes the successful action or a representation of the target
     2607   resource, with the latter indicated by a Content-Location header field
     2608   with the same value as the effective request URI.  Likewise, response
     2609   messages with an error status code usually contain a representation that
     2610   describes the error and what next steps are suggested for resolving it.
     2611</t>
    25892612<t>
    25902613   Request and Response messages &MAY; transfer a representation if not otherwise
     
    25932616   body).  When a complete or partial representation is enclosed in an HTTP message,
    25942617   it is referred to as the payload of the message.
     2618   <cref>#351</cref>
    25952619</t>
    25962620<t>
     
    25992623   from the message body by decoding any Transfer-Encoding that might
    26002624   have been applied to ensure safe and proper transfer of the message.
     2625   <cref>#351</cref>
    26012626</t>
    26022627
     
    26402665</section>
    26412666
     2667<section title="Representation Header Fields" anchor="representation.header.fields">
     2668  <x:anchor-alias value="representation-header"/>
     2669<t>
     2670   Representation header fields define metadata about the representation data
     2671   enclosed in the message body or, if no message body is present, about
     2672   the representation that would have been transferred in a 200 response
     2673   to a simultaneous GET request with the same effective request URI.
     2674</t>
     2675<t>
     2676   The following header fields are defined as representation metadata:
     2677</t>
     2678<texttable align="left">
     2679  <ttcol>Header Field Name</ttcol>
     2680  <ttcol>Defined in...</ttcol>
     2681
     2682  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
     2683  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
     2684  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
     2685  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
     2686  <c>Expires</c> <c>&header-expires;</c>
     2687</texttable>
     2688<t>
     2689   Additional header fields define metadata about the selected
     2690   representation, which might differ from the representation included
     2691   in the message for responses to some state-changing methods.
     2692   The following header fields are defined as selected representation
     2693   metadata:
     2694</t>
     2695<texttable align="left">
     2696  <ttcol>Header Field Name</ttcol>
     2697  <ttcol>Defined in...</ttcol>
     2698
     2699  <c>ETag</c> <c>&header-etag;</c>
     2700  <c>Last-Modified</c> <c>&header-last-modified;</c>
     2701</texttable>
     2702</section>
     2703
     2704<section title="Representation Data" anchor="representation.data">
     2705  <x:anchor-alias value="representation-data"/>
     2706<t>
     2707   The representation body associated with an HTTP message is
     2708   either provided as the payload body of the message or
     2709   referred to by the message semantics and the effective request
     2710   URI.  The representation data is in a format and encoding defined by
     2711   the representation metadata header fields.
     2712</t>
     2713<t>
     2714   The data type of the representation data
     2715   is determined via the header fields Content-Type and Content-Encoding.
     2716   These define a two-layer, ordered encoding model:
     2717</t>
     2718<figure><artwork type="example">
     2719  representation-data := Content-Encoding( Content-Type( bits ) )
     2720</artwork></figure>
     2721<t>
     2722   Content-Type specifies the media type of the underlying data, which
     2723   defines both the data format and how that data &SHOULD; be processed
     2724   by the recipient (within the scope of the request method semantics).
     2725   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     2726   Content-Type header field defining the media type of the associated
     2727   representation unless that metadata is unknown to the sender.
     2728   If the Content-Type header field is not present, it indicates that
     2729   the sender does not know the media type of the representation;
     2730   recipients &MAY; either assume that the media type is
     2731   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     2732   or examine the content to determine its type.
     2733</t>
     2734<t>
     2735   In practice, resource owners do not always properly configure their origin
     2736   server to provide the correct Content-Type for a given representation,
     2737   with the result that some clients will examine a response body's content
     2738   and override the specified type.
     2739   Clients that do so risk drawing incorrect conclusions, which might expose
     2740   additional security risks (e.g., "privilege escalation").  Furthermore,
     2741   it is impossible to determine the sender's intent by examining the data
     2742   format: many data formats match multiple media types that differ only in
     2743   processing semantics.  Implementers are encouraged to provide a means of
     2744   disabling such "content sniffing" when it is used.
     2745</t>
     2746<t>
     2747   Content-Encoding is used to indicate any additional content
     2748   codings applied to the data, usually for the purpose of data
     2749   compression, that are a property of the representation.  If
     2750   Content-Encoding is not present, then there is no additional
     2751   encoding beyond that defined by the Content-Type.
     2752</t>
     2753</section>
    26422754</section>
    26432755
     
    66756787</section>
    66766788
    6677 <section title="THE TEXT FORMERLY KNOWN AS PART3">
    6678 
    6679 <section title="Representation" anchor="representation3">
    6680 <iref item="representation"/>
    6681 <t>
    6682    A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
    6683    communicated from one party to another.  A resource representation
    6684    is information that reflects the state of that resource, as observed
    6685    at some point in the past (e.g., in a response to GET) or to be
    6686    desired at some point in the future (e.g., in a PUT request).
    6687 </t>
    6688 <t>
    6689    Most, but not all, representations transferred via HTTP are intended
    6690    to be a representation of the target resource (the resource identified
    6691    by the effective request URI).  The precise semantics of a representation
    6692    are determined by the type of message (request or response), the request
    6693    method, the response status code, and the representation metadata.
    6694    For example, the above semantic is true for the representation in any
    6695    200 (OK) response to GET and for the representation in any PUT request.
    6696    A 200 response to PUT, in contrast, contains either a representation
    6697    that describes the successful action or a representation of the target
    6698    resource, with the latter indicated by a Content-Location header field
    6699    with the same value as the effective request URI.  Likewise, response
    6700    messages with an error status code usually contain a representation that
    6701    describes the error and what next steps are suggested for resolving it.
    6702 </t>
    6703 
    6704 <section title="Representation Header Fields" anchor="representation.header.fields">
    6705   <x:anchor-alias value="representation-header"/>
    6706 <t>
    6707    Representation header fields define metadata about the representation data
    6708    enclosed in the message body or, if no message body is present, about
    6709    the representation that would have been transferred in a 200 response
    6710    to a simultaneous GET request with the same effective request URI.
    6711 </t>
    6712 <t>
    6713    The following header fields are defined as representation metadata:
    6714 </t>
    6715 <texttable align="left">
    6716   <ttcol>Header Field Name</ttcol>
    6717   <ttcol>Defined in...</ttcol>
    6718 
    6719   <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
    6720   <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    6721   <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    6722   <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    6723   <c>Expires</c> <c>&header-expires;</c>
    6724 </texttable>
    6725 <t>
    6726    Additional header fields define metadata about the selected
    6727    representation, which might differ from the representation included
    6728    in the message for responses to some state-changing methods.
    6729    The following header fields are defined as selected representation
    6730    metadata:
    6731 </t>
    6732 <texttable align="left">
    6733   <ttcol>Header Field Name</ttcol>
    6734   <ttcol>Defined in...</ttcol>
    6735 
    6736   <c>ETag</c> <c>&header-etag;</c>
    6737   <c>Last-Modified</c> <c>&header-last-modified;</c>
    6738 </texttable>
    6739 </section>
    6740 
    6741 <section title="Representation Data" anchor="representation.data">
    6742   <x:anchor-alias value="representation-data"/>
    6743 <t>
    6744    The representation body associated with an HTTP message is
    6745    either provided as the payload body of the message or
    6746    referred to by the message semantics and the effective request
    6747    URI.  The representation data is in a format and encoding defined by
    6748    the representation metadata header fields.
    6749 </t>
    6750 <t>
    6751    The data type of the representation data
    6752    is determined via the header fields Content-Type and Content-Encoding.
    6753    These define a two-layer, ordered encoding model:
    6754 </t>
    6755 <figure><artwork type="example">
    6756   representation-data := Content-Encoding( Content-Type( bits ) )
    6757 </artwork></figure>
    6758 <t>
    6759    Content-Type specifies the media type of the underlying data, which
    6760    defines both the data format and how that data &SHOULD; be processed
    6761    by the recipient (within the scope of the request method semantics).
    6762    Any HTTP/1.1 message containing a payload body &SHOULD; include a
    6763    Content-Type header field defining the media type of the associated
    6764    representation unless that metadata is unknown to the sender.
    6765    If the Content-Type header field is not present, it indicates that
    6766    the sender does not know the media type of the representation;
    6767    recipients &MAY; either assume that the media type is
    6768    "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    6769    or examine the content to determine its type.
    6770 </t>
    6771 <t>
    6772    In practice, resource owners do not always properly configure their origin
    6773    server to provide the correct Content-Type for a given representation,
    6774    with the result that some clients will examine a response body's content
    6775    and override the specified type.
    6776    Clients that do so risk drawing incorrect conclusions, which might expose
    6777    additional security risks (e.g., "privilege escalation").  Furthermore,
    6778    it is impossible to determine the sender's intent by examining the data
    6779    format: many data formats match multiple media types that differ only in
    6780    processing semantics.  Implementers are encouraged to provide a means of
    6781    disabling such "content sniffing" when it is used.
    6782 </t>
    6783 <t>
    6784    Content-Encoding is used to indicate any additional content
    6785    codings applied to the data, usually for the purpose of data
    6786    compression, that are a property of the representation.  If
    6787    Content-Encoding is not present, then there is no additional
    6788    encoding beyond that defined by the Content-Type.
    6789 </t>
    6790 </section>
    6791 </section>
    6792 </section>
    6793 
    67946789</back>
    67956790</rfc>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1647 r1650  
    686686      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#notation" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    687687  <a href="#notation" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    688   <a href="#notation" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>&gt;
     688  <a href="#notation" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>&gt;
    689689</pre><div id="rfc.iref.m.1"></div>
    690690      <div id="rfc.iref.v.1"></div>
     
    896896      </div>
    897897      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3>
    898       <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix F.3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>):
     898      <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>):
    899899      </p>
    900900      <div id="rfc.figure.u.6"></div>
     
    11231123         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    11241124      </p>
    1125       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200
     1125      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200
    11261126         response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires,
    11271127         or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
     
    14241424                  </li>
    14251425                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">4.1</a>, <a href="#Part2"><b>8.1</b></a><ul>
    1426                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2</a></li>
    1427                         <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.3</a></li>
    1428                         <li><em>Section 7.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1</a></li>
    1429                         <li><em>Appendix F.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1426                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2</a></li>
     1427                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1428                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.3</a></li>
     1429                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1</a></li>
    14301430                     </ul>
    14311431                  </li>
  • draft-ietf-httpbis/latest/p5-range.html

    r1643 r1650  
    711711      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">OWS</a>        = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    712712  <a href="#core.rules" class="smpl">token</a>      = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    713   <a href="#core.rules" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>&gt;
     713  <a href="#core.rules" class="smpl">HTTP-date</a>  = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>&gt;
    714714</pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    715715      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
     
    15851585                  </li>
    15861586                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.2.1</a>, <a href="#rfc.xref.Part2.2">1.2.1</a>, <a href="#Part2"><b>9.1</b></a><ul>
    1587                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2.1</a></li>
     1587                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2.1</a></li>
    15881588                     </ul>
    15891589                  </li>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1645 r1650  
    805805      <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p>
    806806      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">field-name</a>    = &lt;field-name, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>&gt;
    807   <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a>&gt;
     807  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>&gt;
    808808  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    809809  <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a>&gt;
     
    987987         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    988988            response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
    989             operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     989            operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    990990         </li>
    991991      </ul>
     
    14491449         that time.
    14501450      </p>
    1451       <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
     1451      <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
    14521452      </p>
    14531453      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
     
    21842184                        <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.2</a>, <a href="#rfc.xref.Part2.6">2.6</a></li>
    21852185                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    2186                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
    2187                         <li><em>Section 7.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
     2186                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
     2187                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
    21882188                     </ul>
    21892189                  </li>
Note: See TracChangeset for help on using the changeset viewer.