Ignore:
Timestamp:
Jul 22, 2010, 10:43:59 PM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

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

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