Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.html

    r981 r994  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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.">
     
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: March 5, 2011</td>
     428               <td class="left">Expires: March 11, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
     
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">September 1, 2010</td>
     485               <td class="right">September 7, 2010</td>
    486486            </tr>
    487487         </tbody>
     
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire on March 5, 2011.</p>
     511      <p>This Internet-Draft will expire on March 11, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    598598      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    599599         errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
    600          resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition
     600         resource metadata will be discussed first and then followed by each conditional request-header field, concluding with a definition
    601601         of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more
    602602         content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements
     
    802802      <p id="rfc.section.4.p.11">or </p>
    803803      <ul>
    804          <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has
    805             a cache entry for the associated representation, and
     804         <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header field, because the client
     805            has a cache entry for the associated representation, and
    806806         </li>
    807807         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
     
    841841         </li>
    842842         <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
    843             result from using this date in an If-Modified-Since header would lead to serious problems.
     843            result from using this date in an If-Modified-Since header field would lead to serious problems.
    844844         </li>
    845845      </ul>
     
    912912      <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
    913913         appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality
    914          would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0)
     914         would open up a can of worms. Thus, comparisons of any other header fields (except Last-Modified, for compatibility with HTTP/1.0)
    915915         are never used for purposes of validating a cache entry.
    916916      </p>
     
    929929  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    930930</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
    931          GET request (without the If-Match header) on that resource, or if "*" is given and any current representation exists for that
    932          resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
     931         GET request (without the If-Match header field) on that resource, or if "*" is given and any current representation exists
     932         for that resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    933933      </p>
    934934      <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,
     
    936936      </p>
    937937      <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
    938          If-Match header <em class="bcp14">MUST</em> be ignored.
     938         If-Match header field <em class="bcp14">MUST</em> be ignored.
    939939      </p>
    940940      <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.
     
    962962</pre><p id="rfc.section.6.3.p.3">An example of the field is:</p>
    963963      <div id="rfc.figure.u.12"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    964 </pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header and no Range header requests that the representation be transferred only if
    965          it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the
    966          following cases:
     964</pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header field and no Range header field requests that the representation be transferred
     965         only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining this
     966         includes the following cases:
    967967      </p>
    968968      <ol>
     
    988988            field whenever possible.
    989989         </li>
    990          <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
    991             the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized
    992             clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes
    993             the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since
    994             date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived
    995             from the client's clock without correction to the server's clock. Corrections for different time bases between client and
    996             server are at best approximate due to network latency.
     990         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the Last-Modified header
     991            field for the same request, the client needs to be aware that this date is interpreted in the server's understanding of time.
     992            Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server, are concerns.
     993            This includes the possibility of race conditions if the document has changed between the time it was first requested and the
     994            If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
     995            date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between
     996            client and server are at best approximate due to network latency.
    997997         </li>
    998998      </ul>
     
    10151015  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    10161016</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
    1017          GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
     1017         GET request (without the If-None-Match header field) on that resource, or if "*" is given and any current representation exists
    10181018         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
    10191019         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations
     
    10231023      </p>
    10241024      <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 code, then
    1025          the 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.)
     1025         the If-None-Match header field <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.)
    10261026      </p>
    10271027      <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.
     
    10411041      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the representation that would
    10421042         have been transferred in a 200 response to a GET request on the same resource has not been modified since the time specified
    1043          in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
     1043         in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header field were not present.
    10441044      </p>
    10451045      <p id="rfc.section.6.5.p.2">If the representation has been modified since the specified time, the server <em class="bcp14">MUST NOT</em> perform the requested operation, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed).
     
    10501050</pre><p id="rfc.section.6.5.p.4">An example of the field is:</p>
    10511051      <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1052 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status
    1053          code, the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored.
    1054       </p>
    1055       <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header is ignored.</p>
     1052</pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or
     1053         412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored.
     1054      </p>
     1055      <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header field is ignored.</p>
    10561056      <p id="rfc.section.6.5.p.8">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
    10571057         header fields is undefined by this specification.
     
    13161316         </li>
    13171317      </ul>
    1318       <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1319       </p>
    1320       <ul>
    1321          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1318      <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1319      </p>
     1320      <ul>
     1321         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
    13221322      </ul>
    13231323      <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p4-conditional-03</a></h2>
     
    13371337         <li>Use "/" instead of "|" for alternatives.</li>
    13381338         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1339          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1339         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    13401340      </ul>
    13411341      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p4-conditional-05</a></h2>
Note: See TracChangeset for help on using the changeset viewer.