Changeset 1739


Ignore:
Timestamp:
Jul 8, 2012, 7:50:41 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions(P4)

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

Legend:

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

    r1738 r1739  
    979979         in the response and not the source text of the process, unless that text happens to be the output of the process.
    980980      </p>
    981       <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
    982          If-Match, If-None-Match, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
     981      <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
    983982         header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
    984983         to be refreshed without requiring multiple requests or transferring data already held by the client.
     
    17111710      <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
    17121711      </p>
    1713       <p id="rfc.section.4.4.2.p.4">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
    1714          identified by the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
     1712      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
     1713         the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    17151714      </p>
    17161715      <div id="rfc.iref.27"></div>
     
    17431742         current representation after the requested action.
    17441743      </p>
    1745       <p id="rfc.section.4.4.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field,
    1746          then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
     1744      <p id="rfc.section.4.4.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that
     1745         target resource.
    17471746      </p>
    17481747      <p id="rfc.section.4.4.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1738 r1739  
    580580<t>
    581581   The semantics of the GET method change to a "conditional GET" if the
    582    request message includes an If-Modified-Since, If-Unmodified-Since,
    583    If-Match, If-None-Match, or <x:ref>If-Range</x:ref> header field
     582   request message includes an <x:ref>If-Modified-Since</x:ref>,
     583   <x:ref>If-Unmodified-Since</x:ref>, <x:ref>If-Match</x:ref>,
     584   <x:ref>If-None-Match</x:ref>, or <x:ref>If-Range</x:ref> header field
    584585   (<xref target="Part4"/>). A conditional GET requests that the representation
    585586   be transferred only under the circumstances described by the conditional
     
    14181419</t>
    14191420<t>
    1420    A 201 response &MAY; contain an ETag response header field indicating
    1421    the current value of the entity-tag for the representation of the resource
    1422    identified by the Location header field or, in case the Location header
    1423    field was omitted, by the Effective Request URI (see &header-etag;).
     1421   A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field
     1422   indicating the current value of the entity-tag for the representation of the
     1423   resource identified by the Location header field or, in case the Location
     1424   header field was omitted, by the Effective Request URI (see &header-etag;).
    14241425</t>
    14251426</section>
     
    14831484<t>
    14841485   For example, if a 204 status code is received in response to a PUT
    1485    request and the response contains an ETag header field, then the PUT
    1486    was successful and the ETag field-value contains the entity-tag for
     1486   request and the response contains an <x:ref>ETag</x:ref> header field, then
     1487   the PUT was successful and the ETag field-value contains the entity-tag for
    14871488   the new representation of that target resource.
    14881489</t>
     
    46494650  <x:source basename="p4-conditional" href="p4-conditional.xml">
    46504651    <x:defines>304 (Not Modified)</x:defines>
     4652    <x:defines>ETag</x:defines>
     4653    <x:defines>If-Match</x:defines>
     4654    <x:defines>If-Modified-Since</x:defines>
     4655    <x:defines>If-None-Match</x:defines>
     4656    <x:defines>If-Unmodified-Since</x:defines>
    46514657  </x:source>
    46524658</reference>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r1738 r1739  
    769769      <p id="rfc.section.2.2.2.p.2">or </p>
    770770      <ul>
    771          <li>The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since header field, because the client
    772             has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and
     771         <li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field, because the client has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and
    773772         </li>
    774773         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
     
    932931            or if it is unfeasible to send a strong entity-tag.
    933932         </li>
    934          <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one.
     933         <li><em class="bcp14">SHOULD</em> send a <a href="#header.last-modified" class="smpl">Last-Modified</a> value if it is feasible to send one.
    935934         </li>
    936935      </ul>
    937       <p id="rfc.section.2.4.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
    938          value.
     936      <p id="rfc.section.2.4.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 <a href="#header.last-modified" class="smpl">Last-Modified</a> value.
    939937      </p>
    940938      <p id="rfc.section.2.4.p.4">HTTP/1.1 clients: </p>
    941939      <ul>
    942          <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
    943             by the origin server.
    944          </li>
    945          <li><em class="bcp14">SHOULD</em> use the Last-Modified value in non-subrange cache-conditional requests (using If-Modified-Since) if only a Last-Modified value
    946             has been provided by the origin server.
    947          </li>
    948          <li><em class="bcp14">MAY</em> use the Last-Modified value in subrange cache-conditional requests (using If-Unmodified-Since) if only a Last-Modified value
    949             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.
    950          </li>
    951          <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
    952             origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
     940         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
     941         </li>
     942         <li><em class="bcp14">SHOULD</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in non-subrange cache-conditional requests (using <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>) if only a Last-Modified value has been provided by the origin server.
     943         </li>
     944         <li><em class="bcp14">MAY</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in subrange cache-conditional requests (using <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>) if only a Last-Modified value 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.
     945         </li>
     946         <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
    953947         </li>
    954948      </ul>
    955       <p id="rfc.section.2.4.p.5">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
    956          or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
     949      <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
    957950      </p>
    958951      <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
     
    996989  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    997990  If-Match: *
    998 </pre><p id="rfc.section.3.1.p.9">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header field
    999          is undefined by this specification.
     991</pre><p id="rfc.section.3.1.p.9">The result of a request having both an If-Match header field and either an <a href="#header.if-none-match" class="smpl">If-None-Match</a> or an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field is undefined by this specification.
    1000992      </p>
    1001993      <div id="rfc.iref.i.2"></div>
     
    10151007      <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>
    10161008</pre><p id="rfc.section.3.2.p.4">If any of the entity-tags listed in the If-None-Match field-value match (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>) the entity-tag of the selected representation, or if "*" is given and any current representation exists for that resource,
    1017          then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly ETag) of the selected representation that has a matching
    1018          entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
    1019       </p>
    1020       <p id="rfc.section.3.2.p.5">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 <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
    1021       </p>
    1022       <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then 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;2.4</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
     1009         then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly <a href="#header.etag" class="smpl">ETag</a>) of the selected representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
     1010      </p>
     1011      <p id="rfc.section.3.2.p.5">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 <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
     1012      </p>
     1013      <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then 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;2.4</a> for a discussion of server behavior when both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and If-None-Match appear in the same request.)
    10231014      </p>
    10241015      <p id="rfc.section.3.2.p.7">Examples:</p>
     
    10281019  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
    10291020  If-None-Match: *
    1030 </pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
    1031          field is undefined by this specification.
     1021</pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an <a href="#header.if-match" class="smpl">If-Match</a> or an <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field is undefined by this specification.
    10321022      </p>
    10331023      <div id="rfc.iref.i.3"></div>
     
    10621052         <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
    10631053            function, for deciding whether to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to
    1064             use the exact date string received in a previous Last-Modified header field whenever possible.
    1065          </li>
    1066          <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
    1067             field for the same request, the client needs to be aware that this date is interpreted in the server's understanding of time.
    1068             Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server, are concerns.
    1069             This includes the possibility of race conditions if the document has changed between the time it was first requested and the
    1070             If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
     1054            use the exact date string received in a previous <a href="#header.last-modified" class="smpl">Last-Modified</a> header field whenever possible.
     1055         </li>
     1056         <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 <a href="#header.last-modified" class="smpl">Last-Modified</a> header field for the same request, the client needs to be aware that this date is interpreted in the server's understanding
     1057            of time. Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server,
     1058            are concerns. This includes the possibility of race conditions if the document has changed between the time it was first requested
     1059            and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
    10711060            date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between
    10721061            client and server are at best approximate due to network latency.
    10731062         </li>
    10741063      </ul>
    1075       <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header
    1076          field is undefined by this specification.
     1064      <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an <a href="#header.if-match" class="smpl">If-Match</a> or an <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field is undefined by this specification.
    10771065      </p>
    10781066      <div id="rfc.iref.i.4"></div>
     
    10891077      <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
    10901078      </p>
    1091       <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
    1092          header field is undefined by this specification.
     1079      <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an <a href="#header.if-none-match" class="smpl">If-None-Match</a> or an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field is undefined by this specification.
    10931080      </p>
    10941081      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
    1095       <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to If-Match and If-Unmodified-Since
    1096          but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
     1082      <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
    10971083      </p>
    10981084      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
     
    11051091         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.
    11061092      </p>
    1107       <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, 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 (OK)</a> response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, <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.
     1093      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, 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 (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>, Content-Location, <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.
    11081094      </p>
    11091095      <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
     
    12911277      <p id="rfc.section.A.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>).
    12921278      </p>
    1293       <p id="rfc.section.A.p.2">Change ETag header field ABNF not to use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)
     1279      <p id="rfc.section.A.p.2">Change <a href="#header.etag" class="smpl">ETag</a> header field ABNF not to use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)
    12941280      </p>
    12951281      <p id="rfc.section.A.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Precondition Header Fields">Section&nbsp;3</a>)
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1738 r1739  
    422422   or
    423423  <list style="symbols">
    424      <t>The validator is about to be used by a client in an If-Modified-Since,
    425         If-Unmodified-Since header field, because the client has a cache entry,
    426         or <x:ref>If-Range</x:ref> for the associated representation, and</t>
     424     <t>The validator is about to be used by a client in an <x:ref>If-Modified-Since</x:ref>,
     425        <x:ref>If-Unmodified-Since</x:ref> header field, because the client has
     426        a cache entry, or <x:ref>If-Range</x:ref> for the associated
     427        representation, and</t>
    427428     <t>That cache entry includes a Date value, which gives the time
    428429        when the origin server sent the original response, and</t>
     
    663664        or if it is unfeasible to send a strong entity-tag.</t>
    664665
    665      <t>&SHOULD; send a Last-Modified value if it is feasible to send one.</t>
     666     <t>&SHOULD; send a <x:ref>Last-Modified</x:ref> value if it is feasible to
     667        send one.</t>
    666668  </list>
    667669</t>
    668670<t>
    669671   In other words, the preferred behavior for an HTTP/1.1 origin server
    670    is to send both a strong entity-tag and a Last-Modified value.
     672   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value.
    671673</t>
    672674<t>
     
    674676  <list style="symbols">
    675677     <t>&MUST; use that entity-tag in any cache-conditional request (using
    676         If-Match or If-None-Match) if an entity-tag has been provided by the
    677         origin server.</t>
    678 
    679      <t>&SHOULD; use the Last-Modified value in non-subrange cache-conditional
    680         requests (using If-Modified-Since) if only a Last-Modified value has
    681         been provided by the origin server. </t>
    682 
    683      <t>&MAY; use the Last-Modified value in subrange cache-conditional
    684         requests (using If-Unmodified-Since) if only a Last-Modified value has
    685         been provided by an HTTP/1.0 origin server. The user agent &SHOULD;
    686         provide a way to disable this, in case of difficulty.</t>
     678        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
     679        entity-tag has been provided by the origin server.</t>
     680
     681     <t>&SHOULD; use the <x:ref>Last-Modified</x:ref> value in non-subrange
     682        cache-conditional requests (using <x:ref>If-Modified-Since</x:ref>)
     683        if only a Last-Modified value has been provided by the origin server.</t>
     684
     685     <t>&MAY; use the <x:ref>Last-Modified</x:ref> value in subrange
     686        cache-conditional requests (using <x:ref>If-Unmodified-Since</x:ref>)
     687        if only a Last-Modified value has been provided by an HTTP/1.0 origin
     688        server. The user agent &SHOULD; provide a way to disable this, in case
     689        of difficulty.</t>
    687690
    688691     <t>&SHOULD; use both validators in cache-conditional requests if both an
    689         entity-tag and a Last-Modified value have been provided by the origin
    690         server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond
    691         appropriately.</t>
     692        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
     693        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
     694        respond appropriately.</t>
    692695  </list>
    693696</t>
    694697<t>
    695698   An HTTP/1.1 origin server, upon receiving a conditional request that
    696    includes both a Last-Modified date (e.g., in an If-Modified-Since or
    697    If-Unmodified-Since header field) and one or more entity-tags (e.g.,
    698    in an If-Match, If-None-Match, or <x:ref>If-Range</x:ref> header field) as
    699    cache validators, &MUST-NOT; return a response status code of
    700    <x:ref>304 (Not Modified)</x:ref> unless doing so is consistent with all of
    701    the conditional header fields in the request.
     699   includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>
     700   or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more
     701   entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
     702   or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
     703   return a response status code of <x:ref>304 (Not Modified)</x:ref> unless
     704   doing so is consistent with all of the conditional header fields in the
     705   request.
    702706</t>
    703707<t>
     
    782786<t>
    783787   The result of a request having both an If-Match header field and
    784    either an If-None-Match or an If-Modified-Since header field is
    785    undefined by this specification.
     788   either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
     789   header field is undefined by this specification.
    786790</t>
    787791</section>
     
    822826   Instead, if the request method was GET or HEAD, the server &SHOULD;
    823827   respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the cache-related
    824    header fields (particularly ETag) of the selected representation that has
     828   header fields (particularly <x:ref>ETag</x:ref>) of the selected representation that has
    825829   a matching entity-tag.  For all other request methods, the server &MUST;
    826830   respond with a <x:ref>412 (Precondition Failed)</x:ref> status code.
     
    829833   If none of the entity-tags match, then the server &MAY; perform the
    830834   requested method as if the If-None-Match header field did not exist,
    831    but &MUST; also ignore any If-Modified-Since header field(s) in the
    832    request. That is, if no entity-tags match, then the server &MUST-NOT;
     835   but &MUST; also ignore any <x:ref>If-Modified-Since</x:ref> header field(s)
     836   in the request. That is, if no entity-tags match, then the server &MUST-NOT;
    833837   return a <x:ref>304 (Not Modified)</x:ref> response.
    834838</t>
     
    839843   header field &MUST; be ignored. (See <xref
    840844   target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
    841    a discussion of server behavior when both If-Modified-Since and
    842    If-None-Match appear in the same request.)
     845   a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref>
     846   and If-None-Match appear in the same request.)
    843847</t>
    844848<t>
     
    854858<t>
    855859   The result of a request having both an If-None-Match header field and
    856    either an If-Match or an If-Unmodified-Since header field is
    857    undefined by this specification.
     860   either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
     861   header field is undefined by this specification.
    858862</t>
    859863</section>
     
    915919      response. To get best results when sending an If-Modified-Since
    916920      header field for cache validation, clients are
    917       advised to use the exact date string received in a previous Last-Modified
    918       header field whenever possible.
     921      advised to use the exact date string received in a previous
     922      <x:ref>Last-Modified</x:ref> header field whenever possible.
    919923    </t><t>
    920924      &Note; If a client uses an arbitrary date in the If-Modified-Since
    921       header field instead of a date taken from the Last-Modified header field for
    922       the same request, the client needs to be aware that this
     925      header field instead of a date taken from the <x:ref>Last-Modified</x:ref>
     926      header field for the same request, the client needs to be aware that this
    923927      date is interpreted in the server's understanding of time.
    924928      Unsynchronized clocks and rounding problems, due to the different
     
    937941<t>
    938942   The result of a request having both an If-Modified-Since header field
    939    and either an If-Match or an If-Unmodified-Since header field is
    940    undefined by this specification.
     943   and either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
     944   header field is undefined by this specification.
    941945</t>
    942946</section>
     
    976980<t>
    977981   The result of a request having both an If-Unmodified-Since header
    978    field and either an If-None-Match or an If-Modified-Since header
    979    field is undefined by this specification.
     982   field and either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
     983   header field is undefined by this specification.
    980984</t>
    981985</section>
     
    984988<t>
    985989   The "If-Range" header field provides a special conditional request
    986    mechanism that is similar to If-Match and If-Unmodified-Since but
    987    specific to HTTP range requests. If-Range is defined in &header-if-range;.
     990   mechanism that is similar to <x:ref>If-Match</x:ref> and
     991   <x:ref>If-Unmodified-Since</x:ref> but specific to HTTP range requests.
     992   If-Range is defined in &header-if-range;.
    988993</t>
    989994</section>
     
    10141019   reasonable approximation of the current time.  If a <x:ref>200 (OK)</x:ref>
    10151020   response to the same request would have included any of the header fields
    1016    Cache-Control, Content-Location, ETag, <x:ref>Expires</x:ref>, or
    1017    <x:ref>Vary</x:ref>, then those same header fields &MUST; be sent in a 304
    1018    response.
     1021   <x:ref>Cache-Control</x:ref>, Content-Location, <x:ref>ETag</x:ref>,
     1022   <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then those same header
     1023   fields &MUST; be sent in a 304 response.
    10191024</t>
    10201025<t>
     
    12531258  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    12541259  <x:source href="p6-cache.xml" basename="p6-cache">
     1260    <x:defines>Cache-Control</x:defines>
    12551261    <x:defines>Expires</x:defines>
    12561262    <x:defines>Vary</x:defines>
     
    13731379</t>
    13741380<t>
    1375   Change ETag header field ABNF not to use quoted-string, thus avoiding
    1376   escaping issues.
     1381  Change <x:ref>ETag</x:ref> header field ABNF not to use quoted-string, thus
     1382  avoiding escaping issues.
    13771383  (<xref target="header.etag"/>)
    13781384</t>
  • draft-ietf-httpbis/latest/p5-range.html

    r1738 r1739  
    742742         </li>
    743743         <li>Date</li>
    744          <li>Cache-Control, ETag, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
     744         <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
    745745         </li>
    746746      </ul>
     
    794794         one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation.
    795795         These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is
    796          defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     796         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    797797      </p>
    798798      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
     
    888888      <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>
    889889      <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it
    890          could use the <a href="#range.retrieval.requests" class="smpl">Range</a> header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition
    891          fails because the representation has been modified, the client would then have to make a second request to obtain the entire
    892          current representation.
     890         could use the <a href="#range.retrieval.requests" class="smpl">Range</a> header field with a conditional GET (using either or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>.) However, if the condition fails because the representation has been modified, the client would then have to make a second
     891         request to obtain the entire current representation.
    893892      </p>
    894893      <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation
     
    896895      </p>
    897896      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#core.rules" class="smpl">HTTP-date</a>
    898 </pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a Last-Modified date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified
    899          date it does have for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     897</pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified date it does have
     898         for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    900899      </p>
    901900      <p id="rfc.section.5.3.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <em class="bcp14">MUST</em> evaluate the condition as false if the entity-tag used as a validator is marked as weak or, when an HTTP-date is used as the
     
    983982            In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>.
    984983         </li>
    985          <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,
    986             or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
    987             is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response returned if the conditional is false.
     984         <li>The presence of a Range header field in a conditional GET (a request using one or both of <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or one or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>) modifies what is returned if the GET is otherwise successful and the condition is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response returned if the conditional is false.
    988985         </li>
    989986      </ul>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1738 r1739  
    338338    </t>
    339339    <t>
    340         Cache-Control, ETag, <x:ref>Expires</x:ref>, Content-Location and/or
    341         Vary, if the header field would have been sent in a <x:ref>200 (OK)</x:ref>
    342         response to the same request
     340        <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
     341        <x:ref>Expires</x:ref>, Content-Location and/or
     342        <x:ref>Vary</x:ref>, if the header field would have been sent in a
     343        <x:ref>200 (OK)</x:ref> response to the same request
    343344    </t>
    344345  </list>
     
    447448   where "strong validator" is defined to be either an entity-tag that is
    448449   not marked as weak (&entity-tags;) or, if no entity-tag is provided, a
    449    Last-Modified value that is strong in the sense defined by
     450   <x:ref>Last-Modified</x:ref> value that is strong in the sense defined by
    450451   &lastmod-comparison;.
    451452</t>
     
    646647   to have an up-to-date copy of the entire representation, it could use the
    647648   <x:ref>Range</x:ref> header field with a conditional GET (using
    648    either or both of If-Unmodified-Since and If-Match.) However, if the
    649    condition fails because the representation has been modified, the client
    650    would then have to make a second request to obtain the entire current
    651    representation.
     649   either or both of <x:ref>If-Unmodified-Since</x:ref> and
     650   <x:ref>If-Match</x:ref>.) However, if the condition fails because the
     651   representation has been modified, the client would then have to make a
     652   second request to obtain the entire current representation.
    652653</t>
    653654<t>
     
    662663<t>
    663664   Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
    664    field value and &MUST-NOT; use a Last-Modified date in an If-Range
    665    field value unless it has no entity-tag for the representation and
     665   field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an
     666   If-Range field value unless it has no entity-tag for the representation and
    666667   the Last-Modified date it does have for the representation is strong
    667668   in the sense defined by &lastmod-comparison;.
     
    843844
    844845     <t>The presence of a Range header field in a conditional GET (a request
    845         using one or both of If-Modified-Since and If-None-Match, or
    846         one or both of If-Unmodified-Since and If-Match) modifies what
    847         is returned if the GET is otherwise successful and the
     846        using one or both of <x:ref>If-Modified-Since</x:ref> and
     847        <x:ref>If-None-Match</x:ref>, or one or both of
     848        <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
     849        what is returned if the GET is otherwise successful and the
    848850        condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
    849851        response returned if the conditional is false.</t>
     
    10531055  <x:source href="p4-conditional.xml" basename="p4-conditional">
    10541056    <x:defines>304 (Not Modified)</x:defines>
     1057    <x:defines>ETag</x:defines>
     1058    <x:defines>If-Match</x:defines>
     1059    <x:defines>If-Modified-Since</x:defines>
     1060    <x:defines>If-None-Match</x:defines>
     1061    <x:defines>If-Unmodified-Since</x:defines>
     1062    <x:defines>Last-Modified</x:defines>
    10551063  </x:source>
    10561064</reference>
     
    10791087  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
    10801088  <x:source href="p6-cache.xml" basename="p6-cache">
     1089    <x:defines>Cache-Control</x:defines>
    10811090    <x:defines>Expires</x:defines>
     1091    <x:defines>Vary</x:defines>
    10821092  </x:source>
    10831093</reference>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1738 r1739  
    769769      </p>
    770770      <ul class="empty">
    771          <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an
    772             equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     771         <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    773772         </li>
    774773      </ul>
     
    777776      <ul class="empty">
    778777         <li>A validator that is defined by the origin server such that its current value will change if the representation body changes;
    779             i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
     778            i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    780779         </li>
    781780      </ul>
     
    932931      </p>
    933932      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
    934          values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific
    935          algorithms, but does impose worst-case constraints on their results.
     933         values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case
     934         constraints on their results.
    936935      </p>
    937936      <div id="rfc.figure.u.4"></div>
     
    969968         present.
    970969      </p>
    971       <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     970      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
    972971         time. A typical setting of this fraction might be 10%.
    973972      </p>
     
    10741073         update it. This process is known as "validating" or "revalidating" the stored response.
    10751074      </p>
    1076       <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an If-Modified-Since header field whose value is that of the Last-Modified
    1077          header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) stored response, if available.
    1078       </p>
    1079       <p id="rfc.section.2.4.p.3">Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses
    1080          stored for the requested URI, if present. However, if any of the stored responses contains only partial content, the cache
    1081          shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied
    1082          by that stored response.
     1075      <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) stored response, if available.
     1076      </p>
     1077      <p id="rfc.section.2.4.p.3">Additionally, a cache can add an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from all responses stored for the requested URI, if present. However, if any of the stored responses contains
     1078         only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for
     1079         a range that would be fully satisfied by that stored response.
    10831080      </p>
    10841081      <p id="rfc.section.2.4.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
     
    11241121         a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
    11251122      </p>
    1126       <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the Content-Length, ETag or Last-Modified value of a HEAD response differs from that in a selected
    1127          GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
    1128       </p>
    1129       <p id="rfc.section.2.5.p.3">If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected
    1130          GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:
     1123      <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
     1124      </p>
     1125      <p id="rfc.section.2.5.p.3">If the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:
    11311126      </p>
    11321127      <ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1738 r1739  
    284284   <x:dfn>validator</x:dfn>
    285285   <list>
    286       <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
    287       is used to find out whether a stored response is an equivalent copy of
    288       a representation. See &weak-and-strong;.</t>
     286      <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
     287      time) that is used to find out whether a stored response is an equivalent
     288      copy of a representation. See &weak-and-strong;.</t>
    289289   </list>
    290290</t>
     
    297297         current value will change if the representation body changes; i.e.,
    298298         an entity-tag that is not marked as weak (&entity-tags;) or,
    299          if no entity-tag is provided, a Last-Modified value that is strong
    300          in the sense defined by &lastmod-comparison;.</t>
     299         if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
     300         that is strong in the sense defined by &lastmod-comparison;.</t>
    301301   </list>
    302302</t>
     
    619619   a cache &MAY; assign a heuristic expiration time when an explicit time is not
    620620   specified, employing algorithms that use other header field values (such as the
    621    Last-Modified time) to estimate a plausible expiration time. This
    622    specification does not provide specific algorithms, but does impose
     621   <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.
     622   This specification does not provide specific algorithms, but does impose
    623623   worst-case constraints on their results.
    624624</t>
     
    697697</t>
    698698<t>
    699    Also, if the response has a Last-Modified header field
     699   Also, if the response has a <x:ref>Last-Modified</x:ref> header field
    700700   (&header-last-modified;), caches are encouraged to use a heuristic
    701701   expiration value that is no more than some fraction of the interval since
     
    896896</t>
    897897<t>
    898    When sending such a conditional request, a cache adds an If-Modified-Since
    899    header field whose value is that of the Last-Modified header field from the
    900    selected (see <xref target="caching.negotiated.responses"/>) stored
    901    response, if available.
    902 </t>
    903 <t>
    904    Additionally, a cache can add an If-None-Match header field whose value is
    905    that of the ETag header field(s) from all responses stored for the
    906    requested URI, if present. However, if any of the stored responses contains
    907    only partial content, the cache shouldn't include its entity-tag in the
    908    If-None-Match header field unless the request is for a range that would be
    909    fully satisfied by that stored response.
     898   When sending such a conditional request, a cache adds an
     899   <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
     900   <x:ref>Last-Modified</x:ref> header field from the selected
     901   (see <xref target="caching.negotiated.responses"/>) stored response, if
     902   available.
     903</t>
     904<t>
     905   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
     906   whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
     907   responses stored for the requested URI, if present. However, if any of the
     908   stored responses contains only partial content, the cache shouldn't
     909   include its entity-tag in the If-None-Match header field unless the request
     910   is for a range that would be fully satisfied by that stored response.
    910911</t>
    911912
     
    989990   If one or more stored GET responses can be selected (as per <xref
    990991   target="caching.negotiated.responses"/>) for a HEAD request, and the
    991    Content-Length, ETag or Last-Modified value of a HEAD response differs from
    992    that in a selected GET response, the cache &MUST; consider that selected
    993    response to be stale.
    994 </t>
    995 <t>
    996    If the Content-Length, ETag and Last-Modified values of a HEAD response
    997    (when present) are the same as that in a selected GET response (as per
    998    <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
    999    remaining headers in the stored response using the following rules:
     992   Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of
     993   a HEAD response differs from that in a selected GET response, the cache
     994   &MUST; consider that selected response to be stale.
     995</t>
     996<t>
     997   If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
     998   values of a HEAD response (when present) are the same as that in a selected
     999   GET response (as per <xref target="caching.negotiated.responses"/>), the
     1000   cache &SHOULD; update the remaining headers in the stored response using the
     1001   following rules:
    10001002   <list style="symbols">
    10011003      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     
    23312333      <x:defines>304</x:defines>
    23322334      <x:defines>304 (Not Modified)</x:defines>
     2335      <x:defines>ETag</x:defines>
     2336      <x:defines>If-Modified-Since</x:defines>
     2337      <x:defines>If-None-Match</x:defines>
     2338      <x:defines>Last-Modified</x:defines>
    23332339    </x:source>
    23342340  </reference>
Note: See TracChangeset for help on using the changeset viewer.