Changeset 1783 for draft-ietf-httpbis


Ignore:
Timestamp:
15/07/12 06:40:35 (8 years ago)
Author:
fielding@…
Message:

Update p4 abstract and introduction; replace redundancies with reference to p1

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

Legend:

Unmodified
Added
Removed

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

    r1773 r1783  
    475475      <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3">
    476476      <link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4">
    477       <link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5">
    478       <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6">
    479       <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7">
    480       <link rel="Chapter" href="#rfc.section.8" title="8 References">
     477      <link rel="Chapter" title="5 ABNF Rules Defined Elsewhere" href="#rfc.section.5">
     478      <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
     479      <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
     480      <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
     481      <link rel="Chapter" href="#rfc.section.9" title="9 References">
    481482      <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A">
    482483      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    … …  
    492493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
    493494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    495       <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
     496      <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    496497   </head>
    497498   <body onload="init();">
    … …  
    532533      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    533534      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information
    534          systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the
    535          seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
    536       </p> 
    537       <p>Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those
    538          requests.
     535         systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes,
     536         request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request
     537         when one or more preconditions evaluate to false.
    539538      </p>
    540539      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    … …  
    572571      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    573572      <ul class="toc">
    574          <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    575                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li>
    576                <li>1.2&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a></li>
    577             </ul>
    578          </li>
     573         <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a></li>
    579574         <li>2.&nbsp;&nbsp;&nbsp;<a href="#validators">Validators</a><ul>
    580575               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#weak.and.strong.validators">Weak versus Strong</a></li>
    … …  
    606601            </ul>
    607602         </li>
    608          <li>5.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    609                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
    610                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     603         <li>5.&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules Defined Elsewhere</a></li>
     604         <li>6.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     605               <li>6.1&nbsp;&nbsp;&nbsp;<a href="#status.code.registration">Status Code Registration</a></li>
     606               <li>6.2&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    611607            </ul>
    612608         </li>
    613          <li>6.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    614          <li>7.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
    615          <li>8.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    616                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    617                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     609         <li>7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
     610         <li>8.&nbsp;&nbsp;&nbsp;<a href="#acks">Acknowledgments</a></li>
     611         <li>9.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     612               <li>9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     613               <li>9.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    618614            </ul>
    619615         </li>
    … …  
    628624      </ul>
    629625      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    630       <p id="rfc.section.1.p.1">This document defines the HTTP/1.1 conditional request mechanisms, including both metadata for indicating/observing changes
    631          in resource representations and request header fields that specify preconditions on that metadata; to be checked before performing
    632          the request method. Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem:
     626      <p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the
     627         target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target
     628         resource is changed. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax
     629         notation, and conformance criteria defined in <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     630      </p>
     631      <p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem:
    633632         one client accidentally overwriting the work of another client that has been acting in parallel.
    634633      </p>
    635       <p id="rfc.section.1.p.2">Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the
     634      <p id="rfc.section.1.p.3">Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the
    636635         state as observed in a previously obtained representation (one value in that set). A resource might have multiple current
    637636         representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests
    … …  
    640639         when the precondition evaluates to false.
    641640      </p>
    642       <p id="rfc.section.1.p.3"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the current representation of the target resource that would have been selected in a successful response if
     641      <p id="rfc.section.1.p.4"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the current representation of the target resource that would have been selected in a successful response if
    643642         the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request
    644643         preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the
    645644         selected representation.
    646645      </p>
    647       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2>
    648       <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    649          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    650       </p>
    651       <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
    652          requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways,
    653          or caches, depending on what behavior is being constrained by the requirement. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms.
    654       </p>
    655       <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely
    656          forwarding a received element downstream.
    657       </p>
    658       <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
    659          in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
    660       </p>
    661       <p id="rfc.section.1.1.p.5">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section&nbsp;1.2</a>). In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
    662          to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable
    663          to the recipient's role.
    664       </p>
    665       <p id="rfc.section.1.1.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
    666          except when they have a direct impact on security, since different applications of the protocol require different error handling
    667          strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery
    668          to be dangerous.
    669       </p>
    670       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    671       <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF with the list rule expanded.
    672       </p>
    673       <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
    674          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
    675          character).
    676       </p>
    677       <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>:
    678       </p>
    679       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#notation" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
    680   <a href="#notation" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
    681   <a href="#notation" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>&gt;
    682 </pre><div id="rfc.iref.m.1"></div>
     646      <div id="rfc.iref.m.1"></div>
    683647      <div id="rfc.iref.v.1"></div>
    684648      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="validators" href="#validators">Validators</a></h1>
    … …  
    737701         was last modified.
    738702      </p>
    739       <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#notation" class="smpl">HTTP-date</a>
     703      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    740704</pre><p id="rfc.section.2.2.p.3">An example of its use is</p>
    741       <div id="rfc.figure.u.3"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
     705      <div id="rfc.figure.u.2"></div><pre class="text">  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    742706</pre><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="lastmod.generation" href="#lastmod.generation">Generation</a></h3>
    743707      <p id="rfc.section.2.2.1.p.1">Origin servers <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined,
    … …  
    799763         same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
    800764      </p>
    801       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.etag" class="smpl">ETag</a>       = <a href="#header.etag" class="smpl">entity-tag</a>
     765      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.etag" class="smpl">ETag</a>       = <a href="#header.etag" class="smpl">entity-tag</a>
    802766
    803767  <a href="#header.etag" class="smpl">entity-tag</a> = [ <a href="#header.etag" class="smpl">weak</a> ] <a href="#header.etag" class="smpl">opaque-tag</a>
    804768  <a href="#header.etag" class="smpl">weak</a>       = %x57.2F ; "W/", case-sensitive
    805   <a href="#header.etag" class="smpl">opaque-tag</a> = <a href="#notation" class="smpl">DQUOTE</a> *<a href="#header.etag" class="smpl">etagc</a> <a href="#notation" class="smpl">DQUOTE</a>
    806   <a href="#header.etag" class="smpl">etagc</a>      = %x21 / %x23-7E / <a href="#notation" class="smpl">obs-text</a>
    807              ; <a href="#notation" class="smpl">VCHAR</a> except double quotes, plus obs-text
     769  <a href="#header.etag" class="smpl">opaque-tag</a> = <a href="#abnf.dependencies" class="smpl">DQUOTE</a> *<a href="#header.etag" class="smpl">etagc</a> <a href="#abnf.dependencies" class="smpl">DQUOTE</a>
     770  <a href="#header.etag" class="smpl">etagc</a>      = %x21 / %x23-7E / <a href="#abnf.dependencies" class="smpl">obs-text</a>
     771             ; <a href="#abnf.dependencies" class="smpl">VCHAR</a> except double quotes, plus obs-text
    808772</pre><div class="note" id="rfc.section.2.3.p.3">
    809773         <p> <b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>), thus some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity
    … …  
    815779         not consistently maintained.
    816780      </p>
    817       <div id="rfc.figure.u.5"></div>
     781      <div id="rfc.figure.u.4"></div>
    818782      <p>Examples:</p>  <pre class="text">  ETag: "xyzzy"
    819783  ETag: W/"xyzzy"
    … …  
    887851      </div>
    888852      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3>
    889       <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):
    890       </p>
    891       <div id="rfc.figure.u.6"></div>
     853      <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):
     854      </p>
     855      <div id="rfc.figure.u.5"></div>
    892856      <p>&gt;&gt; Request:</p><pre class="text2">GET /index HTTP/1.1
    893857Host: www.example.com
    … …  
    895859
    896860</pre><p id="rfc.section.2.3.3.p.3">In this case, the response might or might not use the gzip content coding. If it does not, the response might look like:</p>
    897       <div id="rfc.figure.u.7"></div>
     861      <div id="rfc.figure.u.6"></div>
    898862      <p>&gt;&gt; Response:</p><pre class="text">HTTP/1.1 200 OK
    899863Date: Thu, 26 Mar 2010 00:05:00 GMT
    … …  
    909873Hello World!
    910874</span></pre><p id="rfc.section.2.3.3.p.5">An alternative representation that does use gzip content coding would be:</p>
    911       <div id="rfc.figure.u.8"></div>
     875      <div id="rfc.figure.u.7"></div>
    912876      <p>&gt;&gt; Response:</p><pre class="text">HTTP/1.1 200 OK
    913877Date: Thu, 26 Mar 2010 00:05:00 GMT
    … …  
    921885         <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation has to be distinct
    922886            from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings
    923             (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</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.
     887            (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.2"><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.
    924888         </p>
    925889      </div>
    … …  
    978942         field-value of "*" places the precondition on the existence of any current representation for the target resource.
    979943      </p>
    980       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
     944      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
    981945</pre><p id="rfc.section.3.1.p.4">The If-Match condition is met if and only if any of the entity-tags listed in the If-Match field value match the entity-tag
    982946         of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), or if "*" is given and any current representation exists for the target resource.
    … …  
    992956      </p>
    993957      <p id="rfc.section.3.1.p.9">Examples:</p>
    994       <div id="rfc.figure.u.10"></div><pre class="text">  If-Match: "xyzzy"
     958      <div id="rfc.figure.u.9"></div><pre class="text">  If-Match: "xyzzy"
    995959  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    996960  If-Match: *
    … …  
    1013977         for the target resource.
    1014978      </p>
    1015       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
     979      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
    1016980</pre><p id="rfc.section.3.2.p.5">The If-None-Match condition is met if and only if none of the entity-tags listed in the If-None-Match field value match the
    1017981         entity-tag of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>), or if "*" is given and no current representation exists for that resource.
    … …  
    1026990      </p>
    1027991      <p id="rfc.section.3.2.p.9">Examples:</p>
    1028       <div id="rfc.figure.u.12"></div><pre class="text">  If-None-Match: "xyzzy"
     992      <div id="rfc.figure.u.11"></div><pre class="text">  If-None-Match: "xyzzy"
    1029993  If-None-Match: W/"xyzzy"
    1030994  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    … …  
    10401004         respond as detailed below.
    10411005      </p>
    1042       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>
     1006      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    10431007</pre><p id="rfc.section.3.3.p.3">An example of the field is:</p>
    1044       <div id="rfc.figure.u.14"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
     1008      <div id="rfc.figure.u.13"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    10451009</pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by
    10461010         the If-Modified-Since header field. The algorithm for determining this includes the following cases:
    … …  
    10821046         representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.
    10831047      </p>
    1084       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>
     1048      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    10851049</pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
    1086       <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
     1050      <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    10871051</pre><p id="rfc.section.3.4.p.5">If a request normally (i.e., in absence of the If-Unmodified-Since header field) would result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
    10881052      </p>
    … …  
    11031067         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    11041068      </p>
    1105       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
     1069      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
    11061070            (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
    11071071      </p>
    … …  
    11231087         and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
    11241088      </p>
    1125       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    1126       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
    1127       <p id="rfc.section.5.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
     1089      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules Defined Elsewhere</a></h1>
     1090      <p id="rfc.section.5.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;B</a> shows the collected ABNF with the list rule expanded.
     1091      </p>
     1092      <p id="rfc.section.5.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
     1093         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
     1094         character).
     1095      </p>
     1096      <p id="rfc.section.5.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>:
     1097      </p>
     1098      <div id="rfc.figure.u.16"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">OWS</a>           = &lt;OWS, 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#whitespace" title="Whitespace">Section 3.2.1</a>&gt;
     1099  <a href="#abnf.dependencies" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>&gt;
     1100  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>&gt;
     1101</pre><p id="rfc.section.5.p.5">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     1102         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     1103      </p>
     1104      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
     1105      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
     1106      <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    11281107      </p>
    11291108      <div id="rfc.table.1">
    … …  
    11531132         </table>
    11541133      </div>
    1155       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1156       <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1134      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
     1135      <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    11571136      </p>
    11581137      <div id="rfc.table.2">
    … …  
    12131192         </table>
    12141193      </div>
    1215       <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1216       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1217       <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    1218       </p>
    1219       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    1220       <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    1221       </p>
    1222       <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
     1194      <p id="rfc.section.6.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1195      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     1196      <p id="rfc.section.7.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1197      </p>
     1198      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     1199      <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1200      </p>
     1201      <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
    12231202      </h1>
    1224       <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References
     1203      <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References
    12251204      </h2>
    12261205      <table>           
    … …  
    12561235         </tr>
    12571236      </table>
    1258       <h2 id="rfc.references.2"><a href="#rfc.section.8.2" id="rfc.section.8.2">8.2</a> Informative References
     1237      <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
    12591238      </h2>
    12601239      <table>     
    … …  
    12971276      <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
    12981277
    1299 <a href="#notation" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 5.1&gt;
     1278<a href="#abnf.dependencies" class="smpl">HTTP-date</a> = &lt;HTTP-date, defined in [Part2], Section 5.1&gt;
    13001279
    13011280<a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
    … …  
    13081287<a href="#header.last-modified" class="smpl">Last-Modified</a> = HTTP-date
    13091288
    1310 <a href="#notation" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
     1289<a href="#abnf.dependencies" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
    13111290
    13121291<a href="#header.etag" class="smpl">entity-tag</a> = [ weak ] opaque-tag
    … …  
    13141293 / obs-text
    13151294
    1316 <a href="#notation" class="smpl">obs-text</a> = &lt;obs-text, defined in [Part1], Section 3.2.4&gt;
     1295<a href="#abnf.dependencies" class="smpl">obs-text</a> = &lt;obs-text, defined in [Part1], Section 3.2.4&gt;
    13171296<a href="#header.etag" class="smpl">opaque-tag</a> = DQUOTE *etagc DQUOTE
    13181297
    … …  
    13391318         <ul class="ind">
    13401319            <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
    1341                   <li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.27"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">5.1</a></li>
     1320                  <li>304 Not Modified (status code)&nbsp;&nbsp;<a href="#rfc.iref.27"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">6.1</a></li>
    13421321               </ul>
    13431322            </li>
    13441323            <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
    1345                   <li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.28"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">5.1</a></li>
     1324                  <li>412 Precondition Failed (status code)&nbsp;&nbsp;<a href="#rfc.iref.28"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li>
    13461325               </ul>
    13471326            </li>
    13481327            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    1349                   <li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">5.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>
     1328                  <li>ETag header field&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>
    13501329               </ul>
    13511330            </li>
    … …  
    13701349                  <li>Header Fields&nbsp;&nbsp;
    13711350                     <ul>
    1372                         <li>ETag&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.h.2"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">5.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>
    1373                         <li>If-Match&nbsp;&nbsp;<a href="#rfc.iref.h.3"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">5.2</a></li>
    1374                         <li>If-Modified-Since&nbsp;&nbsp;<a href="#rfc.iref.h.5"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">5.2</a></li>
    1375                         <li>If-None-Match&nbsp;&nbsp;<a href="#rfc.iref.h.4"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">5.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
    1376                         <li>If-Unmodified-Since&nbsp;&nbsp;<a href="#rfc.iref.h.6"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">5.2</a></li>
    1377                         <li>Last-Modified&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.h.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">5.2</a></li>
     1351                        <li>ETag&nbsp;&nbsp;<a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.h.2"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>
     1352                        <li>If-Match&nbsp;&nbsp;<a href="#rfc.iref.h.3"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6.2</a></li>
     1353                        <li>If-Modified-Since&nbsp;&nbsp;<a href="#rfc.iref.h.5"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">6.2</a></li>
     1354                        <li>If-None-Match&nbsp;&nbsp;<a href="#rfc.iref.h.4"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">6.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
     1355                        <li>If-Unmodified-Since&nbsp;&nbsp;<a href="#rfc.iref.h.6"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6.2</a></li>
     1356                        <li>Last-Modified&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.h.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">6.2</a></li>
    13781357                     </ul>
    13791358                  </li>
    … …  
    13811360            </li>
    13821361            <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul>
    1383                   <li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">5.2</a></li>
    1384                   <li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">5.2</a></li>
    1385                   <li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">5.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
    1386                   <li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">5.2</a></li>
     1362                  <li>If-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6.2</a></li>
     1363                  <li>If-Modified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">6.2</a></li>
     1364                  <li>If-None-Match header field&nbsp;&nbsp;<a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">6.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>
     1365                  <li>If-Unmodified-Since header field&nbsp;&nbsp;<a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6.2</a></li>
    13871366               </ul>
    13881367            </li>
    13891368            <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
    1390                   <li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">5.2</a></li>
     1369                  <li>Last-Modified header field&nbsp;&nbsp;<a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">6.2</a></li>
    13911370               </ul>
    13921371            </li>
    … …  
    13961375            </li>
    13971376            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1398                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">1.2</a>, <a href="#rfc.xref.Part1.6">2.3.3</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
    1399                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    1400                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    1401                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.2</a></li>
    1402                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2</a></li>
    1403                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2.3.3</a></li>
    1404                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">7</a></li>
     1377                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">2.3.3</a>, <a href="#rfc.xref.Part1.3">5</a>, <a href="#rfc.xref.Part1.4">5</a>, <a href="#rfc.xref.Part1.5">5</a>, <a href="#rfc.xref.Part1.6">5</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#rfc.xref.Part1.8">8</a>, <a href="#Part1"><b>9.1</b></a><ul>
     1378                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">5</a></li>
     1379                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a></li>
     1380                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">5</a></li>
     1381                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">5</a></li>
     1382                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">2.3.3</a></li>
     1383                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">8</a></li>
    14051384                     </ul>
    14061385                  </li>
    1407                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">4.1</a>, <a href="#Part2"><b>8.1</b></a><ul>
    1408                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2</a></li>
    1409                         <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
    1410                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.3</a></li>
    1411                         <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1</a></li>
     1386                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">5</a>, <a href="#rfc.xref.Part2.6">5</a>, <a href="#Part2"><b>9.1</b></a><ul>
     1387                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">5</a></li>
     1388                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.3</a></li>
     1389                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1390                        <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
    14121391                     </ul>
    14131392                  </li>
    1414                   <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.2">3.5</a>, <a href="#Part5"><b>8.1</b></a><ul>
     1393                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.2">3.5</a>, <a href="#Part5"><b>9.1</b></a><ul>
    14151394                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">3.5</a></li>
    14161395                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.3</a></li>
    14171396                     </ul>
    14181397                  </li>
    1419                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#Part6"><b>8.1</b></a></li>
     1398                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#Part6"><b>9.1</b></a></li>
    14201399               </ul>
    14211400            </li>
    14221401            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    1423                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li>
    1424                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>8.2</b></a><ul>
     1402                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">5</a>, <a href="#RFC2119"><b>9.1</b></a></li>
     1403                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>9.2</b></a><ul>
    14251404                        <li><em>Section 3.11</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">2.3</a></li>
    14261405                     </ul>
    14271406                  </li>
    1428                   <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">5.2</a>, <a href="#RFC3864"><b>8.2</b></a></li>
    1429                   <li><em>RFC4918</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>8.2</b></a></li>
    1430                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#RFC5234"><b>8.1</b></a><ul>
    1431                         <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">1.2</a></li>
     1407                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">6.2</a>, <a href="#RFC3864"><b>9.2</b></a></li>
     1408                  <li><em>RFC4918</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>9.2</b></a></li>
     1409                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">5</a>, <a href="#rfc.xref.RFC5234.2">5</a>, <a href="#RFC5234"><b>9.1</b></a><ul>
     1410                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">5</a></li>
    14321411                     </ul>
    14331412                  </li>
    … …  
    14381417                  <li>Status Codes&nbsp;&nbsp;
    14391418                     <ul>
    1440                         <li>304 Not Modified&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">5.1</a></li>
    1441                         <li>412 Precondition Failed&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">5.1</a></li>
     1419                        <li>304 Not Modified&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">6.1</a></li>
     1420                        <li>412 Precondition Failed&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li>
    14421421                     </ul>
    14431422                  </li>

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

    r1773 r1783  
    105105<t>
    106106   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
    107    distributed, collaborative, hypertext information systems. HTTP has been in
    108    use by the World Wide Web global information initiative since 1990. This
    109    document is Part 4 of the seven-part specification that defines the protocol
    110    referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
    111 </t>
    112 <t>
    113    Part 4 defines request header fields for indicating conditional requests and
    114    the rules for constructing responses to those requests.
     107   distributed, collaborative, hypertext information systems. This document
     108   defines HTTP/1.1 conditional requests, including metadata header fields
     109   for indicating state changes, request header fields for making
     110   preconditions on such state, and rules for constructing the responses to a
     111   conditional request when one or more preconditions evaluate to false.
    115112</t>
    116113</abstract>
    … …  
    133130</note>
    134131</front>
     132
    135133<middle>
    136134<section title="Introduction" anchor="introduction">
    137135<t>
    138    This document defines the HTTP/1.1 conditional request mechanisms,
    139    including both metadata for indicating/observing changes in resource
    140    representations and request header fields that specify preconditions
    141    on that metadata; to be checked before performing the request method.
     136   Conditional requests are HTTP requests <xref target="Part2"/> that include
     137   one or more header fields indicating a precondition to be tested before
     138   applying the method semantics to the target resource.
     139   Each precondition is based on metadata that is expected to change if the
     140   selected representation of the target resource is changed.
     141   This document defines the HTTP/1.1 conditional request mechanisms in terms
     142   of the architecture, syntax notation, and conformance criteria defined in
     143   &architecture;.
     144</t>
     145<t>
    142146   Conditional GET requests are the most efficient mechanism for HTTP
    143147   cache updates &caching;.  Conditionals can also be
    … …  
    167171   for the selected representation.
    168172</t>
    169 
    170 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    171 <t>
    172    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    173    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    174    document are to be interpreted as described in <xref target="RFC2119"/>.
    175 </t>
    176 <t>
    177    This specification targets conformance criteria according to the role of
    178    a participant in HTTP communication.  Hence, HTTP requirements are placed
    179    on senders, recipients, clients, servers, user agents, intermediaries,
    180    origin servers, proxies, gateways, or caches, depending on what behavior
    181    is being constrained by the requirement. See &architecture; for definitions
    182    of these terms.
    183 </t>
    184 <t>
    185    The verb "generate" is used instead of "send" where a requirement
    186    differentiates between creating a protocol element and merely forwarding a
    187    received element downstream.
    188 </t>
    189 <t>
    190    An implementation is considered conformant if it complies with all of the
    191    requirements associated with the roles it partakes in HTTP. Note that
    192    SHOULD-level requirements are relevant here, unless one of the documented
    193    exceptions is applicable.
    194 </t>
    195 <t>
    196    This document also uses ABNF to define valid protocol elements
    197    (<xref target="notation"/>).
    198    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    199    generate protocol elements that do not match the grammar defined by the
    200    ABNF rules for those protocol elements that are applicable to the sender's
    201    role. If a received protocol element is processed, the recipient &MUST; be
    202    able to parse any value that would match the ABNF rules for that protocol
    203    element, excluding only those rules not applicable to the recipient's role.
    204 </t>
    205 <t>
    206    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    207    protocol element from an invalid construct.  HTTP does not define
    208    specific error handling mechanisms except when they have a direct impact
    209    on security, since different applications of the protocol require
    210    different error handling strategies.  For example, a Web browser might
    211    wish to transparently recover from a response where the
    212    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    213    whereas a systems control client might consider any form of error recovery
    214    to be dangerous.
    215 </t>
    216 </section>
    217 
    218 <section title="Syntax Notation" anchor="notation">
    219   <x:anchor-alias value="ALPHA"/>
    220   <x:anchor-alias value="CR"/>
    221   <x:anchor-alias value="DIGIT"/>
    222   <x:anchor-alias value="DQUOTE"/>
    223   <x:anchor-alias value="LF"/>
    224   <x:anchor-alias value="OCTET"/>
    225   <x:anchor-alias value="VCHAR"/>
    226   <x:anchor-alias value="core.rules"/>
    227   <x:anchor-alias value="obs-text"/>
    228   <x:anchor-alias value="OWS"/>
    229   <x:anchor-alias value="HTTP-date"/>
    230 <t>
    231    This specification uses the Augmented Backus-Naur Form (ABNF) notation
    232    of <xref target="RFC5234"/> with the list rule extension defined in
    233    &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
    234    with the list rule expanded.
    235 </t>
    236 <t>
    237   The following core rules are included by
    238   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
    239   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
    240   DIGIT (decimal 0-9), DQUOTE (double quote),
    241   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
    242   OCTET (any 8-bit sequence of data), SP (space), and
    243   VCHAR (any visible US-ASCII character).
    244 </t>
    245 <t>
    246   The ABNF rules below are defined in <xref target="Part1"/> and
    247   <xref target="Part2"/>:
    248 </t>
    249 <figure><artwork type="abnf2616">
    250   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
    251   <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
    252   <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
    253 </artwork></figure>
    254 </section>
    255173</section>
    256174
    … …  
    10841002</t>
    10851003</section>
     1004</section>
     1005
     1006<section title="ABNF Rules Defined Elsewhere" anchor="abnf.dependencies">
     1007  <x:anchor-alias value="ALPHA"/>
     1008  <x:anchor-alias value="CR"/>
     1009  <x:anchor-alias value="DIGIT"/>
     1010  <x:anchor-alias value="DQUOTE"/>
     1011  <x:anchor-alias value="LF"/>
     1012  <x:anchor-alias value="OCTET"/>
     1013  <x:anchor-alias value="VCHAR"/>
     1014  <x:anchor-alias value="core.rules"/>
     1015  <x:anchor-alias value="obs-text"/>
     1016  <x:anchor-alias value="OWS"/>
     1017  <x:anchor-alias value="HTTP-date"/>
     1018<t>
     1019   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     1020   of <xref target="RFC5234"/> with the list rule extension defined in
     1021   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     1022   with the list rule expanded.
     1023</t>
     1024<t>
     1025  The following core rules are included by
     1026  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
     1027  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
     1028  DIGIT (decimal 0-9), DQUOTE (double quote),
     1029  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
     1030  OCTET (any 8-bit sequence of data), SP (space), and
     1031  VCHAR (any visible US-ASCII character).
     1032</t>
     1033<t>
     1034  The ABNF rules below are defined in <xref target="Part1"/> and
     1035  <xref target="Part2"/>:
     1036</t>
     1037<figure><artwork type="abnf2616">
     1038  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     1039  <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
     1040  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
     1041</artwork></figure>
     1042<t>
     1043   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     1044   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     1045   document are to be interpreted as described in <xref target="RFC2119"/>.
     1046</t>
    10861047</section>
    10871048
Note: See TracChangeset for help on using the changeset viewer.