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

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

editorial consistency:
Use "request method" when talking about HTTP method tokens
unless it is obvious from context.
Make method descriptions a bit more consistent.

  • Property svn:eol-style set to native
File size: 70.1 KB
[29]1<?xml version="1.0" encoding="utf-8"?>
[101]2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
[8]3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns=''>MAY</bcp14>">
5  <!ENTITY MUST "<bcp14 xmlns=''>MUST</bcp14>">
6  <!ENTITY MUST-NOT "<bcp14 xmlns=''>MUST NOT</bcp14>">
7  <!ENTITY OPTIONAL "<bcp14 xmlns=''>OPTIONAL</bcp14>">
8  <!ENTITY RECOMMENDED "<bcp14 xmlns=''>RECOMMENDED</bcp14>">
9  <!ENTITY REQUIRED "<bcp14 xmlns=''>REQUIRED</bcp14>">
10  <!ENTITY SHALL "<bcp14 xmlns=''>SHALL</bcp14>">
11  <!ENTITY SHALL-NOT "<bcp14 xmlns=''>SHALL NOT</bcp14>">
12  <!ENTITY SHOULD "<bcp14 xmlns=''>SHOULD</bcp14>">
13  <!ENTITY SHOULD-NOT "<bcp14 xmlns=''>SHOULD NOT</bcp14>">
[29]14  <!ENTITY ID-VERSION "latest">
[1145]15  <!ENTITY ID-MONTH "March">
[1099]16  <!ENTITY ID-YEAR "2011">
[424]17  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x=''/>">
[205]18  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x=''/>">
19  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x=''/>">
[306]20  <!ENTITY header-date                "<xref target='Part1' x:rel='' xmlns:x=''/>">
[31]21  <!ENTITY messaging                  "<xref target='Part1' xmlns:x=''/>">
[163]22  <!ENTITY caching                    "<xref target='Part6' xmlns:x=''/>">
[800]23  <!ENTITY header-accept-encoding     "<xref target='Part3' x:rel='#header.accept-encoding' xmlns:x=''/>">
[31]24  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x=''/>">
25  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x=''/>">
26  <!ENTITY header-vary                "<xref target='Part6' x:rel='#header.vary' xmlns:x=''/>">
[45]27  <!ENTITY clockless                  "<xref target='Part1' x:rel='#clockless.origin.server.operation' xmlns:x=''/>">
[580]28  <!ENTITY full-date                  "<xref target='Part1' x:rel='' xmlns:x=''/>">
[800]29  <!ENTITY transfer-codings           "<xref target='Part1' x:rel='#transfer.codings' xmlns:x=''/>">
30  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x=''/>">
32<?rfc toc="yes" ?>
[29]33<?rfc symrefs="yes" ?>
34<?rfc sortrefs="yes" ?>
[8]35<?rfc compact="yes"?>
36<?rfc subcompact="no" ?>
37<?rfc linkmailto="no" ?>
38<?rfc editing="no" ?>
[203]39<?rfc comments="yes"?>
40<?rfc inline="yes"?>
[799]41<?rfc rfcedstyle="yes"?>
[8]42<?rfc-ext allow-markup-in-artwork="yes" ?>
43<?rfc-ext include-references-in-index="yes" ?>
[308]44<rfc obsoletes="2616" category="std" x:maturity-level="draft"
[446]45     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"
[153]46     xmlns:x=''>
[120]49  <title abbrev="HTTP/1.1, Part 4">HTTP/1.1, part 4: Conditional Requests</title>
[29]51  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]52    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[8]53    <address>
54      <postal>
[1106]55        <street>345 Park Ave</street>
56        <city>San Jose</city>
[8]57        <region>CA</region>
[1106]58        <code>95110</code>
[29]59        <country>USA</country>
[8]60      </postal>
[29]61      <email></email>
62      <uri></uri>
[8]63    </address>
64  </author>
[29]66  <author initials="J." surname="Gettys" fullname="Jim Gettys">
[844]67    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
[8]68    <address>
69      <postal>
[29]70        <street>21 Oak Knoll Road</street>
71        <city>Carlisle</city>
[8]72        <region>MA</region>
[29]73        <code>01741</code>
74        <country>USA</country>
[8]75      </postal>
[844]76      <email></email>
77      <uri></uri>
[8]78    </address>
79  </author>
81  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
[29]82    <organization abbrev="HP">Hewlett-Packard Company</organization>
[8]83    <address>
84      <postal>
[29]85        <street>HP Labs, Large Scale Systems Group</street>
86        <street>1501 Page Mill Road, MS 1177</street>
[8]87        <city>Palo Alto</city>
88        <region>CA</region>
[29]89        <code>94304</code>
90        <country>USA</country>
[8]91      </postal>
[29]92      <email></email>
[8]93    </address>
94  </author>
96  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
[29]97    <organization abbrev="Microsoft">Microsoft Corporation</organization>
[8]98    <address>
99      <postal>
[29]100        <street>1 Microsoft Way</street>
101        <city>Redmond</city>
102        <region>WA</region>
103        <code>98052</code>
104        <country>USA</country>
[8]105      </postal>
[29]106      <email></email>
[8]107    </address>
108  </author>
110  <author initials="L." surname="Masinter" fullname="Larry Masinter">
[1106]111    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[8]112    <address>
113      <postal>
[29]114        <street>345 Park Ave</street>
115        <city>San Jose</city>
[8]116        <region>CA</region>
[29]117        <code>95110</code>
118        <country>USA</country>
[8]119      </postal>
[29]120      <email></email>
121      <uri></uri>
[8]122    </address>
123  </author>
125  <author initials="P." surname="Leach" fullname="Paul J. Leach">
126    <organization abbrev="Microsoft">Microsoft Corporation</organization>
127    <address>
128      <postal>
129        <street>1 Microsoft Way</street>
130        <city>Redmond</city>
131        <region>WA</region>
132        <code>98052</code>
133      </postal>
134      <email></email>
135    </address>
136  </author>
138  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
139    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
140    <address>
141      <postal>
[34]142        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
143        <street>The Stata Center, Building 32</street>
144        <street>32 Vassar Street</street>
[8]145        <city>Cambridge</city>
146        <region>MA</region>
147        <code>02139</code>
[29]148        <country>USA</country>
[8]149      </postal>
150      <email></email>
[34]151      <uri></uri>
[8]152    </address>
153  </author>
[95]155  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
[94]156    <organization abbrev="W3C">World Wide Web Consortium</organization>
157    <address>
158      <postal>
159        <street>W3C / ERCIM</street>
160        <street>2004, rte des Lucioles</street>
161        <city>Sophia-Antipolis</city>
162        <region>AM</region>
163        <code>06902</code>
164        <country>France</country>
165      </postal>
166      <email></email>
167      <uri></uri>
168    </address>
169  </author>
171  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
172    <organization abbrev="greenbytes">greenbytes GmbH</organization>
173    <address>
174      <postal>
175        <street>Hafenweg 16</street>
176        <city>Muenster</city><region>NW</region><code>48155</code>
177        <country>Germany</country>
178      </postal>
[609]179      <phone>+49 251 2807760</phone>
180      <facsimile>+49 251 2807761</facsimile>
181      <email></email>
182      <uri></uri>
[95]183    </address>
184  </author>
[31]186  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
[440]187  <workgroup>HTTPbis Working Group</workgroup>
191   The Hypertext Transfer Protocol (HTTP) is an application-level
192   protocol for distributed, collaborative, hypermedia information
[29]193   systems. HTTP has been in use by the World Wide Web global information
[35]194   initiative since 1990. This document is Part 4 of the seven-part specification
[29]195   that defines the protocol referred to as "HTTP/1.1" and, taken together,
[42]196   obsoletes RFC 2616.  Part 4 defines request header fields for
[29]197   indicating conditional requests and the rules for constructing responses
198   to those requests.
202<note title="Editorial Note (To be removed by RFC Editor)">
203  <t>
204    Discussion of this draft should take place on the HTTPBIS working group
205    mailing list ( The current issues list is
[848]206    at <eref target=""/>
[36]207    and related documents (including fancy diffs) can be found at
[324]208    <eref target=""/>.
[36]209  </t>
[153]210  <t>
[1052]211    The changes in this draft are summarized in <xref target="changes.since.12"/>.
[153]212  </t>
216<section title="Introduction" anchor="introduction">
[163]218   This document defines HTTP/1.1 response metadata for indicating potential
219   changes to payload content, including modification time stamps and opaque
220   entity-tags, and the HTTP conditional request mechanisms that allow
221   preconditions to be placed on a request method.  Conditional GET requests
222   allow for efficient cache updates.  Other conditional request methods are
223   used to protect against overwriting or misunderstanding the state of a
224   resource that has been changed unbeknownst to the requesting client.
227   This document is currently disorganized in order to minimize the changes
228   between drafts and enable reviewers to see the smaller errata changes.
[980]229   A future draft will reorganize the sections to better reflect the content.
[163]230   In particular, the sections on resource metadata will be discussed first
[994]231   and then followed by each conditional request-header field, concluding with a
[163]232   definition of precedence and the expectation of ordering strong validator
233   checks before weak validator checks.  It is likely that more content from
234   &caching; will migrate to this part, where appropriate.
235   The current mess reflects how widely dispersed these topics and associated
236   requirements had become in <xref target="RFC2616"/>.
239<section title="Requirements" anchor="intro.requirements">
241   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
242   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
243   document are to be interpreted as described in <xref target="RFC2119"/>.
246   An implementation is not compliant if it fails to satisfy one or more
[847]247   of the "MUST" or "REQUIRED" level requirements for the protocols it
248   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
249   level and all the "SHOULD" level requirements for its protocols is said
250   to be "unconditionally compliant"; one that satisfies all the "MUST"
251   level requirements but not all the "SHOULD" level requirements for its
252   protocols is said to be "conditionally compliant".
[424]256<section title="Syntax Notation" anchor="notation">
[425]257  <x:anchor-alias value="ALPHA"/>
258  <x:anchor-alias value="CR"/>
259  <x:anchor-alias value="DIGIT"/>
260  <x:anchor-alias value="LF"/>
261  <x:anchor-alias value="OCTET"/>
262  <x:anchor-alias value="VCHAR"/>
263  <x:anchor-alias value="WSP"/>
[543]265  This specification uses the ABNF syntax defined in &notation; (which
266  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
267  <xref target="collected.abnf"/> shows the collected ABNF, with the list
268  rule expanded.
[425]271  The following core rules are included by
272  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
273  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
274  DIGIT (decimal 0-9), DQUOTE (double quote),
275  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
276  OCTET (any 8-bit sequence of data), SP (space),
277  VCHAR (any visible USASCII character),
278  and WSP (whitespace).
281<section title="Core Rules" anchor="core.rules">
[229]282  <x:anchor-alias value="quoted-string"/>
[362]283  <x:anchor-alias value="OWS"/>
[424]285  The core rules below are defined in &basic-rules;:
287<figure><artwork type="abnf2616">
[229]288  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &basic-rules;&gt;
[362]289  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
293<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
[229]294  <x:anchor-alias value="HTTP-date"/>
[205]296  The ABNF rules below are defined in other parts:
[207]298<figure><!--Part1--><artwork type="abnf2616">
[229]299  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &full-date;&gt;
[874]307<section title="Entity-Tags" anchor="entity.tags">
[229]308  <x:anchor-alias value="entity-tag"/>
309  <x:anchor-alias value="opaque-tag"/>
310  <x:anchor-alias value="weak"/>
[965]312   Entity-tags are used for comparing two or more representations of the same
313   resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),
[8]314   If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
[29]315   If-Range (&header-if-range;) header fields. The definition of how they
[8]316   are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
[874]317   entity-tag consists of an opaque quoted string, possibly prefixed by
[8]318   a weakness indicator.
320<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/>
[229]321  <x:ref>entity-tag</x:ref> = [ <x:ref>weak</x:ref> ] <x:ref>opaque-tag</x:ref>
[570]322  <x:ref>weak</x:ref>       = <x:abnf-char-sequence>"W/"</x:abnf-char-sequence> ; "W/", case-sensitive
[229]323  <x:ref>opaque-tag</x:ref> = <x:ref>quoted-string</x:ref>
[874]326   A "strong entity-tag" &MAY; be shared by two representations of a resource
[8]327   only if they are equivalent by octet equality.
[879]330   A "weak entity-tag", indicated by the "W/" prefix, &MAY; be shared by
[874]331   two representations of a resource only if the representations are equivalent and
[8]332   could be substituted for each other with no significant change in
[874]333   semantics. A weak entity-tag can only be used for weak comparison.
[874]336   An entity-tag &MUST; be unique across all versions of all representations
337   associated with a particular resource. A given entity-tag value &MAY;
338   be used for representations obtained by requests on different URIs. The use
339   of the same entity-tag value in conjunction with representations obtained by
[8]340   requests on different URIs does not imply the equivalence of those
[874]341   representations.
[874]344<section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
346   Consider a resource that is subject to content negotiation (&content-negotiation;),
347   and where the representations returned upon a GET request vary based on
348   the Accept-Encoding request header field (&header-accept-encoding;):
350<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
351GET /index HTTP/1.1
353Accept-Encoding: gzip
[908]357   In this case, the response might or might not use the gzip content coding.
[860]358   If it does not, the response might look like:
360<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
361HTTP/1.1 200 OK
362Date: Thu, 26 Mar 2010 00:05:00 GMT
363ETag: "123-a"
364Content-Length: <x:length-of target="exbody"/>
365Vary: Accept-Encoding
366Content-Type: text/plain
368<x:span anchor="exbody">Hello World!
369Hello World!
370Hello World!
371Hello World!
372Hello World!
[860]375   An alternative representation that does use gzip content coding would be:
377<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
378HTTP/1.1 200 OK
379Date: Thu, 26 Mar 2010 00:05:00 GMT
380ETag: "123-b"
381Content-Length: 43
382Vary: Accept-Encoding
383Content-Type: text/plain
384Content-Encoding: gzip
386<spanx>...binary data...</spanx></artwork></figure>
388  <t>
[860]389    <x:h>Note:</x:h> Content codings are a property of the representation,
[874]390    so therefore an entity-tag of an encoded representation must be distinct
[860]391    from an unencoded representation to prevent conflicts during cache updates
392    and range requests.  In contrast, transfer codings (&transfer-codings;)
[874]393    apply only during message transfer and do not require distinct entity-tags.
[800]394  </t>
[838]399<section title="Status Code Definitions" anchor="status.code.definitions">
[45]400<section title="304 Not Modified" anchor="status.304">
401  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
402  <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
404   If the client has performed a conditional GET request and access is
405   allowed, but the document has not been modified, the server &SHOULD;
406   respond with this status code. The 304 response &MUST-NOT; contain a
407   message-body, and thus is always terminated by the first empty line
408   after the header fields.
[860]411   A 304 response &MUST; include a Date header field (&header-date;)
412   unless its omission is required by &clockless;.  If a 200 response
413   to the same request would have included any of the header fields
414   Cache-Control, Content-Location, ETag, Expires, Last-Modified, or
415   Vary, then those same header fields &MUST; be sent in a 304 response.
[860]418   Since the goal of a 304 response is to minimize information transfer
419   when the recipient already has one or more cached representations,
420   the response &SHOULD-NOT; include representation metadata other
421   than the above listed fields unless said metadata exists for the
422   purpose of guiding cache updates (e.g., future HTTP extensions).
[860]425   If a 304 response includes an entity-tag that indicates a
426   representation not currently cached, then the recipient &MUST-NOT;
427   use the 304 to update its own cache.  If that conditional request originated
428   with an outbound client, such as a user agent with its own cache sending a
[960]429   conditional GET to a shared proxy, then the 304 response &MAY; be
[860]430   forwarded to the outbound client.  Otherwise, disregard the response
431   and repeat the request without the conditional.
434   If a cache uses a received 304 response to update a cache entry, the
435   cache &MUST; update the entry to reflect any new field values given in
436   the response.
440<section title="412 Precondition Failed" anchor="status.412">
441  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
442  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
444   The precondition given in one or more of the request-header fields
445   evaluated to false when it was tested on the server. This response
446   code allows the client to place preconditions on the current resource
[867]447   metadata (header field data) and thus prevent the requested
[45]448   method from being applied to a resource other than the one intended.
[8]453<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
455   Since both origin servers and caches will compare two validators to
[866]456   decide if they represent the same or different representations, one normally
457   would expect that if the representation (including both representation
458   header fields and representation body) changes in any way, then the
459   associated validator would change as well. If this is true, then we
[879]460   call this validator a "strong validator".
463   However, there might be cases when a server prefers to change the
464   validator only on semantically significant changes, and not when
[866]465   insignificant aspects of the representation change. A validator that does not
[879]466   always change when the representation changes is a "weak validator".
[874]469   An entity-tag is normally a strong validator, but the protocol
[879]470   provides a mechanism to tag an entity-tag as "weak". One can think of
[866]471   a strong validator as one that changes whenever the sequence of bits
472   in a representation changes, while a weak value changes whenever the
473   meaning of a representation changes. Alternatively, one can think of
474   a strong validator as part of an identifier for a specific representation,
475   whereas a weak validator is part of an identifier for a set of semantically
476   equivalent representations.
[8]477  <list><t>
478      <x:h>Note:</x:h> One example of a strong validator is an integer that is
[866]479      incremented in stable storage every time a representation is changed.
[8]480    </t><t>
[874]481      A representation's modification time, if defined with only one-second
[8]482      resolution, could be a weak validator, since it is possible that
[866]483      the representation might be modified twice during a single second.
[8]484    </t><t>
485      Support for weak validators is optional. However, weak validators
486      allow for more efficient caching of equivalent objects; for
487      example, a hit counter on a site is probably good enough if it is
488      updated every few days or weeks, and any value during that period
489      is likely "good enough" to be equivalent.
490    </t></list>
493   A "use" of a validator is either when a client generates a request
494   and includes the validator in a validating header field, or when a
495   server compares two validators.
498   Strong validators are usable in any context. Weak validators are only
[866]499   usable in contexts that do not depend on exact equality of a representation.
500   For example, either kind is usable for a normal conditional GET.
501   However, only a strong validator is usable for a sub-range
[8]502   retrieval, since otherwise the client might end up with an internally
[866]503   inconsistent representation.
[245]506   Clients &MUST-NOT; use weak validators in range requests (<xref target="Part5"/>).
[172]509   The only function that HTTP/1.1 defines on validators is
[8]510   comparison. There are two validator comparison functions, depending
511   on whether the comparison context allows the use of weak validators
512   or not:
513  <list style="symbols">
514     <t>The strong comparison function: in order to be considered equal,
[298]515        both opaque-tags &MUST; be identical character-by-character, and both
516        &MUST-NOT; be weak.</t>
517     <t>The weak comparison function: in order to be considered equal, both
[610]518        opaque-tags &MUST; be identical character-by-character, but
519        either or both of them &MAY; be tagged as "weak" without affecting
520        the result.</t>
[8]521  </list>
[874]524   The example below shows the results for a set of entity-tag pairs,
[298]525   and both the weak and strong comparison function results:
527<texttable align="left">
528  <ttcol>ETag 1</ttcol>
529  <ttcol>ETag 2</ttcol>
530  <ttcol>Strong Comparison</ttcol>
531  <ttcol>Weak Comparison</ttcol>
533  <c>W/"1"</c>
534  <c>W/"1"</c>
535  <c>no match</c>
536  <c>match</c>
538  <c>W/"1"</c>
539  <c>W/"2"</c>
540  <c>no match</c>
541  <c>no match</c>
543  <c>W/"1"</c>
544  <c>"1"</c>
545  <c>no match</c>
546  <c>match</c>
548  <c>"1"</c>
549  <c>"1"</c>
550  <c>match</c>
551  <c>match</c>
[874]554   An entity-tag is strong unless it is explicitly tagged as weak.
555   <xref target="entity.tags"/> gives the syntax for entity-tags.
558   A Last-Modified time, when used as a validator in a request, is
559   implicitly weak unless it is possible to deduce that it is strong,
560   using the following rules:
561  <list style="symbols">
562     <t>The validator is being compared by an origin server to the
[866]563        actual current validator for the representation and,</t>
564     <t>That origin server reliably knows that the associated representation did
[8]565        not change twice during the second covered by the presented
566        validator.</t>
567  </list>
570   or
571  <list style="symbols">
572     <t>The validator is about to be used by a client in an If-Modified-Since
[994]573        or If-Unmodified-Since header field, because the client
[866]574        has a cache entry for the associated representation, and</t>
[8]575     <t>That cache entry includes a Date value, which gives the time
576        when the origin server sent the original response, and</t>
577     <t>The presented Last-Modified time is at least 60 seconds before
578        the Date value.</t>
579  </list>
582   or
583  <list style="symbols">
584     <t>The validator is being compared by an intermediate cache to the
[866]585        validator stored in its cache entry for the representation, and</t>
[8]586     <t>That cache entry includes a Date value, which gives the time
587        when the origin server sent the original response, and</t>
588     <t>The presented Last-Modified time is at least 60 seconds before
589        the Date value.</t>
590  </list>
593   This method relies on the fact that if two different responses were
594   sent by the origin server during the same second, but both had the
595   same Last-Modified time, then at least one of those responses would
596   have a Date value equal to its Last-Modified time. The arbitrary 60-second
597   limit guards against the possibility that the Date and Last-Modified
598   values are generated from different clocks, or at somewhat
599   different times during the preparation of the response. An
600   implementation &MAY; use a value larger than 60 seconds, if it is
601   believed that 60 seconds is too short.
604   If a client wishes to perform a sub-range retrieval on a value for
605   which it has only a Last-Modified time and no opaque validator, it
606   &MAY; do this only if the Last-Modified time is strong in the sense
607   described here.
[245]610   A cache or origin server receiving a conditional range request
611   (<xref target="Part5"/>) &MUST; use the strong comparison function to
[8]612   evaluate the condition.
615   These rules allow HTTP/1.1 caches and clients to safely perform sub-range
616   retrievals on values that have been obtained from HTTP/1.0
617   servers.
[874]621<section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="">
623   We adopt a set of rules and recommendations for origin servers,
624   clients, and caches regarding when various validator types ought to
625   be used, and for what purposes.
628   HTTP/1.1 origin servers:
629  <list style="symbols">
[874]630     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
[8]631        generate one.</t>
[874]633     <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if
634        performance considerations support the use of weak entity-tags,
635        or if it is unfeasible to send a strong entity-tag.</t>
637     <t>&SHOULD; send a Last-Modified value if it is feasible to send one,
638        unless the risk of a breakdown in semantic transparency that
639        could result from using this date in an If-Modified-Since header
[994]640        field would lead to serious problems.</t>
[8]641  </list>
644   In other words, the preferred behavior for an HTTP/1.1 origin server
[874]645   is to send both a strong entity-tag and a Last-Modified value.
[1107]648   In order to be legitimate, a strong entity-tag &MUST; change whenever the
[874]649   associated representation changes in any way. A weak entity-tag &SHOULD;
650   change whenever the associated representation changes in a semantically
[8]651   significant way.
654  <t>
[756]655    <x:h>Note:</x:h> In order to provide semantically transparent caching, an
[874]656    origin server must avoid reusing a specific strong entity-tag
657    value for two different representations, or reusing a specific weak
658    entity-tag value for two semantically different representations. Cache
[563]659    entries might persist for arbitrarily long periods, regardless of
660    expiration times, so it might be inappropriate to expect that a
661    cache will never again attempt to validate an entry using a
662    validator that it obtained at some point in the past.
663  </t>
666   HTTP/1.1 clients:
667  <list style="symbols">
[874]668     <t>&MUST; use that entity-tag in any cache-conditional request (using
669        If-Match or If-None-Match) if an entity-tag has been provided by the
[755]670        origin server.</t>
[755]672     <t>&SHOULD; use the Last-Modified value in non-subrange cache-conditional
673        requests (using If-Modified-Since) if only a Last-Modified value has
674        been provided by the origin server. </t>
[755]676     <t>&MAY; use the Last-Modified value in subrange cache-conditional
677        requests (using If-Unmodified-Since) if only a Last-Modified value has
678        been provided by an HTTP/1.0 origin server. The user agent &SHOULD;
[8]679        provide a way to disable this, in case of difficulty.</t>
[755]681     <t>&SHOULD; use both validators in cache-conditional requests if both an
[874]682        entity-tag and a Last-Modified value have been provided by the origin
[755]683        server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond
684        appropriately.</t>
[8]685  </list>
688   An HTTP/1.1 origin server, upon receiving a conditional request that
689   includes both a Last-Modified date (e.g., in an If-Modified-Since or
[874]690   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
[8]691   in an If-Match, If-None-Match, or If-Range header field) as cache
[925]692   validators, &MUST-NOT; return a response status code of 304 (Not Modified)
[8]693   unless doing so is consistent with all of the conditional header
694   fields in the request.
697   An HTTP/1.1 caching proxy, upon receiving a conditional request that
[874]698   includes both a Last-Modified date and one or more entity-tags as
[8]699   cache validators, &MUST-NOT; return a locally cached response to the
700   client unless that cached response is consistent with all of the
701   conditional header fields in the request.
702  <list><t>
703      <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
[969]704      servers and clients ought to transmit as much non-redundant
[8]705      information as is available in their responses and requests.
706      HTTP/1.1 systems receiving this information will make the most
707      conservative assumptions about the validators they receive.
708  </t><t>
[1107]709      HTTP/1.0 clients and caches might ignore entity-tags. Generally,
[8]710      last-modified values received or used by these systems will
711      support transparent and efficient caching, and so HTTP/1.1 origin
712      servers should provide Last-Modified values. In those rare cases
713      where the use of a Last-Modified value as a validator by an
714      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
715      origin servers should not provide one.
716  </t></list>
720<section title="Header Field Definitions" anchor="header.fields">
[117]722   This section defines the syntax and semantics of HTTP/1.1 header fields
723   related to conditional requests.
726<section title="ETag" anchor="header.etag">
[1120]727  <iref primary="true" item="ETag header field" x:for-anchor=""/>
728  <iref primary="true" item="Header Fields" subitem="ETag" x:for-anchor=""/>
[229]729  <x:anchor-alias value="ETag"/>
[362]730  <x:anchor-alias value="ETag-v"/>
[697]732   The "ETag" response-header field provides the current value of the
[874]733   entity-tag (see <xref target="entity.tags"/>) for one representation of
[972]734   the target resource.  An entity-tag
[860]735   is intended for use as a resource-local identifier for differentiating
736   between representations of the same resource that vary over time or via
737   content negotiation (see <xref target="weak.and.strong.validators"/>).
[362]739<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="ETag-v"/>
[366]740  <x:ref>ETag</x:ref>   = "ETag" ":" <x:ref>OWS</x:ref> <x:ref>ETag-v</x:ref>
[362]741  <x:ref>ETag-v</x:ref> = <x:ref>entity-tag</x:ref>
[362]744  Examples:
746<artwork type="example">
[362]747  ETag: "xyzzy"
748  ETag: W/"xyzzy"
749  ETag: ""
[874]752   An entity-tag provides an "opaque" cache validator that allows for
[860]753   more reliable validation than modification dates in situations where
754   it is inconvenient to store modification dates,
[183]755   where the one-second resolution of HTTP date values is not
756   sufficient, or where the origin server wishes to avoid certain
757   paradoxes that might arise from the use of modification dates.
[874]760   The principle behind entity-tags is that only the service author
[183]761   knows the semantics of a resource well enough to select an
762   appropriate cache validation mechanism, and the specification of any
763   validator comparison function more complex than byte-equality would
[994]764   open up a can of worms. Thus, comparisons of any other header fields
[183]765   (except Last-Modified, for compatibility with HTTP/1.0) are never
766   used for purposes of validating a cache entry.
770<section title="If-Match" anchor="header.if-match">
[1120]771  <iref primary="true" item="If-Match header field" x:for-anchor=""/>
772  <iref primary="true" item="Header Fields" subitem="If-Match" x:for-anchor=""/>
[229]773  <x:anchor-alias value="If-Match"/>
[362]774  <x:anchor-alias value="If-Match-v"/>
[698]776   The "If-Match" request-header field is used to make a request method
[874]777   conditional. A client that has one or more representations previously
778   obtained from the resource can verify that one of those representations is
779   current by including a list of their associated entity-tags in the
[698]780   If-Match header field.
783   This allows efficient updates of cached information with a minimum amount of
784   transaction overhead. It is also used when updating resources, to prevent
785   inadvertent modification of the wrong version of a resource. As a special
[874]786   case, the value "*" matches any current representation of the resource.
[362]788<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/>
[366]789  <x:ref>If-Match</x:ref>   = "If-Match" ":" <x:ref>OWS</x:ref> <x:ref>If-Match-v</x:ref>
[362]790  <x:ref>If-Match-v</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
[874]793   If any of the entity-tags match the entity-tag of the representation that
[8]794   would have been returned in the response to a similar GET request
[994]795   (without the If-Match header field) on that resource, or if "*" is given
[874]796   and any current representation exists for that resource, then the server &MAY;
[8]797   perform the requested method as if the If-Match header field did not
798   exist.
[874]801   If none of the entity-tags match, or if "*" is given and no current
[866]802   representation exists, the server &MUST-NOT; perform the requested method, and
[8]803   &MUST; return a 412 (Precondition Failed) response. This behavior is
[1161]804   most useful when the client wants to prevent an updating request method,
805   such as PUT, from modifying a resource that has changed since the client
[8]806   last retrieved it.
809   If the request would, without the If-Match header field, result in
[994]810   anything other than a 2xx or 412 status code, then the If-Match header field
[8]811   &MUST; be ignored.
[1161]814   The meaning of "If-Match: *" is that the request method &SHOULD; be performed
[8]815   if the representation selected by the origin server (or by a cache,
[29]816   possibly using the Vary mechanism, see &header-vary;) exists, and
[8]817   &MUST-NOT; be performed if the representation does not exist.
820   A request intended to update a resource (e.g., a PUT) &MAY; include an
821   If-Match header field to signal that the request method &MUST-NOT; be
[866]822   applied if the representation corresponding to the If-Match value (a single
[874]823   entity-tag) is no longer a representation of that resource. This
[8]824   allows the user to indicate that they do not wish the request to be
825   successful if the resource has been changed without their knowledge.
826   Examples:
828<figure><artwork type="example">
[362]829  If-Match: "xyzzy"
830  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
831  If-Match: *
834   The result of a request having both an If-Match header field and
835   either an If-None-Match or an If-Modified-Since header fields is
836   undefined by this specification.
840<section title="If-Modified-Since" anchor="header.if-modified-since">
[1120]841  <iref primary="true" item="If-Modified-Since header field" x:for-anchor=""/>
842  <iref primary="true" item="Header Fields" subitem="If-Modified-Since" x:for-anchor=""/>
[229]843  <x:anchor-alias value="If-Modified-Since"/>
[362]844  <x:anchor-alias value="If-Modified-Since-v"/>
[698]846   The "If-Modified-Since" request-header field is used to make a request
[860]847   method conditional by date: if the representation that would have been
848   transferred in a 200 response to a GET request has not been modified since
849   the time specified in this field, then do not perform the method;
850   instead, respond as detailed below.
[362]852<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/>
[376]853  <x:ref>If-Modified-Since</x:ref>   = "If-Modified-Since" ":" <x:ref>OWS</x:ref>
854                        <x:ref>If-Modified-Since-v</x:ref>
[362]855  <x:ref>If-Modified-Since-v</x:ref> = <x:ref>HTTP-date</x:ref>
858   An example of the field is:
860<figure><artwork type="example">
[362]861  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
[994]864   A GET method with an If-Modified-Since header field and no Range header
865   field requests that the representation be transferred only if it has
866   been modified since the date given by the If-Modified-Since header field.
[8]867   The algorithm for determining this includes the following cases:
868  <list style="numbers">
869      <t>If the request would normally result in anything other than a
[925]870         200 (OK) status code, or if the passed If-Modified-Since date is
[8]871         invalid, the response is exactly the same as for a normal GET.
872         A date which is later than the server's current time is
873         invalid.</t>
[860]875      <t>If the representation has been modified since the If-Modified-Since
[8]876         date, the response is exactly the same as for a normal GET.</t>
[860]878      <t>If the representation has not been modified since a valid
879         If-Modified-Since date, the server &SHOULD; return a
880         304 (Not Modified) response.</t>
[8]881  </list>
884   The purpose of this feature is to allow efficient updates of cached
885   information with a minimum amount of transaction overhead.
886  <list><t>
887      <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since;
[29]888      see &header-range; for full details.
[8]889    </t><t>
890      <x:h>Note:</x:h> If-Modified-Since times are interpreted by the server, whose
891      clock might not be synchronized with the client.
892    </t><t>
893      <x:h>Note:</x:h> When handling an If-Modified-Since header field, some
894      servers will use an exact date comparison function, rather than a
895      less-than function, for deciding whether to send a 304 (Not
896      Modified) response. To get best results when sending an If-Modified-Since
897      header field for cache validation, clients are
898      advised to use the exact date string received in a previous Last-Modified
899      header field whenever possible.
900    </t><t>
901      <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since
[994]902      header field instead of a date taken from the Last-Modified header field for
[969]903      the same request, the client needs to be aware that this
904      date is interpreted in the server's understanding of time.
905      Unsynchronized clocks and rounding problems, due to the different
906      encodings of time between the client and server, are concerns.
907      This includes the possibility of race conditions if the
[8]908      document has changed between the time it was first requested and
909      the If-Modified-Since date of a subsequent request, and the
910      possibility of clock-skew-related problems if the If-Modified-Since
911      date is derived from the client's clock without correction
912      to the server's clock. Corrections for different time bases
913      between client and server are at best approximate due to network
914      latency.
915    </t>
916  </list>
919   The result of a request having both an If-Modified-Since header field
920   and either an If-Match or an If-Unmodified-Since header fields is
921   undefined by this specification.
925<section title="If-None-Match" anchor="header.if-none-match">
[1120]926  <iref primary="true" item="If-None-Match header field" x:for-anchor=""/>
927  <iref primary="true" item="Header Fields" subitem="If-None-Match" x:for-anchor=""/>
[229]928  <x:anchor-alias value="If-None-Match"/>
[362]929  <x:anchor-alias value="If-None-Match-v"/>
[698]931   The "If-None-Match" request-header field is used to make a request method
[874]932   conditional. A client that has one or more representations previously
933   obtained from the resource can verify that none of those representations is
934   current by including a list of their associated entity-tags in the
[698]935   If-None-Match header field.
938   This allows efficient updates of cached information with a minimum amount of
[1161]939   transaction overhead. It is also used to prevent a request method (e.g., PUT)
[8]940   from inadvertently modifying an existing resource when the client
941   believes that the resource does not exist.
[874]944   As a special case, the value "*" matches any current representation of the
[8]945   resource.
[362]947<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/><iref primary="true" item="Grammar" subitem="If-None-Match-v"/>
[366]948  <x:ref>If-None-Match</x:ref>   = "If-None-Match" ":" <x:ref>OWS</x:ref> <x:ref>If-None-Match-v</x:ref>
[362]949  <x:ref>If-None-Match-v</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
[874]952   If any of the entity-tags match the entity-tag of the representation that
[8]953   would have been returned in the response to a similar GET request
[994]954   (without the If-None-Match header field) on that resource, or if "*" is
[866]955   given and any current representation exists for that resource, then the
[8]956   server &MUST-NOT; perform the requested method, unless required to do
957   so because the resource's modification date fails to match that
958   supplied in an If-Modified-Since header field in the request.
959   Instead, if the request method was GET or HEAD, the server &SHOULD;
960   respond with a 304 (Not Modified) response, including the cache-related
[866]961   header fields (particularly ETag) of one of the representations that
[8]962   matched. For all other request methods, the server &MUST; respond with
[925]963   a 412 (Precondition Failed) status code.
[874]966   If none of the entity-tags match, then the server &MAY; perform the
[8]967   requested method as if the If-None-Match header field did not exist,
968   but &MUST; also ignore any If-Modified-Since header field(s) in the
[874]969   request. That is, if no entity-tags match, then the server &MUST-NOT;
[8]970   return a 304 (Not Modified) response.
973   If the request would, without the If-None-Match header field, result
[925]974   in anything other than a 2xx or 304 status code, then the If-None-Match
[994]975   header field &MUST; be ignored. (See <xref target=""/> for a discussion of
[8]976   server behavior when both If-Modified-Since and If-None-Match appear
977   in the same request.)
[1161]980   The meaning of "If-None-Match: *" is that the request method &MUST-NOT; be
[8]981   performed if the representation selected by the origin server (or by
[29]982   a cache, possibly using the Vary mechanism, see &header-vary;)
[8]983   exists, and &SHOULD; be performed if the representation does not exist.
984   This feature is intended to be useful in preventing races between PUT
985   operations.
988   Examples:
990<figure><artwork type="example">
[362]991  If-None-Match: "xyzzy"
992  If-None-Match: W/"xyzzy"
993  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
994  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
995  If-None-Match: *
998   The result of a request having both an If-None-Match header field and
999   either an If-Match or an If-Unmodified-Since header fields is
1000   undefined by this specification.
1004<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
[1120]1005  <iref primary="true" item="If-Unmodified-Since header field" x:for-anchor=""/>
1006  <iref primary="true" item="Header Fields" subitem="If-Unmodified-Since" x:for-anchor=""/>
[229]1007  <x:anchor-alias value="If-Unmodified-Since"/>
[362]1008  <x:anchor-alias value="If-Unmodified-Since-v"/>
[698]1010   The "If-Unmodified-Since" request-header field is used to make a request
[860]1011   method conditional.  If the representation that would have been transferred
1012   in a 200 response to a GET request on the same resource has not been modified
[8]1013   since the time specified in this field, the server &SHOULD; perform the
[994]1014   requested operation as if the If-Unmodified-Since header field were not
[8]1015   present.
[860]1018   If the representation has been modified since the specified time,
[8]1019   the server &MUST-NOT; perform the requested operation, and &MUST; return
1020   a 412 (Precondition Failed).
[362]1022<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/><iref primary="true" item="Grammar" subitem="If-Unmodified-Since-v"/>
[376]1023  <x:ref>If-Unmodified-Since</x:ref>   = "If-Unmodified-Since" ":" <x:ref>OWS</x:ref>
1024                          <x:ref>If-Unmodified-Since-v</x:ref>
[362]1025  <x:ref>If-Unmodified-Since-v</x:ref> = <x:ref>HTTP-date</x:ref>
1028   An example of the field is:
1030<figure><artwork type="example">
[362]1031  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
1034   If the request normally (i.e., without the If-Unmodified-Since
[994]1035   header field) would result in anything other than a 2xx or 412 status code,
1036   the If-Unmodified-Since header field &SHOULD; be ignored.
[994]1039   If the specified date is invalid, the header field is ignored.
1042   The result of a request having both an If-Unmodified-Since header
1043   field and either an If-None-Match or an If-Modified-Since header
1044   fields is undefined by this specification.
1048<section title="Last-Modified" anchor="header.last-modified">
[1120]1049  <iref primary="true" item="Last-Modified header field" x:for-anchor=""/>
1050  <iref primary="true" item="Header Fields" subitem="Last-Modified" x:for-anchor=""/>
[229]1051  <x:anchor-alias value="Last-Modified"/>
[362]1052  <x:anchor-alias value="Last-Modified-v"/>
[965]1054   The "Last-Modified" header field indicates the date and time at
[860]1055   which the origin server believes the representation was last modified.
[362]1057<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/><iref primary="true" item="Grammar" subitem="Last-Modified-v"/>
[366]1058  <x:ref>Last-Modified</x:ref>   = "Last-Modified" ":" <x:ref>OWS</x:ref> <x:ref>Last-Modified-v</x:ref>
[362]1059  <x:ref>Last-Modified-v</x:ref> = <x:ref>HTTP-date</x:ref>
1062   An example of its use is
1064<figure><artwork type="example">
[362]1065  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
1068   The exact meaning of this header field depends on the implementation
1069   of the origin server and the nature of the original resource. For
[908]1070   files, it might be just the file system last-modified time. For
1071   representations with dynamically included parts, it might be the most recent
[8]1072   of the set of last-modify times for its component parts. For database
[908]1073   gateways, it might be the last-update time stamp of the record. For
1074   virtual objects, it might be the last time the internal state changed.
1077   An origin server &MUST-NOT; send a Last-Modified date which is later
1078   than the server's time of message origination. In such cases, where
1079   the resource's last modification would indicate some time in the
1080   future, the server &MUST; replace that date with the message
1081   origination date.
[866]1084   An origin server &SHOULD; obtain the Last-Modified value of the representation
[8]1085   as close as possible to the time that it generates the Date value of
1086   its response. This allows a recipient to make an accurate assessment
[874]1087   of the representation's modification time, especially if the representation changes
[8]1088   near the time that the response is generated.
1091   HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible.
[965]1094   The Last-Modified header field value is often used as a cache
[183]1095   validator. In simple terms, a cache entry is considered to be valid
[860]1096   if the representation has not been modified since the Last-Modified value.
[29]1102<section title="IANA Considerations" anchor="IANA.considerations">
1104<section title="Status Code Registration" anchor="status.code.registration">
1106   The HTTP Status Code Registry located at <eref target=""/>
[969]1107   shall be updated with the registrations below:
1109<?BEGININC p4-conditional.iana-status-codes ?>
1110<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
1111<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
1112   <ttcol>Value</ttcol>
1113   <ttcol>Description</ttcol>
1114   <ttcol>Reference</ttcol>
1115   <c>304</c>
1116   <c>Not Modified</c>
1117   <c>
1118      <xref target="status.304"/>
1119   </c>
1120   <c>412</c>
1121   <c>Precondition Failed</c>
1122   <c>
1123      <xref target="status.412"/>
1124   </c>
1127<?ENDINC p4-conditional.iana-status-codes ?>
[921]1130<section title="Header Field Registration" anchor="header.field.registration">
[969]1132   The Message Header Field Registry located at <eref target=""/> shall be updated
[290]1133   with the permanent registrations below (see <xref target="RFC3864"/>):
[680]1135<?BEGININC p4-conditional.iana-headers ?>
[253]1136<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
[290]1137<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
[253]1138   <ttcol>Header Field Name</ttcol>
1139   <ttcol>Protocol</ttcol>
1140   <ttcol>Status</ttcol>
1141   <ttcol>Reference</ttcol>
1143   <c>ETag</c>
1144   <c>http</c>
1145   <c>standard</c>
1146   <c>
1147      <xref target="header.etag"/>
1148   </c>
1149   <c>If-Match</c>
1150   <c>http</c>
1151   <c>standard</c>
1152   <c>
1153      <xref target="header.if-match"/>
1154   </c>
1155   <c>If-Modified-Since</c>
1156   <c>http</c>
1157   <c>standard</c>
1158   <c>
1159      <xref target="header.if-modified-since"/>
1160   </c>
1161   <c>If-None-Match</c>
1162   <c>http</c>
1163   <c>standard</c>
1164   <c>
1165      <xref target="header.if-none-match"/>
1166   </c>
1167   <c>If-Unmodified-Since</c>
1168   <c>http</c>
1169   <c>standard</c>
1170   <c>
1171      <xref target="header.if-unmodified-since"/>
1172   </c>
1173   <c>Last-Modified</c>
1174   <c>http</c>
1175   <c>standard</c>
1176   <c>
1177      <xref target="header.last-modified"/>
1178   </c>
[680]1181<?ENDINC p4-conditional.iana-headers ?>
[290]1183   The change controller is: "IETF ( - Internet Engineering Task Force".
1188<section title="Security Considerations" anchor="security.considerations">
[29]1190   No additional security considerations have been identified beyond
1191   those applicable to HTTP in general &messaging;.
1195<section title="Acknowledgments" anchor="ack">
1200<references title="Normative References">
[31]1202<reference anchor="Part1">
[119]1203  <front>
1204    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
1205    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]1206      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1207      <address><email></email></address>
1208    </author>
1209    <author initials="J." surname="Gettys" fullname="Jim Gettys">
[844]1210      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1211      <address><email></email></address>
[119]1212    </author>
1213    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1214      <organization abbrev="HP">Hewlett-Packard Company</organization>
1215      <address><email></email></address>
1216    </author>
1217    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1218      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1219      <address><email></email></address>
1220    </author>
1221    <author initials="L." surname="Masinter" fullname="Larry Masinter">
[1106]1222      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1223      <address><email></email></address>
1224    </author>
1225    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1226      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1227      <address><email></email></address>
1228    </author>
1229    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1230      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1231      <address><email></email></address>
1232    </author>
1233    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1234      <organization abbrev="W3C">World Wide Web Consortium</organization>
1235      <address><email></email></address>
1236    </author>
1237    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1238      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1239      <address><email></email></address>
1240    </author>
1241    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1242  </front>
1243  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
1244  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
[800]1247<reference anchor="Part3">
1248  <front>
1249    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
1250    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]1251      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[800]1252      <address><email></email></address>
1253    </author>
1254    <author initials="J." surname="Gettys" fullname="Jim Gettys">
[844]1255      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1256      <address><email></email></address>
[800]1257    </author>
1258    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1259      <organization abbrev="HP">Hewlett-Packard Company</organization>
1260      <address><email></email></address>
1261    </author>
1262    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1263      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1264      <address><email></email></address>
1265    </author>
1266    <author initials="L." surname="Masinter" fullname="Larry Masinter">
[1106]1267      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[800]1268      <address><email></email></address>
1269    </author>
1270    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1271      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1272      <address><email></email></address>
1273    </author>
1274    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1275      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1276      <address><email></email></address>
1277    </author>
1278    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1279      <organization abbrev="W3C">World Wide Web Consortium</organization>
1280      <address><email></email></address>
1281    </author>
1282    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1283      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1284      <address><email></email></address>
1285    </author>
1286    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1287  </front>
1288  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/>
1289  <x:source href="p3-payload.xml" basename="p3-payload"/>
[31]1292<reference anchor="Part5">
[119]1293  <front>
1294    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
1295    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]1296      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1297      <address><email></email></address>
1298    </author>
1299    <author initials="J." surname="Gettys" fullname="Jim Gettys">
[844]1300      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1301      <address><email></email></address>
[119]1302    </author>
1303    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1304      <organization abbrev="HP">Hewlett-Packard Company</organization>
1305      <address><email></email></address>
1306    </author>
1307    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1308      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1309      <address><email></email></address>
1310    </author>
1311    <author initials="L." surname="Masinter" fullname="Larry Masinter">
[1106]1312      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1313      <address><email></email></address>
1314    </author>
1315    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1316      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1317      <address><email></email></address>
1318    </author>
1319    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1320      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1321      <address><email></email></address>
1322    </author>
1323    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1324      <organization abbrev="W3C">World Wide Web Consortium</organization>
1325      <address><email></email></address>
1326    </author>
1327    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1328      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1329      <address><email></email></address>
1330    </author>
1331    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1332  </front>
1333  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
1334  <x:source href="p5-range.xml" basename="p5-range"/>
1337<reference anchor="Part6">
[119]1338  <front>
1339    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
1340    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
[1106]1341      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1342      <address><email></email></address>
1343    </author>
1344    <author initials="J." surname="Gettys" fullname="Jim Gettys">
[844]1345      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
1346      <address><email></email></address>
[119]1347    </author>
1348    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
1349      <organization abbrev="HP">Hewlett-Packard Company</organization>
1350      <address><email></email></address>
1351    </author>
1352    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
1353      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1354      <address><email></email></address>
1355    </author>
1356    <author initials="L." surname="Masinter" fullname="Larry Masinter">
[1106]1357      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
[119]1358      <address><email></email></address>
1359    </author>
1360    <author initials="P." surname="Leach" fullname="Paul J. Leach">
1361      <organization abbrev="Microsoft">Microsoft Corporation</organization>
1362      <address><email></email></address>
1363    </author>
1364    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
1365      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
1366      <address><email></email></address>
1367    </author>
1368    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1369      <organization abbrev="W3C">World Wide Web Consortium</organization>
1370      <address><email></email></address>
1371    </author>
[601]1372    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1373      <address><email></email></address>
1374    </author>
[119]1375    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1376      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1377      <address><email></email></address>
1378    </author>
1379    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1380  </front>
1381  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
1382  <x:source href="p6-cache.xml" basename="p6-cache"/>
[96]1385<reference anchor="RFC2119">
1386  <front>
1387    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1388    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1389      <organization>Harvard University</organization>
1390      <address><email></email></address>
1391    </author>
1392    <date month="March" year="1997"/>
1393  </front>
1394  <seriesInfo name="BCP" value="14"/>
1395  <seriesInfo name="RFC" value="2119"/>
[425]1398<reference anchor="RFC5234">
1399  <front>
1400    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1401    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1402      <organization>Brandenburg InternetWorking</organization>
1403      <address>
[728]1404        <email></email>
1405      </address> 
[425]1406    </author>
1407    <author initials="P." surname="Overell" fullname="Paul Overell">
1408      <organization>THUS plc.</organization>
1409      <address>
[728]1410        <email></email>
1411      </address>
[425]1412    </author>
1413    <date month="January" year="2008"/>
1414  </front>
1415  <seriesInfo name="STD" value="68"/>
1416  <seriesInfo name="RFC" value="5234"/>
1421<references title="Informative References">
1423<reference anchor="RFC2616">
1424  <front>
1425    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1426    <author initials="R." surname="Fielding" fullname="R. Fielding">
1427      <organization>University of California, Irvine</organization>
1428      <address><email></email></address>
1429    </author>
1430    <author initials="J." surname="Gettys" fullname="J. Gettys">
1431      <organization>W3C</organization>
1432      <address><email></email></address>
1433    </author>
1434    <author initials="J." surname="Mogul" fullname="J. Mogul">
1435      <organization>Compaq Computer Corporation</organization>
1436      <address><email></email></address>
1437    </author>
1438    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1439      <organization>MIT Laboratory for Computer Science</organization>
1440      <address><email></email></address>
1441    </author>
1442    <author initials="L." surname="Masinter" fullname="L. Masinter">
1443      <organization>Xerox Corporation</organization>
1444      <address><email></email></address>
1445    </author>
1446    <author initials="P." surname="Leach" fullname="P. Leach">
1447      <organization>Microsoft Corporation</organization>
1448      <address><email></email></address>
1449    </author>
1450    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1451      <organization>W3C</organization>
1452      <address><email></email></address>
1453    </author>
1454    <date month="June" year="1999"/>
1455  </front>
1456  <seriesInfo name="RFC" value="2616"/>
[253]1459<reference anchor='RFC3864'>
1460  <front>
1461    <title>Registration Procedures for Message Header Fields</title>
1462    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
1463      <organization>Nine by Nine</organization>
1464      <address><email></email></address>
1465    </author>
1466    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
1467      <organization>BEA Systems</organization>
1468      <address><email></email></address>
1469    </author>
1470    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
1471      <organization>HP Labs</organization>
1472      <address><email></email></address>
1473    </author>
1474    <date year='2004' month='September' />
1475  </front>
1476  <seriesInfo name='BCP' value='90' />
1477  <seriesInfo name='RFC' value='3864' />
1482<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
[874]1484  Allow weak entity-tags in all requests except range requests (Sections
[245]1485  <xref target="weak.and.strong.validators" format="counter"/> and
1486  <xref target="header.if-none-match" format="counter"/>).
[680]1490<?BEGININC p4-conditional.abnf-appendix ?>
[427]1491<section xmlns:x="" title="Collected ABNF" anchor="collected.abnf">
1493<artwork type="abnf" name="p4-conditional.parsed-abnf">
1494<x:ref>ETag</x:ref> = "ETag:" OWS ETag-v
1495<x:ref>ETag-v</x:ref> = entity-tag
[678]1497<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part1], Section 6.1&gt;
1499<x:ref>If-Match</x:ref> = "If-Match:" OWS If-Match-v
1500<x:ref>If-Match-v</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1501 entity-tag ] ) )
1502<x:ref>If-Modified-Since</x:ref> = "If-Modified-Since:" OWS If-Modified-Since-v
1503<x:ref>If-Modified-Since-v</x:ref> = HTTP-date
1504<x:ref>If-None-Match</x:ref> = "If-None-Match:" OWS If-None-Match-v
1505<x:ref>If-None-Match-v</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1506 entity-tag ] ) )
1507<x:ref>If-Unmodified-Since</x:ref> = "If-Unmodified-Since:" OWS
1508 If-Unmodified-Since-v
1509<x:ref>If-Unmodified-Since-v</x:ref> = HTTP-date
1511<x:ref>Last-Modified</x:ref> = "Last-Modified:" OWS Last-Modified-v
1512<x:ref>Last-Modified-v</x:ref> = HTTP-date
1514<x:ref>OWS</x:ref> = &lt;OWS, defined in [Part1], Section 1.2.2&gt;
1516<x:ref>entity-tag</x:ref> = [ weak ] opaque-tag
1518<x:ref>opaque-tag</x:ref> = quoted-string
1520<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 1.2.2&gt;
[581]1522<x:ref>weak</x:ref> = %x57.2F ; W/
[532]1525<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
1526; ETag defined but not used
[427]1527; If-Match defined but not used
1528; If-Modified-Since defined but not used
1529; If-None-Match defined but not used
1530; If-Unmodified-Since defined but not used
1531; Last-Modified defined but not used
[680]1533<?ENDINC p4-conditional.abnf-appendix ?>
[252]1535<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
[1002]1537<section title="Since RFC 2616">
1539  Extracted relevant partitions from <xref target="RFC2616"/>.
1543<section title="Since draft-ietf-httpbis-p4-conditional-00">
[152]1545  Closed issues:
1546  <list style="symbols"> 
1547    <t>
[324]1548      <eref target=""/>:
[152]1549      "Normative and Informative references"
1550    </t>
1551  </list>
[116]1554  Other changes:
1555  <list style="symbols"> 
1556    <t>
1557      Move definitions of 304 and 412 condition codes from Part2.
1558    </t>
1559  </list>
[170]1563<section title="Since draft-ietf-httpbis-p4-conditional-01">
[324]1565  Ongoing work on ABNF conversion (<eref target=""/>):
[205]1566  <list style="symbols"> 
1567    <t>
1568      Add explicit references to BNF syntax and rules imported from other parts of the specification.
1569    </t>
1570  </list>
[252]1574<section title="Since draft-ietf-httpbis-p4-conditional-02" anchor="changes.since.02">
[245]1576  Closed issues:
1577  <list style="symbols"> 
1578    <t>
[324]1579      <eref target=""/>:
[245]1580      "Weak ETags on non-GET requests"
1581    </t>
1582  </list>
[994]1585  Ongoing work on IANA Message Header Field Registration (<eref target=""/>):
[253]1586  <list style="symbols"> 
1587    <t>
[994]1588      Reference RFC 3984, and update header field registrations for header fields defined
[253]1589      in this document.
1590    </t>
1591  </list>
[267]1595<section title="Since draft-ietf-httpbis-p4-conditional-03" anchor="changes.since.03">
[298]1597  Closed issues:
1598  <list style="symbols"> 
1599    <t>
[324]1600      <eref target=""/>:
[298]1601      "Examples for ETag matching"
1602    </t>
[302]1603    <t>
[324]1604      <eref target=""/>:
[302]1605      "'entity value' undefined"
1606    </t>
[306]1607    <t>
[324]1608      <eref target=""/>:
[306]1609      "bogus 2068 Date header reference"
1610    </t>
[298]1611  </list>
[323]1615<section title="Since draft-ietf-httpbis-p4-conditional-04" anchor="changes.since.04">
[334]1617  Ongoing work on ABNF conversion (<eref target=""/>):
1618  <list style="symbols"> 
1619    <t>
1620      Use "/" instead of "|" for alternatives.
1621    </t>
[362]1622    <t>
1623      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1624      whitespace ("OWS") and required whitespace ("RWS").
1625    </t>
1626    <t>
1627      Rewrite ABNFs to spell out whitespace rules, factor out
[994]1628      header field value format definitions.
[362]1629    </t>
[334]1630  </list>
[382]1634<section title="Since draft-ietf-httpbis-p4-conditional-05" anchor="changes.since.05">
[543]1636  Final work on ABNF conversion (<eref target=""/>):
[421]1637  <list style="symbols"> 
1638    <t>
[424]1639      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
[421]1640    </t>
1641  </list>
[547]1645<section title="Since draft-ietf-httpbis-p4-conditional-06" anchor="changes.since.06">
[570]1647  Closed issues:
1648  <list style="symbols"> 
1649    <t>
1650      <eref target=""/>:
1651      "case-sensitivity of etag weakness indicator"
1652    </t>
1653  </list>
[604]1657<section title="Since draft-ietf-httpbis-p4-conditional-07" anchor="changes.since.07">
[656]1659  Closed issues:
1660  <list style="symbols"> 
1661    <t>
1662      <eref target=""/>:
1663      "Weak ETags on non-GET requests" (If-Match still was defined to require
1664      strong matching)
1665    </t>
[700]1666    <t>
1667      <eref target=""/>:
1668      "move IANA registrations for optional status codes"
1669    </t>
[656]1670  </list>
[720]1674<section title="Since draft-ietf-httpbis-p4-conditional-08" anchor="changes.since.08">
[765]1676  No significant changes.
[773]1680<section title="Since draft-ietf-httpbis-p4-conditional-09" anchor="changes.since.09">
[841]1682  No significant changes.
1686<section title="Since draft-ietf-httpbis-p4-conditional-10" anchor="changes.since.10">
[863]1688  Closed issues:
1689  <list style="symbols"> 
1690    <t>
1691      <eref target=""/>:
1692      "Clarify 'Requested Variant'"
1693    </t>
1694    <t>
1695      <eref target=""/>:
1696      "Clarify entity / representation / variant terminology"
1697    </t>
[911]1698    <t>
1699      <eref target=""/>:
1700      "consider removing the 'changes from 2068' sections"
1701    </t>
[863]1702  </list>
[973]1706<section title="Since draft-ietf-httpbis-p4-conditional-11" anchor="changes.since.11">
[1052]1708  None.
1712<section title="Since draft-ietf-httpbis-p4-conditional-12" anchor="changes.since.12">
[973]1714  None yet.
Note: See TracBrowser for help on using the repository browser.