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

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

Define time of evaluation along with precedence; remove more duplicate and conflicting requirements revealed by the addition of 428 (Precondition Required); reduce requirements targeting entity-tag to facts; clarify that servers only need to send validators on successful retrieval responses; addresses #350 and #427

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 63.0 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
14  <!ENTITY ID-VERSION "latest">
15  <!ENTITY ID-MONTH "January">
16  <!ENTITY ID-YEAR "2013">
17  <!ENTITY Note "<x:h xmlns:x='http://purl.org/net/xml2rfc/ext'>Note:</x:h>">
18  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
19  <!ENTITY conformance                "<xref target='Part1' x:rel='#conformance' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
20  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
21  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
22  <!ENTITY acks                       "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
23  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
24  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
25  <!ENTITY header-date                "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
26  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
27  <!ENTITY semantics                  "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
28  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
29  <!ENTITY freshening-responses       "<xref target='Part6' x:rel='#freshening.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
30  <!ENTITY header-accept-encoding     "<xref target='Part2' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
31  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
32  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
33  <!ENTITY header-vary                "<xref target='Part2' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
34  <!ENTITY http-date                  "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
35  <!ENTITY transfer-codings           "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
36  <!ENTITY content-negotiation        "<xref target='Part2' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
37]>
38<?rfc toc="yes" ?>
39<?rfc symrefs="yes" ?>
40<?rfc sortrefs="yes" ?>
41<?rfc compact="yes"?>
42<?rfc subcompact="no" ?>
43<?rfc linkmailto="no" ?>
44<?rfc editing="no" ?>
45<?rfc comments="yes"?>
46<?rfc inline="yes"?>
47<?rfc rfcedstyle="yes"?>
48<?rfc-ext allow-markup-in-artwork="yes" ?>
49<?rfc-ext include-references-in-index="yes" ?>
50<rfc obsoletes="2616" category="std" x:maturity-level="proposed"
51     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"
52     xmlns:x='http://purl.org/net/xml2rfc/ext'>
53<x:link rel="prev" basename="p2-semantics"/>
54<x:link rel="next" basename="p5-range"/>
55<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
56<front>
57
58  <title abbrev="HTTP/1.1 Conditional Requests">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
59
60  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
61    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
62    <address>
63      <postal>
64        <street>345 Park Ave</street>
65        <city>San Jose</city>
66        <region>CA</region>
67        <code>95110</code>
68        <country>USA</country>
69      </postal>
70      <email>fielding@gbiv.com</email>
71      <uri>http://roy.gbiv.com/</uri>
72    </address>
73  </author>
74
75  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
76    <organization abbrev="greenbytes">greenbytes GmbH</organization>
77    <address>
78      <postal>
79        <street>Hafenweg 16</street>
80        <city>Muenster</city><region>NW</region><code>48155</code>
81        <country>Germany</country>
82      </postal>
83      <email>julian.reschke@greenbytes.de</email>
84      <uri>http://greenbytes.de/tech/webdav/</uri>
85    </address>
86  </author>
87
88  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
89  <workgroup>HTTPbis Working Group</workgroup>
90
91<abstract>
92<t>
93   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
94   distributed, collaborative, hypertext information systems. This document
95   defines HTTP/1.1 conditional requests, including metadata header fields
96   for indicating state changes, request header fields for making
97   preconditions on such state, and rules for constructing the responses to a
98   conditional request when one or more preconditions evaluate to false.
99</t>
100</abstract>
101
102<note title="Editorial Note (To be removed by RFC Editor)">
103  <t>
104    Discussion of this draft takes place on the HTTPBIS working group
105    mailing list (ietf-http-wg@w3.org), which is archived at
106    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
107  </t>
108  <t>
109    The current issues list is at
110    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
111    documents (including fancy diffs) can be found at
112    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
113  </t>
114  <t>
115    The changes in this draft are summarized in <xref target="changes.since.21"/>.
116  </t>
117</note>
118</front>
119
120<middle>
121<section title="Introduction" anchor="introduction">
122<t>
123   Conditional requests are HTTP requests <xref target="Part2"/> that include
124   one or more header fields indicating a precondition to be tested before
125   applying the method semantics to the target resource.
126   Each precondition is based on metadata that is expected to change if the
127   selected representation of the target resource is changed.
128   This document defines the HTTP/1.1 conditional request mechanisms in terms
129   of the architecture, syntax notation, and conformance criteria defined in
130   <xref target="Part1"/>.
131</t>
132<t>
133   Conditional GET requests are the most efficient mechanism for HTTP
134   cache updates &caching;.  Conditionals can also be
135   applied to state-changing methods, such as PUT and DELETE, to prevent
136   the "lost update" problem: one client accidentally overwriting
137   the work of another client that has been acting in parallel.
138</t>
139<t>
140   Conditional request preconditions are based on the state of the target
141   resource as a whole (its current value set) or the state as observed
142   in a previously obtained representation (one value in that set).
143   A resource might have multiple current representations, each with its
144   own observable state.  The conditional request mechanisms assume that
145   the mapping of requests to corresponding representations will be
146   consistent over time if the server intends to take advantage of
147   conditionals.  Regardless, if the mapping is inconsistent and
148   the server is unable to select the appropriate representation, then
149   no harm will result when the precondition evaluates to false.
150</t>
151<t><iref primary="true" item="selected representation"/>
152   We use the term "<x:dfn>selected representation</x:dfn>" to refer to
153   the current representation of the target resource that would have been
154   selected in a successful response if the same request had used the method
155   GET and had excluded all of the conditional request header fields.
156   The conditional request preconditions are evaluated by comparing the
157   values provided in the request header fields to the current metadata
158   for the selected representation.
159</t>
160
161<section title="Conformance and Error Handling" anchor="conformance">
162<t>
163   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
164   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
165   document are to be interpreted as described in <xref target="RFC2119"/>.
166</t>
167<t>
168   Conformance criteria and considerations regarding error handling
169   are defined in &conformance;.
170</t>
171</section>
172
173<section title="Syntax Notation" anchor="notation">
174<t>
175   This specification uses the Augmented Backus-Naur Form (ABNF) notation
176   of <xref target="RFC5234"/> with the list rule extension defined in
177   &notation;. <xref target="imported.abnf"/> describes rules imported from
178   other documents. <xref target="collected.abnf"/> shows the collected ABNF
179   with the list rule expanded.
180</t>
181</section>
182</section>
183
184<section title="Validators" anchor="validators">
185   <iref primary="true" item="metadata"/>
186   <iref primary="true" item="validator"/>
187<t>
188   This specification defines two forms of metadata that are commonly used
189   to observe resource state and test for preconditions: modification dates
190   (<xref target="header.last-modified"/>) and opaque entity tags
191   (<xref target="header.etag"/>).  Additional metadata that reflects resource state
192   has been defined by various extensions of HTTP, such as WebDAV
193   <xref target="RFC4918"/>, that are beyond the scope of this specification.
194   A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>"
195   when it is used within a precondition.
196</t>
197
198<section title="Weak versus Strong" anchor="weak.and.strong.validators">
199   <iref primary="true" item="validator" subitem="weak"/>
200   <iref primary="true" item="validator" subitem="strong"/>
201<t>
202   Validators come in two flavors: strong or weak.  Weak validators are easy
203   to generate but are far less useful for comparisons.  Strong validators
204   are ideal for comparisons but can be very difficult (and occasionally
205   impossible) to generate efficiently.  Rather than impose that all forms
206   of resource adhere to the same strength of validator, HTTP exposes the
207   type of validator in use and imposes restrictions on when weak validators
208   can be used as preconditions.
209</t>
210<t>
211   A "strong validator" is a representation metadata value that is
212   changed to a new, previously unused or guaranteed unique, value whenever
213   a change occurs to the representation data such that a change would be
214   observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET.
215</t>
216<t>  
217   A strong validator might change for other reasons, such as when a semantically
218   significant part of the representation metadata is changed (e.g.,
219   <x:ref>Content-Type</x:ref>), but it is in the best interests of the origin
220   server to only change the value when it is necessary to invalidate the
221   stored responses held by remote caches and authoring tools.  A strong
222   validator is unique across all representations of a given resource,
223   such that no two representations of that resource share the same validator
224   unless their payload body would be identical.
225</t>
226<t>
227   Cache entries might persist for arbitrarily long periods, regardless
228   of expiration times.  Thus, a cache might attempt to validate an
229   entry using a validator that it obtained in the distant past.
230   A strong validator is unique across all versions of all
231   representations associated with a particular resource over time.
232   However, there is no implication of uniqueness across representations
233   of different resources (i.e., the same strong validator might be
234   in use for representations of multiple resources at the same time
235   and does not imply that those representations are equivalent).
236</t>
237<t>
238   There are a variety of strong validators used in practice.  The best are
239   based on strict revision control, wherein each change to a representation
240   always results in a unique node name and revision identifier being assigned
241   before the representation is made accessible to GET.  A collision-resistant hash
242   function applied to the representation data is also sufficient if the data
243   is available prior to the response header fields being sent and the digest
244   does not need to be recalculated every time a validation request is
245   received.  However, if a resource has distinct representations that differ
246   only in their metadata, such as might occur with content negotiation over
247   media types that happen to share the same data format, then the origin
248   server &SHOULD; incorporate additional information in the validator to
249   distinguish those representations and avoid confusing cache behavior.
250</t>
251<t>
252   In contrast, a "weak validator" is a representation metadata value that
253   might not be changed for every change to the representation data.  This
254   weakness might be due to limitations in how the value is calculated, such
255   as clock resolution or an inability to ensure uniqueness for all possible
256   representations of the resource, or due to a desire by the resource owner
257   to group representations by some self-determined set of equivalency
258   rather than unique sequences of data.  An origin server &SHOULD; change a
259   weak entity-tag whenever it considers prior representations to be
260   unacceptable as a substitute for the current representation. In other words,
261   a weak entity-tag ought to change whenever the origin server wants caches to
262   invalidate old responses.
263</t>
264<t>
265   For example, the representation of a weather report that changes in
266   content every second, based on dynamic measurements, might be grouped
267   into sets of equivalent representations (from the origin server's
268   perspective) with the same weak validator in order to allow cached
269   representations to be valid for a reasonable period of time (perhaps
270   adjusted dynamically based on server load or weather quality).
271   Likewise, a representation's modification time, if defined with only
272   one-second resolution, might be a weak validator if it is possible
273   for the representation to be modified twice during a single second and
274   retrieved between those modifications.
275</t>
276<t>
277   A "use" of a validator occurs when either a client generates a request
278   and includes the validator in a precondition or when a server
279   compares two validators.
280   Weak validators are only usable in contexts that do not depend on exact
281   equality of a representation's payload body.
282   Strong validators are usable and preferred for all conditional requests,
283   including cache validation, partial content ranges, and "lost update"
284   avoidance.
285</t>
286</section>
287
288<section title="Last-Modified" anchor="header.last-modified">
289  <iref primary="true" item="Last-Modified header field" x:for-anchor=""/>
290  <x:anchor-alias value="Last-Modified"/>
291<t>
292   The "Last-Modified" header field in a response provides a timestamp
293   indicating the date and time at which the origin server believes the
294   selected representation was last modified, as determined at the conclusion
295   of handling the request.
296</t>
297<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/>
298  <x:ref>Last-Modified</x:ref> = <x:ref>HTTP-date</x:ref>
299</artwork></figure>
300<t>
301   An example of its use is
302</t>
303<figure><artwork type="example">
304  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
305</artwork></figure>
306
307<section title="Generation" anchor="lastmod.generation">
308<t>
309   Origin servers &SHOULD; send Last-Modified for any selected
310   representation for which a last modification date can be reasonably
311   and consistently determined, since its use in conditional requests
312   and evaluating cache freshness (&caching;) results in a substantial
313   reduction of HTTP traffic on the Internet and can be a significant
314   factor in improving service scalability and reliability.
315</t>
316<t>
317   A representation is typically the sum of many parts behind the
318   resource interface.  The last-modified time would usually be
319   the most recent time that any of those parts were changed.
320   How that value is determined for any given resource is an
321   implementation detail beyond the scope of this specification.
322   What matters to HTTP is how recipients of the Last-Modified
323   header field can use its value to make conditional requests
324   and test the validity of locally cached responses.
325</t>
326<t>
327   An origin server &SHOULD; obtain the Last-Modified value of the
328   representation as close as possible to the time that it generates the
329   <x:ref>Date</x:ref> field value for its response. This allows a recipient to
330   make an accurate assessment of the representation's modification time,
331   especially if the representation changes near the time that the
332   response is generated.
333</t>
334<t>
335   An origin server with a clock &MUST-NOT; send a Last-Modified date
336   that is later than the server's time of message origination (<x:ref>Date</x:ref>).
337   If the last modification time is derived from implementation-specific
338   metadata that evaluates to some time in the future, according to the
339   origin server's clock, then the origin server &MUST; replace that
340   value with the message origination date. This prevents a future
341   modification date from having an adverse impact on cache validation.
342</t>
343<t>
344   An origin server without a clock &MUST-NOT; assign Last-Modified
345   values to a response unless these values were associated
346   with the resource by some other system or user with a reliable clock.
347</t>
348</section>
349
350<section title="Comparison" anchor="lastmod.comparison">
351<t>
352   A Last-Modified time, when used as a validator in a request, is
353   implicitly weak unless it is possible to deduce that it is strong,
354   using the following rules:
355  <list style="symbols">
356     <t>The validator is being compared by an origin server to the
357        actual current validator for the representation and,</t>
358     <t>That origin server reliably knows that the associated representation did
359        not change twice during the second covered by the presented
360        validator.</t>
361  </list>
362</t>
363<t>
364   or
365  <list style="symbols">
366     <t>The validator is about to be used by a client in an <x:ref>If-Modified-Since</x:ref>,
367        <x:ref>If-Unmodified-Since</x:ref> header field, because the client has
368        a cache entry, or <x:ref>If-Range</x:ref> for the associated
369        representation, and</t>
370     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
371        time when the origin server sent the original response, and</t>
372     <t>The presented Last-Modified time is at least 60 seconds before
373        the Date value.</t>
374  </list>
375</t>
376<t>
377   or
378  <list style="symbols">
379     <t>The validator is being compared by an intermediate cache to the
380        validator stored in its cache entry for the representation, and</t>
381     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
382        time when the origin server sent the original response, and</t>
383     <t>The presented Last-Modified time is at least 60 seconds before
384        the Date value.</t>
385  </list>
386</t>
387<t>
388   This method relies on the fact that if two different responses were
389   sent by the origin server during the same second, but both had the
390   same Last-Modified time, then at least one of those responses would
391   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
392   arbitrary 60-second limit guards against the possibility that the Date and
393   Last-Modified values are generated from different clocks, or at somewhat
394   different times during the preparation of the response. An
395   implementation &MAY; use a value larger than 60 seconds, if it is
396   believed that 60 seconds is too short.
397</t>
398</section>
399</section>
400
401<section title="ETag" anchor="header.etag">
402  <iref primary="true" item="ETag header field" x:for-anchor=""/>
403  <x:anchor-alias value="ETag"/>
404  <x:anchor-alias value="entity-tag"/>
405  <x:anchor-alias value="opaque-tag"/>
406  <x:anchor-alias value="weak"/>
407  <x:anchor-alias value="etagc"/>
408<t>
409   The "ETag" header field in a response provides the current entity-tag for
410   the selected representation, as determined at the conclusion of handling
411   the request.
412   An entity-tag is an opaque validator for differentiating between
413   multiple representations of the same resource, regardless of whether
414   those multiple representations are due to resource state changes over
415   time, content negotiation resulting in multiple representations being
416   valid at the same time, or both. An entity-tag consists of an opaque
417   quoted string, possibly prefixed by a weakness indicator.
418</t>
419<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/><iref primary="true" item="Grammar" subitem="etagc"/>
420  <x:ref>ETag</x:ref>       = <x:ref>entity-tag</x:ref>
421
422  <x:ref>entity-tag</x:ref> = [ <x:ref>weak</x:ref> ] <x:ref>opaque-tag</x:ref>
423  <x:ref>weak</x:ref>       = <x:abnf-char-sequence>"W/"</x:abnf-char-sequence> ; "W/", case-sensitive
424  <x:ref>opaque-tag</x:ref> = <x:ref>DQUOTE</x:ref> *<x:ref>etagc</x:ref> <x:ref>DQUOTE</x:ref>
425  <x:ref>etagc</x:ref>      = %x21 / %x23-7E / <x:ref>obs-text</x:ref>
426             ; <x:ref>VCHAR</x:ref> except double quotes, plus obs-text
427</artwork></figure>
428<x:note>
429  <t>
430    &Note; Previously, opaque-tag was defined to be a quoted-string
431    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>), thus some recipients
432    might perform backslash unescaping. Servers therefore ought to avoid
433    backslash characters in entity tags.
434  </t>
435</x:note>
436<t>
437   An entity-tag can be more reliable for validation than a modification
438   date in situations where it is inconvenient to store modification
439   dates, where the one-second resolution of HTTP date values is not
440   sufficient, or where modification dates are not consistently maintained.
441</t>
442<figure><preamble>
443  Examples:
444</preamble>
445<artwork type="example">
446  ETag: "xyzzy"
447  ETag: W/"xyzzy"
448  ETag: ""
449</artwork></figure>
450<t>
451   An entity-tag can be either a weak or strong validator, with
452   strong being the default.  If an origin server provides an entity-tag
453   for a representation and the generation of that entity-tag does not satisfy
454   the requirements for a strong validator
455   (<xref target="weak.and.strong.validators"/>), then the origin server
456   &MUST; mark the entity-tag as weak by prefixing its opaque value
457   with "W/" (case-sensitive).
458</t>
459
460<section title="Generation" anchor="entity.tag.generation">
461<t>
462   The principle behind entity-tags is that only the service author
463   knows the implementation of a resource well enough to select the
464   most accurate and efficient validation mechanism for that resource,
465   and that any such mechanism can be mapped to a simple sequence of
466   octets for easy comparison.  Since the value is opaque, there is no
467   need for the client to be aware of how each entity-tag is constructed.
468</t>
469<t>
470   For example, a resource that has implementation-specific versioning
471   applied to all changes might use an internal revision number, perhaps
472   combined with a variance identifier for content negotiation, to
473   accurately differentiate between representations.
474   Other implementations might use a collision-resistant hash of
475   representation content,
476   a combination of various filesystem attributes, or a modification
477   timestamp that has sub-second resolution.
478</t>
479<t>
480   Origin servers &SHOULD; send ETag for any selected representation
481   for which detection of changes can be reasonably and consistently
482   determined, since the entity-tag's use in conditional requests and
483   evaluating cache freshness (&caching;) can result in a substantial
484   reduction of HTTP network traffic and can be a significant factor in
485   improving service scalability and reliability.
486</t>
487</section>
488
489<section title="Comparison" anchor="entity.tag.comparison">
490  <x:anchor-alias value="validator.comparison"/>
491  <x:anchor-alias value="strong comparison"/>
492  <x:anchor-alias value="weak comparison"/>
493<t>
494   There are two entity-tag comparison functions, depending
495   on whether the comparison context allows the use of weak validators
496   or not:
497  <list style="symbols">
498     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
499        are not weak and their opaque-tags match character-by-character.</t>
500     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
501        match character-by-character, regardless of either or both
502        being tagged as "weak".</t>
503  </list>
504</t>
505<t>
506   The example below shows the results for a set of entity-tag pairs,
507   and both the weak and strong comparison function results:
508</t>
509<texttable align="left">
510  <ttcol>ETag 1</ttcol>
511  <ttcol>ETag 2</ttcol>
512  <ttcol>Strong Comparison</ttcol>
513  <ttcol>Weak Comparison</ttcol>
514
515  <c>W/"1"</c>
516  <c>W/"1"</c>
517  <c>no match</c>
518  <c>match</c>
519 
520  <c>W/"1"</c>
521  <c>W/"2"</c>
522  <c>no match</c>
523  <c>no match</c>
524
525  <c>W/"1"</c>
526  <c>"1"</c>
527  <c>no match</c>
528  <c>match</c>
529
530  <c>"1"</c>
531  <c>"1"</c>
532  <c>match</c>
533  <c>match</c>
534</texttable>
535</section>
536
537<section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
538<t>
539   Consider a resource that is subject to content negotiation
540   (&content-negotiation;), and where the representations sent in response to
541   a GET request vary based on the <x:ref>Accept-Encoding</x:ref> request
542   header field (&header-accept-encoding;):
543</t>
544<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
545GET /index HTTP/1.1
546Host: www.example.com
547Accept-Encoding: gzip
548
549</artwork></figure>
550<t>
551   In this case, the response might or might not use the gzip content coding.
552   If it does not, the response might look like:
553</t>
554<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
555HTTP/1.1 200 OK
556Date: Thu, 26 Mar 2010 00:05:00 GMT
557ETag: "123-a"
558Content-Length: <x:length-of target="exbody"/>
559Vary: Accept-Encoding
560Content-Type: text/plain
561
562<x:span anchor="exbody">Hello World!
563Hello World!
564Hello World!
565Hello World!
566Hello World!
567</x:span></artwork></figure>
568<t>
569   An alternative representation that does use gzip content coding would be:
570</t>
571<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
572HTTP/1.1 200 OK
573Date: Thu, 26 Mar 2010 00:05:00 GMT
574ETag: "123-b"
575Content-Length: 43
576Vary: Accept-Encoding
577Content-Type: text/plain
578Content-Encoding: gzip
579
580<spanx>...binary data...</spanx></artwork></figure>
581<x:note>
582  <t>
583    &Note; Content codings are a property of the representation,
584    so therefore an entity-tag of an encoded representation has to be distinct
585    from an unencoded representation to prevent conflicts during cache updates
586    and range requests.  In contrast, transfer codings (&transfer-codings;)
587    apply only during message transfer and do not require distinct entity-tags.
588  </t>
589</x:note>
590</section>
591</section>
592
593<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
594<t>
595   We adopt a set of rules and recommendations for origin servers,
596   clients, and caches regarding when various validator types ought to
597   be used, and for what purposes.
598</t>
599<t>
600   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
601  <list style="symbols">
602     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
603        generate one.</t>
604
605     <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if
606        performance considerations support the use of weak entity-tags,
607        or if it is unfeasible to send a strong entity-tag.</t>
608
609     <t>&SHOULD; send a <x:ref>Last-Modified</x:ref> value if it is feasible to
610        send one.</t>
611  </list>
612</t>
613<t>
614   In other words, the preferred behavior for an origin server
615   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
616   value in successful responses to a retrieval request.
617</t>
618<t>
619   A client:
620  <list style="symbols">
621     <t>&MUST; use that entity-tag in any cache-conditional request (using
622        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
623        entity-tag has been provided by the origin server.</t>
624
625     <t>&SHOULD; use the <x:ref>Last-Modified</x:ref> value in non-subrange
626        cache-conditional requests (using <x:ref>If-Modified-Since</x:ref>)
627        if only a Last-Modified value has been provided by the origin server.</t>
628
629     <t>&MAY; use the <x:ref>Last-Modified</x:ref> value in subrange
630        cache-conditional requests (using <x:ref>If-Unmodified-Since</x:ref>)
631        if only a Last-Modified value has been provided by an HTTP/1.0 origin
632        server. The user agent &SHOULD; provide a way to disable this, in case
633        of difficulty.</t>
634
635     <t>&SHOULD; use both validators in cache-conditional requests if both an
636        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
637        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
638        respond appropriately.</t>
639  </list>
640</t>
641</section>
642</section>
643
644<section title="Precondition Header Fields" anchor="header.field.definitions">
645<t>
646   This section defines the syntax and semantics of HTTP/1.1 header fields
647   for applying preconditions on requests.
648   <xref target="precedence"/> defines when the preconditions are applied and
649   the order of evaluation when more than one precondition is present.
650</t>
651
652<section title="If-Match" anchor="header.if-match">
653  <iref primary="true" item="If-Match header field" x:for-anchor=""/>
654  <x:anchor-alias value="If-Match"/>
655<t>
656   The "If-Match" header field can be used to make a request method conditional
657   on the current existence or value of an entity-tag for one or more
658   representations of the target resource.
659</t>
660<t>
661   If-Match is generally useful for resource update requests, such as PUT
662   requests, as a means for protecting against accidental overwrites when
663   multiple clients are acting in parallel on the same resource (i.e., the
664   "lost update" problem).  An If-Match field-value of "*" places the
665   precondition on the existence of any current representation for the
666   target resource.
667</t>
668<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
669  <x:ref>If-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
670</artwork></figure>
671<t>
672   The If-Match condition is met if and only if any of the entity-tags listed
673   in the If-Match field value match the entity-tag of the selected
674   representation for the target resource (as per <xref
675   target="entity.tag.comparison"/>), or if "*" is given and any current
676   representation exists for the target resource.
677</t>
678<t>
679   If the condition is met, the server &MAY; perform the request method.
680</t>
681<t>
682   Origin servers &MUST-NOT; perform the requested method if the condition is
683   not met; instead they &MUST; respond with the <x:ref>412 (Precondition
684   Failed)</x:ref> status code.
685</t>
686<t>
687   Proxy servers using a cached response as the selected representation
688   &MUST-NOT; perform the requested method if the condition is not met;
689   instead, they &MUST; forward the request towards the origin server.
690</t>
691<t>
692   Examples:
693</t>
694<figure><artwork type="example">
695  If-Match: "xyzzy"
696  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
697  If-Match: *
698</artwork></figure>
699</section>
700
701<section title="If-None-Match" anchor="header.if-none-match">
702  <iref primary="true" item="If-None-Match header field" x:for-anchor=""/>
703  <x:anchor-alias value="If-None-Match"/>
704<t>
705   The "If-None-Match" header field can be used to make a request method
706   conditional on not matching any of the current entity-tag values for
707   representations of the target resource.
708</t>
709<t>
710   If-None-Match is primarily used in conditional GET requests to enable
711   efficient updates of cached information with a minimum amount of transaction
712   overhead. A client that has one or more representations previously obtained
713   from the target resource can send If-None-Match with a list of the
714   associated entity-tags in the hope of receiving a <x:ref>304 (Not
715   Modified)</x:ref> response if at least one of those representations matches
716   the selected representation.
717</t>
718<t>
719   If-None-Match can also be used with a value of "*" to prevent an unsafe
720   request method (e.g., PUT) from inadvertently modifying an existing
721   representation of the target resource when the client believes that
722   the resource does not have a current representation.  This is a variation
723   on the "lost update" problem that might arise if more than one client
724   attempts to create an initial representation for the target resource.
725</t>
726<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
727  <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
728</artwork></figure>
729<t>
730   The If-None-Match condition is met if and only if none of the entity-tags
731   listed in the If-None-Match field value match the entity-tag of the selected
732   representation for the target resource (as per <xref
733   target="entity.tag.comparison"/>), or if "*" is given and no current
734   representation exists for that resource.
735</t>
736<t>
737   If the condition is not met, the server &MUST-NOT; perform the requested
738   method. Instead, if the request method was GET or HEAD, the server &SHOULD;
739   respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the
740   cache-related header fields (particularly <x:ref>ETag</x:ref>) of the
741   selected representation that has a matching entity-tag. For all other
742   request methods, the server &MUST; respond with a <x:ref>412 (Precondition
743   Failed)</x:ref> status code when the condition is not met.
744</t>
745<t>
746   If the condition is met, the server &MAY; perform the requested method and
747   &MUST; ignore any <x:ref>If-Modified-Since</x:ref> header field(s) in the
748   request. That is, if no entity-tags match, then the server &MUST-NOT; send
749   a <x:ref>304 (Not Modified)</x:ref> response.
750</t>
751<t>
752   Examples:
753</t>
754<figure><artwork type="example">
755  If-None-Match: "xyzzy"
756  If-None-Match: W/"xyzzy"
757  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
758  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
759  If-None-Match: *
760</artwork></figure>
761</section>
762
763<section title="If-Modified-Since" anchor="header.if-modified-since">
764  <iref primary="true" item="If-Modified-Since header field" x:for-anchor=""/>
765  <x:anchor-alias value="If-Modified-Since"/>
766<t>
767   The "If-Modified-Since" header field can be used with GET or HEAD to make
768   the method conditional by modification date: if the selected representation
769   has not been modified since the time specified in this field, then
770   do not perform the request method; instead, respond as detailed below.
771</t>
772<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
773  <x:ref>If-Modified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
774</artwork></figure>
775<t>
776   An example of the field is:
777</t>
778<figure><artwork type="example">
779  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
780</artwork></figure>
781<t>
782   A GET method with an If-Modified-Since header field and no <x:ref>Range</x:ref>
783   header field requests that the selected representation be transferred only if
784   it has been modified since the date given by the If-Modified-Since
785   header field.
786   The algorithm for determining this includes the following cases:
787  <list style="numbers">
788      <t>If the request would normally result in anything other than a
789         <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
790         invalid, the response is exactly the same as for a normal GET.
791         A date that is later than the server's current time is
792         invalid.</t>
793
794      <t>If the selected representation has been modified since the
795         If-Modified-Since date, the response is exactly the same as for
796         a normal GET.</t>
797
798      <t>If the selected representation has not been modified since a valid
799         If-Modified-Since date, the server &SHOULD; send a
800         <x:ref>304 (Not Modified)</x:ref> response.</t>
801  </list>
802</t>
803<t>
804   The two purposes of this feature are to allow efficient updates of cached
805   information, with a minimum amount of transaction overhead, and to limit
806   the scope of a web traversal to resources that have recently changed.
807</t>
808<t>
809   When used for cache updates, a cache will typically use the value of the
810   cached message's <x:ref>Last-Modified</x:ref> field to generate the field
811   value of If-Modified-Since. This behavior is most interoperable for cases
812   where clocks are poorly synchronized or when the server has chosen to only
813   honor exact timestamp matches (due to a problem with Last-Modified dates
814   that appear to go "back in time" when the origin server's clock is
815   corrected or a representation is restored from an archived backup).
816   However, caches occasionally generate the field value based on other data,
817   such as the <x:ref>Date</x:ref> header field of the cached message or the
818   local clock time that the message was received, particularly when the
819   cached message does not contain a <x:ref>Last-Modified</x:ref> field.
820</t>
821<t>
822   When used for limiting the scope of retrieval to a recent time window, a
823   user agent will generate an If-Modified-Since field value based on either
824   its own local clock or a <x:ref>Date</x:ref> header field received from the
825   server during a past run. Origin servers that choose an exact timestamp
826   match based on the selected representation's <x:ref>Last-Modified</x:ref>
827   field will not be able to help the user agent limit its data transfers to
828   only those changed during the specified window.
829</t>
830<t>
831   The <x:ref>Range</x:ref> header field modifies the interpretation of
832   If-Modified-Since, as defined in &header-range;.
833</t>
834<x:note>
835  <t>
836     &Note; If a client uses an arbitrary date in the If-Modified-Since
837     header field instead of a date taken from a <x:ref>Last-Modified</x:ref>
838     or <x:ref>Date</x:ref> header field from the origin server, the client
839     ought to be aware that its date will be interpreted according to the
840     server's understanding of time.
841  </t>
842</x:note>
843</section>
844
845<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
846  <iref primary="true" item="If-Unmodified-Since header field" x:for-anchor=""/>
847  <x:anchor-alias value="If-Unmodified-Since"/>
848<t>
849   The "If-Unmodified-Since" header field can be used to make a request
850   method conditional by modification date: if the selected representation
851   has been modified since the time specified in this field, then the
852   server &MUST-NOT; perform the requested operation and &MUST; instead
853   respond with the <x:ref>412 (Precondition Failed)</x:ref> status code.
854   If the selected representation has not been modified since the time
855   specified in this field, the server &MAY; perform the request.
856</t>
857<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
858  <x:ref>If-Unmodified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
859</artwork></figure>
860<t>
861   An example of the field is:
862</t>
863<figure><artwork type="example">
864  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
865</artwork></figure>
866<t>
867   A server &MUST; ignore the If-Unmodified-Since header field if the
868   received value is not a valid HTTP-date.
869</t>
870</section>
871
872<section title="If-Range" anchor="header.if-range">
873<t>
874   The "If-Range" header field provides a special conditional request
875   mechanism that is similar to <x:ref>If-Match</x:ref> and
876   <x:ref>If-Unmodified-Since</x:ref> but specific to HTTP range requests.
877   If-Range is defined in &header-if-range;.
878</t>
879</section>
880
881</section>
882
883<section title="Status Code Definitions" anchor="status.code.definitions">
884<section title="304 Not Modified" anchor="status.304">
885  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
886  <x:anchor-alias value="304"/>
887  <x:anchor-alias value="304 (Not Modified)"/>
888<t>
889   The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a conditional GET request has been
890   received and would have resulted in a <x:ref>200 (OK)</x:ref> response
891   if it were not for the fact that the condition has evaluated to false.
892   In other words, there is no need for the server to transfer a
893   representation of the target resource because the request indicates that
894   the client, which made the request conditional, already has a valid
895   representation; the server is therefore redirecting the client to make
896   use of that stored representation as if it were the payload of a
897   <x:ref>200 (OK)</x:ref> response.
898</t>
899<t>
900   The server generating a 304 response &MUST; generate any of the following
901   header fields that would have been sent in a <x:ref>200 (OK)</x:ref>
902   response to the same request:
903   <x:ref>Cache-Control</x:ref>,
904   <x:ref>Content-Location</x:ref>,
905   <x:ref>ETag</x:ref>,
906   <x:ref>Expires</x:ref>, and
907   <x:ref>Vary</x:ref>.
908</t>
909<t>
910   Since the goal of a 304 response is to minimize information transfer
911   when the recipient already has one or more cached representations,
912   a sender &SHOULD-NOT; generate representation metadata other
913   than the above listed fields unless said metadata exists for the
914   purpose of guiding cache updates (e.g., <x:ref>Last-Modified</x:ref> might
915   be useful if the response does not have an <x:ref>ETag</x:ref> field).
916</t>
917<t>
918   Requirements on a cache that receives a 304 response are defined in
919   &freshening-responses;. If the conditional request originated with an
920   outbound client, such as a user agent with its own cache sending a
921   conditional GET to a shared proxy, then the proxy &SHOULD; forward the
922   304 response to that client.
923</t>
924<t>
925   A 304 response cannot contain a message-body; it is always
926   terminated by the first empty line after the header fields.
927</t>
928</section>
929
930<section title="412 Precondition Failed" anchor="status.412">
931  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
932  <x:anchor-alias value="412 (Precondition Failed)"/>
933<t>
934   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
935   or more preconditions given in the request header fields evaluated to false
936   when tested on the server. This response code allows the client to place
937   preconditions on the current resource state (its current representations
938   and metadata) and thus prevent the request method from being applied if the
939   target resource is in an unexpected state.
940</t>
941</section>
942</section>
943
944<section title="Evaluation and Precedence" anchor="precedence">
945<t>
946   For each conditional request, a server &MUST; evaluate the request
947   preconditions after it has successfully performed its normal request checks
948   (i.e., just before it would perform the action associated with the request
949   method). Preconditions are ignored if the server determines that an error
950   or redirect response applies before they are evaluated.
951</t>
952<t>
953   When more than one conditional request header field is present in a request,
954   the order in which the fields are evaluated becomes important. In practice,
955   the fields defined in this document are consistently implemented in a
956   single, logical order, due to the fact that entity tags are presumed to be
957   more accurate than date validators. For example, the only reason to send
958   both <x:ref>If-Modified-Since</x:ref> and <x:ref>If-None-Match</x:ref> in
959   the same GET request is to support intermediary caches that might not have
960   implemented <x:ref>If-None-Match</x:ref>, so it makes sense to ignore the
961   <x:ref>If-Modified-Since</x:ref> when entity tags are understood and
962   available for the selected representation.
963</t>
964<t>
965   The general rule of conditional precedence is that exact match conditions
966   are evaluated before cache-validating conditions and, within that order,
967   last-modified conditions are only evaluated if the corresponding
968   entity tag condition is not present (or not applicable because the
969   selected representation does not have an entity tag).
970</t>
971<t>
972   Specifically, the fields defined by this specification are evaluated
973   as follows:
974   <list style="numbers">
975     <t>When <x:ref>If-Match</x:ref> is present, evaluate it:
976       <list style="symbols">
977         <t>if true, continue to step 3</t>
978         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref></t>
979       </list>
980     </t>
981     <t>When <x:ref>If-Match</x:ref> is not present and
982        <x:ref>If-Unmodified-Since</x:ref> is present, evaluate it:
983       <list style="symbols">
984         <t>if true, continue to step 3</t>
985         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref></t>
986       </list>
987     </t>
988     <t>When the method is GET and both <x:ref>Range</x:ref> and
989        <x:ref>If-Range</x:ref> are present, evaluate it:
990       <list style="symbols">
991         <t>if the validator matches, respond 206 (Partial Content)</t>
992         <t>if the validator does not match, respond <x:ref>200 (OK)</x:ref></t>
993       </list>
994     </t>
995     <t>When <x:ref>If-None-Match</x:ref> is present, evaluate it:
996       <list style="symbols">
997         <t>if true, all conditions are met</t>
998         <t>if false for GET/HEAD, respond <x:ref>304 (Not Modified)</x:ref></t>
999         <t>if false for other methods, respond <x:ref>412 (Precondition Failed)</x:ref></t>
1000       </list>
1001     </t>
1002     <t>When the method is GET or HEAD,
1003        <x:ref>If-None-Match</x:ref> is not present, and
1004        <x:ref>If-Modified-Since</x:ref> is present, evaluate it:
1005       <list style="symbols">
1006         <t>if true, all conditions are met</t>
1007         <t>if false, respond <x:ref>304 (Not Modified)</x:ref></t>
1008       </list>
1009     </t>
1010   </list>
1011</t>
1012<t>
1013   Any extension to HTTP/1.1 that defines additional conditional request
1014   header fields ought to define its own expectations regarding the order
1015   for evaluating such fields in relation to those defined in this document
1016   and other conditionals that might be found in practice.
1017</t>
1018</section>
1019
1020<section title="IANA Considerations" anchor="IANA.considerations">
1021
1022<section title="Status Code Registration" anchor="status.code.registration">
1023<t>
1024   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
1025   shall be updated with the registrations below:
1026</t>
1027<?BEGININC p4-conditional.iana-status-codes ?>
1028<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
1029<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
1030   <ttcol>Value</ttcol>
1031   <ttcol>Description</ttcol>
1032   <ttcol>Reference</ttcol>
1033   <c>304</c>
1034   <c>Not Modified</c>
1035   <c>
1036      <xref target="status.304"/>
1037   </c>
1038   <c>412</c>
1039   <c>Precondition Failed</c>
1040   <c>
1041      <xref target="status.412"/>
1042   </c>
1043</texttable>
1044<!--(END)-->
1045<?ENDINC p4-conditional.iana-status-codes ?>
1046</section>
1047
1048<section title="Header Field Registration" anchor="header.field.registration">
1049<t>
1050   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
1051   with the permanent registrations below (see <xref target="BCP90"/>):
1052</t>
1053<?BEGININC p4-conditional.iana-headers ?>
1054<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
1055<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
1056   <ttcol>Header Field Name</ttcol>
1057   <ttcol>Protocol</ttcol>
1058   <ttcol>Status</ttcol>
1059   <ttcol>Reference</ttcol>
1060
1061   <c>ETag</c>
1062   <c>http</c>
1063   <c>standard</c>
1064   <c>
1065      <xref target="header.etag"/>
1066   </c>
1067   <c>If-Match</c>
1068   <c>http</c>
1069   <c>standard</c>
1070   <c>
1071      <xref target="header.if-match"/>
1072   </c>
1073   <c>If-Modified-Since</c>
1074   <c>http</c>
1075   <c>standard</c>
1076   <c>
1077      <xref target="header.if-modified-since"/>
1078   </c>
1079   <c>If-None-Match</c>
1080   <c>http</c>
1081   <c>standard</c>
1082   <c>
1083      <xref target="header.if-none-match"/>
1084   </c>
1085   <c>If-Unmodified-Since</c>
1086   <c>http</c>
1087   <c>standard</c>
1088   <c>
1089      <xref target="header.if-unmodified-since"/>
1090   </c>
1091   <c>Last-Modified</c>
1092   <c>http</c>
1093   <c>standard</c>
1094   <c>
1095      <xref target="header.last-modified"/>
1096   </c>
1097</texttable>
1098<!--(END)-->
1099<?ENDINC p4-conditional.iana-headers ?>
1100<t>
1101   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
1102</t>
1103</section>
1104</section>
1105
1106<section title="Security Considerations" anchor="security.considerations">
1107<t>
1108   This section is meant to inform developers, information providers, and
1109   users of known security concerns specific to the HTTP/1.1 conditional
1110   request mechanisms. No additional security considerations have been
1111   identified beyond those applicable to HTTP messaging &messaging; and
1112   semantics &semantics;.
1113</t>
1114<t>
1115   The validators defined by this specification are not intended to ensure
1116   the validity of a representation, guard against malicious changes, or
1117   detect man-in-the-middle attacks. At best, they enable more efficient cache
1118   updates and optimistic concurrent writes when all participants are behaving
1119   nicely. At worst, the conditions will fail and the client will receive a
1120   response that is no more harmful than an HTTP exchange without conditional
1121   requests.
1122</t>
1123</section>
1124
1125<section title="Acknowledgments" anchor="acks">
1126<t>
1127  See &acks;.
1128</t>
1129</section>
1130</middle>
1131<back>
1132
1133<references title="Normative References">
1134
1135<reference anchor="Part1">
1136  <front>
1137    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
1138    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1139      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1140      <address><email>fielding@gbiv.com</email></address>
1141    </author>
1142    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1143      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1144      <address><email>julian.reschke@greenbytes.de</email></address>
1145    </author>
1146    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1147  </front>
1148  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
1149  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
1150</reference>
1151
1152<reference anchor="Part2">
1153  <front>
1154    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
1155    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1156      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1157      <address><email>fielding@gbiv.com</email></address>
1158    </author>
1159    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1160      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1161      <address><email>julian.reschke@greenbytes.de</email></address>
1162    </author>
1163    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1164  </front>
1165  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
1166  <x:source href="p2-semantics.xml" basename="p2-semantics">
1167    <x:defines>2xx</x:defines>
1168    <x:defines>2xx (Successful)</x:defines>
1169    <x:defines>200 (OK)</x:defines>
1170    <x:defines>Accept-Encoding</x:defines>
1171    <x:defines>Content-Location</x:defines>
1172    <x:defines>Content-Type</x:defines>
1173    <x:defines>Date</x:defines>
1174    <x:defines>Location</x:defines>
1175    <x:defines>Vary</x:defines>
1176  </x:source>
1177</reference>
1178
1179<reference anchor="Part5">
1180  <front>
1181    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
1182    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1183      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1184      <address><email>fielding@gbiv.com</email></address>
1185    </author>
1186    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1187      <organization abbrev="W3C">World Wide Web Consortium</organization>
1188      <address><email>ylafon@w3.org</email></address>
1189    </author>
1190    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1191      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1192      <address><email>julian.reschke@greenbytes.de</email></address>
1193    </author>
1194    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1195  </front>
1196  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
1197  <x:source href="p5-range.xml" basename="p5-range">
1198    <x:defines>If-Range</x:defines>
1199    <x:defines>Range</x:defines>
1200  </x:source>
1201</reference>
1202
1203<reference anchor="Part6">
1204  <front>
1205    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
1206    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1207      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1208      <address><email>fielding@gbiv.com</email></address>
1209    </author>
1210    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1211      <organization>Akamai</organization>
1212      <address><email>mnot@mnot.net</email></address>
1213    </author>
1214    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1215      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1216      <address><email>julian.reschke@greenbytes.de</email></address>
1217    </author>
1218    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1219  </front>
1220  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
1221  <x:source href="p6-cache.xml" basename="p6-cache">
1222    <x:defines>Cache-Control</x:defines>
1223    <x:defines>Expires</x:defines>
1224  </x:source>
1225</reference>
1226
1227<reference anchor="RFC2119">
1228  <front>
1229    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1230    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1231      <organization>Harvard University</organization>
1232      <address><email>sob@harvard.edu</email></address>
1233    </author>
1234    <date month="March" year="1997"/>
1235  </front>
1236  <seriesInfo name="BCP" value="14"/>
1237  <seriesInfo name="RFC" value="2119"/>
1238</reference>
1239
1240<reference anchor="RFC5234">
1241  <front>
1242    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1243    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1244      <organization>Brandenburg InternetWorking</organization>
1245      <address>
1246        <email>dcrocker@bbiw.net</email>
1247      </address> 
1248    </author>
1249    <author initials="P." surname="Overell" fullname="Paul Overell">
1250      <organization>THUS plc.</organization>
1251      <address>
1252        <email>paul.overell@thus.net</email>
1253      </address>
1254    </author>
1255    <date month="January" year="2008"/>
1256  </front>
1257  <seriesInfo name="STD" value="68"/>
1258  <seriesInfo name="RFC" value="5234"/>
1259</reference>
1260
1261</references>
1262
1263<references title="Informative References">
1264
1265<reference anchor="RFC2616">
1266  <front>
1267    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1268    <author initials="R." surname="Fielding" fullname="R. Fielding">
1269      <organization>University of California, Irvine</organization>
1270      <address><email>fielding@ics.uci.edu</email></address>
1271    </author>
1272    <author initials="J." surname="Gettys" fullname="J. Gettys">
1273      <organization>W3C</organization>
1274      <address><email>jg@w3.org</email></address>
1275    </author>
1276    <author initials="J." surname="Mogul" fullname="J. Mogul">
1277      <organization>Compaq Computer Corporation</organization>
1278      <address><email>mogul@wrl.dec.com</email></address>
1279    </author>
1280    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1281      <organization>MIT Laboratory for Computer Science</organization>
1282      <address><email>frystyk@w3.org</email></address>
1283    </author>
1284    <author initials="L." surname="Masinter" fullname="L. Masinter">
1285      <organization>Xerox Corporation</organization>
1286      <address><email>masinter@parc.xerox.com</email></address>
1287    </author>
1288    <author initials="P." surname="Leach" fullname="P. Leach">
1289      <organization>Microsoft Corporation</organization>
1290      <address><email>paulle@microsoft.com</email></address>
1291    </author>
1292    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1293      <organization>W3C</organization>
1294      <address><email>timbl@w3.org</email></address>
1295    </author>
1296    <date month="June" year="1999"/>
1297  </front>
1298  <seriesInfo name="RFC" value="2616"/>
1299</reference>
1300
1301<reference anchor='BCP90'>
1302  <front>
1303    <title>Registration Procedures for Message Header Fields</title>
1304    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
1305      <organization>Nine by Nine</organization>
1306      <address><email>GK-IETF@ninebynine.org</email></address>
1307    </author>
1308    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
1309      <organization>BEA Systems</organization>
1310      <address><email>mnot@pobox.com</email></address>
1311    </author>
1312    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
1313      <organization>HP Labs</organization>
1314      <address><email>JeffMogul@acm.org</email></address>
1315    </author>
1316    <date year='2004' month='September' />
1317  </front>
1318  <seriesInfo name='BCP' value='90' />
1319  <seriesInfo name='RFC' value='3864' />
1320</reference>
1321
1322<reference anchor='RFC4918'>
1323  <front>
1324    <title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title>
1325    <author initials="L.M." surname="Dusseault" fullname="Lisa Dusseault" role="editor" >
1326      <organization abbrev="CommerceNet">CommerceNet</organization>
1327      <address><email>ldusseault@commerce.net</email></address>
1328    </author>
1329    <date month="June" year="2007" />
1330  </front>
1331  <seriesInfo name='RFC' value='4918' />
1332</reference>
1333</references>
1334
1335<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1336<t>
1337  The definition of validator weakness has been expanded and clarified.
1338  (<xref target="weak.and.strong.validators" />)
1339</t>
1340<t>
1341  Weak entity-tags are now allowed in all requests except range requests
1342  (Sections <xref target="weak.and.strong.validators" format="counter"/> and
1343  <xref target="header.if-none-match" format="counter"/>).
1344</t>
1345<t>
1346  The <x:ref>ETag</x:ref> header field ABNF has been changed to not use
1347  quoted-string, thus avoiding escaping issues.
1348  (<xref target="header.etag" />)
1349</t>
1350<t>
1351  ETag is defined to provide an entity tag for the selected representation,
1352  thereby clarifying what it applies to in various situations (such as a
1353  PUT response).
1354  (<xref target="header.etag" />)
1355</t>
1356<t>
1357  The precedence for evaluation of conditional requests has been defined.
1358  (<xref target="precedence" />)
1359</t>
1360</section>
1361
1362<section title="Imported ABNF" anchor="imported.abnf">
1363  <x:anchor-alias value="ALPHA"/>
1364  <x:anchor-alias value="CR"/>
1365  <x:anchor-alias value="DIGIT"/>
1366  <x:anchor-alias value="DQUOTE"/>
1367  <x:anchor-alias value="LF"/>
1368  <x:anchor-alias value="OCTET"/>
1369  <x:anchor-alias value="VCHAR"/>
1370  <x:anchor-alias value="core.rules"/>
1371  <x:anchor-alias value="obs-text"/>
1372  <x:anchor-alias value="OWS"/>
1373  <x:anchor-alias value="HTTP-date"/>
1374<t>
1375  The following core rules are included by
1376  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
1377  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1378  DIGIT (decimal 0-9), DQUOTE (double quote),
1379  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1380  OCTET (any 8-bit sequence of data), SP (space), and
1381  VCHAR (any visible US-ASCII character).
1382</t>
1383<t>
1384  The rules below are defined in <xref target="Part1"/>:
1385</t>
1386<figure><artwork type="abnf2616">
1387  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
1388  <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
1389</artwork></figure>
1390<t>
1391  The rules below are defined in other parts:
1392</t>
1393<figure><artwork type="abnf2616">
1394  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
1395</artwork></figure>
1396</section>
1397
1398<?BEGININC p4-conditional.abnf-appendix ?>
1399<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
1400<figure>
1401<artwork type="abnf" name="p4-conditional.parsed-abnf">
1402<x:ref>ETag</x:ref> = entity-tag
1403
1404<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
1405
1406<x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1407 entity-tag ] ) )
1408<x:ref>If-Modified-Since</x:ref> = HTTP-date
1409<x:ref>If-None-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1410 entity-tag ] ) )
1411<x:ref>If-Unmodified-Since</x:ref> = HTTP-date
1412
1413<x:ref>Last-Modified</x:ref> = HTTP-date
1414
1415<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;
1416
1417<x:ref>entity-tag</x:ref> = [ weak ] opaque-tag
1418<x:ref>etagc</x:ref> = "!" / %x23-7E ; '#'-'~'
1419 / obs-text
1420
1421<x:ref>obs-text</x:ref> = &lt;obs-text, defined in [Part1], Section 3.2.6&gt;
1422<x:ref>opaque-tag</x:ref> = DQUOTE *etagc DQUOTE
1423
1424<x:ref>weak</x:ref> = %x57.2F ; W/
1425</artwork>
1426</figure>
1427</section>
1428<?ENDINC p4-conditional.abnf-appendix ?>
1429
1430<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1431<t>
1432  Changes up to the first Working Group Last Call draft are summarized
1433  in <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-19#appendix-C"/>.
1434</t>
1435
1436<section title="Since draft-ietf-httpbis-p4-conditional-19" anchor="changes.since.19">
1437<t>
1438  Closed issues:
1439  <list style="symbols">
1440    <t>
1441      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/241"/>:
1442      "Need to clarify eval order/interaction of conditional headers"
1443    </t>
1444    <t>
1445      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/345"/>:
1446      "Required headers on 304 and 206"
1447    </t>
1448    <t>
1449      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/350"/>:
1450      "Optionality of Conditional Request Support"
1451    </t>
1452    <t>
1453      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/354"/>:
1454      "ETags and Conditional Requests"
1455    </t>
1456    <t>
1457      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>:
1458      "ABNF requirements for recipients"
1459    </t>
1460    <t>
1461      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/363"/>:
1462      "Rare cases"
1463    </t>
1464    <t>
1465      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/365"/>:
1466      "Conditional Request Security Considerations"
1467    </t>
1468    <t>
1469      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/371"/>:
1470      "If-Modified-Since lacks definition for method != GET"
1471    </t>
1472    <t>
1473      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/372"/>:
1474      "refactor conditional header field descriptions"
1475    </t>
1476  </list>
1477</t>
1478</section>
1479
1480<section title="Since draft-ietf-httpbis-p4-conditional-20" anchor="changes.since.20">
1481<t>
1482  <list style="symbols">
1483    <t>
1484      Conformance criteria and considerations regarding error handling are
1485      now defined in Part 1.
1486    </t>
1487  </list>
1488</t>
1489</section>
1490
1491<section title="Since draft-ietf-httpbis-p4-conditional-21" anchor="changes.since.21">
1492<t>
1493  Closed issues:
1494  <list style="symbols">
1495    <t>
1496      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/384"/>:
1497      "unclear prose in definition of 304"
1498    </t>
1499    <t>
1500      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/406"/>:
1501      "304 without validator"
1502    </t>
1503  </list>
1504</t>
1505</section>
1506
1507</section>
1508
1509</back>
1510</rfc>
Note: See TracBrowser for help on using the repository browser.