source: draft-ietf-httpbis/02/draft-ietf-httpbis-p4-conditional-02.xml @ 1391

Last change on this file since 1391 was 559, checked in by fielding@…, 11 years ago

remove executable and set eol-style for earlier drafts

  • Property svn:eol-style set to native
File size: 51.6 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<!DOCTYPE rfc
17  PUBLIC "" "rfc2629.dtd">
18<rfc obsoletes="2616" category="std" ipr="full3978" docName="draft-ietf-httpbis-p4-conditional-02">
19<front>
20
21  <title abbrev="HTTP/1.1, Part 4">HTTP/1.1, part 4: Conditional Requests</title>
22
23  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
24    <organization abbrev="Day Software">Day Software</organization>
25    <address>
26      <postal>
27        <street>23 Corporate Plaza DR, Suite 280</street>
28        <city>Newport Beach</city>
29        <region>CA</region>
30        <code>92660</code>
31        <country>USA</country>
32      </postal>
33      <phone>+1-949-706-5300</phone>
34      <facsimile>+1-949-706-5305</facsimile>
35      <email>fielding@gbiv.com</email>
36      <uri>http://roy.gbiv.com/</uri>
37    </address>
38  </author>
39
40  <author initials="J." surname="Gettys" fullname="Jim Gettys">
41    <organization>One Laptop per Child</organization>
42    <address>
43      <postal>
44        <street>21 Oak Knoll Road</street>
45        <city>Carlisle</city>
46        <region>MA</region>
47        <code>01741</code>
48        <country>USA</country>
49      </postal>
50      <email>jg@laptop.org</email>
51      <uri>http://www.laptop.org/</uri>
52    </address>
53  </author>
54 
55  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
56    <organization abbrev="HP">Hewlett-Packard Company</organization>
57    <address>
58      <postal>
59        <street>HP Labs, Large Scale Systems Group</street>
60        <street>1501 Page Mill Road, MS 1177</street>
61        <city>Palo Alto</city>
62        <region>CA</region>
63        <code>94304</code>
64        <country>USA</country>
65      </postal>
66      <email>JeffMogul@acm.org</email>
67    </address>
68  </author>
69
70  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
71    <organization abbrev="Microsoft">Microsoft Corporation</organization>
72    <address>
73      <postal>
74        <street>1 Microsoft Way</street>
75        <city>Redmond</city>
76        <region>WA</region>
77        <code>98052</code>
78        <country>USA</country>
79      </postal>
80      <email>henrikn@microsoft.com</email>
81    </address>
82  </author>
83
84  <author initials="L." surname="Masinter" fullname="Larry Masinter">
85    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
86    <address>
87      <postal>
88        <street>345 Park Ave</street>
89        <city>San Jose</city>
90        <region>CA</region>
91        <code>95110</code>
92        <country>USA</country>
93      </postal>
94      <email>LMM@acm.org</email>
95      <uri>http://larry.masinter.net/</uri>
96    </address>
97  </author>
98 
99  <author initials="P." surname="Leach" fullname="Paul J. Leach">
100    <organization abbrev="Microsoft">Microsoft Corporation</organization>
101    <address>
102      <postal>
103        <street>1 Microsoft Way</street>
104        <city>Redmond</city>
105        <region>WA</region>
106        <code>98052</code>
107      </postal>
108      <email>paulle@microsoft.com</email>
109    </address>
110  </author>
111   
112  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
113    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
114    <address>
115      <postal>
116        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
117        <street>The Stata Center, Building 32</street>
118        <street>32 Vassar Street</street>
119        <city>Cambridge</city>
120        <region>MA</region>
121        <code>02139</code>
122        <country>USA</country>
123      </postal>
124      <email>timbl@w3.org</email>
125      <uri>http://www.w3.org/People/Berners-Lee/</uri>
126    </address>
127  </author>
128
129  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
130    <organization abbrev="W3C">World Wide Web Consortium</organization>
131    <address>
132      <postal>
133        <street>W3C / ERCIM</street>
134        <street>2004, rte des Lucioles</street>
135        <city>Sophia-Antipolis</city>
136        <region>AM</region>
137        <code>06902</code>
138        <country>France</country>
139      </postal>
140      <email>ylafon@w3.org</email>
141      <uri>http://www.raubacapeu.net/people/yves/</uri>
142    </address>
143  </author>
144
145  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
146    <organization abbrev="greenbytes">greenbytes GmbH</organization>
147    <address>
148      <postal>
149        <street>Hafenweg 16</street>
150        <city>Muenster</city><region>NW</region><code>48155</code>
151        <country>Germany</country>
152      </postal>
153      <phone>+49 251 2807760</phone>   
154      <facsimile>+49 251 2807761</facsimile>   
155      <email>julian.reschke@greenbytes.de</email>       
156      <uri>http://greenbytes.de/tech/webdav/</uri>     
157    </address>
158  </author>
159
160  <date month="February" year="2008" day="24"/>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level
165   protocol for distributed, collaborative, hypermedia information
166   systems. HTTP has been in use by the World Wide Web global information
167   initiative since 1990. This document is Part 4 of the seven-part specification
168   that defines the protocol referred to as "HTTP/1.1" and, taken together,
169   obsoletes RFC 2616.  Part 4 defines request header fields for
170   indicating conditional requests and the rules for constructing responses
171   to those requests.
172</t>
173</abstract>
174
175<note title="Editorial Note (To be removed by RFC Editor)">
176  <t>
177    Discussion of this draft should take place on the HTTPBIS working group
178    mailing list (ietf-http-wg@w3.org). The current issues list is
179    at <eref target="http://www.tools.ietf.org/wg/httpbis/trac/report/11"/>
180    and related documents (including fancy diffs) can be found at
181    <eref target="http://www.tools.ietf.org/wg/httpbis/"/>.
182  </t>
183  <t>
184    This draft incorporates those issue resolutions that were either
185    collected in the original RFC2616 errata list (<eref target="http://purl.org/NET/http-errata"/>),
186    or which were agreed upon on the mailing list between October 2006 and
187    November 2007 (as published in "draft-lafon-rfc2616bis-03").
188  </t>
189</note>
190</front>
191<middle>
192<section title="Introduction" anchor="introduction">
193<t>
194   This document defines HTTP/1.1 response metadata for indicating potential
195   changes to payload content, including modification time stamps and opaque
196   entity-tags, and the HTTP conditional request mechanisms that allow
197   preconditions to be placed on a request method.  Conditional GET requests
198   allow for efficient cache updates.  Other conditional request methods are
199   used to protect against overwriting or misunderstanding the state of a
200   resource that has been changed unbeknownst to the requesting client.
201</t>
202<t>
203   This document is currently disorganized in order to minimize the changes
204   between drafts and enable reviewers to see the smaller errata changes.
205   The next draft will reorganize the sections to better reflect the content.
206   In particular, the sections on resource metadata will be discussed first
207   and then followed by each conditional request-header, concluding with a
208   definition of precedence and the expectation of ordering strong validator
209   checks before weak validator checks.  It is likely that more content from
210   <xref target="Part6"/> will migrate to this part, where appropriate.
211   The current mess reflects how widely dispersed these topics and associated
212   requirements had become in <xref target="RFC2616"/>.
213</t>
214
215<section title="Requirements" anchor="intro.requirements">
216<t>
217   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
218   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
219   document are to be interpreted as described in <xref target="RFC2119"/>.
220</t>
221<t>
222   An implementation is not compliant if it fails to satisfy one or more
223   of the MUST or REQUIRED level requirements for the protocols it
224   implements. An implementation that satisfies all the MUST or REQUIRED
225   level and all the SHOULD level requirements for its protocols is said
226   to be "unconditionally compliant"; one that satisfies all the MUST
227   level requirements but not all the SHOULD level requirements for its
228   protocols is said to be "conditionally compliant."
229</t>
230</section>
231</section>
232
233<section title="Notational Conventions and Generic Grammar" anchor="notation">
234<t>
235  This specification uses the ABNF syntax defined in Section 2.1 of <xref target="Part1"/> and
236  the core rules defined in Section 2.2 of <xref target="Part1"/>:
237  <cref anchor="abnf.dep">ABNF syntax and basic rules will be adopted from RFC 5234, see
238  &lt;http://tools.ietf.org/wg/httpbis/trac/ticket/36&gt;.</cref>
239</t>
240<figure><artwork type="abnf2616"><![CDATA[
241  quoted-string = <quoted-string, defined in [Part1], Section 2.2>
242]]></artwork></figure>
243<t anchor="abnf.dependencies">
244  The ABNF rules below are defined in other parts:
245</t>
246<figure><!--Part1--><artwork type="abnf2616"><![CDATA[
247  HTTP-date     = <HTTP-date, defined in [Part1], Section 3.3.1>
248]]></artwork></figure>
249</section>
250
251<section title="Entity Tags" anchor="entity.tags">
252<t>
253   Entity tags are used for comparing two or more entities from the same
254   requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
255   If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
256   If-Range (Section 6.3 of <xref target="Part5"/>) header fields. The definition of how they
257   are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
258   entity tag consists of an opaque quoted string, possibly prefixed by
259   a weakness indicator.
260</t>
261<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[
262  entity-tag = [ weak ] opaque-tag
263  weak       = "W/"
264  opaque-tag = quoted-string
265]]></artwork></figure>
266<t>
267   A "strong entity tag" MAY be shared by two entities of a resource
268   only if they are equivalent by octet equality.
269</t>
270<t>
271   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
272   two entities of a resource only if the entities are equivalent and
273   could be substituted for each other with no significant change in
274   semantics. A weak entity tag can only be used for weak comparison.
275</t>
276<t>
277   An entity tag MUST be unique across all versions of all entities
278   associated with a particular resource. A given entity tag value MAY
279   be used for entities obtained by requests on different URIs. The use
280   of the same entity tag value in conjunction with entities obtained by
281   requests on different URIs does not imply the equivalence of those
282   entities.
283</t>
284</section>
285
286<section title="Status Code Definitions">
287<section title="304 Not Modified" anchor="status.304">
288  <iref primary="true" item="304 Not Modified (status code)"/>
289  <iref primary="true" item="Status Codes" subitem="304 Not Modified"/>
290<t>
291   If the client has performed a conditional GET request and access is
292   allowed, but the document has not been modified, the server SHOULD
293   respond with this status code. The 304 response MUST NOT contain a
294   message-body, and thus is always terminated by the first empty line
295   after the header fields.
296</t>
297<t>
298   The response MUST include the following header fields:
299  <list style="symbols">
300    <t>Date, unless its omission is required by Section 8.3.1 of <xref target="Part1"/></t>
301  </list>
302</t>
303<t>
304   If a clockless origin server obeys these rules, and proxies and
305   clients add their own Date to any response received without one (as
306   already specified by <xref target="RFC2068"/>, Section 14.19), caches will operate
307   correctly.
308  <list style="symbols">
309    <t>ETag and/or Content-Location, if the header would have been sent
310        in a 200 response to the same request</t>
311    <t>Expires, Cache-Control, and/or Vary, if the field-value might
312        differ from that sent in any previous response for the same
313        variant</t>
314  </list>
315</t>
316<t>
317   If the conditional GET used a strong cache validator (see <xref target="weak.and.strong.validators"/>),
318   the response SHOULD NOT  include other entity-headers.
319   Otherwise (i.e., the conditional GET used a weak validator), the
320   response MUST NOT include other entity-headers; this prevents
321   inconsistencies between cached entity-bodies and updated headers.
322</t>
323<t>
324   If a 304 response indicates an entity not currently cached, then the
325   cache MUST disregard the response and repeat the request without the
326   conditional.
327</t>
328<t>
329   If a cache uses a received 304 response to update a cache entry, the
330   cache MUST update the entry to reflect any new field values given in
331   the response.
332</t>
333</section>
334
335<section title="412 Precondition Failed" anchor="status.412">
336  <iref primary="true" item="412 Precondition Failed (status code)"/>
337  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed"/>
338<t>
339   The precondition given in one or more of the request-header fields
340   evaluated to false when it was tested on the server. This response
341   code allows the client to place preconditions on the current resource
342   metainformation (header field data) and thus prevent the requested
343   method from being applied to a resource other than the one intended.
344</t>
345</section>
346</section>
347
348<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
349<t>
350   Since both origin servers and caches will compare two validators to
351   decide if they represent the same or different entities, one normally
352   would expect that if the entity (the entity-body or any entity-headers)
353   changes in any way, then the associated validator would
354   change as well. If this is true, then we call this validator a
355   "strong validator."
356</t>
357<t>
358   However, there might be cases when a server prefers to change the
359   validator only on semantically significant changes, and not when
360   insignificant aspects of the entity change. A validator that does not
361   always change when the resource changes is a "weak validator."
362</t>
363<t>
364   Entity tags are normally "strong validators," but the protocol
365   provides a mechanism to tag an entity tag as "weak." One can think of
366   a strong validator as one that changes whenever the bits of an entity
367   changes, while a weak value changes whenever the meaning of an entity
368   changes. Alternatively, one can think of a strong validator as part
369   of an identifier for a specific entity, while a weak validator is
370   part of an identifier for a set of semantically equivalent entities.
371  <list><t>
372      Note: One example of a strong validator is an integer that is
373      incremented in stable storage every time an entity is changed.
374    </t><t>
375      An entity's modification time, if represented with one-second
376      resolution, could be a weak validator, since it is possible that
377      the resource might be modified twice during a single second.
378    </t><t>
379      Support for weak validators is optional. However, weak validators
380      allow for more efficient caching of equivalent objects; for
381      example, a hit counter on a site is probably good enough if it is
382      updated every few days or weeks, and any value during that period
383      is likely "good enough" to be equivalent.
384    </t></list>
385</t>
386<t>
387   A "use" of a validator is either when a client generates a request
388   and includes the validator in a validating header field, or when a
389   server compares two validators.
390</t>
391<t>
392   Strong validators are usable in any context. Weak validators are only
393   usable in contexts that do not depend on exact equality of an entity.
394   For example, either kind is usable for a conditional GET of a full
395   entity. However, only a strong validator is usable for a sub-range
396   retrieval, since otherwise the client might end up with an internally
397   inconsistent entity.
398</t>
399<t>
400   Clients MAY issue simple (non-subrange) GET requests with either weak
401   validators or strong validators. Clients MUST NOT use weak validators
402   in other forms of request.
403</t>
404<t>
405   The only function that HTTP/1.1 defines on validators is
406   comparison. There are two validator comparison functions, depending
407   on whether the comparison context allows the use of weak validators
408   or not:
409  <list style="symbols">
410     <t>The strong comparison function: in order to be considered equal,
411        both validators MUST be identical in every way, and both MUST NOT
412        be weak.</t>
413     <t>The weak comparison function: in order to be considered equal,
414        both validators MUST be identical in every way, but either or
415        both of them MAY be tagged as "weak" without affecting the
416        result.</t>
417  </list>
418</t>
419<t>
420   An entity tag is strong unless it is explicitly tagged as weak.
421   <xref target="entity.tags"/> gives the syntax for entity tags.
422</t>
423<t>
424   A Last-Modified time, when used as a validator in a request, is
425   implicitly weak unless it is possible to deduce that it is strong,
426   using the following rules:
427  <list style="symbols">
428     <t>The validator is being compared by an origin server to the
429        actual current validator for the entity and,</t>
430     <t>That origin server reliably knows that the associated entity did
431        not change twice during the second covered by the presented
432        validator.</t>
433  </list>
434</t>
435<t>
436   or
437  <list style="symbols">
438     <t>The validator is about to be used by a client in an If-Modified-Since
439        or If-Unmodified-Since header, because the client
440        has a cache entry for the associated entity, and</t>
441     <t>That cache entry includes a Date value, which gives the time
442        when the origin server sent the original response, and</t>
443     <t>The presented Last-Modified time is at least 60 seconds before
444        the Date value.</t>
445  </list>
446</t>
447<t>
448   or
449  <list style="symbols">
450     <t>The validator is being compared by an intermediate cache to the
451        validator stored in its cache entry for the entity, and</t>
452     <t>That cache entry includes a Date value, which gives the time
453        when the origin server sent the original response, and</t>
454     <t>The presented Last-Modified time is at least 60 seconds before
455        the Date value.</t>
456  </list>
457</t>
458<t>
459   This method relies on the fact that if two different responses were
460   sent by the origin server during the same second, but both had the
461   same Last-Modified time, then at least one of those responses would
462   have a Date value equal to its Last-Modified time. The arbitrary 60-second
463   limit guards against the possibility that the Date and Last-Modified
464   values are generated from different clocks, or at somewhat
465   different times during the preparation of the response. An
466   implementation MAY use a value larger than 60 seconds, if it is
467   believed that 60 seconds is too short.
468</t>
469<t>
470   If a client wishes to perform a sub-range retrieval on a value for
471   which it has only a Last-Modified time and no opaque validator, it
472   MAY do this only if the Last-Modified time is strong in the sense
473   described here.
474</t>
475<t>
476   A cache or origin server receiving a conditional request, other than
477   a full-body GET request, MUST use the strong comparison function to
478   evaluate the condition.
479</t>
480<t>
481   These rules allow HTTP/1.1 caches and clients to safely perform sub-range
482   retrievals on values that have been obtained from HTTP/1.0
483   servers.
484</t>
485</section>
486
487<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">
488<t>
489   We adopt a set of rules and recommendations for origin servers,
490   clients, and caches regarding when various validator types ought to
491   be used, and for what purposes.
492</t>
493<t>
494   HTTP/1.1 origin servers:
495  <list style="symbols">
496     <t>SHOULD send an entity tag validator unless it is not feasible to
497        generate one.</t>
498
499     <t>MAY send a weak entity tag instead of a strong entity tag, if
500        performance considerations support the use of weak entity tags,
501        or if it is unfeasible to send a strong entity tag.</t>
502
503     <t>SHOULD send a Last-Modified value if it is feasible to send one,
504        unless the risk of a breakdown in semantic transparency that
505        could result from using this date in an If-Modified-Since header
506        would lead to serious problems.</t>
507  </list>
508</t>
509<t>
510   In other words, the preferred behavior for an HTTP/1.1 origin server
511   is to send both a strong entity tag and a Last-Modified value.
512</t>
513<t>
514   In order to be legal, a strong entity tag MUST change whenever the
515   associated entity value changes in any way. A weak entity tag SHOULD
516   change whenever the associated entity changes in a semantically
517   significant way.
518  <list><t>
519      Note: in order to provide semantically transparent caching, an
520      origin server must avoid reusing a specific strong entity tag
521      value for two different entities, or reusing a specific weak
522      entity tag value for two semantically different entities. Cache
523      entries might persist for arbitrarily long periods, regardless of
524      expiration times, so it might be inappropriate to expect that a
525      cache will never again attempt to validate an entry using a
526      validator that it obtained at some point in the past.
527  </t></list>
528</t>
529<t>
530   HTTP/1.1 clients:
531  <list style="symbols">
532     <t>If an entity tag has been provided by the origin server, MUST
533        use that entity tag in any cache-conditional request (using If-Match
534        or If-None-Match).</t>
535
536     <t>If only a Last-Modified value has been provided by the origin
537        server, SHOULD use that value in non-subrange cache-conditional
538        requests (using If-Modified-Since).</t>
539
540     <t>If only a Last-Modified value has been provided by an HTTP/1.0
541        origin server, MAY use that value in subrange cache-conditional
542        requests (using If-Unmodified-Since:). The user agent SHOULD
543        provide a way to disable this, in case of difficulty.</t>
544
545     <t>If both an entity tag and a Last-Modified value have been
546        provided by the origin server, SHOULD use both validators in
547        cache-conditional requests. This allows both HTTP/1.0 and
548        HTTP/1.1 caches to respond appropriately.</t>
549  </list>
550</t>
551<t>
552   An HTTP/1.1 origin server, upon receiving a conditional request that
553   includes both a Last-Modified date (e.g., in an If-Modified-Since or
554   If-Unmodified-Since header field) and one or more entity tags (e.g.,
555   in an If-Match, If-None-Match, or If-Range header field) as cache
556   validators, MUST NOT return a response status of 304 (Not Modified)
557   unless doing so is consistent with all of the conditional header
558   fields in the request.
559</t>
560<t>
561   An HTTP/1.1 caching proxy, upon receiving a conditional request that
562   includes both a Last-Modified date and one or more entity tags as
563   cache validators, MUST NOT return a locally cached response to the
564   client unless that cached response is consistent with all of the
565   conditional header fields in the request.
566  <list><t>
567      Note: The general principle behind these rules is that HTTP/1.1
568      servers and clients should transmit as much non-redundant
569      information as is available in their responses and requests.
570      HTTP/1.1 systems receiving this information will make the most
571      conservative assumptions about the validators they receive.
572  </t><t>
573      HTTP/1.0 clients and caches will ignore entity tags. Generally,
574      last-modified values received or used by these systems will
575      support transparent and efficient caching, and so HTTP/1.1 origin
576      servers should provide Last-Modified values. In those rare cases
577      where the use of a Last-Modified value as a validator by an
578      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
579      origin servers should not provide one.
580  </t></list>
581</t>
582</section>
583
584<section title="Header Field Definitions" anchor="header.fields">
585<t>
586   This section defines the syntax and semantics of HTTP/1.1 header fields
587   related to conditional requests.
588</t>
589<t>
590   For entity-header fields, both sender and recipient refer to either the
591   client or the server, depending on who sends and who receives the entity.
592</t>
593
594<section title="ETag" anchor="header.etag">
595  <iref primary="true" item="ETag header"/>
596  <iref primary="true" item="Headers" subitem="ETag"/>
597<t>
598   The ETag response-header field provides the current value of the
599   entity tag for the requested variant. The headers used with entity
600   tags are described in Sections <xref target="header.if-match" format="counter"/>
601   and <xref target="header.if-none-match" format="counter"/> of this document,
602   and in Section 6.3 of <xref target="Part5"/>. The entity tag
603   MAY be used for comparison with other entities from the same resource
604   (see <xref target="weak.and.strong.validators"/>).
605</t>
606<figure><iref primary="true" item="Grammar" subitem="ETag"/><artwork type="abnf2616"><![CDATA[
607  ETag = "ETag" ":" entity-tag
608]]></artwork></figure>
609<figure><preamble>
610   Examples:
611</preamble>
612<artwork type="example"><![CDATA[
613   ETag: "xyzzy"
614   ETag: W/"xyzzy"
615   ETag: ""
616]]></artwork></figure>
617<t>
618   The ETag response-header field value, an entity tag, provides for an
619   "opaque" cache validator. This might allow more reliable validation
620   in situations where it is inconvenient to store modification dates,
621   where the one-second resolution of HTTP date values is not
622   sufficient, or where the origin server wishes to avoid certain
623   paradoxes that might arise from the use of modification dates.
624</t>
625<t>
626   The principle behind entity tags is that only the service author
627   knows the semantics of a resource well enough to select an
628   appropriate cache validation mechanism, and the specification of any
629   validator comparison function more complex than byte-equality would
630   open up a can of worms. Thus, comparisons of any other headers
631   (except Last-Modified, for compatibility with HTTP/1.0) are never
632   used for purposes of validating a cache entry.
633</t>
634</section>
635
636<section title="If-Match" anchor="header.if-match">
637  <iref primary="true" item="If-Match header"/>
638  <iref primary="true" item="Headers" subitem="If-Match"/>
639<t>
640   The If-Match request-header field is used with a method to make it
641   conditional. A client that has one or more entities previously
642   obtained from the resource can verify that one of those entities is
643   current by including a list of their associated entity tags in the
644   If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The
645   purpose of this feature is to allow efficient updates of cached
646   information with a minimum amount of transaction overhead. It is also
647   used, on updating requests, to prevent inadvertent modification of
648   the wrong version of a resource. As a special case, the value "*"
649   matches any current entity of the resource.
650</t>
651<figure><iref primary="true" item="Grammar" subitem="If-Match"/><artwork type="abnf2616"><![CDATA[
652  If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
653]]></artwork></figure>
654<t>
655   If any of the entity tags match the entity tag of the entity that
656   would have been returned in the response to a similar GET request
657   (without the If-Match header) on that resource, or if "*" is given
658   and any current entity exists for that resource, then the server MAY
659   perform the requested method as if the If-Match header field did not
660   exist.
661</t>
662<t>
663   A server MUST use the strong comparison function (see <xref target="weak.and.strong.validators"/>)
664   to compare the entity tags in If-Match.
665</t>
666<t>
667   If none of the entity tags match, or if "*" is given and no current
668   entity exists, the server MUST NOT perform the requested method, and
669   MUST return a 412 (Precondition Failed) response. This behavior is
670   most useful when the client wants to prevent an updating method, such
671   as PUT, from modifying a resource that has changed since the client
672   last retrieved it.
673</t>
674<t>
675   If the request would, without the If-Match header field, result in
676   anything other than a 2xx or 412 status, then the If-Match header
677   MUST be ignored.
678</t>
679<t>
680   The meaning of "If-Match: *" is that the method SHOULD be performed
681   if the representation selected by the origin server (or by a cache,
682   possibly using the Vary mechanism, see Section 16.5 of <xref target="Part6"/>) exists, and
683   MUST NOT be performed if the representation does not exist.
684</t>
685<t>
686   A request intended to update a resource (e.g., a PUT) MAY include an
687   If-Match header field to signal that the request method MUST NOT be
688   applied if the entity corresponding to the If-Match value (a single
689   entity tag) is no longer a representation of that resource. This
690   allows the user to indicate that they do not wish the request to be
691   successful if the resource has been changed without their knowledge.
692   Examples:
693</t>
694<figure><artwork type="example"><![CDATA[
695    If-Match: "xyzzy"
696    If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
697    If-Match: *
698]]></artwork></figure>
699<t>
700   The result of a request having both an If-Match header field and
701   either an If-None-Match or an If-Modified-Since header fields is
702   undefined by this specification.
703</t>
704</section>
705
706<section title="If-Modified-Since" anchor="header.if-modified-since">
707  <iref primary="true" item="If-Modified-Since header"/>
708  <iref primary="true" item="Headers" subitem="If-Modified-Since"/>
709<t>
710   The If-Modified-Since request-header field is used with a method to
711   make it conditional: if the requested variant has not been modified
712   since the time specified in this field, an entity will not be
713   returned from the server; instead, a 304 (Not Modified) response will
714   be returned without any message-body.
715</t>
716<figure><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><artwork type="abnf2616"><![CDATA[
717  If-Modified-Since = "If-Modified-Since" ":" HTTP-date
718]]></artwork></figure>
719<t>
720   An example of the field is:
721</t>
722<figure><artwork type="example"><![CDATA[
723    If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
724]]></artwork></figure>
725<t>
726   A GET method with an If-Modified-Since header and no Range header
727   requests that the identified entity be transferred only if it has
728   been modified since the date given by the If-Modified-Since header.
729   The algorithm for determining this includes the following cases:
730  <list style="numbers">
731      <t>If the request would normally result in anything other than a
732         200 (OK) status, or if the passed If-Modified-Since date is
733         invalid, the response is exactly the same as for a normal GET.
734         A date which is later than the server's current time is
735         invalid.</t>
736
737      <t>If the variant has been modified since the If-Modified-Since
738         date, the response is exactly the same as for a normal GET.</t>
739
740      <t>If the variant has not been modified since a valid If-Modified-Since
741         date, the server SHOULD return a 304 (Not
742         Modified) response.</t>
743  </list>
744</t>
745<t>
746   The purpose of this feature is to allow efficient updates of cached
747   information with a minimum amount of transaction overhead.
748  <list><t>
749      Note: The Range request-header field modifies the meaning of If-Modified-Since;
750      see Section 6.4 of <xref target="Part5"/> for full details.
751    </t><t>
752      Note: If-Modified-Since times are interpreted by the server, whose
753      clock might not be synchronized with the client.
754    </t><t>
755      Note: When handling an If-Modified-Since header field, some
756      servers will use an exact date comparison function, rather than a
757      less-than function, for deciding whether to send a 304 (Not
758      Modified) response. To get best results when sending an If-Modified-Since
759      header field for cache validation, clients are
760      advised to use the exact date string received in a previous Last-Modified
761      header field whenever possible.
762    </t><t>
763      Note: If a client uses an arbitrary date in the If-Modified-Since
764      header instead of a date taken from the Last-Modified header for
765      the same request, the client should be aware of the fact that this
766      date is interpreted in the server's understanding of time. The
767      client should consider unsynchronized clocks and rounding problems
768      due to the different encodings of time between the client and
769      server. This includes the possibility of race conditions if the
770      document has changed between the time it was first requested and
771      the If-Modified-Since date of a subsequent request, and the
772      possibility of clock-skew-related problems if the If-Modified-Since
773      date is derived from the client's clock without correction
774      to the server's clock. Corrections for different time bases
775      between client and server are at best approximate due to network
776      latency.
777    </t>
778  </list>
779</t>
780<t>
781   The result of a request having both an If-Modified-Since header field
782   and either an If-Match or an If-Unmodified-Since header fields is
783   undefined by this specification.
784</t>
785</section>
786
787<section title="If-None-Match" anchor="header.if-none-match">
788  <iref primary="true" item="If-None-Match header"/>
789  <iref primary="true" item="Headers" subitem="If-None-Match"/>
790<t>
791   The If-None-Match request-header field is used with a method to make
792   it conditional. A client that has one or more entities previously
793   obtained from the resource can verify that none of those entities is
794   current by including a list of their associated entity tags in the
795   If-None-Match header field. The purpose of this feature is to allow
796   efficient updates of cached information with a minimum amount of
797   transaction overhead. It is also used to prevent a method (e.g. PUT)
798   from inadvertently modifying an existing resource when the client
799   believes that the resource does not exist.
800</t>
801<t>
802   As a special case, the value "*" matches any current entity of the
803   resource.
804</t>
805<figure><iref primary="true" item="Grammar" subitem="If-None-Match"/><artwork type="abnf2616"><![CDATA[
806  If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
807]]></artwork></figure>
808<t>
809   If any of the entity tags match the entity tag of the entity that
810   would have been returned in the response to a similar GET request
811   (without the If-None-Match header) on that resource, or if "*" is
812   given and any current entity exists for that resource, then the
813   server MUST NOT perform the requested method, unless required to do
814   so because the resource's modification date fails to match that
815   supplied in an If-Modified-Since header field in the request.
816   Instead, if the request method was GET or HEAD, the server SHOULD
817   respond with a 304 (Not Modified) response, including the cache-related
818   header fields (particularly ETag) of one of the entities that
819   matched. For all other request methods, the server MUST respond with
820   a status of 412 (Precondition Failed).
821</t>
822<t>
823   See <xref target="weak.and.strong.validators"/> for rules on how to determine if two entities tags
824   match. The weak comparison function can only be used with GET or HEAD
825   requests.
826</t>
827<t>
828   If none of the entity tags match, then the server MAY perform the
829   requested method as if the If-None-Match header field did not exist,
830   but MUST also ignore any If-Modified-Since header field(s) in the
831   request. That is, if no entity tags match, then the server MUST NOT
832   return a 304 (Not Modified) response.
833</t>
834<t>
835   If the request would, without the If-None-Match header field, result
836   in anything other than a 2xx or 304 status, then the If-None-Match
837   header MUST be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of
838   server behavior when both If-Modified-Since and If-None-Match appear
839   in the same request.)
840</t>
841<t>
842   The meaning of "If-None-Match: *" is that the method MUST NOT be
843   performed if the representation selected by the origin server (or by
844   a cache, possibly using the Vary mechanism, see Section 16.5 of <xref target="Part6"/>)
845   exists, and SHOULD be performed if the representation does not exist.
846   This feature is intended to be useful in preventing races between PUT
847   operations.
848</t>
849<t>
850   Examples:
851</t>
852<figure><artwork type="example"><![CDATA[
853    If-None-Match: "xyzzy"
854    If-None-Match: W/"xyzzy"
855    If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
856    If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
857    If-None-Match: *
858]]></artwork></figure>
859<t>
860   The result of a request having both an If-None-Match header field and
861   either an If-Match or an If-Unmodified-Since header fields is
862   undefined by this specification.
863</t>
864</section>
865
866<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
867  <iref primary="true" item="If-Unmodified-Since header"/>
868  <iref primary="true" item="Headers" subitem="If-Unmodified-Since"/>
869<t>
870   The If-Unmodified-Since request-header field is used with a method to
871   make it conditional. If the requested resource has not been modified
872   since the time specified in this field, the server SHOULD perform the
873   requested operation as if the If-Unmodified-Since header were not
874   present.
875</t>
876<t>
877   If the requested variant has been modified since the specified time,
878   the server MUST NOT perform the requested operation, and MUST return
879   a 412 (Precondition Failed).
880</t>
881<figure><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/><artwork type="abnf2616"><![CDATA[
882  If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
883]]></artwork></figure>
884<t>
885   An example of the field is:
886</t>
887<figure><artwork type="example"><![CDATA[
888    If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
889]]></artwork></figure>
890<t>
891   If the request normally (i.e., without the If-Unmodified-Since
892   header) would result in anything other than a 2xx or 412 status, the
893   If-Unmodified-Since header SHOULD be ignored.
894</t>
895<t>
896   If the specified date is invalid, the header is ignored.
897</t>
898<t>
899   The result of a request having both an If-Unmodified-Since header
900   field and either an If-None-Match or an If-Modified-Since header
901   fields is undefined by this specification.
902</t>
903</section>
904
905<section title="Last-Modified" anchor="header.last-modified">
906  <iref primary="true" item="Last-Modified header"/>
907  <iref primary="true" item="Headers" subitem="Last-Modified"/>
908<t>
909   The Last-Modified entity-header field indicates the date and time at
910   which the origin server believes the variant was last modified.
911</t>
912<figure><iref primary="true" item="Grammar" subitem="Last-Modified"/><artwork type="abnf2616"><![CDATA[
913  Last-Modified  = "Last-Modified" ":" HTTP-date
914]]></artwork></figure>
915<t>
916   An example of its use is
917</t>
918<figure><artwork type="example"><![CDATA[
919    Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
920]]></artwork></figure>
921<t>
922   The exact meaning of this header field depends on the implementation
923   of the origin server and the nature of the original resource. For
924   files, it may be just the file system last-modified time. For
925   entities with dynamically included parts, it may be the most recent
926   of the set of last-modify times for its component parts. For database
927   gateways, it may be the last-update time stamp of the record. For
928   virtual objects, it may be the last time the internal state changed.
929</t>
930<t>
931   An origin server MUST NOT send a Last-Modified date which is later
932   than the server's time of message origination. In such cases, where
933   the resource's last modification would indicate some time in the
934   future, the server MUST replace that date with the message
935   origination date.
936</t>
937<t>
938   An origin server SHOULD obtain the Last-Modified value of the entity
939   as close as possible to the time that it generates the Date value of
940   its response. This allows a recipient to make an accurate assessment
941   of the entity's modification time, especially if the entity changes
942   near the time that the response is generated.
943</t>
944<t>
945   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
946</t>
947<t>
948   The Last-Modified entity-header field value is often used as a cache
949   validator. In simple terms, a cache entry is considered to be valid
950   if the entity has not been modified since the Last-Modified value.
951</t>
952</section>
953
954</section>
955
956<section title="IANA Considerations" anchor="IANA.considerations">
957<t>
958   <cref>TBD.</cref>
959</t>
960</section>
961
962<section title="Security Considerations" anchor="security.considerations">
963<t>
964   No additional security considerations have been identified beyond
965   those applicable to HTTP in general <xref target="Part1"/>.
966</t>
967</section>
968
969<section title="Acknowledgments" anchor="ack">
970</section>
971</middle>
972<back>
973
974<references title="Normative References">
975
976<reference anchor="Part1">
977  <front>
978    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
979    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
980      <organization abbrev="Day Software">Day Software</organization>
981      <address><email>fielding@gbiv.com</email></address>
982    </author>
983    <author initials="J." surname="Gettys" fullname="Jim Gettys">
984      <organization>One Laptop per Child</organization>
985      <address><email>jg@laptop.org</email></address>
986    </author>
987    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
988      <organization abbrev="HP">Hewlett-Packard Company</organization>
989      <address><email>JeffMogul@acm.org</email></address>
990    </author>
991    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
992      <organization abbrev="Microsoft">Microsoft Corporation</organization>
993      <address><email>henrikn@microsoft.com</email></address>
994    </author>
995    <author initials="L." surname="Masinter" fullname="Larry Masinter">
996      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
997      <address><email>LMM@acm.org</email></address>
998    </author>
999    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1000      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1001      <address><email>paulle@microsoft.com</email></address>
1002    </author>
1003    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1004      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1005      <address><email>timbl@w3.org</email></address>
1006    </author>
1007    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1008      <organization abbrev="W3C">World Wide Web Consortium</organization>
1009      <address><email>ylafon@w3.org</email></address>
1010    </author>
1011    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1012      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1013      <address><email>julian.reschke@greenbytes.de</email></address>
1014    </author>
1015    <date month="February" year="2008"/>
1016  </front>
1017  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-02"/>
1018 
1019</reference>
1020
1021<reference anchor="Part5">
1022  <front>
1023    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
1024    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1025      <organization abbrev="Day Software">Day Software</organization>
1026      <address><email>fielding@gbiv.com</email></address>
1027    </author>
1028    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1029      <organization>One Laptop per Child</organization>
1030      <address><email>jg@laptop.org</email></address>
1031    </author>
1032    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1033      <organization abbrev="HP">Hewlett-Packard Company</organization>
1034      <address><email>JeffMogul@acm.org</email></address>
1035    </author>
1036    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1037      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1038      <address><email>henrikn@microsoft.com</email></address>
1039    </author>
1040    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1041      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1042      <address><email>LMM@acm.org</email></address>
1043    </author>
1044    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1045      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1046      <address><email>paulle@microsoft.com</email></address>
1047    </author>
1048    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1049      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1050      <address><email>timbl@w3.org</email></address>
1051    </author>
1052    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1053      <organization abbrev="W3C">World Wide Web Consortium</organization>
1054      <address><email>ylafon@w3.org</email></address>
1055    </author>
1056    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1057      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1058      <address><email>julian.reschke@greenbytes.de</email></address>
1059    </author>
1060    <date month="February" year="2008"/>
1061  </front>
1062  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-02"/>
1063 
1064</reference>
1065
1066<reference anchor="Part6">
1067  <front>
1068    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
1069    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1070      <organization abbrev="Day Software">Day Software</organization>
1071      <address><email>fielding@gbiv.com</email></address>
1072    </author>
1073    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1074      <organization>One Laptop per Child</organization>
1075      <address><email>jg@laptop.org</email></address>
1076    </author>
1077    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1078      <organization abbrev="HP">Hewlett-Packard Company</organization>
1079      <address><email>JeffMogul@acm.org</email></address>
1080    </author>
1081    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1082      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1083      <address><email>henrikn@microsoft.com</email></address>
1084    </author>
1085    <author initials="L." surname="Masinter" fullname="Larry Masinter">
1086      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
1087      <address><email>LMM@acm.org</email></address>
1088    </author>
1089    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1090      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1091      <address><email>paulle@microsoft.com</email></address>
1092    </author>
1093    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1094      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1095      <address><email>timbl@w3.org</email></address>
1096    </author>
1097    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1098      <organization abbrev="W3C">World Wide Web Consortium</organization>
1099      <address><email>ylafon@w3.org</email></address>
1100    </author>
1101    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1102      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1103      <address><email>julian.reschke@greenbytes.de</email></address>
1104    </author>
1105    <date month="February" year="2008"/>
1106  </front>
1107  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-02"/>
1108 
1109</reference>
1110
1111<reference anchor="RFC2119">
1112  <front>
1113    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1114    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1115      <organization>Harvard University</organization>
1116      <address><email>sob@harvard.edu</email></address>
1117    </author>
1118    <date month="March" year="1997"/>
1119  </front>
1120  <seriesInfo name="BCP" value="14"/>
1121  <seriesInfo name="RFC" value="2119"/>
1122</reference>
1123
1124</references>
1125
1126<references title="Informative References">
1127
1128<reference anchor="RFC2068">
1129  <front>
1130    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
1131    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
1132      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
1133      <address><email>fielding@ics.uci.edu</email></address>
1134    </author>
1135    <author initials="J." surname="Gettys" fullname="Jim Gettys">
1136      <organization>MIT Laboratory for Computer Science</organization>
1137      <address><email>jg@w3.org</email></address>
1138    </author>
1139    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1140      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
1141      <address><email>mogul@wrl.dec.com</email></address>
1142    </author>
1143    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
1144      <organization>MIT Laboratory for Computer Science</organization>
1145      <address><email>frystyk@w3.org</email></address>
1146    </author>
1147    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1148      <organization>MIT Laboratory for Computer Science</organization>
1149      <address><email>timbl@w3.org</email></address>
1150    </author>
1151    <date month="January" year="1997"/>
1152  </front>
1153  <seriesInfo name="RFC" value="2068"/>
1154</reference>
1155
1156<reference anchor="RFC2616">
1157  <front>
1158    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1159    <author initials="R." surname="Fielding" fullname="R. Fielding">
1160      <organization>University of California, Irvine</organization>
1161      <address><email>fielding@ics.uci.edu</email></address>
1162    </author>
1163    <author initials="J." surname="Gettys" fullname="J. Gettys">
1164      <organization>W3C</organization>
1165      <address><email>jg@w3.org</email></address>
1166    </author>
1167    <author initials="J." surname="Mogul" fullname="J. Mogul">
1168      <organization>Compaq Computer Corporation</organization>
1169      <address><email>mogul@wrl.dec.com</email></address>
1170    </author>
1171    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1172      <organization>MIT Laboratory for Computer Science</organization>
1173      <address><email>frystyk@w3.org</email></address>
1174    </author>
1175    <author initials="L." surname="Masinter" fullname="L. Masinter">
1176      <organization>Xerox Corporation</organization>
1177      <address><email>masinter@parc.xerox.com</email></address>
1178    </author>
1179    <author initials="P." surname="Leach" fullname="P. Leach">
1180      <organization>Microsoft Corporation</organization>
1181      <address><email>paulle@microsoft.com</email></address>
1182    </author>
1183    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1184      <organization>W3C</organization>
1185      <address><email>timbl@w3.org</email></address>
1186    </author>
1187    <date month="June" year="1999"/>
1188  </front>
1189  <seriesInfo name="RFC" value="2616"/>
1190</reference>
1191
1192</references>
1193
1194<section title="Compatibility with Previous Versions" anchor="compatibility">
1195
1196<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1197</section>
1198
1199</section>
1200
1201<section title="Change Log (to be removed by RFC Editor before publication)">
1202
1203<section title="Since RFC2616">
1204<t>
1205  Extracted relevant partitions from <xref target="RFC2616"/>.
1206</t>
1207</section>
1208
1209<section title="Since draft-ietf-httpbis-p4-conditional-00">
1210<t>
1211  Closed issues:
1212  <list style="symbols"> 
1213    <t>
1214      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
1215      "Normative and Informative references"
1216    </t>
1217  </list>
1218</t>
1219<t>
1220  Other changes:
1221  <list style="symbols"> 
1222    <t>
1223      Move definitions of 304 and 412 condition codes from Part2.
1224    </t>
1225  </list>
1226</t>
1227</section>
1228
1229<section title="Since draft-ietf-httpbis-p4-conditional-01">
1230<t>
1231  Ongoing work on ABNF conversion (<eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
1232  <list style="symbols"> 
1233    <t>
1234      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1235    </t>
1236  </list>
1237</t>
1238</section>
1239
1240</section>
1241
1242</back>
1243</rfc>
Note: See TracBrowser for help on using the repository browser.