source: draft-ietf-httpbis/latest/p4-conditional.xml @ 35

Last change on this file since 35 was 35, checked in by fielding@…, 12 years ago

Use obsoletes instead of updates and seven-part instead of eight.

  • Property svn:eol-style set to native
File size: 41.5 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<!DOCTYPE rfc [
3  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
4  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
5  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
6  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
7  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
8  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
9  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
10  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
11  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
12  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
13  <!ENTITY ID-VERSION "latest">
14  <!ENTITY ID-MONTH "December">
15  <!ENTITY ID-YEAR "2007">
16  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
17  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
18  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
19  <!ENTITY header-vary                "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
20]>
21<?rfc toc="yes" ?>
22<?rfc symrefs="yes" ?>
23<?rfc sortrefs="yes" ?>
24<?rfc compact="yes"?>
25<?rfc subcompact="no" ?>
26<?rfc linkmailto="no" ?>
27<?rfc editing="no" ?>
28<?rfc-ext allow-markup-in-artwork="yes" ?>
29<?rfc-ext include-references-in-index="yes" ?>
30<rfc obsoletes="2068, 2616, 2617" category="std"
31     ipr="full3978" docName="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"
32     xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
33<front>
34
35  <title abbrev="HTTP/1.1, part 4">HTTP/1.1, part 4: Conditional Requests</title>
36
37  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
38    <organization abbrev="Day Software">Day Software</organization>
39    <address>
40      <postal>
41        <street>23 Corporate Plaza DR, Suite 280</street>
42        <city>Newport Beach</city>
43        <region>CA</region>
44        <code>92660</code>
45        <country>USA</country>
46      </postal>
47      <phone>+1-949-706-5300</phone>
48      <facsimile>+1-949-706-5305</facsimile>
49      <email>fielding@gbiv.com</email>
50      <uri>http://roy.gbiv.com/</uri>
51    </address>
52  </author>
53
54  <author initials="J." surname="Gettys" fullname="Jim Gettys">
55    <organization>One Laptop per Child</organization>
56    <address>
57      <postal>
58        <street>21 Oak Knoll Road</street>
59        <city>Carlisle</city>
60        <region>MA</region>
61        <code>01741</code>
62        <country>USA</country>
63      </postal>
64      <email>jg@laptop.org</email>
65      <uri>http://www.laptop.org/</uri>
66    </address>
67  </author>
68 
69  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
70    <organization abbrev="HP">Hewlett-Packard Company</organization>
71    <address>
72      <postal>
73        <street>HP Labs, Large Scale Systems Group</street>
74        <street>1501 Page Mill Road, MS 1177</street>
75        <city>Palo Alto</city>
76        <region>CA</region>
77        <code>94304</code>
78        <country>USA</country>
79      </postal>
80      <email>JeffMogul@acm.org</email>
81    </address>
82  </author>
83
84  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
85    <organization abbrev="Microsoft">Microsoft Corporation</organization>
86    <address>
87      <postal>
88        <street>1 Microsoft Way</street>
89        <city>Redmond</city>
90        <region>WA</region>
91        <code>98052</code>
92        <country>USA</country>
93      </postal>
94      <email>henrikn@microsoft.com</email>
95    </address>
96  </author>
97
98  <author initials="L." surname="Masinter" fullname="Larry Masinter">
99    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
100    <address>
101      <postal>
102        <street>345 Park Ave</street>
103        <city>San Jose</city>
104        <region>CA</region>
105        <code>95110</code>
106        <country>USA</country>
107      </postal>
108      <email>LMM@acm.org</email>
109      <uri>http://larry.masinter.net/</uri>
110    </address>
111  </author>
112 
113  <author initials="P." surname="Leach" fullname="Paul J. Leach">
114    <organization abbrev="Microsoft">Microsoft Corporation</organization>
115    <address>
116      <postal>
117        <street>1 Microsoft Way</street>
118        <city>Redmond</city>
119        <region>WA</region>
120        <code>98052</code>
121      </postal>
122      <email>paulle@microsoft.com</email>
123    </address>
124  </author>
125   
126  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
127    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
128    <address>
129      <postal>
130        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
131        <street>The Stata Center, Building 32</street>
132        <street>32 Vassar Street</street>
133        <city>Cambridge</city>
134        <region>MA</region>
135        <code>02139</code>
136        <country>USA</country>
137      </postal>
138      <email>timbl@w3.org</email>
139      <uri>http://www.w3.org/People/Berners-Lee/</uri>
140    </address>
141  </author>
142
143  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
144
145<abstract>
146<t>
147   The Hypertext Transfer Protocol (HTTP) is an application-level
148   protocol for distributed, collaborative, hypermedia information
149   systems. HTTP has been in use by the World Wide Web global information
150   initiative since 1990. This document is Part 4 of the seven-part specification
151   that defines the protocol referred to as "HTTP/1.1" and, taken together,
152   obsoletes RFC 2616 and RFC 2617.  Part 4 defines request header fields for
153   indicating conditional requests and the rules for constructing responses
154   to those requests.
155</t>
156</abstract>
157</front>
158<middle>
159<section title="Introduction" anchor="introduction">
160<t>
161   This document will define aspects of HTTP related to conditional
162   request messages based on time stamps and entity-tags.  Right now it
163   only includes the extracted relevant sections of <xref target="RFC2616">RFC 2616</xref>
164   without edit.
165</t>
166</section>
167
168<section title="Entity Tags" anchor="entity.tags">
169<t>
170   Entity tags are used for comparing two or more entities from the same
171   requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
172   If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
173   If-Range (&header-if-range;) header fields. The definition of how they
174   are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
175   entity tag consists of an opaque quoted string, possibly prefixed by
176   a weakness indicator.
177</t>
178<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/>
179   entity-tag = [ weak ] opaque-tag
180   weak       = "W/"
181   opaque-tag = quoted-string
182</artwork></figure>
183<t>
184   A "strong entity tag" &MAY; be shared by two entities of a resource
185   only if they are equivalent by octet equality.
186</t>
187<t>
188   A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by
189   two entities of a resource only if the entities are equivalent and
190   could be substituted for each other with no significant change in
191   semantics. A weak entity tag can only be used for weak comparison.
192</t>
193<t>
194   An entity tag &MUST; be unique across all versions of all entities
195   associated with a particular resource. A given entity tag value &MAY;
196   be used for entities obtained by requests on different URIs. The use
197   of the same entity tag value in conjunction with entities obtained by
198   requests on different URIs does not imply the equivalence of those
199   entities.
200</t>
201</section>
202
203<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
204<t>
205   Since both origin servers and caches will compare two validators to
206   decide if they represent the same or different entities, one normally
207   would expect that if the entity (the entity-body or any entity-headers)
208   changes in any way, then the associated validator would
209   change as well. If this is true, then we call this validator a
210   "strong validator."
211</t>
212<t>
213   However, there might be cases when a server prefers to change the
214   validator only on semantically significant changes, and not when
215   insignificant aspects of the entity change. A validator that does not
216   always change when the resource changes is a "weak validator."
217</t>
218<t>
219   Entity tags are normally "strong validators," but the protocol
220   provides a mechanism to tag an entity tag as "weak." One can think of
221   a strong validator as one that changes whenever the bits of an entity
222   changes, while a weak value changes whenever the meaning of an entity
223   changes. Alternatively, one can think of a strong validator as part
224   of an identifier for a specific entity, while a weak validator is
225   part of an identifier for a set of semantically equivalent entities.
226  <list><t>
227      <x:h>Note:</x:h> One example of a strong validator is an integer that is
228      incremented in stable storage every time an entity is changed.
229    </t><t>
230      An entity's modification time, if represented with one-second
231      resolution, could be a weak validator, since it is possible that
232      the resource might be modified twice during a single second.
233    </t><t>
234      Support for weak validators is optional. However, weak validators
235      allow for more efficient caching of equivalent objects; for
236      example, a hit counter on a site is probably good enough if it is
237      updated every few days or weeks, and any value during that period
238      is likely "good enough" to be equivalent.
239    </t></list>
240</t>
241<t>
242   A "use" of a validator is either when a client generates a request
243   and includes the validator in a validating header field, or when a
244   server compares two validators.
245</t>
246<t>
247   Strong validators are usable in any context. Weak validators are only
248   usable in contexts that do not depend on exact equality of an entity.
249   For example, either kind is usable for a conditional GET of a full
250   entity. However, only a strong validator is usable for a sub-range
251   retrieval, since otherwise the client might end up with an internally
252   inconsistent entity.
253</t>
254<t>
255   Clients &MAY; issue simple (non-subrange) GET requests with either weak
256   validators or strong validators. Clients &MUST-NOT; use weak validators
257   in other forms of request.
258</t>
259<t>
260   The only function that the HTTP/1.1 protocol defines on validators is
261   comparison. There are two validator comparison functions, depending
262   on whether the comparison context allows the use of weak validators
263   or not:
264  <list style="symbols">
265     <t>The strong comparison function: in order to be considered equal,
266        both validators &MUST; be identical in every way, and both &MUST-NOT;
267        be weak.</t>
268     <t>The weak comparison function: in order to be considered equal,
269        both validators &MUST; be identical in every way, but either or
270        both of them &MAY; be tagged as "weak" without affecting the
271        result.</t>
272  </list>
273</t>
274<t>
275   An entity tag is strong unless it is explicitly tagged as weak.
276   <xref target="entity.tags"/> gives the syntax for entity tags.
277</t>
278<t>
279   A Last-Modified time, when used as a validator in a request, is
280   implicitly weak unless it is possible to deduce that it is strong,
281   using the following rules:
282  <list style="symbols">
283     <t>The validator is being compared by an origin server to the
284        actual current validator for the entity and,</t>
285     <t>That origin server reliably knows that the associated entity did
286        not change twice during the second covered by the presented
287        validator.</t>
288  </list>
289</t>
290<t>
291   or
292  <list style="symbols">
293     <t>The validator is about to be used by a client in an If-Modified-Since
294        or If-Unmodified-Since header, because the client
295        has a cache entry for the associated entity, and</t>
296     <t>That cache entry includes a Date value, which gives the time
297        when the origin server sent the original response, and</t>
298     <t>The presented Last-Modified time is at least 60 seconds before
299        the Date value.</t>
300  </list>
301</t>
302<t>
303   or
304  <list style="symbols">
305     <t>The validator is being compared by an intermediate cache to the
306        validator stored in its cache entry for the entity, and</t>
307     <t>That cache entry includes a Date value, which gives the time
308        when the origin server sent the original response, and</t>
309     <t>The presented Last-Modified time is at least 60 seconds before
310        the Date value.</t>
311  </list>
312</t>
313<t>
314   This method relies on the fact that if two different responses were
315   sent by the origin server during the same second, but both had the
316   same Last-Modified time, then at least one of those responses would
317   have a Date value equal to its Last-Modified time. The arbitrary 60-second
318   limit guards against the possibility that the Date and Last-Modified
319   values are generated from different clocks, or at somewhat
320   different times during the preparation of the response. An
321   implementation &MAY; use a value larger than 60 seconds, if it is
322   believed that 60 seconds is too short.
323</t>
324<t>
325   If a client wishes to perform a sub-range retrieval on a value for
326   which it has only a Last-Modified time and no opaque validator, it
327   &MAY; do this only if the Last-Modified time is strong in the sense
328   described here.
329</t>
330<t>
331   A cache or origin server receiving a conditional request, other than
332   a full-body GET request, &MUST; use the strong comparison function to
333   evaluate the condition.
334</t>
335<t>
336   These rules allow HTTP/1.1 caches and clients to safely perform sub-range
337   retrievals on values that have been obtained from HTTP/1.0
338   servers.
339</t>
340</section>
341
342<section title="Rules for When to Use Entity Tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
343<t>
344   We adopt a set of rules and recommendations for origin servers,
345   clients, and caches regarding when various validator types ought to
346   be used, and for what purposes.
347</t>
348<t>
349   HTTP/1.1 origin servers:
350  <list style="symbols">
351     <t>&SHOULD; send an entity tag validator unless it is not feasible to
352        generate one.</t>
353
354     <t>&MAY; send a weak entity tag instead of a strong entity tag, if
355        performance considerations support the use of weak entity tags,
356        or if it is unfeasible to send a strong entity tag.</t>
357
358     <t>&SHOULD; send a Last-Modified value if it is feasible to send one,
359        unless the risk of a breakdown in semantic transparency that
360        could result from using this date in an If-Modified-Since header
361        would lead to serious problems.</t>
362  </list>
363</t>
364<t>
365   In other words, the preferred behavior for an HTTP/1.1 origin server
366   is to send both a strong entity tag and a Last-Modified value.
367</t>
368<t>
369   In order to be legal, a strong entity tag &MUST; change whenever the
370   associated entity value changes in any way. A weak entity tag &SHOULD;
371   change whenever the associated entity changes in a semantically
372   significant way.
373  <list><t>
374      <x:h>Note:</x:h> in order to provide semantically transparent caching, an
375      origin server must avoid reusing a specific strong entity tag
376      value for two different entities, or reusing a specific weak
377      entity tag value for two semantically different entities. Cache
378      entries might persist for arbitrarily long periods, regardless of
379      expiration times, so it might be inappropriate to expect that a
380      cache will never again attempt to validate an entry using a
381      validator that it obtained at some point in the past.
382  </t></list>
383</t>
384<t>
385   HTTP/1.1 clients:
386  <list style="symbols">
387     <t>If an entity tag has been provided by the origin server, &MUST;
388        use that entity tag in any cache-conditional request (using If-Match
389        or If-None-Match).</t>
390
391     <t>If only a Last-Modified value has been provided by the origin
392        server, &SHOULD; use that value in non-subrange cache-conditional
393        requests (using If-Modified-Since).</t>
394
395     <t>If only a Last-Modified value has been provided by an HTTP/1.0
396        origin server, &MAY; use that value in subrange cache-conditional
397        requests (using If-Unmodified-Since:). The user agent &SHOULD;
398        provide a way to disable this, in case of difficulty.</t>
399
400     <t>If both an entity tag and a Last-Modified value have been
401        provided by the origin server, &SHOULD; use both validators in
402        cache-conditional requests. This allows both HTTP/1.0 and
403        HTTP/1.1 caches to respond appropriately.</t>
404  </list>
405</t>
406<t>
407   An HTTP/1.1 origin server, upon receiving a conditional request that
408   includes both a Last-Modified date (e.g., in an If-Modified-Since or
409   If-Unmodified-Since header field) and one or more entity tags (e.g.,
410   in an If-Match, If-None-Match, or If-Range header field) as cache
411   validators, &MUST-NOT; return a response status of 304 (Not Modified)
412   unless doing so is consistent with all of the conditional header
413   fields in the request.
414</t>
415<t>
416   An HTTP/1.1 caching proxy, upon receiving a conditional request that
417   includes both a Last-Modified date and one or more entity tags as
418   cache validators, &MUST-NOT; return a locally cached response to the
419   client unless that cached response is consistent with all of the
420   conditional header fields in the request.
421  <list><t>
422      <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
423      servers and clients should transmit as much non-redundant
424      information as is available in their responses and requests.
425      HTTP/1.1 systems receiving this information will make the most
426      conservative assumptions about the validators they receive.
427  </t><t>
428      HTTP/1.0 clients and caches will ignore entity tags. Generally,
429      last-modified values received or used by these systems will
430      support transparent and efficient caching, and so HTTP/1.1 origin
431      servers should provide Last-Modified values. In those rare cases
432      where the use of a Last-Modified value as a validator by an
433      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
434      origin servers should not provide one.
435  </t></list>
436</t>
437</section>
438
439<section title="Header Field Definitions" anchor="header.fields">
440<t>
441   This section defines the syntax and semantics of all standard
442   HTTP/1.1 header fields. For entity-header fields, both sender and
443   recipient refer to either the client or the server, depending on who
444   sends and who receives the entity.
445</t>
446
447<section title="ETag" anchor="header.etag">
448  <iref primary="true" item="ETag header" x:for-anchor=""/>
449  <iref primary="true" item="Headers" subitem="ETag" x:for-anchor=""/>
450<t>
451   The ETag response-header field provides the current value of the
452   entity tag for the requested variant. The headers used with entity
453   tags are described in sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag
454   &MAY; be used for comparison with other entities from the same resource
455   (see <xref target="weak.and.strong.validators"/>).
456</t>
457<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/>
458    ETag = "ETag" ":" entity-tag
459</artwork></figure>
460<figure><preamble>
461   Examples:
462</preamble>
463<artwork type="example">
464   ETag: "xyzzy"
465   ETag: W/"xyzzy"
466   ETag: ""
467</artwork></figure>
468</section>
469
470<section title="If-Match" anchor="header.if-match">
471  <iref primary="true" item="If-Match header" x:for-anchor=""/>
472  <iref primary="true" item="Headers" subitem="If-Match" x:for-anchor=""/>
473<t>
474   The If-Match request-header field is used with a method to make it
475   conditional. A client that has one or more entities previously
476   obtained from the resource can verify that one of those entities is
477   current by including a list of their associated entity tags in the
478   If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The
479   purpose of this feature is to allow efficient updates of cached
480   information with a minimum amount of transaction overhead. It is also
481   used, on updating requests, to prevent inadvertent modification of
482   the wrong version of a resource. As a special case, the value "*"
483   matches any current entity of the resource.
484</t>
485<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
486    If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
487</artwork></figure>
488<t>
489   If any of the entity tags match the entity tag of the entity that
490   would have been returned in the response to a similar GET request
491   (without the If-Match header) on that resource, or if "*" is given
492   and any current entity exists for that resource, then the server &MAY;
493   perform the requested method as if the If-Match header field did not
494   exist.
495</t>
496<t>
497   A server &MUST; use the strong comparison function (see <xref target="weak.and.strong.validators"/>)
498   to compare the entity tags in If-Match.
499</t>
500<t>
501   If none of the entity tags match, or if "*" is given and no current
502   entity exists, the server &MUST-NOT; perform the requested method, and
503   &MUST; return a 412 (Precondition Failed) response. This behavior is
504   most useful when the client wants to prevent an updating method, such
505   as PUT, from modifying a resource that has changed since the client
506   last retrieved it.
507</t>
508<t>
509   If the request would, without the If-Match header field, result in
510   anything other than a 2xx or 412 status, then the If-Match header
511   &MUST; be ignored.
512</t>
513<t>
514   The meaning of "If-Match: *" is that the method &SHOULD; be performed
515   if the representation selected by the origin server (or by a cache,
516   possibly using the Vary mechanism, see &header-vary;) exists, and
517   &MUST-NOT; be performed if the representation does not exist.
518</t>
519<t>
520   A request intended to update a resource (e.g., a PUT) &MAY; include an
521   If-Match header field to signal that the request method &MUST-NOT; be
522   applied if the entity corresponding to the If-Match value (a single
523   entity tag) is no longer a representation of that resource. This
524   allows the user to indicate that they do not wish the request to be
525   successful if the resource has been changed without their knowledge.
526   Examples:
527</t>
528<figure><artwork type="example">
529    If-Match: "xyzzy"
530    If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
531    If-Match: *
532</artwork></figure>
533<t>
534   The result of a request having both an If-Match header field and
535   either an If-None-Match or an If-Modified-Since header fields is
536   undefined by this specification.
537</t>
538</section>
539
540<section title="If-Modified-Since" anchor="header.if-modified-since">
541  <iref primary="true" item="If-Modified-Since header" x:for-anchor=""/>
542  <iref primary="true" item="Headers" subitem="If-Modified-Since" x:for-anchor=""/>
543<t>
544   The If-Modified-Since request-header field is used with a method to
545   make it conditional: if the requested variant has not been modified
546   since the time specified in this field, an entity will not be
547   returned from the server; instead, a 304 (not modified) response will
548   be returned without any message-body.
549</t>
550<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
551    If-Modified-Since = "If-Modified-Since" ":" HTTP-date
552</artwork></figure>
553<t>
554   An example of the field is:
555</t>
556<figure><artwork type="example">
557    If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
558</artwork></figure>
559<t>
560   A GET method with an If-Modified-Since header and no Range header
561   requests that the identified entity be transferred only if it has
562   been modified since the date given by the If-Modified-Since header.
563   The algorithm for determining this includes the following cases:
564  <list style="numbers">
565      <t>If the request would normally result in anything other than a
566         200 (OK) status, or if the passed If-Modified-Since date is
567         invalid, the response is exactly the same as for a normal GET.
568         A date which is later than the server's current time is
569         invalid.</t>
570
571      <t>If the variant has been modified since the If-Modified-Since
572         date, the response is exactly the same as for a normal GET.</t>
573
574      <t>If the variant has not been modified since a valid If-Modified-Since
575         date, the server &SHOULD; return a 304 (Not
576         Modified) response.</t>
577  </list>
578</t>
579<t>
580   The purpose of this feature is to allow efficient updates of cached
581   information with a minimum amount of transaction overhead.
582  <list><t>
583      <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since;
584      see &header-range; for full details.
585    </t><t>
586      <x:h>Note:</x:h> If-Modified-Since times are interpreted by the server, whose
587      clock might not be synchronized with the client.
588    </t><t>
589      <x:h>Note:</x:h> When handling an If-Modified-Since header field, some
590      servers will use an exact date comparison function, rather than a
591      less-than function, for deciding whether to send a 304 (Not
592      Modified) response. To get best results when sending an If-Modified-Since
593      header field for cache validation, clients are
594      advised to use the exact date string received in a previous Last-Modified
595      header field whenever possible.
596    </t><t>
597      <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
598      header instead of a date taken from the Last-Modified header for
599      the same request, the client should be aware of the fact that this
600      date is interpreted in the server's understanding of time. The
601      client should consider unsynchronized clocks and rounding problems
602      due to the different encodings of time between the client and
603      server. This includes the possibility of race conditions if the
604      document has changed between the time it was first requested and
605      the If-Modified-Since date of a subsequent request, and the
606      possibility of clock-skew-related problems if the If-Modified-Since
607      date is derived from the client's clock without correction
608      to the server's clock. Corrections for different time bases
609      between client and server are at best approximate due to network
610      latency.
611    </t>
612  </list>
613</t>
614<t>
615   The result of a request having both an If-Modified-Since header field
616   and either an If-Match or an If-Unmodified-Since header fields is
617   undefined by this specification.
618</t>
619</section>
620
621<section title="If-None-Match" anchor="header.if-none-match">
622  <iref primary="true" item="If-None-Match header" x:for-anchor=""/>
623  <iref primary="true" item="Headers" subitem="If-None-Match" x:for-anchor=""/>
624<t>
625   The If-None-Match request-header field is used with a method to make
626   it conditional. A client that has one or more entities previously
627   obtained from the resource can verify that none of those entities is
628   current by including a list of their associated entity tags in the
629   If-None-Match header field. The purpose of this feature is to allow
630   efficient updates of cached information with a minimum amount of
631   transaction overhead. It is also used to prevent a method (e.g. PUT)
632   from inadvertently modifying an existing resource when the client
633   believes that the resource does not exist.
634</t>
635<t>
636   As a special case, the value "*" matches any current entity of the
637   resource.
638</t>
639<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
640    If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
641</artwork></figure>
642<t>
643   If any of the entity tags match the entity tag of the entity that
644   would have been returned in the response to a similar GET request
645   (without the If-None-Match header) on that resource, or if "*" is
646   given and any current entity exists for that resource, then the
647   server &MUST-NOT; perform the requested method, unless required to do
648   so because the resource's modification date fails to match that
649   supplied in an If-Modified-Since header field in the request.
650   Instead, if the request method was GET or HEAD, the server &SHOULD;
651   respond with a 304 (Not Modified) response, including the cache-related
652   header fields (particularly ETag) of one of the entities that
653   matched. For all other request methods, the server &MUST; respond with
654   a status of 412 (Precondition Failed).
655</t>
656<t>
657   See <xref target="weak.and.strong.validators"/> for rules on how to determine if two entities tags
658   match. The weak comparison function can only be used with GET or HEAD
659   requests.
660</t>
661<t>
662   If none of the entity tags match, then the server &MAY; perform the
663   requested method as if the If-None-Match header field did not exist,
664   but &MUST; also ignore any If-Modified-Since header field(s) in the
665   request. That is, if no entity tags match, then the server &MUST-NOT;
666   return a 304 (Not Modified) response.
667</t>
668<t>
669   If the request would, without the If-None-Match header field, result
670   in anything other than a 2xx or 304 status, then the If-None-Match
671   header &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
672   server behavior when both If-Modified-Since and If-None-Match appear
673   in the same request.)
674</t>
675<t>
676   The meaning of "If-None-Match: *" is that the method &MUST-NOT; be
677   performed if the representation selected by the origin server (or by
678   a cache, possibly using the Vary mechanism, see &header-vary;)
679   exists, and &SHOULD; be performed if the representation does not exist.
680   This feature is intended to be useful in preventing races between PUT
681   operations.
682</t>
683<t>
684   Examples:
685</t>
686<figure><artwork type="example">
687    If-None-Match: "xyzzy"
688    If-None-Match: W/"xyzzy"
689    If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
690    If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
691    If-None-Match: *
692</artwork></figure>
693<t>
694   The result of a request having both an If-None-Match header field and
695   either an If-Match or an If-Unmodified-Since header fields is
696   undefined by this specification.
697</t>
698</section>
699
700<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
701  <iref primary="true" item="If-Unmodified-Since header" x:for-anchor=""/>
702  <iref primary="true" item="Headers" subitem="If-Unmodified-Since" x:for-anchor=""/>
703<t>
704   The If-Unmodified-Since request-header field is used with a method to
705   make it conditional. If the requested resource has not been modified
706   since the time specified in this field, the server &SHOULD; perform the
707   requested operation as if the If-Unmodified-Since header were not
708   present.
709</t>
710<t>
711   If the requested variant has been modified since the specified time,
712   the server &MUST-NOT; perform the requested operation, and &MUST; return
713   a 412 (Precondition Failed).
714</t>
715<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
716   If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
717</artwork></figure>
718<t>
719   An example of the field is:
720</t>
721<figure><artwork type="example">
722    If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
723</artwork></figure>
724<t>
725   If the request normally (i.e., without the If-Unmodified-Since
726   header) would result in anything other than a 2xx or 412 status, the
727   If-Unmodified-Since header &SHOULD; be ignored.
728</t>
729<t>
730   If the specified date is invalid, the header is ignored.
731</t>
732<t>
733   The result of a request having both an If-Unmodified-Since header
734   field and either an If-None-Match or an If-Modified-Since header
735   fields is undefined by this specification.
736</t>
737</section>
738
739<section title="Last-Modified" anchor="header.last-modified">
740  <iref primary="true" item="Last-Modified header" x:for-anchor=""/>
741  <iref primary="true" item="Headers" subitem="Last-Modified" x:for-anchor=""/>
742<t>
743   The Last-Modified entity-header field indicates the date and time at
744   which the origin server believes the variant was last modified.
745</t>
746<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/>
747    Last-Modified  = "Last-Modified" ":" HTTP-date
748</artwork></figure>
749<t>
750   An example of its use is
751</t>
752<figure><artwork type="example">
753    Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
754</artwork></figure>
755<t>
756   The exact meaning of this header field depends on the implementation
757   of the origin server and the nature of the original resource. For
758   files, it may be just the file system last-modified time. For
759   entities with dynamically included parts, it may be the most recent
760   of the set of last-modify times for its component parts. For database
761   gateways, it may be the last-update time stamp of the record. For
762   virtual objects, it may be the last time the internal state changed.
763</t>
764<t>
765   An origin server &MUST-NOT; send a Last-Modified date which is later
766   than the server's time of message origination. In such cases, where
767   the resource's last modification would indicate some time in the
768   future, the server &MUST; replace that date with the message
769   origination date.
770</t>
771<t>
772   An origin server &SHOULD; obtain the Last-Modified value of the entity
773   as close as possible to the time that it generates the Date value of
774   its response. This allows a recipient to make an accurate assessment
775   of the entity's modification time, especially if the entity changes
776   near the time that the response is generated.
777</t>
778<t>
779   HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible.
780</t>
781</section>
782
783</section>
784
785<section title="IANA Considerations" anchor="IANA.considerations">
786<t>
787   TBD.
788</t>
789</section>
790
791<section title="Security Considerations" anchor="security.considerations">
792<t>
793   No additional security considerations have been identified beyond
794   those applicable to HTTP in general &messaging;.
795</t>
796</section>
797
798<section title="Acknowledgments" anchor="ack">
799<t>
800   Based on an XML translation of RFC 2616 by Julian Reschke.
801</t>
802</section>
803</middle>
804<back>
805<references>
806<reference anchor="Part1">
807  <front>
808    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
809 
810    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
811      <organization abbrev="Day Software">Day Software</organization>
812      <address>
813        <email>fielding@gbiv.com</email>
814      </address>
815    </author>
816 
817    <author initials="J." surname="Gettys" fullname="Jim Gettys">
818      <organization>One Laptop per Child</organization>
819      <address>
820        <email>jg@laptop.org</email>
821      </address>
822    </author>
823   
824    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
825      <organization abbrev="HP">Hewlett-Packard Company</organization>
826      <address>
827        <email>JeffMogul@acm.org</email>
828      </address>
829    </author>
830 
831    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
832      <organization abbrev="Microsoft">Microsoft Corporation</organization>
833      <address>
834        <email>henrikn@microsoft.com</email>
835      </address>
836    </author>
837 
838    <author initials="L." surname="Masinter" fullname="Larry Masinter">
839      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
840      <address>
841        <email>LMM@acm.org</email>
842      </address>
843    </author>
844   
845    <author initials="P." surname="Leach" fullname="Paul J. Leach">
846      <organization abbrev="Microsoft">Microsoft Corporation</organization>
847      <address>
848        <email>paulle@microsoft.com</email>
849      </address>
850    </author>
851     
852    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
853      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
854      <address>
855        <email>timbl@w3.org</email>
856      </address>
857    </author>
858 
859    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
860  </front>
861  <seriesInfo name="Internet-Draft" value="draft-fielding-p1-messaging-&ID-VERSION;"/>
862  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
863</reference>
864
865<reference anchor="Part5">
866  <front>
867    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
868 
869    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
870      <organization abbrev="Day Software">Day Software</organization>
871      <address>
872        <email>fielding@gbiv.com</email>
873      </address>
874    </author>
875 
876    <author initials="J." surname="Gettys" fullname="Jim Gettys">
877      <organization>One Laptop per Child</organization>
878      <address>
879        <email>jg@laptop.org</email>
880      </address>
881    </author>
882   
883    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
884      <organization abbrev="HP">Hewlett-Packard Company</organization>
885      <address>
886        <email>JeffMogul@acm.org</email>
887      </address>
888    </author>
889 
890    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
891      <organization abbrev="Microsoft">Microsoft Corporation</organization>
892      <address>
893        <email>henrikn@microsoft.com</email>
894      </address>
895    </author>
896 
897    <author initials="L." surname="Masinter" fullname="Larry Masinter">
898      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
899      <address>
900        <email>LMM@acm.org</email>
901      </address>
902    </author>
903   
904    <author initials="P." surname="Leach" fullname="Paul J. Leach">
905      <organization abbrev="Microsoft">Microsoft Corporation</organization>
906      <address>
907        <email>paulle@microsoft.com</email>
908      </address>
909    </author>
910     
911    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
912      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
913      <address>
914        <email>timbl@w3.org</email>
915      </address>
916    </author>
917 
918    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
919  </front>
920  <seriesInfo name="Internet-Draft" value="draft-fielding-p5-range-&ID-VERSION;"/>
921  <x:source href="p5-range.xml" basename="p5-range"/>
922</reference>
923
924<reference anchor="Part6">
925  <front>
926    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
927 
928    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
929      <organization abbrev="Day Software">Day Software</organization>
930      <address>
931        <email>fielding@gbiv.com</email>
932      </address>
933    </author>
934 
935    <author initials="J." surname="Gettys" fullname="Jim Gettys">
936      <organization>One Laptop per Child</organization>
937      <address>
938        <email>jg@laptop.org</email>
939      </address>
940    </author>
941   
942    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
943      <organization abbrev="HP">Hewlett-Packard Company</organization>
944      <address>
945        <email>JeffMogul@acm.org</email>
946      </address>
947    </author>
948 
949    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
950      <organization abbrev="Microsoft">Microsoft Corporation</organization>
951      <address>
952        <email>henrikn@microsoft.com</email>
953      </address>
954    </author>
955 
956    <author initials="L." surname="Masinter" fullname="Larry Masinter">
957      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
958      <address>
959        <email>LMM@acm.org</email>
960      </address>
961    </author>
962   
963    <author initials="P." surname="Leach" fullname="Paul J. Leach">
964      <organization abbrev="Microsoft">Microsoft Corporation</organization>
965      <address>
966        <email>paulle@microsoft.com</email>
967      </address>
968    </author>
969     
970    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
971      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
972      <address>
973        <email>timbl@w3.org</email>
974      </address>
975    </author>
976 
977    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
978  </front>
979  <seriesInfo name="Internet-Draft" value="draft-fielding-p6-cache-&ID-VERSION;"/>
980  <x:source href="p6-cache.xml" basename="p6-cache"/>
981</reference>
982
983
984   <reference anchor="RFC2616">
985     <front>
986       <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
987       <author initials="R." surname="Fielding" fullname="R. Fielding">
988         <organization>University of California, Irvine</organization>
989         <address><email>fielding@ics.uci.edu</email></address>
990       </author>
991       <author initials="J." surname="Gettys" fullname="J. Gettys">
992         <organization>W3C</organization>
993         <address><email>jg@w3.org</email></address>
994       </author>
995       <author initials="J." surname="Mogul" fullname="J. Mogul">
996         <organization>Compaq Computer Corporation</organization>
997         <address><email>mogul@wrl.dec.com</email></address>
998       </author>
999       <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1000         <organization>MIT Laboratory for Computer Science</organization>
1001         <address><email>frystyk@w3.org</email></address>
1002       </author>
1003       <author initials="L." surname="Masinter" fullname="L. Masinter">
1004         <organization>Xerox Corporation</organization>
1005         <address><email>masinter@parc.xerox.com</email></address>
1006       </author>
1007       <author initials="P." surname="Leach" fullname="P. Leach">
1008         <organization>Microsoft Corporation</organization>
1009         <address><email>paulle@microsoft.com</email></address>
1010       </author>
1011       <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1012         <organization>W3C</organization>
1013         <address><email>timbl@w3.org</email></address>
1014       </author>
1015       <date month="June" year="1999"/>
1016     </front>
1017     <seriesInfo name="RFC" value="2616"/>
1018   </reference>
1019</references>
1020</back>
1021</rfc>
Note: See TracBrowser for help on using the repository browser.