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