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

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

bump up document dates, update to latest version of rfc2629.xslt, add feedback links

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