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