source: draft-ietf-httpbis/19/draft-ietf-httpbis-p4-conditional-19.xml @ 1592

Last change on this file since 1592 was 1592, checked in by julian.reschke@…, 8 years ago

-19

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