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

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

revert changes for auth48 boilerplate checks (#553)

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 69.0 KB
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
3<!DOCTYPE rfc [
4  <!ENTITY MAY "<bcp14 xmlns=''>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>">
14  <!ENTITY ID-VERSION "latest">
15  <!ENTITY ID-MONTH "June">
16  <!ENTITY ID-YEAR "2014">
17  <!ENTITY mdash "&#8212;">
18  <!ENTITY Note "<x:h xmlns:x=''>Note:</x:h>">
19  <!ENTITY architecture               "<xref target='RFC7230' x:rel='#architecture' xmlns:x=''/>">
20  <!ENTITY conformance                "<xref target='RFC7230' x:rel='#conformance' xmlns:x=''/>">
21  <!ENTITY notation                   "<xref target='RFC7230' x:rel='#notation' xmlns:x=''/>">
22  <!ENTITY abnf-extension             "<xref target='RFC7230' x:rel='#abnf.extension' xmlns:x=''/>">
23  <!ENTITY acks                       "<xref target='RFC7230' x:rel='#acks' xmlns:x=''/>">
24  <!ENTITY whitespace                 "<xref target='RFC7230' x:rel='#whitespace' xmlns:x=''/>">
25  <!ENTITY field-components           "<xref target='RFC7230' x:rel='#field.components' xmlns:x=''/>">
26  <!ENTITY header-date                "<xref target='RFC7231' x:rel='' xmlns:x=''/>">
27  <!ENTITY safe-methods               "<xref target='RFC7231' x:rel='#safe.methods' xmlns:x=''/>">
28  <!ENTITY representation             "<xref target='RFC7231' x:rel='#representations' xmlns:x=''/>">
29  <!ENTITY messaging                  "<xref target='RFC7230' xmlns:x=''/>">
30  <!ENTITY semantics                  "<xref target='RFC7231' xmlns:x=''/>">
31  <!ENTITY caching                    "<xref target='RFC7234' xmlns:x=''/>">
32  <!ENTITY cache-key                  "<xref target='RFC7234' x:rel='#constructing.responses.from.caches' xmlns:x=''/>">
33  <!ENTITY cache-validation-received  "<xref target='RFC7234' x:rel='#validation.received' xmlns:x=''/>">
34  <!ENTITY freshening-responses       "<xref target='RFC7234' x:rel='#freshening.responses' xmlns:x=''/>">
35  <!ENTITY header-accept-encoding     "<xref target='RFC7231' x:rel='#header.accept-encoding' xmlns:x=''/>">
36  <!ENTITY header-if-range            "<xref target='RFC7233' x:rel='#header.if-range' xmlns:x=''/>">
37  <!ENTITY header-range               "<xref target='RFC7233' x:rel='#header.range' xmlns:x=''/>">
38  <!ENTITY header-vary                "<xref target='RFC7231' x:rel='#header.vary' xmlns:x=''/>">
39  <!ENTITY http-date                  "<xref target='RFC7231' x:rel='' xmlns:x=''/>">
40  <!ENTITY transfer-codings           "<xref target='RFC7230' x:rel='#transfer.codings' xmlns:x=''/>">
41  <!ENTITY content-negotiation        "<xref target='RFC7231' x:rel='#content.negotiation' xmlns:x=''/>">
43<?rfc toc="yes" ?>
44<?rfc symrefs="yes" ?>
45<?rfc sortrefs="yes" ?>
46<?rfc compact="yes"?>
47<?rfc subcompact="no" ?>
48<?rfc linkmailto="no" ?>
49<?rfc editing="no" ?>
50<?rfc comments="yes"?>
51<?rfc inline="yes"?>
52<?rfc rfcedstyle="yes"?>
53<?rfc-ext allow-markup-in-artwork="yes" ?>
54<?rfc-ext include-references-in-index="yes" ?>
55<rfc obsoletes="2616" category="std" x:maturity-level="proposed"
56     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"
57     xmlns:x=''>
58<x:link rel="Alternate" title="RFC7232" href=""/>
59<x:link rel="prev" basename="p2-semantics"/>
60<x:link rel="next" basename="p5-range"/>
61<x:feedback template="{docname},%20%22{section}%22&amp;body=&lt;{ref}&gt;:"/>
64  <title abbrev="HTTP/1.1 Conditional Requests">Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
66  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
67    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
68    <address>
69      <postal>
70        <street>345 Park Ave</street>
71        <city>San Jose</city>
72        <region>CA</region>
73        <code>95110</code>
74        <country>USA</country>
75      </postal>
76      <email></email>
77      <uri></uri>
78    </address>
79  </author>
81  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
82    <organization abbrev="greenbytes">greenbytes GmbH</organization>
83    <address>
84      <postal>
85        <street>Hafenweg 16</street>
86        <city>Muenster</city><region>NW</region><code>48155</code>
87        <country>Germany</country>
88      </postal>
89      <email></email>
90      <uri></uri>
91    </address>
92  </author>
94  <date month="&ID-MONTH;" year="&ID-YEAR;"/>
96  <area>Applications</area>
97  <workgroup>HTTPbis</workgroup>
99  <keyword>Hypertext Transfer Protocol</keyword>
100  <keyword>HTTP</keyword>
101  <keyword>HTTP conditional requests</keyword>
105   The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for
106   distributed, collaborative, hypertext information systems. This document
107   defines HTTP/1.1 conditional requests, including metadata header fields
108   for indicating state changes, request header fields for making
109   preconditions on such state, and rules for constructing the responses to a
110   conditional request when one or more preconditions evaluate to false.
114<note title="Editorial Note (To be removed by RFC Editor)">
115  <t>
116    Discussion of this draft takes place on the HTTPBIS working group
117    mailing list (, which is archived at
118    <eref target=""/>.
119  </t>
120  <t>
121    The current issues list is at
122    <eref target=""/> and related
123    documents (including fancy diffs) can be found at
124    <eref target=""/>.
125  </t>
126  <t>
127    <spanx>This is a temporary document for the purpose of tracking the editorial changes made during the AUTH48 (RFC publication) phase.</spanx>
128  </t>
133<section title="Introduction" anchor="introduction">
135   Conditional requests are HTTP requests <xref target="RFC7231"/> that include
136   one or more header fields indicating a precondition to be tested before
137   applying the method semantics to the target resource.
138   This document defines the HTTP/1.1 conditional request mechanisms in terms
139   of the architecture, syntax notation, and conformance criteria defined in
140   <xref target="RFC7230"/>.
143   Conditional GET requests are the most efficient mechanism for HTTP
144   cache updates &caching;.  Conditionals can also be
145   applied to state-changing methods, such as PUT and DELETE, to prevent
146   the "lost update" problem: one client accidentally overwriting
147   the work of another client that has been acting in parallel.
149<t><iref primary="true" item="selected representation"/>
150   Conditional request preconditions are based on the state of the target
151   resource as a whole (its current value set) or the state as observed
152   in a previously obtained representation (one value in that set).
153   A resource might have multiple current representations, each with its
154   own observable state.  The conditional request mechanisms assume that
155   the mapping of requests to a "selected representation" (&representation;)
156   will be consistent over time if the server intends to take advantage of
157   conditionals. Regardless, if the mapping is inconsistent and the server is
158   unable to select the appropriate representation, then no harm will result
159   when the precondition evaluates to false.
162   The conditional request preconditions defined by this specification
163   (<xref target="preconditions"/>) are evaluated when applicable to the
164   recipient (<xref target="evaluation"/>) according to their order of
165   precedence (<xref target="precedence"/>).
168<section title="Conformance and Error Handling" anchor="conformance">
170   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
171   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
172   document are to be interpreted as described in <xref target="RFC2119"/>.
175   Conformance criteria and considerations regarding error handling
176   are defined in &conformance;.
180<section title="Syntax Notation" anchor="notation">
182   This specification uses the Augmented Backus-Naur Form (ABNF) notation of
183   <xref target="RFC5234"/> with a list extension, defined in
184   &abnf-extension;, that allows for compact definition of
185   comma-separated lists using a '#' operator (similar to how the '*' operator
186   indicates repetition).
187   <xref target="imported.abnf"/> describes rules imported from
188   other documents.
189   <xref target="collected.abnf"/> shows the collected grammar with all list
190   operators expanded to standard ABNF notation.
195<section title="Validators" anchor="validators">
196   <iref primary="true" item="metadata"/>
197   <iref primary="true" item="validator"/>
199   This specification defines two forms of metadata that are commonly used
200   to observe resource state and test for preconditions: modification dates
201   (<xref target="header.last-modified"/>) and opaque entity tags
202   (<xref target="header.etag"/>).  Additional metadata that reflects resource state
203   has been defined by various extensions of HTTP, such as Web Distributed
204   Authoring and Versioning (WebDAV, <xref target="RFC4918"/>), that are beyond the scope of this specification.
205   A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>"
206   when it is used within a precondition.
209<section title="Weak versus Strong" anchor="weak.and.strong.validators">
210   <iref primary="true" item="validator" subitem="weak"/>
211   <iref primary="true" item="validator" subitem="strong"/>
213   Validators come in two flavors: strong or weak.  Weak validators are easy
214   to generate but are far less useful for comparisons.  Strong validators
215   are ideal for comparisons but can be very difficult (and occasionally
216   impossible) to generate efficiently.  Rather than impose that all forms
217   of resource adhere to the same strength of validator, HTTP exposes the
218   type of validator in use and imposes restrictions on when weak validators
219   can be used as preconditions.
222   A "strong validator" is representation metadata that changes value whenever
223   a change occurs to the representation data that would be observable in the
224   payload body of a <x:ref>200 (OK)</x:ref> response to GET.
227   A strong validator might change for reasons other than a change to the
228   representation data, such as when a
229   semantically significant part of the representation metadata is changed
230   (e.g., <x:ref>Content-Type</x:ref>), but it is in the best interests of the
231   origin server to only change the value when it is necessary to invalidate
232   the stored responses held by remote caches and authoring tools.
235   Cache entries might persist for arbitrarily long periods, regardless
236   of expiration times.  Thus, a cache might attempt to validate an
237   entry using a validator that it obtained in the distant past.
238   A strong validator is unique across all versions of all
239   representations associated with a particular resource over time.
240   However, there is no implication of uniqueness across representations
241   of different resources (i.e., the same strong validator might be
242   in use for representations of multiple resources at the same time
243   and does not imply that those representations are equivalent).
246   There are a variety of strong validators used in practice.  The best are
247   based on strict revision control, wherein each change to a representation
248   always results in a unique node name and revision identifier being assigned
249   before the representation is made accessible to GET.  A collision-resistant hash
250   function applied to the representation data is also sufficient if the data
251   is available prior to the response header fields being sent and the digest
252   does not need to be recalculated every time a validation request is
253   received.  However, if a resource has distinct representations that differ
254   only in their metadata, such as might occur with content negotiation over
255   media types that happen to share the same data format, then the origin
256   server needs to incorporate additional information in the validator to
257   distinguish those representations.
260   In contrast, a "weak validator" is representation metadata that
261   might not change for every change to the representation data.  This
262   weakness might be due to limitations in how the value is calculated, such
263   as clock resolution, an inability to ensure uniqueness for all possible
264   representations of the resource, or a desire of the resource owner
265   to group representations by some self-determined set of equivalency
266   rather than unique sequences of data.  An origin server &SHOULD; change a
267   weak entity-tag whenever it considers prior representations to be
268   unacceptable as a substitute for the current representation. In other words,
269   a weak entity-tag ought to change whenever the origin server wants caches to
270   invalidate old responses.
273   For example, the representation of a weather report that changes in
274   content every second, based on dynamic measurements, might be grouped
275   into sets of equivalent representations (from the origin server's
276   perspective) with the same weak validator in order to allow cached
277   representations to be valid for a reasonable period of time (perhaps
278   adjusted dynamically based on server load or weather quality).
279   Likewise, a representation's modification time, if defined with only
280   one-second resolution, might be a weak validator if it is possible
281   for the representation to be modified twice during a single second and
282   retrieved between those modifications.
285   Likewise, a validator is weak if it is shared by two or more
286   representations of a given resource at the same time, unless those
287   representations have identical representation data. For example, if the
288   origin server sends the same validator for a representation with a gzip
289   content coding applied as it does for a representation with no content
290   coding, then that validator is weak. However, two simultaneous
291   representations might share the same strong validator if they differ only
292   in the representation metadata, such as when two different media types are
293   available for the same representation data.
296   Strong validators are usable for all conditional requests, including cache
297   validation, partial content ranges, and "lost update" avoidance.
298   Weak validators are only usable when the client does not require exact
299   equality with previously obtained representation data, such as when
300   validating a cache entry or limiting a web traversal to recent changes.
304<section title="Last-Modified" anchor="header.last-modified">
305  <iref primary="true" item="Last-Modified header field" x:for-anchor=""/>
306  <x:anchor-alias value="Last-Modified"/>
308   The "Last-Modified" header field in a response provides a timestamp
309   indicating the date and time at which the origin server believes the
310   selected representation was last modified, as determined at the conclusion
311   of handling the request.
313<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/>
314  <x:ref>Last-Modified</x:ref> = <x:ref>HTTP-date</x:ref>
317   An example of its use is
319<figure><artwork type="example">
320  Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
323<section title="Generation" anchor="lastmod.generation">
325   An origin server &SHOULD; send Last-Modified for any selected
326   representation for which a last modification date can be reasonably
327   and consistently determined, since its use in conditional requests
328   and evaluating cache freshness (&caching;) results in a substantial
329   reduction of HTTP traffic on the Internet and can be a significant
330   factor in improving service scalability and reliability.
333   A representation is typically the sum of many parts behind the
334   resource interface.  The last-modified time would usually be
335   the most recent time that any of those parts were changed.
336   How that value is determined for any given resource is an
337   implementation detail beyond the scope of this specification.
338   What matters to HTTP is how recipients of the Last-Modified
339   header field can use its value to make conditional requests
340   and test the validity of locally cached responses.
343   An origin server &SHOULD; obtain the Last-Modified value of the
344   representation as close as possible to the time that it generates the
345   <x:ref>Date</x:ref> field value for its response. This allows a recipient to
346   make an accurate assessment of the representation's modification time,
347   especially if the representation changes near the time that the
348   response is generated.
351   An origin server with a clock &MUST-NOT; send a Last-Modified date
352   that is later than the server's time of message origination (<x:ref>Date</x:ref>).
353   If the last modification time is derived from implementation-specific
354   metadata that evaluates to some time in the future, according to the
355   origin server's clock, then the origin server &MUST; replace that
356   value with the message origination date. This prevents a future
357   modification date from having an adverse impact on cache validation.
360   An origin server without a clock &MUST-NOT; assign Last-Modified
361   values to a response unless these values were associated
362   with the resource by some other system or user with a reliable clock.
366<section title="Comparison" anchor="lastmod.comparison">
368   A Last-Modified time, when used as a validator in a request, is
369   implicitly weak unless it is possible to deduce that it is strong,
370   using the following rules:
371  <list style="symbols">
372     <t>The validator is being compared by an origin server to the
373        actual current validator for the representation and,</t>
374     <t>That origin server reliably knows that the associated representation did
375        not change twice during the second covered by the presented
376        validator.</t>
377  </list>
380   or
381  <list style="symbols">
382     <t>The validator is about to be used by a client in an <x:ref>If-Modified-Since</x:ref>,
383        <x:ref>If-Unmodified-Since</x:ref>, or <x:ref>If-Range</x:ref> header
384        field, because the client has a cache entry for the associated
385        representation, and</t>
386     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
387        time when the origin server sent the original response, and</t>
388     <t>The presented Last-Modified time is at least 60 seconds before
389        the Date value.</t>
390  </list>
393   or
394  <list style="symbols">
395     <t>The validator is being compared by an intermediate cache to the
396        validator stored in its cache entry for the representation, and</t>
397     <t>That cache entry includes a <x:ref>Date</x:ref> value, which gives the
398        time when the origin server sent the original response, and</t>
399     <t>The presented Last-Modified time is at least 60 seconds before
400        the Date value.</t>
401  </list>
404   This method relies on the fact that if two different responses were
405   sent by the origin server during the same second, but both had the
406   same Last-Modified time, then at least one of those responses would
407   have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
408   arbitrary 60-second limit guards against the possibility that the Date and
409   Last-Modified values are generated from different clocks or at somewhat
410   different times during the preparation of the response. An
411   implementation &MAY; use a value larger than 60 seconds, if it is
412   believed that 60 seconds is too short.
417<section title="ETag" anchor="header.etag">
418  <iref primary="true" item="ETag header field" x:for-anchor=""/>
419  <x:anchor-alias value="ETag"/>
420  <x:anchor-alias value="entity-tag"/>
421  <x:anchor-alias value="opaque-tag"/>
422  <x:anchor-alias value="weak"/>
423  <x:anchor-alias value="etagc"/>
425   The "ETag" header field in a response provides the current entity-tag for
426   the selected representation, as determined at the conclusion of handling
427   the request.
428   An entity-tag is an opaque validator for differentiating between
429   multiple representations of the same resource, regardless of whether
430   those multiple representations are due to resource state changes over
431   time, content negotiation resulting in multiple representations being
432   valid at the same time, or both. An entity-tag consists of an opaque
433   quoted string, possibly prefixed by a weakness indicator.
435<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/><iref primary="true" item="Grammar" subitem="etagc"/>
436  <x:ref>ETag</x:ref>       = <x:ref>entity-tag</x:ref>
438  <x:ref>entity-tag</x:ref> = [ <x:ref>weak</x:ref> ] <x:ref>opaque-tag</x:ref>
439  <x:ref>weak</x:ref>       = <x:abnf-char-sequence>"W/"</x:abnf-char-sequence> ; "W/", case-sensitive
440  <x:ref>opaque-tag</x:ref> = <x:ref>DQUOTE</x:ref> *<x:ref>etagc</x:ref> <x:ref>DQUOTE</x:ref>
441  <x:ref>etagc</x:ref>      = %x21 / %x23-7E / <x:ref>obs-text</x:ref>
442             ; <x:ref>VCHAR</x:ref> except double quotes, plus obs-text
445  <t>
446    &Note; Previously, opaque-tag was defined to be a quoted-string
447    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>); thus, some recipients
448    might perform backslash unescaping. Servers therefore ought to avoid
449    backslash characters in entity tags.
450  </t>
453   An entity-tag can be more reliable for validation than a modification
454   date in situations where it is inconvenient to store modification
455   dates, where the one-second resolution of HTTP date values is not
456   sufficient, or where modification dates are not consistently maintained.
459  Examples:
461<artwork type="example">
462  ETag: "xyzzy"
463  ETag: W/"xyzzy"
464  ETag: ""
467   An entity-tag can be either a weak or strong validator, with
468   strong being the default.  If an origin server provides an entity-tag
469   for a representation and the generation of that entity-tag does not satisfy
470   all of the characteristics of a strong validator
471   (<xref target="weak.and.strong.validators"/>), then the origin server
472   &MUST; mark the entity-tag as weak by prefixing its opaque value
473   with "W/" (case-sensitive).
476<section title="Generation" anchor="entity.tag.generation">
478   The principle behind entity-tags is that only the service author
479   knows the implementation of a resource well enough to select the
480   most accurate and efficient validation mechanism for that resource,
481   and that any such mechanism can be mapped to a simple sequence of
482   octets for easy comparison.  Since the value is opaque, there is no
483   need for the client to be aware of how each entity-tag is constructed.
486   For example, a resource that has implementation-specific versioning
487   applied to all changes might use an internal revision number, perhaps
488   combined with a variance identifier for content negotiation, to
489   accurately differentiate between representations.
490   Other implementations might use a collision-resistant hash of
491   representation content, a combination of various file attributes, or
492   a modification timestamp that has sub-second resolution.
495   An origin server &SHOULD; send an ETag for any selected representation
496   for which detection of changes can be reasonably and consistently
497   determined, since the entity-tag's use in conditional requests and
498   evaluating cache freshness (&caching;) can result in a substantial
499   reduction of HTTP network traffic and can be a significant factor in
500   improving service scalability and reliability.
504<section title="Comparison" anchor="entity.tag.comparison">
505  <x:anchor-alias value="validator.comparison"/>
506  <x:anchor-alias value="strong comparison"/>
507  <x:anchor-alias value="weak comparison"/>
509   There are two entity-tag comparison functions, depending on whether or not
510   the comparison context allows the use of weak validators:
511  <list style="symbols">
512     <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
513        are not weak and their opaque-tags match character-by-character.</t>
514     <t><x:dfn>Weak comparison</x:dfn>: two entity-tags are equivalent if their opaque-tags
515        match character-by-character, regardless of either or both
516        being tagged as "weak".</t>
517  </list>
520   The example below shows the results for a set of entity-tag pairs and both
521   the weak and strong comparison function results:
523<texttable align="left">
524  <ttcol>ETag 1</ttcol>
525  <ttcol>ETag 2</ttcol>
526  <ttcol>Strong Comparison</ttcol>
527  <ttcol>Weak Comparison</ttcol>
529  <c>W/"1"</c>
530  <c>W/"1"</c>
531  <c>no match</c>
532  <c>match</c>
534  <c>W/"1"</c>
535  <c>W/"2"</c>
536  <c>no match</c>
537  <c>no match</c>
539  <c>W/"1"</c>
540  <c>"1"</c>
541  <c>no match</c>
542  <c>match</c>
544  <c>"1"</c>
545  <c>"1"</c>
546  <c>match</c>
547  <c>match</c>
551<section title="Example: Entity-Tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
553   Consider a resource that is subject to content negotiation
554   (&content-negotiation;), and where the representations sent in response to
555   a GET request vary based on the <x:ref>Accept-Encoding</x:ref> request
556   header field (&header-accept-encoding;):
558<figure><preamble>>> Request:</preamble><artwork type="message/http; msgtype=&#34;request&#34;"  x:indent-with="  ">
559GET /index HTTP/1.1
561Accept-Encoding: gzip
565   In this case, the response might or might not use the gzip content coding.
566   If it does not, the response might look like:
568<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
569HTTP/1.1 200 OK
570Date: Fri, 26 Mar 2010 00:05:00 GMT
571ETag: "123-a"
572Content-Length: <x:length-of target="exbody"/>
573Vary: Accept-Encoding
574Content-Type: text/plain
576<x:span anchor="exbody">Hello World!
577Hello World!
578Hello World!
579Hello World!
580Hello World!
583   An alternative representation that does use gzip content coding would be:
585<figure><preamble>>> Response:</preamble><artwork type="message/http; msgtype=&#34;response&#34;"  x:indent-with="  ">
586HTTP/1.1 200 OK
587Date: Fri, 26 Mar 2010 00:05:00 GMT
588ETag: "123-b"
589Content-Length: 43
590Vary: Accept-Encoding
591Content-Type: text/plain
592Content-Encoding: gzip
594<spanx>...binary data...</spanx></artwork></figure>
596  <t>
597    &Note; Content codings are a property of the representation data,
598    so a strong entity-tag for a content-encoded representation has to be
599    distinct from the entity tag of an unencoded representation to prevent
600    potential conflicts during cache updates and range requests. In contrast,
601    transfer codings (&transfer-codings;) apply only during message transfer
602    and do not result in distinct entity-tags.
603  </t>
608<section title="When to Use Entity-Tags and Last-Modified Dates" anchor="">
610   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
611  <list style="symbols">
612     <t>&SHOULD; send an entity-tag validator unless it is not feasible to
613        generate one.</t>
615     <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if
616        performance considerations support the use of weak entity-tags,
617        or if it is unfeasible to send a strong entity-tag.</t>
619     <t>&SHOULD; send a <x:ref>Last-Modified</x:ref> value if it is feasible to
620        send one.</t>
621  </list>
624   In other words, the preferred behavior for an origin server
625   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref>
626   value in successful responses to a retrieval request.
629   A client:
630  <list style="symbols">
631     <t>&MUST; send that entity-tag in any cache validation request (using
632        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
633        entity-tag has been provided by the origin server.</t>
635     <t>&SHOULD; send the <x:ref>Last-Modified</x:ref> value in non-subrange
636        cache validation requests (using <x:ref>If-Modified-Since</x:ref>)
637        if only a Last-Modified value has been provided by the origin server.</t>
639     <t>&MAY; send the <x:ref>Last-Modified</x:ref> value in subrange
640        cache validation requests (using <x:ref>If-Unmodified-Since</x:ref>)
641        if only a Last-Modified value has been provided by an HTTP/1.0 origin
642        server. The user agent &SHOULD; provide a way to disable this, in case
643        of difficulty.</t>
645     <t>&SHOULD; send both validators in cache validation requests if both an
646        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
647        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
648        respond appropriately.</t>
649  </list>
654<section title="Precondition Header Fields" anchor="preconditions">
656   This section defines the syntax and semantics of HTTP/1.1 header fields
657   for applying preconditions on requests.
658   <xref target="evaluation"/> defines when the preconditions are applied.
659   <xref target="precedence"/> defines the order of evaluation when more than
660   one precondition is present.
663<section title="If-Match" anchor="header.if-match">
664  <iref primary="true" item="If-Match header field" x:for-anchor=""/>
665  <x:anchor-alias value="If-Match"/>
667   The "If-Match" header field makes the request method conditional on the
668   recipient origin server either having at least one current
669   representation of the target resource, when the field-value is "*", or
670   having a current representation of the target resource that has an
671   entity-tag matching a member of the list of entity-tags provided in the
672   field-value.
675   An origin server &MUST; use the strong comparison function when comparing
676   entity-tags for If-Match (<xref target="entity.tag.comparison"/>), since
677   the client intends this precondition to prevent the method from being
678   applied if there have been any changes to the representation data.
680<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
681  <x:ref>If-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
684   Examples:
686<figure><artwork type="example">
687  If-Match: "xyzzy"
688  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
689  If-Match: *
692   If-Match is most often used with state-changing methods (e.g., POST, PUT,
693   DELETE) to prevent accidental overwrites when multiple user agents might be
694   acting in parallel on the same resource (i.e., to prevent the "lost update"
695   problem). It can also be used with safe methods to abort a request if the
696   <x:ref>selected representation</x:ref> does not match one already stored
697   (or partially stored) from a prior request.
700   An origin server that receives an If-Match header field &MUST; evaluate the
701   condition prior to performing the method (<xref target="evaluation"/>).
702   If the field-value is "*", the condition is false if the origin server
703   does not have a current representation for the target resource.
704   If the field-value is a list of entity-tags, the condition is false if
705   none of the listed tags match the entity-tag of the selected representation.
708   An origin server &MUST-NOT; perform the requested method if a received
709   If-Match condition evaluates to false; instead, the origin server &MUST;
710   respond with either
711   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
712   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
713   server has verified that a state change is being requested and the final
714   state is already reflected in the current state of the target resource
715   (i.e., the change requested by the user agent has already succeeded, but
716   the user agent might not be aware of it, perhaps because the prior response
717   was lost or a compatible change was made by some other user agent).
718   In the latter case, the origin server &MUST-NOT; send a validator header
719   field in the response unless it can verify that the request is a duplicate
720   of an immediately prior change made by the same user agent.
723   The If-Match header field can be ignored by caches and intermediaries
724   because it is not applicable to a stored response.
728<section title="If-None-Match" anchor="header.if-none-match">
729  <iref primary="true" item="If-None-Match header field" x:for-anchor=""/>
730  <x:anchor-alias value="If-None-Match"/>
732   The "If-None-Match" header field makes the request method conditional on
733   a recipient cache or origin server either not having any current
734   representation of the target resource, when the field-value is "*", or
735   having a selected representation with an entity-tag that does not match any
736   of those listed in the field-value.
739   A recipient &MUST; use the weak comparison function when comparing
740   entity-tags for If-None-Match (<xref target="entity.tag.comparison"/>),
741   since weak entity-tags can be used for cache validation even if there have
742   been changes to the representation data.
744<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>
745  <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>
748   Examples:
750<figure><artwork type="example">
751  If-None-Match: "xyzzy"
752  If-None-Match: W/"xyzzy"
753  If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
754  If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
755  If-None-Match: *
758   If-None-Match is primarily used in conditional GET requests to enable
759   efficient updates of cached information with a minimum amount of
760   transaction overhead. When a client desires to update one or more stored
761   responses that have entity-tags, the client &SHOULD; generate an
762   If-None-Match header field containing a list of those entity-tags when
763   making a GET request; this allows recipient servers to send a
764   <x:ref>304 (Not Modified)</x:ref> response to indicate when one of those
765   stored responses matches the selected representation.
768   If-None-Match can also be used with a value of "*" to prevent an unsafe
769   request method (e.g., PUT) from inadvertently modifying an existing
770   representation of the target resource when the client believes that
771   the resource does not have a current representation (&safe-methods;).
772   This is a variation on the "lost update" problem that might arise if more
773   than one client attempts to create an initial representation for the target
774   resource.
777   An origin server that receives an If-None-Match header field &MUST;
778   evaluate the condition prior to performing the method
779   (<xref target="evaluation"/>).
780   If the field-value is "*", the condition is false if the origin server
781   has a current representation for the target resource.
782   If the field-value is a list of entity-tags, the condition is false if
783   one of the listed tags match the entity-tag of the selected representation.
786   An origin server &MUST-NOT; perform the requested method if the condition
787   evaluates to false; instead, the origin server &MUST; respond with either
788   a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method
789   is GET or HEAD or b) the <x:ref>412 (Precondition Failed)</x:ref> status
790   code for all other request methods.
793   Requirements on cache handling of a received If-None-Match header field
794   are defined in &cache-validation-received;.
798<section title="If-Modified-Since" anchor="header.if-modified-since">
799  <iref primary="true" item="If-Modified-Since header field" x:for-anchor=""/>
800  <x:anchor-alias value="If-Modified-Since"/>
802   The "If-Modified-Since" header field makes a GET or HEAD request method
803   conditional on the selected representation's modification date being more
804   recent than the date provided in the field-value. Transfer of the selected
805   representation's data is avoided if that data has not changed.
807<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/>
808  <x:ref>If-Modified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
811   An example of the field is:
813<figure><artwork type="example">
814  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
817   A recipient &MUST; ignore If-Modified-Since if the request contains an
818   <x:ref>If-None-Match</x:ref> header field; the condition in
819   <x:ref>If-None-Match</x:ref> is considered to be a more accurate
820   replacement for the condition in If-Modified-Since, and the two are only
821   combined for the sake of interoperating with older intermediaries that
822   might not implement <x:ref>If-None-Match</x:ref>.
825   A recipient &MUST; ignore the If-Modified-Since header field if the
826   received field-value is not a valid HTTP-date, or if the request method
827   is neither GET nor HEAD.
830   A recipient &MUST; interpret an If-Modified-Since field-value's timestamp
831   in terms of the origin server's clock.
834   If-Modified-Since is typically used for two distinct purposes:
835   1) to allow efficient updates of a cached representation that does not
836   have an entity-tag and 2) to limit the scope of a web traversal to resources
837   that have recently changed.
840   When used for cache updates, a cache will typically use the value of the
841   cached message's <x:ref>Last-Modified</x:ref> field to generate the field
842   value of If-Modified-Since. This behavior is most interoperable for cases
843   where clocks are poorly synchronized or when the server has chosen to only
844   honor exact timestamp matches (due to a problem with Last-Modified dates
845   that appear to go "back in time" when the origin server's clock is
846   corrected or a representation is restored from an archived backup).
847   However, caches occasionally generate the field value based on other data,
848   such as the <x:ref>Date</x:ref> header field of the cached message or the
849   local clock time that the message was received, particularly when the
850   cached message does not contain a <x:ref>Last-Modified</x:ref> field.
853   When used for limiting the scope of retrieval to a recent time window, a
854   user agent will generate an If-Modified-Since field value based on either
855   its own local clock or a <x:ref>Date</x:ref> header field received from the
856   server in a prior response. Origin servers that choose an exact timestamp
857   match based on the selected representation's <x:ref>Last-Modified</x:ref>
858   field will not be able to help the user agent limit its data transfers to
859   only those changed during the specified window.
862   An origin server that receives an If-Modified-Since header field &SHOULD;
863   evaluate the condition prior to performing the method
864   (<xref target="evaluation"/>).
865   The origin server &SHOULD-NOT; perform the requested method if the selected
866   representation's last modification date is earlier than or equal to the
867   date provided in the field-value; instead, the origin server &SHOULD;
868   generate a <x:ref>304 (Not Modified)</x:ref> response, including only those
869   metadata that are useful for identifying or updating a previously cached
870   response.
873   Requirements on cache handling of a received If-Modified-Since header field
874   are defined in &cache-validation-received;.
878<section title="If-Unmodified-Since" anchor="header.if-unmodified-since">
879  <iref primary="true" item="If-Unmodified-Since header field" x:for-anchor=""/>
880  <x:anchor-alias value="If-Unmodified-Since"/>
882   The "If-Unmodified-Since" header field makes the request method conditional
883   on the selected representation's last modification date being earlier than or
884   equal to the date provided in the field-value. This field accomplishes the
885   same purpose as <x:ref>If-Match</x:ref> for cases where the user agent does
886   not have an entity-tag for the representation.
888<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/>
889  <x:ref>If-Unmodified-Since</x:ref> = <x:ref>HTTP-date</x:ref>
892   An example of the field is:
894<figure><artwork type="example">
895  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
898   A recipient &MUST; ignore If-Unmodified-Since if the request contains an
899   <x:ref>If-Match</x:ref> header field; the condition in
900   <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for
901   the condition in If-Unmodified-Since, and the two are only combined for the
902   sake of interoperating with older intermediaries that might not implement
903   <x:ref>If-Match</x:ref>.
906   A recipient &MUST; ignore the If-Unmodified-Since header field if the
907   received field-value is not a valid HTTP-date.
910   A recipient &MUST; interpret an If-Unmodified-Since field-value's timestamp
911   in terms of the origin server's clock.
914   If-Unmodified-Since is most often used with state-changing methods
915   (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple
916   user agents might be acting in parallel on a resource that does
917   not supply entity-tags with its representations (i.e., to prevent the
918   "lost update" problem). It can also be used with safe methods to abort a
919   request if the <x:ref>selected representation</x:ref> does not match one
920   already stored (or partially stored) from a prior request.
923   An origin server that receives an If-Unmodified-Since header field &MUST;
924   evaluate the condition prior to performing the method
925   (<xref target="evaluation"/>).
926   The origin server &MUST-NOT; perform the requested method if the selected
927   representation's last modification date is more recent than the date
928   provided in the field-value; instead the origin server &MUST; respond with either
929   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
930   b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
931   server has verified that a state change is being requested and the final
932   state is already reflected in the current state of the target resource
933   (i.e., the change requested by the user agent has already succeeded, but
934   the user agent might not be aware of that because the prior response message
935   was lost or a compatible change was made by some other user agent).
936   In the latter case, the origin server &MUST-NOT; send a validator header
937   field in the response unless it can verify that the request is a duplicate
938   of an immediately prior change made by the same user agent.
941   The If-Unmodified-Since header field can be ignored by caches and
942   intermediaries because it is not applicable to a stored response.
946<section title="If-Range" anchor="header.if-range">
948   The "If-Range" header field provides a special conditional request
949   mechanism that is similar to the <x:ref>If-Match</x:ref> and
950   <x:ref>If-Unmodified-Since</x:ref> header fields but that instructs the
951   recipient to ignore the <x:ref>Range</x:ref> header field if the validator
952   doesn't match, resulting in transfer of the new selected representation
953   instead of a <x:ref>412 (Precondition Failed)</x:ref> response. If-Range is
954   defined in &header-if-range;.
959<section title="Status Code Definitions" anchor="status.code.definitions">
960<section title="304 Not Modified" anchor="status.304">
961  <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
962  <x:anchor-alias value="304"/>
963  <x:anchor-alias value="304 (Not Modified)"/>
965   The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a
966   conditional GET or HEAD request has been
967   received and would have resulted in a <x:ref>200 (OK)</x:ref> response
968   if it were not for the fact that the condition evaluated to false.
969   In other words, there is no need for the server to transfer a
970   representation of the target resource because the request indicates that
971   the client, which made the request conditional, already has a valid
972   representation; the server is therefore redirecting the client to make
973   use of that stored representation as if it were the payload of a
974   <x:ref>200 (OK)</x:ref> response.
977   The server generating a 304 response &MUST; generate any of the following
978   header fields that would have been sent in a <x:ref>200 (OK)</x:ref>
979   response to the same request:
980   <x:ref>Cache-Control</x:ref>,
981   <x:ref>Content-Location</x:ref>,
982   <x:ref>Date</x:ref>,
983   <x:ref>ETag</x:ref>,
984   <x:ref>Expires</x:ref>, and
985   <x:ref>Vary</x:ref>.
988   Since the goal of a 304 response is to minimize information transfer
989   when the recipient already has one or more cached representations,
990   a sender &SHOULD-NOT; generate representation metadata other
991   than the above listed fields unless said metadata exists for the
992   purpose of guiding cache updates (e.g., <x:ref>Last-Modified</x:ref> might
993   be useful if the response does not have an <x:ref>ETag</x:ref> field).
996   Requirements on a cache that receives a 304 response are defined in
997   &freshening-responses;. If the conditional request originated with an
998   outbound client, such as a user agent with its own cache sending a
999   conditional GET to a shared proxy, then the proxy &SHOULD; forward the
1000   304 response to that client.
1003   A 304 response cannot contain a message-body; it is always
1004   terminated by the first empty line after the header fields.
1008<section title="412 Precondition Failed" anchor="status.412">
1009  <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
1010  <x:anchor-alias value="412 (Precondition Failed)"/>
1012   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one
1013   or more conditions given in the request header fields evaluated to false
1014   when tested on the server. This response code allows the client to place
1015   preconditions on the current resource state (its current representations
1016   and metadata) and, thus, prevent the request method from being applied if the
1017   target resource is in an unexpected state.
1022<section title="Evaluation" anchor="evaluation">
1024   Except when excluded below, a recipient cache or origin server &MUST;
1025   evaluate received request preconditions after it has successfully performed
1026   its normal request checks and just before it would perform the action
1027   associated with the request method.
1028   A server &MUST; ignore all received preconditions if its response to the
1029   same request without those conditions would have been a status code other
1030   than a <x:ref>2xx (Successful)</x:ref> or <x:ref>412 (Precondition Failed)</x:ref>.
1031   In other words, redirects and failures take precedence over the evaluation
1032   of preconditions in conditional requests.
1035   A server that is not the origin server for the target resource and cannot
1036   act as a cache for requests on the target resource &MUST-NOT; evaluate the
1037   conditional request header fields defined by this specification, and it
1038   &MUST; forward them if the request is forwarded, since the generating
1039   client intends that they be evaluated by a server that can provide a
1040   current representation.
1041   Likewise, a server &MUST; ignore the conditional request header fields
1042   defined by this specification when received with a request method that does
1043   not involve the selection or modification of a
1044   <x:ref>selected representation</x:ref>, such as CONNECT, OPTIONS, or TRACE.
1047   Conditional request header fields that are defined by extensions to HTTP
1048   might place conditions on all recipients, on the state of the target
1049   resource in general, or on a group of resources. For instance, the "If"
1050   header field in WebDAV can make a request conditional on various aspects
1051   of multiple resources, such as locks, if the recipient understands and
1052   implements that field (<xref target="RFC4918" x:fmt="," x:sec="10.4"/>).
1055   Although conditional request header fields are defined as being usable with
1056   the HEAD method (to keep HEAD's semantics consistent with those of GET),
1057   there is no point in sending a conditional HEAD because a successful
1058   response is around the same size as a <x:ref>304 (Not Modified)</x:ref>
1059   response and more useful than a <x:ref>412 (Precondition Failed)</x:ref>
1060   response.
1064<section title="Precedence" anchor="precedence">
1066   When more than one conditional request header field is present in a request,
1067   the order in which the fields are evaluated becomes important. In practice,
1068   the fields defined in this document are consistently implemented in a
1069   single, logical order, since "lost update" preconditions have more strict
1070   requirements than cache validation, a validated cache is more efficient
1071   than a partial response, and entity tags are presumed to be more accurate
1072   than date validators.
1075   A recipient cache or origin server &MUST; evaluate the request
1076   preconditions defined by this specification in the following order:
1077   <list style="numbers">
1078     <t anchor="precedence1">When recipient is the origin server and
1079       <x:ref>If-Match</x:ref> is present,
1080       evaluate the <x:ref>If-Match</x:ref> precondition:
1081       <list style="symbols">
1082         <t>if true, continue to step <xref target="precedence3" format="counter"/></t>
1083         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref> unless
1084            it can be determined that the state-changing request has already
1085            succeeded (see <xref target="header.if-match"/>)</t>
1086       </list>
1087     </t>
1088     <t anchor="precedence2">When recipient is the origin server,
1089       <x:ref>If-Match</x:ref> is not present, and
1090       <x:ref>If-Unmodified-Since</x:ref> is present,
1091       evaluate the <x:ref>If-Unmodified-Since</x:ref> precondition:
1092       <list style="symbols">
1093         <t>if true, continue to step <xref target="precedence3" format="counter"/></t>
1094         <t>if false, respond <x:ref>412 (Precondition Failed)</x:ref> unless
1095            it can be determined that the state-changing request has already
1096            succeeded (see <xref target="header.if-unmodified-since"/>)</t>
1097       </list>
1098     </t>
1099     <t anchor="precedence3">When <x:ref>If-None-Match</x:ref> is present,
1100       evaluate the <x:ref>If-None-Match</x:ref> precondition:
1101       <list style="symbols">
1102         <t>if true, continue to step <xref target="precedence5" format="counter"/></t>
1103         <t>if false for GET/HEAD, respond <x:ref>304 (Not Modified)</x:ref></t>
1104         <t>if false for other methods, respond <x:ref>412 (Precondition Failed)</x:ref></t>
1105       </list>
1106     </t>
1107     <t anchor="precedence4">When the method is GET or HEAD,
1108       <x:ref>If-None-Match</x:ref> is not present, and
1109       <x:ref>If-Modified-Since</x:ref> is present,
1110       evaluate the <x:ref>If-Modified-Since</x:ref> precondition:
1111       <list style="symbols">
1112         <t>if true, continue to step <xref target="precedence5" format="counter"/></t>
1113         <t>if false, respond <x:ref>304 (Not Modified)</x:ref></t>
1114       </list>
1115     </t>
1116     <t anchor="precedence5">When the method is GET and both
1117       <x:ref>Range</x:ref> and <x:ref>If-Range</x:ref> are present,
1118       evaluate the <x:ref>If-Range</x:ref> precondition:
1119       <list style="symbols">
1120         <t>if the validator matches and the Range specification is
1121            applicable to the selected representation, respond
1122            <x:ref>206 (Partial Content)</x:ref> <xref target="RFC7233"/></t>
1123       </list>
1124     </t>
1125     <t anchor="precedencelast">Otherwise,
1126       <list style="symbols">
1127         <t>all conditions are met, so perform the requested action and
1128            respond according to its success or failure.</t>
1129       </list>
1130     </t>
1131   </list>
1134   Any extension to HTTP/1.1 that defines additional conditional request
1135   header fields ought to define its own expectations regarding the order
1136   for evaluating such fields in relation to those defined in this document
1137   and other conditionals that might be found in practice.
1141<section title="IANA Considerations" anchor="IANA.considerations">
1143<section title="Status Code Registration" anchor="status.code.registration">
1145   The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <eref target=""/>
1146   has been updated with the registrations below:
1148<?BEGININC p4-conditional.iana-status-codes ?>
1149<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
1150<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
1151   <ttcol>Value</ttcol>
1152   <ttcol>Description</ttcol>
1153   <ttcol>Reference</ttcol>
1154   <c>304</c>
1155   <c>Not Modified</c>
1156   <c>
1157      <xref target="status.304"/>
1158   </c>
1159   <c>412</c>
1160   <c>Precondition Failed</c>
1161   <c>
1162      <xref target="status.412"/>
1163   </c>
1166<?ENDINC p4-conditional.iana-status-codes ?>
1169<section title="Header Field Registration" anchor="header.field.registration">
1171   HTTP header fields are registered within the "Message Headers" registry
1172   maintained at
1173   <eref target=""/>.
1176   This document defines the following HTTP header fields, so their
1177   associated registry entries have been updated according to the
1178   permanent registrations below (see <xref target="BCP90"/>):
1180<?BEGININC p4-conditional.iana-headers ?>
1181<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
1182<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
1183   <ttcol>Header Field Name</ttcol>
1184   <ttcol>Protocol</ttcol>
1185   <ttcol>Status</ttcol>
1186   <ttcol>Reference</ttcol>
1188   <c>ETag</c>
1189   <c>http</c>
1190   <c>standard</c>
1191   <c>
1192      <xref target="header.etag"/>
1193   </c>
1194   <c>If-Match</c>
1195   <c>http</c>
1196   <c>standard</c>
1197   <c>
1198      <xref target="header.if-match"/>
1199   </c>
1200   <c>If-Modified-Since</c>
1201   <c>http</c>
1202   <c>standard</c>
1203   <c>
1204      <xref target="header.if-modified-since"/>
1205   </c>
1206   <c>If-None-Match</c>
1207   <c>http</c>
1208   <c>standard</c>
1209   <c>
1210      <xref target="header.if-none-match"/>
1211   </c>
1212   <c>If-Unmodified-Since</c>
1213   <c>http</c>
1214   <c>standard</c>
1215   <c>
1216      <xref target="header.if-unmodified-since"/>
1217   </c>
1218   <c>Last-Modified</c>
1219   <c>http</c>
1220   <c>standard</c>
1221   <c>
1222      <xref target="header.last-modified"/>
1223   </c>
1226<?ENDINC p4-conditional.iana-headers ?>
1228   The change controller is: "IETF ( - Internet Engineering Task Force".
1233<section title="Security Considerations" anchor="security.considerations">
1235   This section is meant to inform developers, information providers, and
1236   users of known security concerns specific to the HTTP conditional
1237   request mechanisms. More general security considerations are addressed
1238   in HTTP "Message Syntax and Routing" &messaging; and "Semantics and Content"
1239   &semantics;.
1242   The validators defined by this specification are not intended to ensure
1243   the validity of a representation, guard against malicious changes, or
1244   detect man-in-the-middle attacks. At best, they enable more efficient cache
1245   updates and optimistic concurrent writes when all participants are behaving
1246   nicely. At worst, the conditions will fail and the client will receive a
1247   response that is no more harmful than an HTTP exchange without conditional
1248   requests.
1251   An entity-tag can be abused in ways that create privacy risks. For example,
1252   a site might deliberately construct a semantically invalid entity-tag that
1253   is unique to the user or user agent, send it in a cacheable response with a
1254   long freshness time, and then read that entity-tag in later conditional
1255   requests as a means of re-identifying that user or user agent. Such an
1256   identifying tag would become a persistent identifier for as long as the
1257   user agent retained the original cache entry. User agents that cache
1258   representations ought to ensure that the cache is cleared or replaced
1259   whenever the user performs privacy-maintaining actions, such as clearing
1260   stored cookies or changing to a private browsing mode.
1264<section title="Acknowledgments" anchor="acks">
1266  See &acks;.
1272<references title="Normative References">
1274<reference anchor="RFC7230">
1275  <front>
1276    <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
1277    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1278      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1279      <address><email></email></address>
1280    </author>
1281    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1282      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1283      <address><email></email></address>
1284    </author>
1285    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1286  </front>
1287  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
1288  <x:source href="p1-messaging.xml" basename="p1-messaging"/>
1291<reference anchor="RFC7231">
1292  <front>
1293    <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
1294    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1295      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1296      <address><email></email></address>
1297    </author>
1298    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1299      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1300      <address><email></email></address>
1301    </author>
1302    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1303  </front>
1304  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
1305  <x:source href="p2-semantics.xml" basename="p2-semantics">
1306    <x:defines>2xx</x:defines>
1307    <x:defines>2xx (Successful)</x:defines>
1308    <x:defines>200 (OK)</x:defines>
1309    <x:defines>204 (No Content)</x:defines>
1310    <x:defines>Accept-Encoding</x:defines>
1311    <x:defines>Content-Location</x:defines>
1312    <x:defines>Content-Type</x:defines>
1313    <x:defines>Date</x:defines>
1314    <x:defines>Location</x:defines>
1315    <x:defines>Vary</x:defines>
1316    <x:defines>selected representation</x:defines>
1317  </x:source>
1320<reference anchor="RFC7233">
1321  <front>
1322    <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
1323    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1324      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1325      <address><email></email></address>
1326    </author>
1327    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
1328      <organization abbrev="W3C">World Wide Web Consortium</organization>
1329      <address><email></email></address>
1330    </author>
1331    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1332      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1333      <address><email></email></address>
1334    </author>
1335    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1336  </front>
1337  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
1338  <x:source href="p5-range.xml" basename="p5-range">
1339    <x:defines>If-Range</x:defines>
1340    <x:defines>Range</x:defines>
1341    <x:defines>206 (Partial Content)</x:defines>
1342  </x:source>
1345<reference anchor="RFC7234">
1346  <front>
1347    <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
1348    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
1349      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
1350      <address><email></email></address>
1351    </author>
1352    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
1353      <organization>Akamai</organization>
1354      <address><email></email></address>
1355    </author>
1356    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
1357      <organization abbrev="greenbytes">greenbytes GmbH</organization>
1358      <address><email></email></address>
1359    </author>
1360    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
1361  </front>
1362  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
1363  <x:source href="p6-cache.xml" basename="p6-cache">
1364    <x:defines>Cache-Control</x:defines>
1365    <x:defines>Expires</x:defines>
1366  </x:source>
1369<reference anchor="RFC2119">
1370  <front>
1371    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
1372    <author initials="S." surname="Bradner" fullname="Scott Bradner">
1373      <organization>Harvard University</organization>
1374      <address><email></email></address>
1375    </author>
1376    <date month="March" year="1997"/>
1377  </front>
1378  <seriesInfo name="BCP" value="14"/>
1379  <seriesInfo name="RFC" value="2119"/>
1382<reference anchor="RFC5234">
1383  <front>
1384    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
1385    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
1386      <organization>Brandenburg InternetWorking</organization>
1387      <address>
1388        <email></email>
1389      </address> 
1390    </author>
1391    <author initials="P." surname="Overell" fullname="Paul Overell">
1392      <organization>THUS plc.</organization>
1393      <address>
1394        <email></email>
1395      </address>
1396    </author>
1397    <date month="January" year="2008"/>
1398  </front>
1399  <seriesInfo name="STD" value="68"/>
1400  <seriesInfo name="RFC" value="5234"/>
1405<references title="Informative References">
1407<reference anchor="RFC2616">
1408  <front>
1409    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
1410    <author initials="R." surname="Fielding" fullname="R. Fielding">
1411      <organization>University of California, Irvine</organization>
1412      <address><email></email></address>
1413    </author>
1414    <author initials="J." surname="Gettys" fullname="J. Gettys">
1415      <organization>W3C</organization>
1416      <address><email></email></address>
1417    </author>
1418    <author initials="J." surname="Mogul" fullname="J. Mogul">
1419      <organization>Compaq Computer Corporation</organization>
1420      <address><email></email></address>
1421    </author>
1422    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
1423      <organization>MIT Laboratory for Computer Science</organization>
1424      <address><email></email></address>
1425    </author>
1426    <author initials="L." surname="Masinter" fullname="L. Masinter">
1427      <organization>Xerox Corporation</organization>
1428      <address><email></email></address>
1429    </author>
1430    <author initials="P." surname="Leach" fullname="P. Leach">
1431      <organization>Microsoft Corporation</organization>
1432      <address><email></email></address>
1433    </author>
1434    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
1435      <organization>W3C</organization>
1436      <address><email></email></address>
1437    </author>
1438    <date month="June" year="1999"/>
1439  </front>
1440  <seriesInfo name="RFC" value="2616"/>
1443<reference anchor='BCP90'>
1444  <front>
1445    <title>Registration Procedures for Message Header Fields</title>
1446    <author initials='G.' surname='Klyne' fullname='G. Klyne'>
1447      <organization>Nine by Nine</organization>
1448      <address><email></email></address>
1449    </author>
1450    <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
1451      <organization>BEA Systems</organization>
1452      <address><email></email></address>
1453    </author>
1454    <author initials='J.' surname='Mogul' fullname='J. Mogul'>
1455      <organization>HP Labs</organization>
1456      <address><email></email></address>
1457    </author>
1458    <date year='2004' month='September' />
1459  </front>
1460  <seriesInfo name='BCP' value='90' />
1461  <seriesInfo name='RFC' value='3864' />
1464<reference anchor='RFC4918'>
1465  <front>
1466    <title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title>
1467    <author initials="L.M." surname="Dusseault" fullname="Lisa Dusseault" role="editor" >
1468      <organization abbrev="CommerceNet">CommerceNet</organization>
1469      <address><email></email></address>
1470    </author>
1471    <date month="June" year="2007" />
1472  </front>
1473  <seriesInfo name='RFC' value='4918' />
1477<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
1479  The definition of validator weakness has been expanded and clarified.
1480  (<xref target="weak.and.strong.validators" />)
1483  Weak entity-tags are now allowed in all requests except range requests.
1484  (Sections <xref target="weak.and.strong.validators" format="counter"/> and
1485  <xref target="header.if-none-match" format="counter"/>)
1488  The <x:ref>ETag</x:ref> header field ABNF has been changed to not use
1489  quoted-string, thus avoiding escaping issues.
1490  (<xref target="header.etag" />)
1493  ETag is defined to provide an entity tag for the selected representation,
1494  thereby clarifying what it applies to in various situations (such as a
1495  PUT response).
1496  (<xref target="header.etag" />)
1499  The precedence for evaluation of conditional requests has been defined.
1500  (<xref target="precedence" />)
1504<section title="Imported ABNF" anchor="imported.abnf">
1505  <x:anchor-alias value="ALPHA"/>
1506  <x:anchor-alias value="CR"/>
1507  <x:anchor-alias value="DIGIT"/>
1508  <x:anchor-alias value="DQUOTE"/>
1509  <x:anchor-alias value="LF"/>
1510  <x:anchor-alias value="OCTET"/>
1511  <x:anchor-alias value="VCHAR"/>
1512  <x:anchor-alias value="core.rules"/>
1513  <x:anchor-alias value="obs-text"/>
1514  <x:anchor-alias value="OWS"/>
1515  <x:anchor-alias value="HTTP-date"/>
1517  The following core rules are included by
1518  reference, as defined in <xref target="RFC5234" x:fmt="of" x:sec="B.1"/>:
1519  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
1520  DIGIT (decimal 0-9), DQUOTE (double quote),
1521  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
1522  OCTET (any 8-bit sequence of data), SP (space), and
1523  VCHAR (any visible US-ASCII character).
1526  The rules below are defined in <xref target="RFC7230"/>:
1528<figure><artwork type="abnf2616">
1529  <x:ref>OWS</x:ref>           = &lt;OWS, see &whitespace;&gt;
1530  <x:ref>obs-text</x:ref>      = &lt;obs-text, see &field-components;&gt;
1533  The rules below are defined in other parts:
1535<figure><artwork type="abnf2616">
1536  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, see &http-date;&gt;
1540<?BEGININC p4-conditional.abnf-appendix ?>
1541<section xmlns:x="" title="Collected ABNF" anchor="collected.abnf">
1543  In the collected ABNF below, list rules are expanded as per <xref target="RFC7230" x:rel="#notation"/>.
1545<artwork type="abnf" name="p4-conditional.parsed-abnf">
1546<x:ref>ETag</x:ref> = entity-tag
1548<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, see [RFC7231], Section;
1550<x:ref>If-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1551 entity-tag ] ) )
1552<x:ref>If-Modified-Since</x:ref> = HTTP-date
1553<x:ref>If-None-Match</x:ref> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1554 entity-tag ] ) )
1555<x:ref>If-Unmodified-Since</x:ref> = HTTP-date
1557<x:ref>Last-Modified</x:ref> = HTTP-date
1559<x:ref>OWS</x:ref> = &lt;OWS, see [RFC7230], Section 3.2.3&gt;
1561<x:ref>entity-tag</x:ref> = [ weak ] opaque-tag
1562<x:ref>etagc</x:ref> = "!" / %x23-7E ; '#'-'~'
1563 / obs-text
1565<x:ref>obs-text</x:ref> = &lt;obs-text, see [RFC7230], Section 3.2.6&gt;
1566<x:ref>opaque-tag</x:ref> = DQUOTE *etagc DQUOTE
1568<x:ref>weak</x:ref> = %x57.2F ; W/
1572<?ENDINC p4-conditional.abnf-appendix ?>
Note: See TracBrowser for help on using the repository browser.