Ignore:
Timestamp:
23/07/10 05:43:59 (12 years ago)
Author:
fielding@…
Message:

regenerate html

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r873 r875  
    711711         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
    712712         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate request targets and relationships between resources. Messages are passed in a format similar to that used by Internet
    713          mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
     713         mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
    714714      </p>
    715715      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented

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

    r868 r875  
    551551         </li>
    552552         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a></li>
    553          <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#entity">Representation</a><ul class="toc">
     553         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
    554554               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li>
    555555            </ul>
    … …  
    903903         fields. Unrecognized header fields are treated as entity-header fields.
    904904      </p>
    905       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="entity" href="#entity">Representation</a></h1>
     905      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    906906      <p id="rfc.section.6.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
    907907         of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed
    … …  
    968968      </p>
    969969      <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p>
    970       <p id="rfc.section.7.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
     970      <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    971971         the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
    972972         to HTTP might use the OPTIONS body to make more detailed queries on the server.
    … …  
    991991      <div id="rfc.iref.g.8"></div>
    992992      <div id="rfc.iref.m.2"></div>
    993       <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) currently corresponds to the resource identified
    994          by the Effective Request URI.
     993      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
     994         identified by the Effective Request URI.
    995995      </p>
    996996      <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
    … …  
    10001000         If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred
    10011001         only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce
    1002          unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring
     1002         unnecessary network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring
    10031003         data already held by the client.
    10041004      </p>
    … …  
    10181018         hypertext links for validity, accessibility, and recent modification.
    10191019      </p>
    1020       <p id="rfc.section.7.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs
    1021          from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the
    1022          cache <em class="bcp14">MUST</em> treat the cache entry as stale.
     1020      <p id="rfc.section.7.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource. If the new field values indicate that the cached
     1021         representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5,
     1022         ETag or Last-Modified), then the cache <em class="bcp14">MUST</em> treat the cache entry as stale.
    10231023      </p>
    10241024      <div id="rfc.iref.p.1"></div>
    10251025      <div id="rfc.iref.m.4"></div>
    10261026      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    1027       <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed
    1028          by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following
    1029          functions:
     1027      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
     1028         processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the
     1029         following functions:
    10301030      </p>
    10311031      <ul>
    … …  
    10391039      </p>
    10401040      <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
    1041          200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
     1041         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes a representation
    10421042         that describes the result.
    10431043      </p>
    1044       <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location
    1045          header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
     1044      <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
     1045         a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    10461046      </p>
    10471047      <p id="rfc.section.7.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.
    … …  
    10851085         location.
    10861086      </p>
    1087       <p id="rfc.section.7.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted,
    1088          or 204 (No Content) if the action has been enacted but the response does not include a representation.
    1089       </p>
    1090       <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those
    1091          entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
     1087      <p id="rfc.section.7.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been
     1088         enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
     1089      </p>
     1090      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached representations,
     1091         those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method <em class="bcp14">MUST NOT</em> be cached.
    10921092      </p>
    10931093      <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2>
    … …  
    10951095      <div id="rfc.iref.m.7"></div>
    10961096      <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the
    1097          request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the
    1098          origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
     1097         request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
     1098         the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
    10991099      </p>
    11001100      <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    … …  
    11031103         infinite loop.
    11041104      </p>
    1105       <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.
     1105      <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method <em class="bcp14">MUST NOT</em> be cached.
    11061106      </p>
    11071107      <div id="rfc.iref.c.1"></div>
    … …  
    11521152      <dl>
    11531153         <dt>GET</dt>
    1154          <dd>an entity corresponding to the requested resource is sent in the response;</dd>
     1154         <dd>a representation corresponding to the requested resource is sent in the response;</dd>
    11551155         <dt>HEAD</dt>
    11561156         <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd>
    11571157         <dt>POST</dt>
    1158          <dd>an entity describing or containing the result of the action;</dd>
     1158         <dd>a representation describing or containing the result of the action;</dd>
    11591159         <dt>TRACE</dt>
    1160          <dd>an entity containing the request message as received by the end server.</dd>
     1160         <dd>a representation containing the request message as received by the end server.</dd>
    11611161      </dl>
    11621162      <div id="rfc.iref.28"></div>
    … …  
    11691169         server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead.
    11701170      </p>
    1171       <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the representation of the resource
     1171      <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
    11721172         just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> of <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    11731173      </p>
    … …  
    12161216      <div id="rfc.iref.s.10"></div>
    12171217      <h3 id="rfc.section.8.2.7"><a href="#rfc.section.8.2.7">8.2.7</a>&nbsp;<a id="status.206" href="#status.206">206 Partial Content</a></h3>
    1218       <p id="rfc.section.8.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined
    1219          in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
     1218      <p id="rfc.section.8.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed payload is a partial representation as
     1219         defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
    12201220      </p>
    12211221      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    13261326      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
    13271327      <p id="rfc.section.8.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD
    1328          request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
    1329          These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user.
     1328         request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
     1329         These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
    13301330      </p>
    13311331      <p id="rfc.section.8.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    … …  
    13711371      <div id="rfc.iref.s.25"></div>
    13721372      <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    1373       <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response entities which have content characteristics
     1373      <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    13741374         not acceptable according to the accept headers sent in the request.
    13751375      </p>
    … …  
    14011401      <p id="rfc.section.8.4.10.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
    14021402         situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response
    1403          body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include
    1404          enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
     1403         body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
     1404         include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
    14051405      </p>
    14061406      <p id="rfc.section.8.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation
    … …  
    14371437      <div id="rfc.iref.s.32"></div>
    14381438      <h3 id="rfc.section.8.4.14"><a href="#rfc.section.8.4.14">8.4.14</a>&nbsp;<a id="status.413" href="#status.413">413 Request Entity Too Large</a></h3>
    1439       <p id="rfc.section.8.4.14.p.1">The server is refusing to process a request because the request entity is larger than the server is willing or able to process.
    1440          The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
     1439      <p id="rfc.section.8.4.14.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able
     1440         to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.
    14411441      </p>
    14421442      <p id="rfc.section.8.4.14.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
    … …  
    14701470      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
    14711471      <p id="rfc.section.8.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
    1472          of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
    1473          User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method.
     1472         of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
     1473         User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
    14741474      </p>
    14751475      <div id="rfc.iref.60"></div>
    … …  
    15151515      <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    15161516         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    1517          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
     1517         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.
    15181518      </p>
    15191519      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>

  • draft-ietf-httpbis/latest/p3-payload.html

    r868 r875  
    377377      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    378378      <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2">
    379       <link rel="Chapter" title="3 Entity" href="#rfc.section.3">
     379      <link rel="Chapter" title="3 Representation" href="#rfc.section.3">
    380380      <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4">
    381381      <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
    … …  
    384384      <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
    385385      <link rel="Chapter" href="#rfc.section.9" title="9 References">
    386       <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A">
     386      <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
    387387      <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
    388388      <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C">
    … …  
    555555            </ul>
    556556         </li>
    557          <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#entity">Entity</a><ul class="toc">
     557         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
    558558               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#entity.header.fields">Entity Header Fields</a></li>
    559                <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#entity.body">Entity Body</a><ul class="toc">
     559               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a><ul class="toc">
    560560                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
    561561                  </ul>
    … …  
    597597         </li>
    598598         <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
    599          <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc">
     599         <li class="tocline0">A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul class="toc">
    600600               <li class="tocline1">A.1&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li>
    601601               <li class="tocline1">A.2&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
    … …  
    818818      </p>
    819819      <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>
    820       <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next
    821          paragraph.
     820      <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
    822821      </p>
    823822      <p id="rfc.section.2.3.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and
    824823         allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
    825          entire entity-body. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if
    826          the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for
    827          some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent
    828          the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body;
    829          a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
    830       </p>
    831       <p id="rfc.section.2.3.1.p.3">If an entity-body is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
    832       </p>
    833       <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character set (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
    834          to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or
    835          its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section&nbsp;2.1.1</a> for compatibility problems.
     824         entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is
     825         in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte
     826         character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the
     827         equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload
     828         body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
     829      </p>
     830      <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
     831      </p>
     832      <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined
     833         to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1"
     834         or its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section&nbsp;2.1.1</a> for compatibility problems.
    836835      </p>
    837836      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    838       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All
    839          multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
     837      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message-body.
     838         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
    840839      </p>
    841840      <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does
    … …  
    866865</pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
    867866      </p>
    868       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="entity" href="#entity">Entity</a></h1>
     867      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    869868      <p id="rfc.section.3.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
    870869         of entity-header fields and a representation body, although some responses will only include the entity-headers.
    … …  
    874873      </p>
    875874      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>
    876       <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the entity-body or, if no body is present, about the resource identified by the
    877          request.
     875      <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is
     876         present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the
     877         Effective Request URI.
    878878      </p>
    879879      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#entity.header.fields" class="smpl">entity-header</a>  = <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
    … …  
    892892         fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies.
    893893      </p>
    894       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="entity.body" href="#entity.body">Entity Body</a></h2>
    895       <p id="rfc.section.3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
    896       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  <a href="#entity.body" class="smpl">entity-body</a>    = *<a href="#notation" class="smpl">OCTET</a>
    897 </pre><p id="rfc.section.3.2.p.3">An entity-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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     894      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
     895      <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
     896      <p id="rfc.section.3.2.p.2">A payload 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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    898897         safe and proper transfer of the message.
    899898      </p>
    900899      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="type" href="#type">Type</a></h3>
    901       <p id="rfc.section.3.2.1.p.1">When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type
     900      <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type
    902901         and Content-Encoding. These define a two-layer, ordered encoding model:
    903902      </p>
    904       <div id="rfc.figure.u.14"></div><pre class="text">  entity-body := Content-Encoding( Content-Type( data ) )
    905 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.
     903      <div id="rfc.figure.u.13"></div><pre class="text">  payload-body := Content-Encoding( Content-Type( data ) )
     904</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a payload body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.
    906905      </p>
    907906      <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it 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.
    … …  
    911910         the specified type.
    912911      </p>
    913       <p id="rfc.section.3.2.1.p.6">Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").
     912      <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").
    914913         Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
    915914      </p>
    916915      <p id="rfc.section.3.2.1.p.7">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data
    917          compression, that are a property of the requested resource. There is no default encoding.
     916         compression, that are a property of the representation. There is no default encoding.
    918917      </p>
    919918      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    … …  
    977976      <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
    978977         an initial response from the origin server. Selection is based on a list of the available representations of the response
    979          included within the header fields or entity-body of the initial response, with each representation identified by its own URI.
    980          Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually
    981          by the user selecting from a generated (possibly hypertext) menu.
     978         included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     979         from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the
     980         user selecting from a generated (possibly hypertext) menu.
    982981      </p>
    983982      <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
    … …  
    10051004         for an in-line image.
    10061005      </p>
    1007       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
     1006      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
    10081007  <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
    10091008 
    … …  
    10301029      </div>
    10311030      <p id="rfc.section.5.1.p.6">The example</p>
    1032       <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
     1031      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    10331032</pre><p id="rfc.section.5.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
    10341033         quality."
    … …  
    10391038      </p>
    10401039      <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
    1041       <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
     1040      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10421041          text/x-dvi; q=0.8, text/x-c
    10431042</pre><p id="rfc.section.5.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
    … …  
    10471046         to a given type, the most specific reference has precedence. For example,
    10481047      </p>
    1049       <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
     1048      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
    10501049</pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
    10511050      <ol>
    … …  
    10581057         which matches that type. For example,
    10591058      </p>
    1060       <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     1059      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10611060          text/html;level=2;q=0.4, */*;q=0.5
    10621061</pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
    … …  
    11071106         to a server which is capable of representing documents in those character sets.
    11081107      </p>
    1109       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
     1108      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
    11101109          <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a>
    11111110  <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
    … …  
    11141113         example is
    11151114      </p>
    1116       <div id="rfc.figure.u.21"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     1115      <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    11171116</pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
    11181117         not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
    … …  
    11281127      <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
    11291128      </p>
    1130       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
     1129      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
    11311130                     <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>
    11321131  <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>  =
    … …  
    11361135      </p>
    11371136      <p id="rfc.section.5.3.p.4">Examples of its use are:</p>
    1138       <div id="rfc.figure.u.23"></div><pre class="text">  Accept-Encoding: compress, gzip
     1137      <div id="rfc.figure.u.22"></div><pre class="text">  Accept-Encoding: compress, gzip
    11391138  Accept-Encoding:
    11401139  Accept-Encoding: *
    … …  
    11801179         in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    11811180      </p>
    1182       <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
     1181      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
    11831182                    <a href="#header.accept-language" class="smpl">Accept-Language-v</a>
    11841183  <a href="#header.accept-language" class="smpl">Accept-Language-v</a> =
    … …  
    11891188         languages specified by that range. The quality value defaults to "q=1". For example,
    11901189      </p>
    1191       <div id="rfc.figure.u.25"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     1190      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    11921191</pre><p id="rfc.section.5.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>)
    11931192      </p>
    … …  
    12181217         is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
    12191218      </p>
    1220       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
     1219      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
    12211220  <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    12221221</pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
    12231222      </p>
    1224       <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
     1223      <div id="rfc.figure.u.26"></div><pre class="text">  Content-Encoding: gzip
    12251224</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
    12261225         and is only decoded before rendering or analogous usage. However, a non-transparent 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
    … …  
    12291228      <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <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;5.5</a>) that lists the non-identity content-coding(s) used.
    12301229      </p>
    1231       <p id="rfc.section.5.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1230      <p id="rfc.section.5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
    12321231      </p>
    12331232      <p id="rfc.section.5.5.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.
    … …  
    12371236      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    12381237      <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.
    1239          Note that this might not be equivalent to all the languages used within the entity-body.
    1240       </p>
    1241       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
     1238         Note that this might not be equivalent to all the languages used within the representation.
     1239      </p>
     1240      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
    12421241  <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    12431242</pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    … …  
    12451244         field is
    12461245      </p>
    1247       <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
     1246      <div id="rfc.figure.u.28"></div><pre class="text">  Content-Language: da
    12481247</pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
    12491248         that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
    … …  
    12531252         simultaneously in the original Maori and English versions, would call for
    12541253      </p>
    1255       <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
     1254      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
    12561255</pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    12571256         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
    … …  
    12671266         would contain the same representation that is enclosed as payload in this message.
    12681267      </p>
    1269       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
     1268      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
    12701269                    <a href="#header.content-location" class="smpl">Content-Location-v</a>
    12711270  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    … …  
    13081307      <div id="rfc.iref.h.8"></div>
    13091308      <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
    1310       <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body that provides an end-to-end message integrity check (MIC) of the entity-body. Note that
    1311          a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.
    1312       </p>
    1313       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
     1309      <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
     1310         message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload
     1311         body in transit, but is not proof against malicious attacks.
     1312      </p>
     1313      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
    13141314  <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>&gt;
    1315 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including
    1316          gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received.
    1317       </p>
    1318       <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but
    1319          not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that
    1320          encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation.
    1321       </p>
    1322       <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would
    1323          be sent if no transfer-encoding were being applied.
    1324       </p>
    1325       <p id="rfc.section.5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
     1315</pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
     1316         agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
     1317      </p>
     1318      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
     1319         applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response
     1320         chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload.
     1321      </p>
     1322      <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
    13261323         but this does not change how the digest is computed as defined in the preceding paragraph.
    13271324      </p>
    1328       <p id="rfc.section.5.8.p.7">There are several consequences of this. The entity-body for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
     1325      <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
    13291326         headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
    13301327         body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
    13311328         The Transfer-Encoding header field is not allowed within body-parts.
    13321329      </p>
    1333       <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
    1334       </p>
    1335       <div class="note" id="rfc.section.5.8.p.9">
     1330      <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
     1331      </p>
     1332      <div class="note" id="rfc.section.5.8.p.8">
    13361333         <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
    13371334            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
    … …  
    13451342      <div id="rfc.iref.h.9"></div>
    13461343      <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    1347       <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. In the case of responses to the HEAD method,
    1348          the media type is that which would have been sent had the request been a GET.
    1349       </p>
    1350       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
     1344      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD
     1345         method, the media type is that which would have been sent had the request been a GET.
     1346      </p>
     1347      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
    13511348  <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a>
    13521349</pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
    13531350      </p>
    1354       <div id="rfc.figure.u.34"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    1355 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
     1351      <div id="rfc.figure.u.33"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
     1352</pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
    13561353      </p>
    13571354      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    … …  
    17151712               <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
    17161713      </div>
    1717       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1>
    1718       <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045
    1719          discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully
    1720          chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date
    1721          comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
    1722       </p>
    1723       <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
     1714      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
     1715      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
     1716         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
     1717         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
     1718         to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
     1719      </p>
     1720      <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
    17241721         to HTTP also need to be aware of the differences because some conversions might be required.
    17251722      </p>
    … …  
    17321729         environments.
    17331730      </p>
    1734       <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
     1731      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
    17351732  <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
    17361733</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
    … …  
    17381735      </p>
    17391736      <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>
    1740       <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity 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;2.3.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
     1737      <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;2.3.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
    17411738         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    17421739         over HTTP.
    … …  
    17541751      </p>
    17551752      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    1756       <p id="rfc.section.A.4.p.1">RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier
    1757          on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental
    1758          applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    1759          a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).
     1753      <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
     1754         the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
     1755         experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
     1756         to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
    17601757      </p>
    17611758      <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
    1762       <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
     1759      <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
    17631760      </p>
    17641761      <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
    … …  
    17901787         in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
    17911788      </p>
    1792       <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
     1789      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
    17931790                        <a href="#content-disposition" class="smpl">content-disposition-v</a>
    17941791  <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a>
    … …  
    18001797  <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a>
    18011798</pre><p id="rfc.section.B.1.p.3">An example is</p>
    1802       <div id="rfc.figure.u.37"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
     1799      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
    18031800</pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply
    18041801         to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only.
    … …  
    18301827      </p>
    18311828      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    1832       <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
     1829      <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
    18331830<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v
    18341831<a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
    … …  
    18871884<a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token
    18881885
    1889 <a href="#entity.body" class="smpl">entity-body</a> = *OCTET
    18901886<a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length
    18911887 / Content-Location / Content-MD5 / Content-Range / Content-Type /
    … …  
    19181914
    19191915<a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
    1920 </pre> <div id="rfc.figure.u.39"></div>
     1916</pre> <div id="rfc.figure.u.38"></div>
    19211917      <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
    19221918; Accept-Charset defined but not used
    … …  
    19251921; MIME-Version defined but not used
    19261922; content-disposition defined but not used
    1927 ; entity-body defined but not used
    19281923; entity-header defined but not used
    19291924</pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    … …  
    21402135                  <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
    21412136                     <ul class="ind">
    2142                         <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
    2143                         <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
    2144                         <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.2</b></a></li>
    2145                         <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
    2146                         <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
    2147                         <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.1</b></a></li>
    2148                         <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
    2149                         <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
    2150                         <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
    2151                         <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
     2137                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li>
     2138                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li>
     2139                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
     2140                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li>
     2141                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
     2142                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
     2143                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li>
     2144                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
     2145                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
     2146                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
    21522147                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
    21532148                        <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
    2154                         <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.3</b></a></li>
     2149                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
    21552150                        <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
    2156                         <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
    2157                         <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
    2158                         <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
    2159                         <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.5</b></a></li>
    2160                         <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
    2161                         <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.6</b></a></li>
    2162                         <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
    2163                         <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.7</b></a></li>
    2164                         <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
    2165                         <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.8</b></a></li>
    2166                         <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
    2167                         <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>5.9</b></a></li>
    2168                         <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.45"><b>B.1</b></a></li>
    2169                         <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
    2170                         <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
    2171                         <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
    2172                         <li class="indline1"><tt>entity-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>3.2</b></a></li>
     2151                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
     2152                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
     2153                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
     2154                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
     2155                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li>
     2156                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
     2157                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li>
     2158                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
     2159                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li>
     2160                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
     2161                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li>
     2162                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
     2163                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
     2164                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
     2165                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
     2166                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
    21732167                        <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li>
    21742168                        <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li>
    2175                         <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
    2176                         <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.4</b></a></li>
     2169                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
     2170                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
    21772171                        <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
    2178                         <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
     2172                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
    21792173                        <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
    2180                         <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
    2181                         <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>A.1</b></a></li>
     2174                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li>
     2175                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
    21822176                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
    21832177                        <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
    … …  
    22742268                  <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>
    22752269                  <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>
    2276                   <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>
     2270                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
    22772271                  <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
    22782272                        <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r868 r875  
    376376      <link rel="Index" href="#rfc.index">
    377377      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    378       <link rel="Chapter" title="2 Entity Tags" href="#rfc.section.2">
     378      <link rel="Chapter" title="2 Entity-Tags" href="#rfc.section.2">
    379379      <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3">
    380380      <link rel="Chapter" title="4 Weak and Strong Validators" href="#rfc.section.4">
    381       <link rel="Chapter" title="5 Rules for When to Use Entity Tags and Last-Modified Dates" href="#rfc.section.5">
     381      <link rel="Chapter" title="5 Rules for When to Use Entity-tags and Last-Modified Dates" href="#rfc.section.5">
    382382      <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6">
    383383      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
    … …  
    536536            </ul>
    537537         </li>
    538          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#entity.tags">Entity Tags</a><ul class="toc">
    539                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity Tags varying on Content-Negotiated Resources</a></li>
     538         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#entity.tags">Entity-Tags</a><ul class="toc">
     539               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></li>
    540540            </ul>
    541541         </li>
    … …  
    546546         </li>
    547547         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak and Strong Validators</a></li>
    548          <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity Tags and Last-Modified Dates</a></li>
     548         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li>
    549549         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
    550550               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#header.etag">ETag</a></li>
    … …  
    629629      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
    630630      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, 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#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
    631 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="entity.tags" href="#entity.tags">Entity Tags</a></h1>
    632       <p id="rfc.section.2.p.1">Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the
    633          ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
     631</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1>
     632      <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations from the same requested resource. HTTP/1.1 uses entity-tags
     633         in the ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
    634634      </p>
    635635      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a>
    636636  <a href="#entity.tags" class="smpl">weak</a>       = %x57.2F ; "W/", case-sensitive
    637637  <a href="#entity.tags" class="smpl">opaque-tag</a> = <a href="#core.rules" class="smpl">quoted-string</a>
    638 </pre><p id="rfc.section.2.p.3">A "strong entity tag" <em class="bcp14">MAY</em> be shared by two entities of a resource only if they are equivalent by octet equality.
    639       </p>
    640       <p id="rfc.section.2.p.4">A "weak entity tag," indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no
    641          significant change in semantics. A weak entity tag can only be used for weak comparison.
    642       </p>
    643       <p id="rfc.section.2.p.5">An entity tag <em class="bcp14">MUST</em> be unique across all versions of all entities associated with a particular resource. A given entity tag value <em class="bcp14">MAY</em> be used for entities obtained by requests on different URIs. The use of the same entity tag value in conjunction with entities
    644          obtained by requests on different URIs does not imply the equivalence of those entities.
    645       </p>
    646       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity Tags varying on Content-Negotiated Resources</a></h2>
     638</pre><p id="rfc.section.2.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality.
     639      </p>
     640      <p id="rfc.section.2.p.4">A "weak entity-tag," indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each
     641         other with no significant change in semantics. A weak entity-tag can only be used for weak comparison.
     642      </p>
     643      <p id="rfc.section.2.p.5">An entity-tag <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource. A given entity-tag value <em class="bcp14">MAY</em> be used for representations obtained by requests on different URIs. The use of the same entity-tag value in conjunction with
     644         representations obtained by requests on different URIs does not imply the equivalence of those representations.
     645      </p>
     646      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2>
    647647      <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):
    648648      </p>
    … …  
    677677
    678678<em>...binary data...</em></pre><div class="note" id="rfc.section.2.1.p.7">
    679          <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity tag of an encoded representation must be distinct
     679         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct
    680680            from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
    681             (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity tags.
     681            (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.
    682682         </p>
    683683      </div>
    … …  
    717717         changes is a "weak validator."
    718718      </p>
    719       <p id="rfc.section.4.p.3">Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can
     719      <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak." One can
    720720         think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
    721721         changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an
    … …  
    726726         <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time a representation is changed.
    727727         </li>
    728          <li>An entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
     728         <li>A representation's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
    729729            that the representation might be modified twice during a single second.
    730730         </li>
    … …  
    752752         </li>
    753753      </ul>
    754       <p id="rfc.section.4.p.8">The example below shows the results for a set of entity tag pairs, and both the weak and strong comparison function results:</p>
     754      <p id="rfc.section.4.p.8">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p>
    755755      <div id="rfc.table.u.1">
    756756         <table class="tt full left" cellpadding="3" cellspacing="0">
    … …  
    791791         </table>
    792792      </div>
    793       <p id="rfc.section.4.p.9">An entity tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a> gives the syntax for entity tags.
     793      <p id="rfc.section.4.p.9">An entity-tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a> gives the syntax for entity-tags.
    794794      </p>
    795795      <p id="rfc.section.4.p.10">A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is
    … …  
    831831         HTTP/1.0 servers.
    832832      </p>
    833       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity Tags and Last-Modified Dates</a></h1>
     833      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h1>
    834834      <p id="rfc.section.5.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types
    835835         ought to be used, and for what purposes.
    … …  
    837837      <p id="rfc.section.5.p.2">HTTP/1.1 origin servers: </p>
    838838      <ul>
    839          <li><em class="bcp14">SHOULD</em> send an entity tag validator unless it is not feasible to generate one.
    840          </li>
    841          <li><em class="bcp14">MAY</em> send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entity tags,
    842             or if it is unfeasible to send a strong entity tag.
     839         <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one.
     840         </li>
     841         <li><em class="bcp14">MAY</em> send a weak entity-tag instead of a strong entity-tag, if performance considerations support the use of weak entity-tags,
     842            or if it is unfeasible to send a strong entity-tag.
    843843         </li>
    844844         <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could
    … …  
    846846         </li>
    847847      </ul>
    848       <p id="rfc.section.5.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity tag and a Last-Modified
     848      <p id="rfc.section.5.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a Last-Modified
    849849         value.
    850850      </p>
    851       <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way.
     851      <p id="rfc.section.5.p.4">In order to be legal, a strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the associated representation changes in a semantically significant way.
    852852      </p>
    853853      <div class="note" id="rfc.section.5.p.5">
    854          <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value
    855             for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries
    856             might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a
    857             cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
     854         <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity-tag value
     855            for two different representations, or reusing a specific weak entity-tag value for two semantically different representations.
     856            Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to
     857            expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the
     858            past.
    858859         </p>
    859860      </div>
    860861      <p id="rfc.section.5.p.6">HTTP/1.1 clients: </p>
    861862      <ul>
    862          <li><em class="bcp14">MUST</em> use that entity tag in any cache-conditional request (using If-Match or If-None-Match) if an entity tag has been provided
     863         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using If-Match or If-None-Match) if an entity-tag has been provided
    863864            by the origin server.
    864865         </li>
    … …  
    869870            has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty.
    870871         </li>
    871          <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity tag and a Last-Modified value have been provided by the
     872         <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a Last-Modified value have been provided by the
    872873            origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
    873874         </li>
    874875      </ul>
    875876      <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
    876          or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header
     877         or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header
    877878         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in
    878879         the request.
    879880      </p>
    880       <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity
    881          tags as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header
     881      <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
     882         as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header
    882883         fields in the request.
    883884      </p>
    … …  
    887888            assumptions about the validators they receive.
    888889         </li>
    889          <li>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will
     890         <li>HTTP/1.0 clients and caches will ignore entity-tags. Generally, last-modified values received or used by these systems will
    890891            support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare
    891892            cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then
    … …  
    901902      <div id="rfc.iref.h.1"></div>
    902903      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    903       <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for one representation of the resource identified by the Effective Request URI. An entity tag is intended for use as a resource-local
     904      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the Effective Request URI. An entity-tag is intended for use as a resource-local
    904905         identifier for differentiating between representations of the same resource that vary over time or via content negotiation
    905906         (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    … …  
    911912  ETag: W/"xyzzy"
    912913  ETag: ""
    913 </pre><p id="rfc.section.6.1.p.4">An entity tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations
     914</pre><p id="rfc.section.6.1.p.4">An entity-tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations
    914915         where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient,
    915916         or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.
    916917      </p>
    917       <p id="rfc.section.6.1.p.5">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an
     918      <p id="rfc.section.6.1.p.5">The principle behind entity-tags is that only the service author knows the semantics of a resource well enough to select an
    918919         appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality
    919920         would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0)
    … …  
    923924      <div id="rfc.iref.h.2"></div>
    924925      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    925       <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more entities previously
    926          obtained from the resource can verify that one of those entities is current by including a list of their associated entity
    927          tags in the If-Match header field.
     926      <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more representations
     927         previously obtained from the resource can verify that one of those representations is current by including a list of their
     928         associated entity-tags in the If-Match header field.
    928929      </p>
    929930      <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating
    930931         resources, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches
    931          any current entity of the resource.
     932         any current representation of the resource.
    932933      </p>
    933934      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a>   = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a>
    934935  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    935 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
    936          GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    937          then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    938       </p>
    939       <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
     936</pre><p id="rfc.section.6.2.p.4">If any of the entity-tags match the entity-tag of the representation that would have been returned in the response to a similar
     937         GET request (without the If-Match header) on that resource, or if "*" is given and any current representation exists for that
     938         resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
     939      </p>
     940      <p id="rfc.section.6.2.p.5">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
    940941         such as PUT, from modifying a resource that has changed since the client last retrieved it.
    941942      </p>
    … …  
    945946      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    946947      </p>
    947       <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity tag) is no longer a representation of
     948      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity-tag) is no longer a representation of
    948949         that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been
    949950         changed without their knowledge. Examples:
    … …  
    10071008      <div id="rfc.iref.h.4"></div>
    10081009      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    1009       <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more entities
    1010          previously obtained from the resource can verify that none of those entities is current by including a list of their associated
    1011          entity tags in the If-None-Match header field.
     1010      <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more representations
     1011         previously obtained from the resource can verify that none of those representations is current by including a list of their
     1012         associated entity-tags in the If-None-Match header field.
    10121013      </p>
    10131014      <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent
    … …  
    10151016         exist.
    10161017      </p>
    1017       <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current entity of the resource.</p>
     1018      <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p>
    10181019      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a>   = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a>
    10191020  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    1020 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
     1021</pre><p id="rfc.section.6.4.p.5">If any of the entity-tags match the entity-tag of the representation that would have been returned in the response to a similar
    10211022         GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
    10221023         for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
    … …  
    10241025         that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
    10251026      </p>
    1026       <p id="rfc.section.6.4.p.6">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
     1027      <p id="rfc.section.6.4.p.6">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
    10271028      </p>
    10281029      <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the
    1029          If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
     1030         If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    10301031      </p>
    10311032      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
    … …  
    10721073      <div id="rfc.figure.u.18"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    10731074</pre><p id="rfc.section.6.6.p.5">The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource.
    1074          For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the
    1075          most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time
    1076          stamp of the record. For virtual objects, it may be the last time the internal state changed.
     1075         For files, it may be just the file system last-modified time. For representations with dynamically included parts, it may
     1076         be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update
     1077         time stamp of the record. For virtual objects, it may be the last time the internal state changed.
    10771078      </p>
    10781079      <p id="rfc.section.6.6.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's
    … …  
    10801081      </p>
    10811082      <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of
    1082          its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the
    1083          representation changes near the time that the response is generated.
     1083         its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially
     1084         if the representation changes near the time that the response is generated.
    10841085      </p>
    10851086      <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
    … …  
    12531254      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    12541255      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    1255       <p id="rfc.section.A.1.p.1">Allow weak entity tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>).
     1256      <p id="rfc.section.A.1.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>).
    12561257      </p>
    12571258      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>

  • draft-ietf-httpbis/latest/p5-range.html

    r868 r875  
    630630      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p>
    631631      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>  = &lt;HTTP-date, 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#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
    632 </pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a>&gt;
     632</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-tag</a> = &lt;entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#entity.tags" title="Entity-Tags">Section 2</a>&gt;
    633633</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="range.units" href="#range.units">Range Units</a></h1>
    634       <p id="rfc.section.2.p.1">HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1
    635          uses range units in the Range (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;5.4</a>) and Content-Range (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;5.2</a>) header fields. An entity can be broken down into subranges according to various structural units.
     634      <p id="rfc.section.2.p.1">HTTP/1.1 allows a client to request that only part (a range of) the representation be included within the response. HTTP/1.1
     635         uses range units in the Range (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section&nbsp;5.4</a>) and Content-Range (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section&nbsp;5.2</a>) header fields. A representation can be broken down into subranges according to various structural units.
    636636      </p>
    637637      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#range.units" class="smpl">range-unit</a>       = <a href="#range.units" class="smpl">bytes-unit</a> / <a href="#range.units" class="smpl">other-range-unit</a>
    … …  
    677677      </p>
    678678      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1>
    679       <p id="rfc.section.4.p.1">A response might transfer only a subrange of an entity-body, either because the request included one or more Range specifications,
    680          or because a connection was broken prematurely. After several such transfers, a cache might have received several ranges of
    681          the same entity-body.
     679      <p id="rfc.section.4.p.1">A response might transfer only a subrange of a representation, either because the request included one or more Range specifications,
     680         or because a connection closed prematurely. After several such transfers, a cache might have received several ranges of the
     681         same representation.
    682682      </p>
    683683      <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for a representation, and an incoming response transfers another subrange,
    … …  
    716716      <div id="rfc.iref.h.2"></div>
    717717      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
    718       <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial entity-body to specify where in the full entity-body the partial
    719          body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
     718      <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial representation to specify where in the full representation
     719         the partial body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
    720720      </p>
    721721      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#header.content-range" class="smpl">Content-Range</a> = "Content-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-range" class="smpl">Content-Range-v</a>
    … …  
    736736                             <a href="#header.content-range" class="smpl">other-range-resp-spec</a>
    737737  <a href="#header.content-range" class="smpl">other-range-resp-spec</a>    = *<a href="#notation" class="smpl">CHAR</a>
    738 </pre><p id="rfc.section.5.2.p.3">The header <em class="bcp14">SHOULD</em> indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*"
    739          character means that the instance-length is unknown at the time when the response was generated.
     738</pre><p id="rfc.section.5.2.p.3">The header <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk
     739         "*" character means that the instance-length is unknown at the time when the response was generated.
    740740      </p>
    741741      <p id="rfc.section.5.2.p.4">Unlike byte-ranges-specifier values (see <a href="#byte.ranges" title="Byte Ranges">Section&nbsp;5.4.1</a>), a byte-range-resp-spec <em class="bcp14">MUST</em> only specify one range, and <em class="bcp14">MUST</em> contain absolute byte positions for both the first and last byte of the range.
    … …  
    781781      </p>
    782782      <p id="rfc.section.5.2.p.13">If the server ignores a byte-range-spec because it is syntactically invalid, the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing
    783          the full entity).
     783         the full representation).
    784784      </p>
    785785      <p id="rfc.section.5.2.p.14">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header
    … …  
    795795      <div id="rfc.iref.h.3"></div>
    796796      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    797       <p id="rfc.section.5.3.p.1">If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its
    798          cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.)
    799          However, if the condition fails because the representation has been modified, the client would then have to make a second
    800          request to obtain the entire current representation.
     797      <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation
     798         in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and
     799         If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make
     800         a second request to obtain the entire current representation.
    801801      </p>
    802802      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
    … …  
    805805      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
    806806  <a href="#header.if-range" class="smpl">If-Range-v</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    807 </pre><p id="rfc.section.5.3.p.4">If the client has no entity tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
     807</pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
    808808         no more than two characters.) The If-Range header <em class="bcp14">SHOULD</em> only be used together with a Range header, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
    809809      </p>
    810       <p id="rfc.section.5.3.p.5">If the entity tag given in the If-Range header matches the current cache validator for the representation, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
     810      <p id="rfc.section.5.3.p.5">If the entity-tag given in the If-Range header matches the current cache validator for the representation, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
    811811         not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response.
    812812      </p>
    … …  
    844844  <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    845845</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length
    846          value. (That is, this form specifies the last N bytes of an entity-body.) If the representation is shorter than the specified
     846         value. (That is, this form specifies the last N bytes of a representation.) If the representation is shorter than the specified
    847847         suffix-length, the entire representation is used.
    848848      </p>
    849849      <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
    850          length of the entity-body, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is
    851          satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the representation.
    852       </p>
    853       <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming an entity-body of length 10000): </p>
     850         length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set
     851         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the representation.
     852      </p>
     853      <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p>
    854854      <ul>
    855855         <li>The first 500 bytes (byte offsets 0-499, inclusive):
    … …  
    882882</pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible,
    883883         since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large
    884          entities.
    885       </p>
    886       <p id="rfc.section.5.4.2.p.4">If the server supports the Range header and the specified range or ranges are appropriate for the entity: </p>
     884         representations.
     885      </p>
     886      <p id="rfc.section.5.4.2.p.4">If the server supports the Range header and the specified range or ranges are appropriate for the representation: </p>
    887887      <ul>
    888888         <li>The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other
    … …  
    897897      </p>
    898898      <p id="rfc.section.5.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire
    899          entity in reply, it <em class="bcp14">SHOULD</em> only return the requested range to its client. It <em class="bcp14">SHOULD</em> store the entire received response in its cache if that is consistent with its cache allocation policies.
     899         representation in reply, it <em class="bcp14">SHOULD</em> only return the requested range to its client. It <em class="bcp14">SHOULD</em> store the entire received response in its cache if that is consistent with its cache allocation policies.
    900900      </p>
    901901      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>

  • draft-ietf-httpbis/latest/p6-cache.html

    r868 r875  
    645645      </p>
    646646      <ul class="empty">
    647          <li>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</li>
     647         <li>The time at which the origin server intends that a representation should no longer be returned by a cache without further
     648            validation.
     649         </li>
    648650      </ul>
    649651      <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    … …  
    680682      </p>
    681683      <ul class="empty">
    682          <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response has an
     684         <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response has an
    683685            equivalent copy of a representation.
    684686         </li>
    … …  
    10181020      <p id="rfc.section.2.8.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
    10191021      </p>
    1020       <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
     1022      <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
    10211023      </p>
    10221024      <p id="rfc.section.2.8.p.7"> <span class="comment" id="ISSUE-how-head">[<a href="#ISSUE-how-head" class="smpl">ISSUE-how-head</a>: discuss how to handle HEAD updates]</span>
    … …  
    11211123      </p>
    11221124      <ul class="empty">
    1123          <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request entity-body.
     1125         <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request representation.
    11241126         </li>
    11251127      </ul>
    … …  
    12251227      </p>
    12261228      <ul class="empty">
    1227          <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response entity-body.
     1229         <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response representation.
    12281230         </li>
    12291231      </ul>
    … …  
    14121414      <p id="rfc.section.3.6.p.17"> 214 Transformation applied </p>
    14131415      <ul class="empty">
    1414          <li><em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the
    1415             Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the
    1416             response, unless this Warning code already appears in the response.
     1416         <li><em class="bcp14">MUST</em> be added by an intermediate proxy if it applies any transformation to the representation, such as changing the content-coding,
     1417            media-type, or modifying the representation data, unless this Warning code already appears in the response.
    14171418         </li>
    14181419      </ul>
    … …  
    14231424      </ul>
    14241425      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h1>
    1425       <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay an entity
     1426      <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation
    14261427         retrieved earlier in a session.
    14271428      </p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r865 r875  
    620620      <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;3.4</a>) containing a challenge applicable to the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
    621621         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    622          already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP
    623          access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
     622         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
     623         information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
    624624      </p>
    625625      <div id="rfc.iref.3"></div>
Note: See TracChangeset for help on using the changeset viewer.