source: draft-ietf-httpbis/10/draft-ietf-httpbis-p4-conditional-10.xml @ 1697

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

fix mime types

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 63.7 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-10">
20<front>
21
22  <title abbrev="HTTP/1.1, Part 4">HTTP/1.1, part 4: Conditional Requests</title>
23
24  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
25    <organization abbrev="Day Software">Day Software</organization>
26    <address>
27      <postal>
28        <street>23 Corporate Plaza DR, Suite 280</street>
29        <city>Newport Beach</city>
30        <region>CA</region>
31        <code>92660</code>
32        <country>USA</country>
33      </postal>
34      <phone>+1-949-706-5300</phone>
35      <facsimile>+1-949-706-5305</facsimile>
36      <email>fielding@gbiv.com</email>
37      <uri>http://roy.gbiv.com/</uri>
38    </address>
39  </author>
40
41  <author initials="J." surname="Gettys" fullname="Jim Gettys">
42    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
43    <address>
44      <postal>
45        <street>21 Oak Knoll Road</street>
46        <city>Carlisle</city>
47        <region>MA</region>
48        <code>01741</code>
49        <country>USA</country>
50      </postal>
51      <email>jg@freedesktop.org</email>
52      <uri>http://gettys.wordpress.com/</uri>
53    </address>
54  </author>
55 
56  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
57    <organization abbrev="HP">Hewlett-Packard Company</organization>
58    <address>
59      <postal>
60        <street>HP Labs, Large Scale Systems Group</street>
61        <street>1501 Page Mill Road, MS 1177</street>
62        <city>Palo Alto</city>
63        <region>CA</region>
64        <code>94304</code>
65        <country>USA</country>
66      </postal>
67      <email>JeffMogul@acm.org</email>
68    </address>
69  </author>
70
71  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
72    <organization abbrev="Microsoft">Microsoft Corporation</organization>
73    <address>
74      <postal>
75        <street>1 Microsoft Way</street>
76        <city>Redmond</city>
77        <region>WA</region>
78        <code>98052</code>
79        <country>USA</country>
80      </postal>
81      <email>henrikn@microsoft.com</email>
82    </address>
83  </author>
84
85  <author initials="L." surname="Masinter" fullname="Larry Masinter">
86    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
87    <address>
88      <postal>
89        <street>345 Park Ave</street>
90        <city>San Jose</city>
91        <region>CA</region>
92        <code>95110</code>
93        <country>USA</country>
94      </postal>
95      <email>LMM@acm.org</email>
96      <uri>http://larry.masinter.net/</uri>
97    </address>
98  </author>
99 
100  <author initials="P." surname="Leach" fullname="Paul J. Leach">
101    <organization abbrev="Microsoft">Microsoft Corporation</organization>
102    <address>
103      <postal>
104        <street>1 Microsoft Way</street>
105        <city>Redmond</city>
106        <region>WA</region>
107        <code>98052</code>
108      </postal>
109      <email>paulle@microsoft.com</email>
110    </address>
111  </author>
112   
113  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
114    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
115    <address>
116      <postal>
117        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
118        <street>The Stata Center, Building 32</street>
119        <street>32 Vassar Street</street>
120        <city>Cambridge</city>
121        <region>MA</region>
122        <code>02139</code>
123        <country>USA</country>
124      </postal>
125      <email>timbl@w3.org</email>
126      <uri>http://www.w3.org/People/Berners-Lee/</uri>
127    </address>
128  </author>
129
130  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
131    <organization abbrev="W3C">World Wide Web Consortium</organization>
132    <address>
133      <postal>
134        <street>W3C / ERCIM</street>
135        <street>2004, rte des Lucioles</street>
136        <city>Sophia-Antipolis</city>
137        <region>AM</region>
138        <code>06902</code>
139        <country>France</country>
140      </postal>
141      <email>ylafon@w3.org</email>
142      <uri>http://www.raubacapeu.net/people/yves/</uri>
143    </address>
144  </author>
145
146  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
147    <organization abbrev="greenbytes">greenbytes GmbH</organization>
148    <address>
149      <postal>
150        <street>Hafenweg 16</street>
151        <city>Muenster</city><region>NW</region><code>48155</code>
152        <country>Germany</country>
153      </postal>
154      <phone>+49 251 2807760</phone>
155      <facsimile>+49 251 2807761</facsimile>
156      <email>julian.reschke@greenbytes.de</email>
157      <uri>http://greenbytes.de/tech/webdav/</uri>
158    </address>
159  </author>
160
161  <date month="July" year="2010" day="12"/>
162  <workgroup>HTTPbis Working Group</workgroup>
163
164<abstract>
165<t>
166   The Hypertext Transfer Protocol (HTTP) is an application-level
167   protocol for distributed, collaborative, hypermedia information
168   systems. HTTP has been in use by the World Wide Web global information
169   initiative since 1990. This document is Part 4 of the seven-part specification
170   that defines the protocol referred to as "HTTP/1.1" and, taken together,
171   obsoletes RFC 2616.  Part 4 defines request header fields for
172   indicating conditional requests and the rules for constructing responses
173   to those requests.
174</t>
175</abstract>
176
177<note title="Editorial Note (To be removed by RFC Editor)">
178  <t>
179    Discussion of this draft should take place on the HTTPBIS working group
180    mailing list (ietf-http-wg@w3.org). The current issues list is
181    at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/>
182    and related documents (including fancy diffs) can be found at
183    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
184  </t>
185  <t>
186    The changes in this draft are summarized in <xref target="changes.since.09"/>.
187  </t>
188</note>
189</front>
190<middle>
191<section title="Introduction" anchor="introduction">
192<t>
193   This document defines HTTP/1.1 response metadata for indicating potential
194   changes to payload content, including modification time stamps and opaque
195   entity-tags, and the HTTP conditional request mechanisms that allow
196   preconditions to be placed on a request method.  Conditional GET requests
197   allow for efficient cache updates.  Other conditional request methods are
198   used to protect against overwriting or misunderstanding the state of a
199   resource that has been changed unbeknownst to the requesting client.
200</t>
201<t>
202   This document is currently disorganized in order to minimize the changes
203   between drafts and enable reviewers to see the smaller errata changes.
204   The next draft will reorganize the sections to better reflect the content.
205   In particular, the sections on resource metadata will be discussed first
206   and then followed by each conditional request-header, concluding with a
207   definition of precedence and the expectation of ordering strong validator
208   checks before weak validator checks.  It is likely that more content from
209   <xref target="Part6"/> will migrate to this part, where appropriate.
210   The current mess reflects how widely dispersed these topics and associated
211   requirements had become in <xref target="RFC2616"/>.
212</t>
213
214<section title="Requirements" anchor="intro.requirements">
215<t>
216   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218   document are to be interpreted as described in <xref target="RFC2119"/>.
219</t>
220<t>
221   An implementation is not compliant if it fails to satisfy one or more
222   of the "MUST" or "REQUIRED" level requirements for the protocols it
223   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
224   level and all the "SHOULD" level requirements for its protocols is said
225   to be "unconditionally compliant"; one that satisfies all the "MUST"
226   level requirements but not all the "SHOULD" level requirements for its
227   protocols is said to be "conditionally compliant".
228</t>
229</section>
230
231<section title="Syntax Notation" anchor="notation">
232 
233 
234 
235 
236 
237 
238 
239<t>
240  This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which
241  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
242  <xref target="collected.abnf"/> shows the collected ABNF, with the list
243  rule expanded.
244</t>
245<t>
246  The following core rules are included by
247  reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
248  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
249  DIGIT (decimal 0-9), DQUOTE (double quote),
250  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
251  OCTET (any 8-bit sequence of data), SP (space),
252  VCHAR (any visible USASCII character),
253  and WSP (whitespace).
254</t>
255
256<section title="Core Rules" anchor="core.rules">
257 
258 
259<t>
260  The core rules below are defined in Section 1.2.2 of <xref target="Part1"/>:
261</t>
262<figure><artwork type="abnf2616"><![CDATA[
263  quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
264  OWS           = <OWS, defined in [Part1], Section 1.2.2>
265]]></artwork></figure>
266</section>
267
268<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
269 
270<t>
271  The ABNF rules below are defined in other parts:
272</t>
273<figure><artwork type="abnf2616"><![CDATA[
274  HTTP-date     = <HTTP-date, defined in [Part1], Section 6.1>
275]]></artwork></figure>
276</section>
277
278</section>
279
280</section>
281
282<section title="Entity Tags" anchor="entity.tags">
283 
284 
285 
286<t>
287   Entity tags are used for comparing two or more entities from the same
288   requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
289   If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
290   If-Range (Section 5.3 of <xref target="Part5"/>) header fields. The definition of how they
291   are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
292   entity tag consists of an opaque quoted string, possibly prefixed by
293   a weakness indicator.
294</t>
295<figure><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/><artwork type="abnf2616"><![CDATA[
296  entity-tag = [ weak ] opaque-tag
297  weak       = %x57.2F ; "W/", case-sensitive
298  opaque-tag = quoted-string
299]]></artwork></figure>
300<t>
301   A "strong entity tag" MAY be shared by two entities of a resource
302   only if they are equivalent by octet equality.
303</t>
304<t>
305   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
306   two entities of a resource only if the entities are equivalent and
307   could be substituted for each other with no significant change in
308   semantics. A weak entity tag can only be used for weak comparison.
309</t>
310<t>
311   An entity tag MUST be unique across all versions of all entities
312   associated with a particular resource. A given entity tag value MAY
313   be used for entities obtained by requests on different URIs. The use
314   of the same entity tag value in conjunction with entities obtained by
315   requests on different URIs does not imply the equivalence of those
316   entities.
317</t>
318
319<section title="Example: Entity Tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
320<t>
321   Consider a resource that is subject to content negotiation (Section 4 of <xref target="Part3"/>),
322   and where the representations returned upon a GET request vary based on
323   the Accept-Encoding request header field (Section 5.3 of <xref target="Part3"/>):
324</t>
325<figure><preamble>&gt;&gt; Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
326  GET /index HTTP/1.1
327  Host: www.example.com
328  Accept-Encoding: gzip
329 
330  ]]></artwork></figure>
331<t>
332   In this case, the response may use the gzip Content Coding or not.
333   If it does, it might look like that:
334</t>
335<figure><preamble>&gt;&gt; Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"><![CDATA[
336  HTTP/1.1 200 OK
337  Date: Thu, 26 Mar 2010 00:05:00 GMT
338  ETag: "123-a"
339  Content-Length: 70
340  Vary: Accept-Encoding
341  Content-Type: text/plain
342 
343  Hello World!
344  Hello World!
345  Hello World!
346  Hello World!
347  Hello World!
348  ]]></artwork></figure>
349<t>
350   A variant that does use gzip Content Coding would be:
351</t>
352<figure><preamble>&gt;&gt; Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"><![CDATA[
353  HTTP/1.1 200 OK
354  Date: Thu, 26 Mar 2010 00:05:00 GMT
355  ETag: "123-b"
356  Content-Length: 43
357  Vary: Accept-Encoding
358  Content-Type: text/plain
359  Content-Encoding: gzip
360 
361  ...binary data...]]></artwork></figure>
362<t><list>
363  <t>
364    Note: Content Codings are a property of the response
365    entity, thus affect the Entity Tag. An alternative are Transfer
366    Codings (Section 6.2 of <xref target="Part1"/>) which apply only to the transfer of
367    the message, and thus do not require assigning distinct entity tags.
368  </t>
369</list></t>
370</section>
371</section>
372
373<section title="Status Code Definitions" anchor="status.code.definitions">
374<section title="304 Not Modified" anchor="status.304">
375  <iref primary="true" item="304 Not Modified (status code)"/>
376  <iref primary="true" item="Status Codes" subitem="304 Not Modified"/>
377<t>
378   If the client has performed a conditional GET request and access is
379   allowed, but the document has not been modified, the server SHOULD
380   respond with this status code. The 304 response MUST NOT contain a
381   message-body, and thus is always terminated by the first empty line
382   after the header fields.
383</t>
384<t>
385   The response MUST include the following header fields:
386  <list style="symbols">
387    <t>Date, unless its omission is required by Section 9.3.1 of <xref target="Part1"/>.<vspace blankLines="1"/>
388         If a clockless origin server obeys these rules, and proxies and
389         clients add their own Date to any response received without one (as
390         already specified by Section 9.3 of <xref target="Part1"/>, caches will operate
391         correctly.</t>
392    <t>ETag and/or Content-Location, if the header would have been sent
393         in a 200 response to the same request.</t>
394    <t>Expires, Cache-Control, and/or Vary, if the field-value might
395         differ from that sent in any previous response for the same
396         variant.</t>
397  </list>
398</t>
399<t>
400   If the conditional GET used a strong cache validator (see <xref target="weak.and.strong.validators"/>),
401   the response SHOULD NOT  include other entity-headers.
402   Otherwise (i.e., the conditional GET used a weak validator), the
403   response MUST NOT include other entity-headers; this prevents
404   inconsistencies between cached entity-bodies and updated headers.
405</t>
406<t>
407   If a 304 response indicates an entity not currently cached, then the
408   cache MUST disregard the response and repeat the request without the
409   conditional.
410</t>
411<t>
412   If a cache uses a received 304 response to update a cache entry, the
413   cache MUST update the entry to reflect any new field values given in
414   the response.
415</t>
416</section>
417
418<section title="412 Precondition Failed" anchor="status.412">
419  <iref primary="true" item="412 Precondition Failed (status code)"/>
420  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed"/>
421<t>
422   The precondition given in one or more of the request-header fields
423   evaluated to false when it was tested on the server. This response
424   code allows the client to place preconditions on the current resource
425   metainformation (header field data) and thus prevent the requested
426   method from being applied to a resource other than the one intended.
427</t>
428</section>
429</section>
430
431<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
432<t>
433   Since both origin servers and caches will compare two validators to
434   decide if they represent the same or different entities, one normally
435   would expect that if the entity (the entity-body or any entity-headers)
436   changes in any way, then the associated validator would
437   change as well. If this is true, then we call this validator a
438   "strong validator."
439</t>
440<t>
441   However, there might be cases when a server prefers to change the
442   validator only on semantically significant changes, and not when
443   insignificant aspects of the entity change. A validator that does not
444   always change when the resource changes is a "weak validator."
445</t>
446<t>
447   Entity tags are normally "strong validators," but the protocol
448   provides a mechanism to tag an entity tag as "weak." One can think of
449   a strong validator as one that changes whenever the bits of an entity
450   changes, while a weak value changes whenever the meaning of an entity
451   changes. Alternatively, one can think of a strong validator as part
452   of an identifier for a specific entity, while a weak validator is
453   part of an identifier for a set of semantically equivalent entities.
454  <list><t>
455      Note: One example of a strong validator is an integer that is
456      incremented in stable storage every time an entity is changed.
457    </t><t>
458      An entity's modification time, if represented with one-second
459      resolution, could be a weak validator, since it is possible that
460      the resource might be modified twice during a single second.
461    </t><t>
462      Support for weak validators is optional. However, weak validators
463      allow for more efficient caching of equivalent objects; for
464      example, a hit counter on a site is probably good enough if it is
465      updated every few days or weeks, and any value during that period
466      is likely "good enough" to be equivalent.
467    </t></list>
468</t>
469<t>
470   A "use" of a validator is either when a client generates a request
471   and includes the validator in a validating header field, or when a
472   server compares two validators.
473</t>
474<t>
475   Strong validators are usable in any context. Weak validators are only
476   usable in contexts that do not depend on exact equality of an entity.
477   For example, either kind is usable for a conditional GET of a full
478   entity. However, only a strong validator is usable for a sub-range
479   retrieval, since otherwise the client might end up with an internally
480   inconsistent entity.
481</t>
482<t>
483   Clients MUST NOT use weak validators in range requests (<xref target="Part5"/>).
484</t>
485<t>
486   The only function that HTTP/1.1 defines on validators is
487   comparison. There are two validator comparison functions, depending
488   on whether the comparison context allows the use of weak validators
489   or not:
490  <list style="symbols">
491     <t>The strong comparison function: in order to be considered equal,
492        both opaque-tags MUST be identical character-by-character, and both
493        MUST NOT be weak.</t>
494     <t>The weak comparison function: in order to be considered equal, both
495        opaque-tags MUST be identical character-by-character, but
496        either or both of them MAY be tagged as "weak" without affecting
497        the result.</t>
498  </list>
499</t>
500<t>
501   The example below shows the results for a set of entity tag pairs,
502   and both the weak and strong comparison function results:
503</t>
504<texttable align="left">
505  <ttcol>ETag 1</ttcol>
506  <ttcol>ETag 2</ttcol>
507  <ttcol>Strong Comparison</ttcol>
508  <ttcol>Weak Comparison</ttcol>
509
510  <c>W/"1"</c>
511  <c>W/"1"</c>
512  <c>no match</c>
513  <c>match</c>
514 
515  <c>W/"1"</c>
516  <c>W/"2"</c>
517  <c>no match</c>
518  <c>no match</c>
519
520  <c>W/"1"</c>
521  <c>"1"</c>
522  <c>no match</c>
523  <c>match</c>
524
525  <c>"1"</c>
526  <c>"1"</c>
527  <c>match</c>
528  <c>match</c>
529</texttable>
530<t>
531   An entity tag is strong unless it is explicitly tagged as weak.
532   <xref target="entity.tags"/> gives the syntax for entity tags.
533</t>
534<t>
535   A Last-Modified time, when used as a validator in a request, is
536   implicitly weak unless it is possible to deduce that it is strong,
537   using the following rules:
538  <list style="symbols">
539     <t>The validator is being compared by an origin server to the
540        actual current validator for the entity and,</t>
541     <t>That origin server reliably knows that the associated entity did
542        not change twice during the second covered by the presented
543        validator.</t>
544  </list>
545</t>
546<t>
547   or
548  <list style="symbols">
549     <t>The validator is about to be used by a client in an If-Modified-Since
550        or If-Unmodified-Since header, because the client
551        has a cache entry for the associated entity, and</t>
552     <t>That cache entry includes a Date value, which gives the time
553        when the origin server sent the original response, and</t>
554     <t>The presented Last-Modified time is at least 60 seconds before
555        the Date value.</t>
556  </list>
557</t>
558<t>
559   or
560  <list style="symbols">
561     <t>The validator is being compared by an intermediate cache to the
562        validator stored in its cache entry for the entity, and</t>
563     <t>That cache entry includes a Date value, which gives the time
564        when the origin server sent the original response, and</t>
565     <t>The presented Last-Modified time is at least 60 seconds before
566        the Date value.</t>
567  </list>
568</t>
569<t>
570   This method relies on the fact that if two different responses were
571   sent by the origin server during the same second, but both had the
572   same Last-Modified time, then at least one of those responses would
573   have a Date value equal to its Last-Modified time. The arbitrary 60-second
574   limit guards against the possibility that the Date and Last-Modified
575   values are generated from different clocks, or at somewhat
576   different times during the preparation of the response. An
577   implementation MAY use a value larger than 60 seconds, if it is
578   believed that 60 seconds is too short.
579</t>
580<t>
581   If a client wishes to perform a sub-range retrieval on a value for
582   which it has only a Last-Modified time and no opaque validator, it
583   MAY do this only if the Last-Modified time is strong in the sense
584   described here.
585</t>
586<t>
587   A cache or origin server receiving a conditional range request
588   (<xref target="Part5"/>) MUST use the strong comparison function to
589   evaluate the condition.
590</t>
591<t>
592   These rules allow HTTP/1.1 caches and clients to safely perform sub-range
593   retrievals on values that have been obtained from HTTP/1.0
594   servers.
595</t>
596</section>
597
598<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">
599<t>
600   We adopt a set of rules and recommendations for origin servers,
601   clients, and caches regarding when various validator types ought to
602   be used, and for what purposes.
603</t>
604<t>
605   HTTP/1.1 origin servers:
606  <list style="symbols">
607     <t>SHOULD send an entity tag validator unless it is not feasible to
608        generate one.</t>
609
610     <t>MAY send a weak entity tag instead of a strong entity tag, if
611        performance considerations support the use of weak entity tags,
612        or if it is unfeasible to send a strong entity tag.</t>
613
614     <t>SHOULD send a Last-Modified value if it is feasible to send one,
615        unless the risk of a breakdown in semantic transparency that
616        could result from using this date in an If-Modified-Since header
617        would lead to serious problems.</t>
618  </list>
619</t>
620<t>
621   In other words, the preferred behavior for an HTTP/1.1 origin server
622   is to send both a strong entity tag and a Last-Modified value.
623</t>
624<t>
625   In order to be legal, a strong entity tag MUST change whenever the
626   associated entity changes in any way. A weak entity tag SHOULD
627   change whenever the associated entity changes in a semantically
628   significant way.
629</t>
630<t><list>
631  <t>
632    Note: In order to provide semantically transparent caching, an
633    origin server must avoid reusing a specific strong entity tag
634    value for two different entities, or reusing a specific weak
635    entity tag value for two semantically different entities. Cache
636    entries might persist for arbitrarily long periods, regardless of
637    expiration times, so it might be inappropriate to expect that a
638    cache will never again attempt to validate an entry using a
639    validator that it obtained at some point in the past.
640  </t>
641</list></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 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 should 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 will 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
697<section title="Header Field Definitions" anchor="header.fields">
698<t>
699   This section defines the syntax and semantics of HTTP/1.1 header fields
700   related to conditional requests.
701</t>
702<t>
703   For entity-header fields, both sender and recipient refer to either the
704   client or the server, depending on who sends and who receives the entity.
705</t>
706
707<section title="ETag" anchor="header.etag">
708  <iref primary="true" item="ETag header"/>
709  <iref primary="true" item="Headers" subitem="ETag"/>
710 
711 
712<t>
713   The "ETag" response-header field provides the current value of the
714   entity tag (see <xref target="entity.tags"/>) for the requested variant,
715   which may be used for comparison with other entities from the same resource
716   (see <xref target="weak.and.strong.validators"/>).
717</t>
718<figure><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="ETag-v"/><artwork type="abnf2616"><![CDATA[
719  ETag   = "ETag" ":" OWS ETag-v
720  ETag-v = entity-tag
721]]></artwork></figure>
722<figure><preamble>
723  Examples:
724</preamble>
725<artwork type="example"><![CDATA[
726  ETag: "xyzzy"
727  ETag: W/"xyzzy"
728  ETag: ""
729]]></artwork></figure>
730<t>
731   The ETag response-header field value, an entity tag, provides for an
732   "opaque" cache validator. This might allow more reliable validation
733   in situations where it is inconvenient to store modification dates,
734   where the one-second resolution of HTTP date values is not
735   sufficient, or where the origin server wishes to avoid certain
736   paradoxes that might arise from the use of modification dates.
737</t>
738<t>
739   The principle behind entity tags is that only the service author
740   knows the semantics of a resource well enough to select an
741   appropriate cache validation mechanism, and the specification of any
742   validator comparison function more complex than byte-equality would
743   open up a can of worms. Thus, comparisons of any other headers
744   (except Last-Modified, for compatibility with HTTP/1.0) are never
745   used for purposes of validating a cache entry.
746</t>
747</section>
748
749<section title="If-Match" anchor="header.if-match">
750  <iref primary="true" item="If-Match header"/>
751  <iref primary="true" item="Headers" subitem="If-Match"/>
752 
753 
754<t>
755   The "If-Match" request-header field is used to make a request method
756   conditional. A client that has one or more entities previously
757   obtained from the resource can verify that one of those entities is
758   current by including a list of their associated entity tags in the
759   If-Match header field.
760</t>
761<t>
762   This allows efficient updates of cached information with a minimum amount of
763   transaction overhead. It is also used when updating resources, to prevent
764   inadvertent modification of the wrong version of a resource. As a special
765   case, the value "*" matches any current entity of the resource.
766</t>
767<figure><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/><artwork type="abnf2616"><![CDATA[
768  If-Match   = "If-Match" ":" OWS If-Match-v
769  If-Match-v = "*" / 1#entity-tag
770]]></artwork></figure>
771<t>
772   If any of the entity tags match the entity tag of the entity that
773   would have been returned in the response to a similar GET request
774   (without the If-Match header) on that resource, or if "*" is given
775   and any current entity exists for that resource, then the server MAY
776   perform the requested method as if the If-Match header field did not
777   exist.
778</t>
779<t>
780   If none of the entity tags match, or if "*" is given and no current
781   entity exists, the server MUST NOT perform the requested method, and
782   MUST return a 412 (Precondition Failed) response. This behavior is
783   most useful when the client wants to prevent an updating method, such
784   as PUT, from modifying a resource that has changed since the client
785   last retrieved it.
786</t>
787<t>
788   If the request would, without the If-Match header field, result in
789   anything other than a 2xx or 412 status, then the If-Match header
790   MUST be ignored.
791</t>
792<t>
793   The meaning of "If-Match: *" is that the method SHOULD be performed
794   if the representation selected by the origin server (or by a cache,
795   possibly using the Vary mechanism, see Section 3.5 of <xref target="Part6"/>) exists, and
796   MUST NOT be performed if the representation does not exist.
797</t>
798<t>
799   A request intended to update a resource (e.g., a PUT) MAY include an
800   If-Match header field to signal that the request method MUST NOT be
801   applied if the entity corresponding to the If-Match value (a single
802   entity tag) is no longer a representation of that resource. This
803   allows the user to indicate that they do not wish the request to be
804   successful if the resource has been changed without their knowledge.
805   Examples:
806</t>
807<figure><artwork type="example"><![CDATA[
808  If-Match: "xyzzy"
809  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
810  If-Match: *
811]]></artwork></figure>
812<t>
813   The result of a request having both an If-Match header field and
814   either an If-None-Match or an If-Modified-Since header fields is
815   undefined by this specification.
816</t>
817</section>
818
819<section title="If-Modified-Since" anchor="header.if-modified-since">
820  <iref primary="true" item="If-Modified-Since header"/>
821  <iref primary="true" item="Headers" subitem="If-Modified-Since"/>
822 
823 
824<t>
825   The "If-Modified-Since" request-header field is used to make a request
826   method conditional: if the requested variant has not been modified since the
827   time specified in this field, the server will not return an entity; instead,
828   a 304 (Not Modified) response will be returned.
829</t>
830<figure><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/><artwork type="abnf2616"><![CDATA[
831  If-Modified-Since   = "If-Modified-Since" ":" OWS
832                        If-Modified-Since-v
833  If-Modified-Since-v = HTTP-date
834]]></artwork></figure>
835<t>
836   An example of the field is:
837</t>
838<figure><artwork type="example"><![CDATA[
839  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
840]]></artwork></figure>
841<t>
842   A GET method with an If-Modified-Since header and no Range header
843   requests that the identified entity be transferred only if it has
844   been modified since the date given by the If-Modified-Since header.
845   The algorithm for determining this includes the following cases:
846  <list style="numbers">
847      <t>If the request would normally result in anything other than a
848         200 (OK) status, or if the passed If-Modified-Since date is
849         invalid, the response is exactly the same as for a normal GET.
850         A date which is later than the server's current time is
851         invalid.</t>
852
853      <t>If the variant has been modified since the If-Modified-Since
854         date, the response is exactly the same as for a normal GET.</t>
855
856      <t>If the variant has not been modified since a valid If-Modified-Since
857         date, the server SHOULD return a 304 (Not
858         Modified) response.</t>
859  </list>
860</t>
861<t>
862   The purpose of this feature is to allow efficient updates of cached
863   information with a minimum amount of transaction overhead.
864  <list><t>
865      Note: The Range request-header field modifies the meaning of If-Modified-Since;
866      see Section 5.4 of <xref target="Part5"/> for full details.
867    </t><t>
868      Note: If-Modified-Since times are interpreted by the server, whose
869      clock might not be synchronized with the client.
870    </t><t>
871      Note: When handling an If-Modified-Since header field, some
872      servers will use an exact date comparison function, rather than a
873      less-than function, for deciding whether to send a 304 (Not
874      Modified) response. To get best results when sending an If-Modified-Since
875      header field for cache validation, clients are
876      advised to use the exact date string received in a previous Last-Modified
877      header field whenever possible.
878    </t><t>
879      Note: If a client uses an arbitrary date in the If-Modified-Since
880      header instead of a date taken from the Last-Modified header for
881      the same request, the client should be aware of the fact that this
882      date is interpreted in the server's understanding of time. The
883      client should consider unsynchronized clocks and rounding problems
884      due to the different encodings of time between the client and
885      server. This includes the possibility of race conditions if the
886      document has changed between the time it was first requested and
887      the If-Modified-Since date of a subsequent request, and the
888      possibility of clock-skew-related problems if the If-Modified-Since
889      date is derived from the client's clock without correction
890      to the server's clock. Corrections for different time bases
891      between client and server are at best approximate due to network
892      latency.
893    </t>
894  </list>
895</t>
896<t>
897   The result of a request having both an If-Modified-Since header field
898   and either an If-Match or an If-Unmodified-Since header fields is
899   undefined by this specification.
900</t>
901</section>
902
903<section title="If-None-Match" anchor="header.if-none-match">
904  <iref primary="true" item="If-None-Match header"/>
905  <iref primary="true" item="Headers" subitem="If-None-Match"/>
906 
907 
908<t>
909   The "If-None-Match" request-header field is used to make a request method
910   conditional. A client that has one or more entities previously
911   obtained from the resource can verify that none of those entities is
912   current by including a list of their associated entity tags in the
913   If-None-Match header field.
914</t>
915<t>
916   This allows efficient updates of cached information with a minimum amount of
917   transaction overhead. It is also used to prevent a method (e.g., PUT)
918   from inadvertently modifying an existing resource when the client
919   believes that the resource does not exist.
920</t>
921<t>
922   As a special case, the value "*" matches any current entity of the
923   resource.
924</t>
925<figure><iref primary="true" item="Grammar" subitem="If-None-Match"/><iref primary="true" item="Grammar" subitem="If-None-Match-v"/><artwork type="abnf2616"><![CDATA[
926  If-None-Match   = "If-None-Match" ":" OWS If-None-Match-v
927  If-None-Match-v = "*" / 1#entity-tag
928]]></artwork></figure>
929<t>
930   If any of the entity tags match the entity tag of the entity that
931   would have been returned in the response to a similar GET request
932   (without the If-None-Match header) on that resource, or if "*" is
933   given and any current entity exists for that resource, then the
934   server MUST NOT perform the requested method, unless required to do
935   so because the resource's modification date fails to match that
936   supplied in an If-Modified-Since header field in the request.
937   Instead, if the request method was GET or HEAD, the server SHOULD
938   respond with a 304 (Not Modified) response, including the cache-related
939   header fields (particularly ETag) of one of the entities that
940   matched. For all other request methods, the server MUST respond with
941   a status of 412 (Precondition Failed).
942</t>
943<t>
944   If none of the entity tags match, then the server MAY perform the
945   requested method as if the If-None-Match header field did not exist,
946   but MUST also ignore any If-Modified-Since header field(s) in the
947   request. That is, if no entity tags match, then the server MUST NOT
948   return a 304 (Not Modified) response.
949</t>
950<t>
951   If the request would, without the If-None-Match header field, result
952   in anything other than a 2xx or 304 status, then the If-None-Match
953   header MUST be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
954   server behavior when both If-Modified-Since and If-None-Match appear
955   in the same request.)
956</t>
957<t>
958   The meaning of "If-None-Match: *" is that the method MUST NOT be
959   performed if the representation selected by the origin server (or by
960   a cache, possibly using the Vary mechanism, see Section 3.5 of <xref target="Part6"/>)
961   exists, and SHOULD be performed if the representation does not exist.
962   This feature is intended to be useful in preventing races between PUT
963   operations.
964</t>
965<t>
966   Examples:
967</t>
968<figure><artwork type="example"><![CDATA[
969  If-None-Match: "xyzzy"
970  If-None-Match: W/"xyzzy"
971  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
972  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
973  If-None-Match: *
974]]></artwork></figure>
975<t>
976   The result of a request having both an If-None-Match header field and
977   either an If-Match or an If-Unmodified-Since header fields is
978   undefined by this specification.
979</t>
980</section>
981
982<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
983  <iref primary="true" item="If-Unmodified-Since header"/>
984  <iref primary="true" item="Headers" subitem="If-Unmodified-Since"/>
985 
986 
987<t>
988   The "If-Unmodified-Since" request-header field is used to make a request
989   method conditional. If the requested resource has not been modified
990   since the time specified in this field, the server SHOULD perform the
991   requested operation as if the If-Unmodified-Since header were not
992   present.
993</t>
994<t>
995   If the requested variant has been modified since the specified time,
996   the server MUST NOT perform the requested operation, and MUST return
997   a 412 (Precondition Failed).
998</t>
999<figure><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/><iref primary="true" item="Grammar" subitem="If-Unmodified-Since-v"/><artwork type="abnf2616"><![CDATA[
1000  If-Unmodified-Since   = "If-Unmodified-Since" ":" OWS
1001                          If-Unmodified-Since-v
1002  If-Unmodified-Since-v = HTTP-date
1003]]></artwork></figure>
1004<t>
1005   An example of the field is:
1006</t>
1007<figure><artwork type="example"><![CDATA[
1008  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
1009]]></artwork></figure>
1010<t>
1011   If the request normally (i.e., without the If-Unmodified-Since
1012   header) would result in anything other than a 2xx or 412 status, the
1013   If-Unmodified-Since header SHOULD be ignored.
1014</t>
1015<t>
1016   If the specified date is invalid, the header is ignored.
1017</t>
1018<t>
1019   The result of a request having both an If-Unmodified-Since header
1020   field and either an If-None-Match or an If-Modified-Since header
1021   fields is undefined by this specification.
1022</t>
1023</section>
1024
1025<section title="Last-Modified" anchor="header.last-modified">
1026  <iref primary="true" item="Last-Modified header"/>
1027  <iref primary="true" item="Headers" subitem="Last-Modified"/>
1028 
1029 
1030<t>
1031   The "Last-Modified" entity-header field indicates the date and time at
1032   which the origin server believes the variant was last modified.
1033</t>
1034<figure><iref primary="true" item="Grammar" subitem="Last-Modified"/><iref primary="true" item="Grammar" subitem="Last-Modified-v"/><artwork type="abnf2616"><![CDATA[
1035  Last-Modified   = "Last-Modified" ":" OWS Last-Modified-v
1036  Last-Modified-v = HTTP-date
1037]]></artwork></figure>
1038<t>
1039   An example of its use is
1040</t>
1041<figure><artwork type="example"><![CDATA[
1042  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
1043]]></artwork></figure>
1044<t>
1045   The exact meaning of this header field depends on the implementation
1046   of the origin server and the nature of the original resource. For
1047   files, it may be just the file system last-modified time. For
1048   entities with dynamically included parts, it may be the most recent
1049   of the set of last-modify times for its component parts. For database
1050   gateways, it may be the last-update time stamp of the record. For
1051   virtual objects, it may be the last time the internal state changed.
1052</t>
1053<t>
1054   An origin server MUST NOT send a Last-Modified date which is later
1055   than the server's time of message origination. In such cases, where
1056   the resource's last modification would indicate some time in the
1057   future, the server MUST replace that date with the message
1058   origination date.
1059</t>
1060<t>
1061   An origin server SHOULD obtain the Last-Modified value of the entity
1062   as close as possible to the time that it generates the Date value of
1063   its response. This allows a recipient to make an accurate assessment
1064   of the entity's modification time, especially if the entity changes
1065   near the time that the response is generated.
1066</t>
1067<t>
1068   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
1069</t>
1070<t>
1071   The Last-Modified entity-header field value is often used as a cache
1072   validator. In simple terms, a cache entry is considered to be valid
1073   if the entity has not been modified since the Last-Modified value.
1074</t>
1075</section>
1076
1077</section>
1078
1079<section title="IANA Considerations" anchor="IANA.considerations">
1080
1081<section title="Status Code Registration" anchor="status.code.registration">
1082<t>
1083   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
1084   should be updated with the registrations below:
1085</t>
1086
1087<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
1088<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
1089   <ttcol>Value</ttcol>
1090   <ttcol>Description</ttcol>
1091   <ttcol>Reference</ttcol>
1092   <c>304</c>
1093   <c>Not Modified</c>
1094   <c>
1095      <xref target="status.304"/>
1096   </c>
1097   <c>412</c>
1098   <c>Precondition Failed</c>
1099   <c>
1100      <xref target="status.412"/>
1101   </c>
1102</texttable>
1103<!--(END)-->
1104
1105</section>
1106
1107<section title="Message Header Registration" anchor="message.header.registration">
1108<t>
1109   The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated
1110   with the permanent registrations below (see <xref target="RFC3864"/>):
1111</t>
1112
1113<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
1114<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
1115   <ttcol>Header Field Name</ttcol>
1116   <ttcol>Protocol</ttcol>
1117   <ttcol>Status</ttcol>
1118   <ttcol>Reference</ttcol>
1119
1120   <c>ETag</c>
1121   <c>http</c>
1122   <c>standard</c>
1123   <c>
1124      <xref target="header.etag"/>
1125   </c>
1126   <c>If-Match</c>
1127   <c>http</c>
1128   <c>standard</c>
1129   <c>
1130      <xref target="header.if-match"/>
1131   </c>
1132   <c>If-Modified-Since</c>
1133   <c>http</c>
1134   <c>standard</c>
1135   <c>
1136      <xref target="header.if-modified-since"/>
1137   </c>
1138   <c>If-None-Match</c>
1139   <c>http</c>
1140   <c>standard</c>
1141   <c>
1142      <xref target="header.if-none-match"/>
1143   </c>
1144   <c>If-Unmodified-Since</c>
1145   <c>http</c>
1146   <c>standard</c>
1147   <c>
1148      <xref target="header.if-unmodified-since"/>
1149   </c>
1150   <c>Last-Modified</c>
1151   <c>http</c>
1152   <c>standard</c>
1153   <c>
1154      <xref target="header.last-modified"/>
1155   </c>
1156</texttable>
1157<!--(END)-->
1158
1159<t>
1160   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
1161</t>
1162</section>
1163</section>
1164
1165<section title="Security Considerations" anchor="security.considerations">
1166<t>
1167   No additional security considerations have been identified beyond
1168   those applicable to HTTP in general <xref target="Part1"/>.
1169</t>
1170</section>
1171
1172<section title="Acknowledgments" anchor="ack">
1173</section>
1174</middle>
1175<back>
1176
1177<references title="Normative References">
1178
1179<reference anchor="Part1">
1180  <front>
1181    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
1182    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1183      <organization abbrev="Day Software">Day Software</organization>
1184      <address><email>fielding@gbiv.com</email></address>
1185    </author>
1186    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1187      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1188      <address><email>jg@freedesktop.org</email></address>
1189    </author>
1190    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1191      <organization abbrev="HP">Hewlett-Packard Company</organization>
1192      <address><email>JeffMogul@acm.org</email></address>
1193    </author>
1194    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1195      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1196      <address><email>henrikn@microsoft.com</email></address>
1197    </author>
1198    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1199      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1200      <address><email>LMM@acm.org</email></address>
1201    </author>
1202    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1203      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1204      <address><email>paulle@microsoft.com</email></address>
1205    </author>
1206    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1207      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1208      <address><email>timbl@w3.org</email></address>
1209    </author>
1210    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1211      <organization abbrev="W3C">World Wide Web Consortium</organization>
1212      <address><email>ylafon@w3.org</email></address>
1213    </author>
1214    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1215      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1216      <address><email>julian.reschke@greenbytes.de</email></address>
1217    </author>
1218    <date month="July" year="2010"/>
1219  </front>
1220  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-10"/>
1221 
1222</reference>
1223
1224<reference anchor="Part3">
1225  <front>
1226    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
1227    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1228      <organization abbrev="Day Software">Day Software</organization>
1229      <address><email>fielding@gbiv.com</email></address>
1230    </author>
1231    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1232      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1233      <address><email>jg@freedesktop.org</email></address>
1234    </author>
1235    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1236      <organization abbrev="HP">Hewlett-Packard Company</organization>
1237      <address><email>JeffMogul@acm.org</email></address>
1238    </author>
1239    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1240      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1241      <address><email>henrikn@microsoft.com</email></address>
1242    </author>
1243    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1244      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1245      <address><email>LMM@acm.org</email></address>
1246    </author>
1247    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1248      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1249      <address><email>paulle@microsoft.com</email></address>
1250    </author>
1251    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1252      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1253      <address><email>timbl@w3.org</email></address>
1254    </author>
1255    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1256      <organization abbrev="W3C">World Wide Web Consortium</organization>
1257      <address><email>ylafon@w3.org</email></address>
1258    </author>
1259    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1260      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1261      <address><email>julian.reschke@greenbytes.de</email></address>
1262    </author>
1263    <date month="July" year="2010"/>
1264  </front>
1265  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-10"/>
1266 
1267</reference>
1268
1269<reference anchor="Part5">
1270  <front>
1271    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
1272    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1273      <organization abbrev="Day Software">Day Software</organization>
1274      <address><email>fielding@gbiv.com</email></address>
1275    </author>
1276    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1277      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1278      <address><email>jg@freedesktop.org</email></address>
1279    </author>
1280    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1281      <organization abbrev="HP">Hewlett-Packard Company</organization>
1282      <address><email>JeffMogul@acm.org</email></address>
1283    </author>
1284    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1285      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1286      <address><email>henrikn@microsoft.com</email></address>
1287    </author>
1288    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1289      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1290      <address><email>LMM@acm.org</email></address>
1291    </author>
1292    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1293      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1294      <address><email>paulle@microsoft.com</email></address>
1295    </author>
1296    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1297      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1298      <address><email>timbl@w3.org</email></address>
1299    </author>
1300    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1301      <organization abbrev="W3C">World Wide Web Consortium</organization>
1302      <address><email>ylafon@w3.org</email></address>
1303    </author>
1304    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1305      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1306      <address><email>julian.reschke@greenbytes.de</email></address>
1307    </author>
1308    <date month="July" year="2010"/>
1309  </front>
1310  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-10"/>
1311 
1312</reference>
1313
1314<reference anchor="Part6">
1315  <front>
1316    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
1317    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1318      <organization abbrev="Day Software">Day Software</organization>
1319      <address><email>fielding@gbiv.com</email></address>
1320    </author>
1321    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1322      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1323      <address><email>jg@freedesktop.org</email></address>
1324    </author>
1325    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1326      <organization abbrev="HP">Hewlett-Packard Company</organization>
1327      <address><email>JeffMogul@acm.org</email></address>
1328    </author>
1329    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1330      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1331      <address><email>henrikn@microsoft.com</email></address>
1332    </author>
1333    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1334      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1335      <address><email>LMM@acm.org</email></address>
1336    </author>
1337    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1338      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1339      <address><email>paulle@microsoft.com</email></address>
1340    </author>
1341    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1342      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1343      <address><email>timbl@w3.org</email></address>
1344    </author>
1345    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1346      <organization abbrev="W3C">World Wide Web Consortium</organization>
1347      <address><email>ylafon@w3.org</email></address>
1348    </author>
1349    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1350      <address><email>mnot@mnot.net</email></address>
1351    </author>
1352    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1353      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1354      <address><email>julian.reschke@greenbytes.de</email></address>
1355    </author>
1356    <date month="July" year="2010"/>
1357  </front>
1358  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-10"/>
1359 
1360</reference>
1361
1362<reference anchor="RFC2119">
1363  <front>
1364    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1365    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1366      <organization>Harvard University</organization>
1367      <address><email>sob@harvard.edu</email></address>
1368    </author>
1369    <date month="March" year="1997"/>
1370  </front>
1371  <seriesInfo name="BCP" value="14"/>
1372  <seriesInfo name="RFC" value="2119"/>
1373</reference>
1374
1375<reference anchor="RFC5234">
1376  <front>
1377    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1378    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1379      <organization>Brandenburg InternetWorking</organization>
1380      <address>
1381        <email>dcrocker@bbiw.net</email>
1382      </address> 
1383    </author>
1384    <author initials="P." surname="Overell" fullname="Paul Overell">
1385      <organization>THUS plc.</organization>
1386      <address>
1387        <email>paul.overell@thus.net</email>
1388      </address>
1389    </author>
1390    <date month="January" year="2008"/>
1391  </front>
1392  <seriesInfo name="STD" value="68"/>
1393  <seriesInfo name="RFC" value="5234"/>
1394</reference>
1395
1396</references>
1397
1398<references title="Informative References">
1399
1400<reference anchor="RFC2616">
1401  <front>
1402    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1403    <author initials="R." surname="Fielding" fullname="R. Fielding">
1404      <organization>University of California, Irvine</organization>
1405      <address><email>fielding@ics.uci.edu</email></address>
1406    </author>
1407    <author initials="J." surname="Gettys" fullname="J. Gettys">
1408      <organization>W3C</organization>
1409      <address><email>jg@w3.org</email></address>
1410    </author>
1411    <author initials="J." surname="Mogul" fullname="J. Mogul">
1412      <organization>Compaq Computer Corporation</organization>
1413      <address><email>mogul@wrl.dec.com</email></address>
1414    </author>
1415    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1416      <organization>MIT Laboratory for Computer Science</organization>
1417      <address><email>frystyk@w3.org</email></address>
1418    </author>
1419    <author initials="L." surname="Masinter" fullname="L. Masinter">
1420      <organization>Xerox Corporation</organization>
1421      <address><email>masinter@parc.xerox.com</email></address>
1422    </author>
1423    <author initials="P." surname="Leach" fullname="P. Leach">
1424      <organization>Microsoft Corporation</organization>
1425      <address><email>paulle@microsoft.com</email></address>
1426    </author>
1427    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1428      <organization>W3C</organization>
1429      <address><email>timbl@w3.org</email></address>
1430    </author>
1431    <date month="June" year="1999"/>
1432  </front>
1433  <seriesInfo name="RFC" value="2616"/>
1434</reference>
1435
1436<reference anchor="RFC3864">
1437  <front>
1438    <title>Registration Procedures for Message Header Fields</title>
1439    <author initials="G." surname="Klyne" fullname="G. Klyne">
1440      <organization>Nine by Nine</organization>
1441      <address><email>GK-IETF@ninebynine.org</email></address>
1442    </author>
1443    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
1444      <organization>BEA Systems</organization>
1445      <address><email>mnot@pobox.com</email></address>
1446    </author>
1447    <author initials="J." surname="Mogul" fullname="J. Mogul">
1448      <organization>HP Labs</organization>
1449      <address><email>JeffMogul@acm.org</email></address>
1450    </author>
1451    <date year="2004" month="September"/>
1452  </front>
1453  <seriesInfo name="BCP" value="90"/>
1454  <seriesInfo name="RFC" value="3864"/>
1455</reference>
1456
1457</references>
1458
1459<section title="Compatibility with Previous Versions" anchor="compatibility">
1460
1461<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1462<t>
1463  Allow weak entity tags in all requests except range requests (Sections
1464  <xref target="weak.and.strong.validators" format="counter"/> and
1465  <xref target="header.if-none-match" format="counter"/>).
1466</t>
1467</section>
1468
1469</section>
1470
1471
1472<section title="Collected ABNF" anchor="collected.abnf">
1473<figure>
1474<artwork type="abnf" name="p4-conditional.parsed-abnf"><![CDATA[
1475ETag = "ETag:" OWS ETag-v
1476ETag-v = entity-tag
1477
1478HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
1479
1480If-Match = "If-Match:" OWS If-Match-v
1481If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1482 entity-tag ] ) )
1483If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v
1484If-Modified-Since-v = HTTP-date
1485If-None-Match = "If-None-Match:" OWS If-None-Match-v
1486If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1487 entity-tag ] ) )
1488If-Unmodified-Since = "If-Unmodified-Since:" OWS
1489 If-Unmodified-Since-v
1490If-Unmodified-Since-v = HTTP-date
1491
1492Last-Modified = "Last-Modified:" OWS Last-Modified-v
1493Last-Modified-v = HTTP-date
1494
1495OWS = <OWS, defined in [Part1], Section 1.2.2>
1496
1497entity-tag = [ weak ] opaque-tag
1498
1499opaque-tag = quoted-string
1500
1501quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
1502
1503weak = %x57.2F ; W/
1504]]></artwork>
1505</figure>
1506<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
1507; ETag defined but not used
1508; If-Match defined but not used
1509; If-Modified-Since defined but not used
1510; If-None-Match defined but not used
1511; If-Unmodified-Since defined but not used
1512; Last-Modified defined but not used
1513]]></artwork></figure></section>
1514
1515
1516<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
1517
1518<section title="Since RFC2616">
1519<t>
1520  Extracted relevant partitions from <xref target="RFC2616"/>.
1521</t>
1522</section>
1523
1524<section title="Since draft-ietf-httpbis-p4-conditional-00">
1525<t>
1526  Closed issues:
1527  <list style="symbols"> 
1528    <t>
1529      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
1530      "Normative and Informative references"
1531    </t>
1532  </list>
1533</t>
1534<t>
1535  Other changes:
1536  <list style="symbols"> 
1537    <t>
1538      Move definitions of 304 and 412 condition codes from Part2.
1539    </t>
1540  </list>
1541</t>
1542</section>
1543
1544<section title="Since draft-ietf-httpbis-p4-conditional-01">
1545<t>
1546  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1547  <list style="symbols"> 
1548    <t>
1549      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1550    </t>
1551  </list>
1552</t>
1553</section>
1554
1555<section title="Since draft-ietf-httpbis-p4-conditional-02" anchor="changes.since.02">
1556<t>
1557  Closed issues:
1558  <list style="symbols"> 
1559    <t>
1560      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/116"/>:
1561      "Weak ETags on non-GET requests"
1562    </t>
1563  </list>
1564</t>
1565<t>
1566  Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
1567  <list style="symbols"> 
1568    <t>
1569      Reference RFC 3984, and update header registrations for headers defined
1570      in this document.
1571    </t>
1572  </list>
1573</t>
1574</section>
1575
1576<section title="Since draft-ietf-httpbis-p4-conditional-03" anchor="changes.since.03">
1577<t>
1578  Closed issues:
1579  <list style="symbols"> 
1580    <t>
1581      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/71"/>:
1582      "Examples for ETag matching"
1583    </t>
1584    <t>
1585      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/124"/>:
1586      "'entity value' undefined"
1587    </t>
1588    <t>
1589      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/126"/>:
1590      "bogus 2068 Date header reference"
1591    </t>
1592  </list>
1593</t>
1594</section>
1595
1596<section title="Since draft-ietf-httpbis-p4-conditional-04" anchor="changes.since.04">
1597<t>
1598  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1599  <list style="symbols"> 
1600    <t>
1601      Use "/" instead of "|" for alternatives.
1602    </t>
1603    <t>
1604      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1605      whitespace ("OWS") and required whitespace ("RWS").
1606    </t>
1607    <t>
1608      Rewrite ABNFs to spell out whitespace rules, factor out
1609      header value format definitions.
1610    </t>
1611  </list>
1612</t>
1613</section>
1614
1615<section title="Since draft-ietf-httpbis-p4-conditional-05" anchor="changes.since.05">
1616<t>
1617  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1618  <list style="symbols"> 
1619    <t>
1620      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
1621    </t>
1622  </list>
1623</t>
1624</section>
1625
1626<section title="Since draft-ietf-httpbis-p4-conditional-06" anchor="changes.since.06">
1627<t>
1628  Closed issues:
1629  <list style="symbols"> 
1630    <t>
1631      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/153"/>:
1632      "case-sensitivity of etag weakness indicator"
1633    </t>
1634  </list>
1635</t>
1636</section>
1637
1638<section title="Since draft-ietf-httpbis-p4-conditional-07" anchor="changes.since.07">
1639<t>
1640  Closed issues:
1641  <list style="symbols"> 
1642    <t>
1643      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/116"/>:
1644      "Weak ETags on non-GET requests" (If-Match still was defined to require
1645      strong matching)
1646    </t>
1647    <t>
1648      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>:
1649      "move IANA registrations for optional status codes"
1650    </t>
1651  </list>
1652</t>
1653</section>
1654
1655<section title="Since draft-ietf-httpbis-p4-conditional-08" anchor="changes.since.08">
1656<t>
1657  No significant changes.
1658</t>
1659</section>
1660
1661<section title="Since draft-ietf-httpbis-p4-conditional-09" anchor="changes.since.09">
1662<t>
1663  No significant changes.
1664</t>
1665</section>
1666
1667</section>
1668
1669</back>
1670</rfc>
Note: See TracBrowser for help on using the repository browser.