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