1 | <?xml version="1.0" encoding="utf-8"?> |
---|
2 | <!DOCTYPE rfc [ |
---|
3 | <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>"> |
---|
4 | <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>"> |
---|
5 | <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>"> |
---|
6 | <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>"> |
---|
7 | <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>"> |
---|
8 | <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>"> |
---|
9 | <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>"> |
---|
10 | <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>"> |
---|
11 | <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> |
---|
12 | <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> |
---|
13 | <!ENTITY ID-VERSION "latest"> |
---|
14 | <!ENTITY ID-MONTH "December"> |
---|
15 | <!ENTITY ID-YEAR "2007"> |
---|
16 | <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
17 | <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
18 | <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
19 | <!ENTITY header-vary "<xref target='Part6' x:rel='#header.vary' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> |
---|
20 | ]> |
---|
21 | <?rfc toc="yes" ?> |
---|
22 | <?rfc symrefs="yes" ?> |
---|
23 | <?rfc sortrefs="yes" ?> |
---|
24 | <?rfc compact="yes"?> |
---|
25 | <?rfc subcompact="no" ?> |
---|
26 | <?rfc linkmailto="no" ?> |
---|
27 | <?rfc editing="no" ?> |
---|
28 | <?rfc-ext allow-markup-in-artwork="yes" ?> |
---|
29 | <?rfc-ext include-references-in-index="yes" ?> |
---|
30 | <rfc obsoletes="2068, 2616, 2617" category="std" |
---|
31 | ipr="full3978" docName="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" |
---|
32 | xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit"> |
---|
33 | <front> |
---|
34 | |
---|
35 | <title abbrev="HTTP/1.1, part 4">HTTP/1.1, part 4: Conditional Requests</title> |
---|
36 | |
---|
37 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
38 | <organization abbrev="Day Software">Day Software</organization> |
---|
39 | <address> |
---|
40 | <postal> |
---|
41 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
42 | <city>Newport Beach</city> |
---|
43 | <region>CA</region> |
---|
44 | <code>92660</code> |
---|
45 | <country>USA</country> |
---|
46 | </postal> |
---|
47 | <phone>+1-949-706-5300</phone> |
---|
48 | <facsimile>+1-949-706-5305</facsimile> |
---|
49 | <email>fielding@gbiv.com</email> |
---|
50 | <uri>http://roy.gbiv.com/</uri> |
---|
51 | </address> |
---|
52 | </author> |
---|
53 | |
---|
54 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
55 | <organization>One Laptop per Child</organization> |
---|
56 | <address> |
---|
57 | <postal> |
---|
58 | <street>21 Oak Knoll Road</street> |
---|
59 | <city>Carlisle</city> |
---|
60 | <region>MA</region> |
---|
61 | <code>01741</code> |
---|
62 | <country>USA</country> |
---|
63 | </postal> |
---|
64 | <email>jg@laptop.org</email> |
---|
65 | <uri>http://www.laptop.org/</uri> |
---|
66 | </address> |
---|
67 | </author> |
---|
68 | |
---|
69 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
70 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
71 | <address> |
---|
72 | <postal> |
---|
73 | <street>HP Labs, Large Scale Systems Group</street> |
---|
74 | <street>1501 Page Mill Road, MS 1177</street> |
---|
75 | <city>Palo Alto</city> |
---|
76 | <region>CA</region> |
---|
77 | <code>94304</code> |
---|
78 | <country>USA</country> |
---|
79 | </postal> |
---|
80 | <email>JeffMogul@acm.org</email> |
---|
81 | </address> |
---|
82 | </author> |
---|
83 | |
---|
84 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
85 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
86 | <address> |
---|
87 | <postal> |
---|
88 | <street>1 Microsoft Way</street> |
---|
89 | <city>Redmond</city> |
---|
90 | <region>WA</region> |
---|
91 | <code>98052</code> |
---|
92 | <country>USA</country> |
---|
93 | </postal> |
---|
94 | <email>henrikn@microsoft.com</email> |
---|
95 | </address> |
---|
96 | </author> |
---|
97 | |
---|
98 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
99 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
100 | <address> |
---|
101 | <postal> |
---|
102 | <street>345 Park Ave</street> |
---|
103 | <city>San Jose</city> |
---|
104 | <region>CA</region> |
---|
105 | <code>95110</code> |
---|
106 | <country>USA</country> |
---|
107 | </postal> |
---|
108 | <email>LMM@acm.org</email> |
---|
109 | <uri>http://larry.masinter.net/</uri> |
---|
110 | </address> |
---|
111 | </author> |
---|
112 | |
---|
113 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
114 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
115 | <address> |
---|
116 | <postal> |
---|
117 | <street>1 Microsoft Way</street> |
---|
118 | <city>Redmond</city> |
---|
119 | <region>WA</region> |
---|
120 | <code>98052</code> |
---|
121 | </postal> |
---|
122 | <email>paulle@microsoft.com</email> |
---|
123 | </address> |
---|
124 | </author> |
---|
125 | |
---|
126 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
127 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
128 | <address> |
---|
129 | <postal> |
---|
130 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
131 | <street>The Stata Center, Building 32</street> |
---|
132 | <street>32 Vassar Street</street> |
---|
133 | <city>Cambridge</city> |
---|
134 | <region>MA</region> |
---|
135 | <code>02139</code> |
---|
136 | <country>USA</country> |
---|
137 | </postal> |
---|
138 | <email>timbl@w3.org</email> |
---|
139 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
140 | </address> |
---|
141 | </author> |
---|
142 | |
---|
143 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
144 | |
---|
145 | <abstract> |
---|
146 | <t> |
---|
147 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
148 | protocol for distributed, collaborative, hypermedia information |
---|
149 | systems. HTTP has been in use by the World Wide Web global information |
---|
150 | initiative since 1990. This document is Part 4 of the eight-part specification |
---|
151 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
152 | updates RFC 2616 and RFC 2617. Part 4 defines request header fields for |
---|
153 | indicating conditional requests and the rules for constructing responses |
---|
154 | to those requests. |
---|
155 | </t> |
---|
156 | </abstract> |
---|
157 | </front> |
---|
158 | <middle> |
---|
159 | <section title="Introduction" anchor="introduction"> |
---|
160 | <t> |
---|
161 | This document will define aspects of HTTP related to conditional |
---|
162 | request messages based on time stamps and entity-tags. Right now it |
---|
163 | only includes the extracted relevant sections of <xref target="RFC2616">RFC 2616</xref> |
---|
164 | without edit. |
---|
165 | </t> |
---|
166 | </section> |
---|
167 | |
---|
168 | <section title="Entity Tags" anchor="entity.tags"> |
---|
169 | <t> |
---|
170 | Entity tags are used for comparing two or more entities from the same |
---|
171 | requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>), |
---|
172 | If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and |
---|
173 | If-Range (&header-if-range;) header fields. The definition of how they |
---|
174 | are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An |
---|
175 | entity tag consists of an opaque quoted string, possibly prefixed by |
---|
176 | a weakness indicator. |
---|
177 | </t> |
---|
178 | <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"/> |
---|
179 | entity-tag = [ weak ] opaque-tag |
---|
180 | weak = "W/" |
---|
181 | opaque-tag = quoted-string |
---|
182 | </artwork></figure> |
---|
183 | <t> |
---|
184 | A "strong entity tag" &MAY; be shared by two entities of a resource |
---|
185 | only if they are equivalent by octet equality. |
---|
186 | </t> |
---|
187 | <t> |
---|
188 | A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by |
---|
189 | two entities of a resource only if the entities are equivalent and |
---|
190 | could be substituted for each other with no significant change in |
---|
191 | semantics. A weak entity tag can only be used for weak comparison. |
---|
192 | </t> |
---|
193 | <t> |
---|
194 | An entity tag &MUST; be unique across all versions of all entities |
---|
195 | associated with a particular resource. A given entity tag value &MAY; |
---|
196 | be used for entities obtained by requests on different URIs. The use |
---|
197 | of the same entity tag value in conjunction with entities obtained by |
---|
198 | requests on different URIs does not imply the equivalence of those |
---|
199 | entities. |
---|
200 | </t> |
---|
201 | </section> |
---|
202 | |
---|
203 | <section title="Weak and Strong Validators" anchor="weak.and.strong.validators"> |
---|
204 | <t> |
---|
205 | Since both origin servers and caches will compare two validators to |
---|
206 | decide if they represent the same or different entities, one normally |
---|
207 | would expect that if the entity (the entity-body or any entity-headers) |
---|
208 | changes in any way, then the associated validator would |
---|
209 | change as well. If this is true, then we call this validator a |
---|
210 | "strong validator." |
---|
211 | </t> |
---|
212 | <t> |
---|
213 | However, there might be cases when a server prefers to change the |
---|
214 | validator only on semantically significant changes, and not when |
---|
215 | insignificant aspects of the entity change. A validator that does not |
---|
216 | always change when the resource changes is a "weak validator." |
---|
217 | </t> |
---|
218 | <t> |
---|
219 | Entity tags are normally "strong validators," but the protocol |
---|
220 | provides a mechanism to tag an entity tag as "weak." One can think of |
---|
221 | a strong validator as one that changes whenever the bits of an entity |
---|
222 | changes, while a weak value changes whenever the meaning of an entity |
---|
223 | changes. Alternatively, one can think of a strong validator as part |
---|
224 | of an identifier for a specific entity, while a weak validator is |
---|
225 | part of an identifier for a set of semantically equivalent entities. |
---|
226 | <list><t> |
---|
227 | <x:h>Note:</x:h> One example of a strong validator is an integer that is |
---|
228 | incremented in stable storage every time an entity is changed. |
---|
229 | </t><t> |
---|
230 | An entity's modification time, if represented with one-second |
---|
231 | resolution, could be a weak validator, since it is possible that |
---|
232 | the resource might be modified twice during a single second. |
---|
233 | </t><t> |
---|
234 | Support for weak validators is optional. However, weak validators |
---|
235 | allow for more efficient caching of equivalent objects; for |
---|
236 | example, a hit counter on a site is probably good enough if it is |
---|
237 | updated every few days or weeks, and any value during that period |
---|
238 | is likely "good enough" to be equivalent. |
---|
239 | </t></list> |
---|
240 | </t> |
---|
241 | <t> |
---|
242 | A "use" of a validator is either when a client generates a request |
---|
243 | and includes the validator in a validating header field, or when a |
---|
244 | server compares two validators. |
---|
245 | </t> |
---|
246 | <t> |
---|
247 | Strong validators are usable in any context. Weak validators are only |
---|
248 | usable in contexts that do not depend on exact equality of an entity. |
---|
249 | For example, either kind is usable for a conditional GET of a full |
---|
250 | entity. However, only a strong validator is usable for a sub-range |
---|
251 | retrieval, since otherwise the client might end up with an internally |
---|
252 | inconsistent entity. |
---|
253 | </t> |
---|
254 | <t> |
---|
255 | Clients &MAY; issue simple (non-subrange) GET requests with either weak |
---|
256 | validators or strong validators. Clients &MUST-NOT; use weak validators |
---|
257 | in other forms of request. |
---|
258 | </t> |
---|
259 | <t> |
---|
260 | The only function that the HTTP/1.1 protocol defines on validators is |
---|
261 | comparison. There are two validator comparison functions, depending |
---|
262 | on whether the comparison context allows the use of weak validators |
---|
263 | or not: |
---|
264 | <list style="symbols"> |
---|
265 | <t>The strong comparison function: in order to be considered equal, |
---|
266 | both validators &MUST; be identical in every way, and both &MUST-NOT; |
---|
267 | be weak.</t> |
---|
268 | <t>The weak comparison function: in order to be considered equal, |
---|
269 | both validators &MUST; be identical in every way, but either or |
---|
270 | both of them &MAY; be tagged as "weak" without affecting the |
---|
271 | result.</t> |
---|
272 | </list> |
---|
273 | </t> |
---|
274 | <t> |
---|
275 | An entity tag is strong unless it is explicitly tagged as weak. |
---|
276 | <xref target="entity.tags"/> gives the syntax for entity tags. |
---|
277 | </t> |
---|
278 | <t> |
---|
279 | A Last-Modified time, when used as a validator in a request, is |
---|
280 | implicitly weak unless it is possible to deduce that it is strong, |
---|
281 | using the following rules: |
---|
282 | <list style="symbols"> |
---|
283 | <t>The validator is being compared by an origin server to the |
---|
284 | actual current validator for the entity and,</t> |
---|
285 | <t>That origin server reliably knows that the associated entity did |
---|
286 | not change twice during the second covered by the presented |
---|
287 | validator.</t> |
---|
288 | </list> |
---|
289 | </t> |
---|
290 | <t> |
---|
291 | or |
---|
292 | <list style="symbols"> |
---|
293 | <t>The validator is about to be used by a client in an If-Modified-Since |
---|
294 | or If-Unmodified-Since header, because the client |
---|
295 | has a cache entry for the associated entity, and</t> |
---|
296 | <t>That cache entry includes a Date value, which gives the time |
---|
297 | when the origin server sent the original response, and</t> |
---|
298 | <t>The presented Last-Modified time is at least 60 seconds before |
---|
299 | the Date value.</t> |
---|
300 | </list> |
---|
301 | </t> |
---|
302 | <t> |
---|
303 | or |
---|
304 | <list style="symbols"> |
---|
305 | <t>The validator is being compared by an intermediate cache to the |
---|
306 | validator stored in its cache entry for the entity, and</t> |
---|
307 | <t>That cache entry includes a Date value, which gives the time |
---|
308 | when the origin server sent the original response, and</t> |
---|
309 | <t>The presented Last-Modified time is at least 60 seconds before |
---|
310 | the Date value.</t> |
---|
311 | </list> |
---|
312 | </t> |
---|
313 | <t> |
---|
314 | This method relies on the fact that if two different responses were |
---|
315 | sent by the origin server during the same second, but both had the |
---|
316 | same Last-Modified time, then at least one of those responses would |
---|
317 | have a Date value equal to its Last-Modified time. The arbitrary 60-second |
---|
318 | limit guards against the possibility that the Date and Last-Modified |
---|
319 | values are generated from different clocks, or at somewhat |
---|
320 | different times during the preparation of the response. An |
---|
321 | implementation &MAY; use a value larger than 60 seconds, if it is |
---|
322 | believed that 60 seconds is too short. |
---|
323 | </t> |
---|
324 | <t> |
---|
325 | If a client wishes to perform a sub-range retrieval on a value for |
---|
326 | which it has only a Last-Modified time and no opaque validator, it |
---|
327 | &MAY; do this only if the Last-Modified time is strong in the sense |
---|
328 | described here. |
---|
329 | </t> |
---|
330 | <t> |
---|
331 | A cache or origin server receiving a conditional request, other than |
---|
332 | a full-body GET request, &MUST; use the strong comparison function to |
---|
333 | evaluate the condition. |
---|
334 | </t> |
---|
335 | <t> |
---|
336 | These rules allow HTTP/1.1 caches and clients to safely perform sub-range |
---|
337 | retrievals on values that have been obtained from HTTP/1.0 |
---|
338 | servers. |
---|
339 | </t> |
---|
340 | </section> |
---|
341 | |
---|
342 | <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"> |
---|
343 | <t> |
---|
344 | We adopt a set of rules and recommendations for origin servers, |
---|
345 | clients, and caches regarding when various validator types ought to |
---|
346 | be used, and for what purposes. |
---|
347 | </t> |
---|
348 | <t> |
---|
349 | HTTP/1.1 origin servers: |
---|
350 | <list style="symbols"> |
---|
351 | <t>&SHOULD; send an entity tag validator unless it is not feasible to |
---|
352 | generate one.</t> |
---|
353 | |
---|
354 | <t>&MAY; send a weak entity tag instead of a strong entity tag, if |
---|
355 | performance considerations support the use of weak entity tags, |
---|
356 | or if it is unfeasible to send a strong entity tag.</t> |
---|
357 | |
---|
358 | <t>&SHOULD; send a Last-Modified value if it is feasible to send one, |
---|
359 | unless the risk of a breakdown in semantic transparency that |
---|
360 | could result from using this date in an If-Modified-Since header |
---|
361 | would lead to serious problems.</t> |
---|
362 | </list> |
---|
363 | </t> |
---|
364 | <t> |
---|
365 | In other words, the preferred behavior for an HTTP/1.1 origin server |
---|
366 | is to send both a strong entity tag and a Last-Modified value. |
---|
367 | </t> |
---|
368 | <t> |
---|
369 | In order to be legal, a strong entity tag &MUST; change whenever the |
---|
370 | associated entity value changes in any way. A weak entity tag &SHOULD; |
---|
371 | change whenever the associated entity changes in a semantically |
---|
372 | significant way. |
---|
373 | <list><t> |
---|
374 | <x:h>Note:</x:h> in order to provide semantically transparent caching, an |
---|
375 | origin server must avoid reusing a specific strong entity tag |
---|
376 | value for two different entities, or reusing a specific weak |
---|
377 | entity tag value for two semantically different entities. Cache |
---|
378 | entries might persist for arbitrarily long periods, regardless of |
---|
379 | expiration times, so it might be inappropriate to expect that a |
---|
380 | cache will never again attempt to validate an entry using a |
---|
381 | validator that it obtained at some point in the past. |
---|
382 | </t></list> |
---|
383 | </t> |
---|
384 | <t> |
---|
385 | HTTP/1.1 clients: |
---|
386 | <list style="symbols"> |
---|
387 | <t>If an entity tag has been provided by the origin server, &MUST; |
---|
388 | use that entity tag in any cache-conditional request (using If-Match |
---|
389 | or If-None-Match).</t> |
---|
390 | |
---|
391 | <t>If only a Last-Modified value has been provided by the origin |
---|
392 | server, &SHOULD; use that value in non-subrange cache-conditional |
---|
393 | requests (using If-Modified-Since).</t> |
---|
394 | |
---|
395 | <t>If only a Last-Modified value has been provided by an HTTP/1.0 |
---|
396 | origin server, &MAY; use that value in subrange cache-conditional |
---|
397 | requests (using If-Unmodified-Since:). The user agent &SHOULD; |
---|
398 | provide a way to disable this, in case of difficulty.</t> |
---|
399 | |
---|
400 | <t>If both an entity tag and a Last-Modified value have been |
---|
401 | provided by the origin server, &SHOULD; use both validators in |
---|
402 | cache-conditional requests. This allows both HTTP/1.0 and |
---|
403 | HTTP/1.1 caches to respond appropriately.</t> |
---|
404 | </list> |
---|
405 | </t> |
---|
406 | <t> |
---|
407 | An HTTP/1.1 origin server, upon receiving a conditional request that |
---|
408 | includes both a Last-Modified date (e.g., in an If-Modified-Since or |
---|
409 | If-Unmodified-Since header field) and one or more entity tags (e.g., |
---|
410 | in an If-Match, If-None-Match, or If-Range header field) as cache |
---|
411 | validators, &MUST-NOT; return a response status of 304 (Not Modified) |
---|
412 | unless doing so is consistent with all of the conditional header |
---|
413 | fields in the request. |
---|
414 | </t> |
---|
415 | <t> |
---|
416 | An HTTP/1.1 caching proxy, upon receiving a conditional request that |
---|
417 | includes both a Last-Modified date and one or more entity tags as |
---|
418 | cache validators, &MUST-NOT; return a locally cached response to the |
---|
419 | client unless that cached response is consistent with all of the |
---|
420 | conditional header fields in the request. |
---|
421 | <list><t> |
---|
422 | <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1 |
---|
423 | servers and clients should transmit as much non-redundant |
---|
424 | information as is available in their responses and requests. |
---|
425 | HTTP/1.1 systems receiving this information will make the most |
---|
426 | conservative assumptions about the validators they receive. |
---|
427 | </t><t> |
---|
428 | HTTP/1.0 clients and caches will ignore entity tags. Generally, |
---|
429 | last-modified values received or used by these systems will |
---|
430 | support transparent and efficient caching, and so HTTP/1.1 origin |
---|
431 | servers should provide Last-Modified values. In those rare cases |
---|
432 | where the use of a Last-Modified value as a validator by an |
---|
433 | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |
---|
434 | origin servers should not provide one. |
---|
435 | </t></list> |
---|
436 | </t> |
---|
437 | </section> |
---|
438 | |
---|
439 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
440 | <t> |
---|
441 | This section defines the syntax and semantics of all standard |
---|
442 | HTTP/1.1 header fields. For entity-header fields, both sender and |
---|
443 | recipient refer to either the client or the server, depending on who |
---|
444 | sends and who receives the entity. |
---|
445 | </t> |
---|
446 | |
---|
447 | <section title="ETag" anchor="header.etag"> |
---|
448 | <iref primary="true" item="ETag header" x:for-anchor=""/> |
---|
449 | <iref primary="true" item="Headers" subitem="ETag" x:for-anchor=""/> |
---|
450 | <t> |
---|
451 | The ETag response-header field provides the current value of the |
---|
452 | entity tag for the requested variant. The headers used with entity |
---|
453 | tags are described in sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag |
---|
454 | &MAY; be used for comparison with other entities from the same resource |
---|
455 | (see <xref target="weak.and.strong.validators"/>). |
---|
456 | </t> |
---|
457 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/> |
---|
458 | ETag = "ETag" ":" entity-tag |
---|
459 | </artwork></figure> |
---|
460 | <figure><preamble> |
---|
461 | Examples: |
---|
462 | </preamble> |
---|
463 | <artwork type="example"> |
---|
464 | ETag: "xyzzy" |
---|
465 | ETag: W/"xyzzy" |
---|
466 | ETag: "" |
---|
467 | </artwork></figure> |
---|
468 | </section> |
---|
469 | |
---|
470 | <section title="If-Match" anchor="header.if-match"> |
---|
471 | <iref primary="true" item="If-Match header" x:for-anchor=""/> |
---|
472 | <iref primary="true" item="Headers" subitem="If-Match" x:for-anchor=""/> |
---|
473 | <t> |
---|
474 | The If-Match request-header field is used with a method to make it |
---|
475 | conditional. A client that has one or more entities previously |
---|
476 | obtained from the resource can verify that one of those entities is |
---|
477 | current by including a list of their associated entity tags in the |
---|
478 | If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The |
---|
479 | purpose of this feature is to allow efficient updates of cached |
---|
480 | information with a minimum amount of transaction overhead. It is also |
---|
481 | used, on updating requests, to prevent inadvertent modification of |
---|
482 | the wrong version of a resource. As a special case, the value "*" |
---|
483 | matches any current entity of the resource. |
---|
484 | </t> |
---|
485 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/> |
---|
486 | If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) |
---|
487 | </artwork></figure> |
---|
488 | <t> |
---|
489 | If any of the entity tags match the entity tag of the entity that |
---|
490 | would have been returned in the response to a similar GET request |
---|
491 | (without the If-Match header) on that resource, or if "*" is given |
---|
492 | and any current entity exists for that resource, then the server &MAY; |
---|
493 | perform the requested method as if the If-Match header field did not |
---|
494 | exist. |
---|
495 | </t> |
---|
496 | <t> |
---|
497 | A server &MUST; use the strong comparison function (see <xref target="weak.and.strong.validators"/>) |
---|
498 | to compare the entity tags in If-Match. |
---|
499 | </t> |
---|
500 | <t> |
---|
501 | If none of the entity tags match, or if "*" is given and no current |
---|
502 | entity exists, the server &MUST-NOT; perform the requested method, and |
---|
503 | &MUST; return a 412 (Precondition Failed) response. This behavior is |
---|
504 | most useful when the client wants to prevent an updating method, such |
---|
505 | as PUT, from modifying a resource that has changed since the client |
---|
506 | last retrieved it. |
---|
507 | </t> |
---|
508 | <t> |
---|
509 | If the request would, without the If-Match header field, result in |
---|
510 | anything other than a 2xx or 412 status, then the If-Match header |
---|
511 | &MUST; be ignored. |
---|
512 | </t> |
---|
513 | <t> |
---|
514 | The meaning of "If-Match: *" is that the method &SHOULD; be performed |
---|
515 | if the representation selected by the origin server (or by a cache, |
---|
516 | possibly using the Vary mechanism, see &header-vary;) exists, and |
---|
517 | &MUST-NOT; be performed if the representation does not exist. |
---|
518 | </t> |
---|
519 | <t> |
---|
520 | A request intended to update a resource (e.g., a PUT) &MAY; include an |
---|
521 | If-Match header field to signal that the request method &MUST-NOT; be |
---|
522 | applied if the entity corresponding to the If-Match value (a single |
---|
523 | entity tag) is no longer a representation of that resource. This |
---|
524 | allows the user to indicate that they do not wish the request to be |
---|
525 | successful if the resource has been changed without their knowledge. |
---|
526 | Examples: |
---|
527 | </t> |
---|
528 | <figure><artwork type="example"> |
---|
529 | If-Match: "xyzzy" |
---|
530 | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
---|
531 | If-Match: * |
---|
532 | </artwork></figure> |
---|
533 | <t> |
---|
534 | The result of a request having both an If-Match header field and |
---|
535 | either an If-None-Match or an If-Modified-Since header fields is |
---|
536 | undefined by this specification. |
---|
537 | </t> |
---|
538 | </section> |
---|
539 | |
---|
540 | <section title="If-Modified-Since" anchor="header.if-modified-since"> |
---|
541 | <iref primary="true" item="If-Modified-Since header" x:for-anchor=""/> |
---|
542 | <iref primary="true" item="Headers" subitem="If-Modified-Since" x:for-anchor=""/> |
---|
543 | <t> |
---|
544 | The If-Modified-Since request-header field is used with a method to |
---|
545 | make it conditional: if the requested variant has not been modified |
---|
546 | since the time specified in this field, an entity will not be |
---|
547 | returned from the server; instead, a 304 (not modified) response will |
---|
548 | be returned without any message-body. |
---|
549 | </t> |
---|
550 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/> |
---|
551 | If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
---|
552 | </artwork></figure> |
---|
553 | <t> |
---|
554 | An example of the field is: |
---|
555 | </t> |
---|
556 | <figure><artwork type="example"> |
---|
557 | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
---|
558 | </artwork></figure> |
---|
559 | <t> |
---|
560 | A GET method with an If-Modified-Since header and no Range header |
---|
561 | requests that the identified entity be transferred only if it has |
---|
562 | been modified since the date given by the If-Modified-Since header. |
---|
563 | The algorithm for determining this includes the following cases: |
---|
564 | <list style="numbers"> |
---|
565 | <t>If the request would normally result in anything other than a |
---|
566 | 200 (OK) status, or if the passed If-Modified-Since date is |
---|
567 | invalid, the response is exactly the same as for a normal GET. |
---|
568 | A date which is later than the server's current time is |
---|
569 | invalid.</t> |
---|
570 | |
---|
571 | <t>If the variant has been modified since the If-Modified-Since |
---|
572 | date, the response is exactly the same as for a normal GET.</t> |
---|
573 | |
---|
574 | <t>If the variant has not been modified since a valid If-Modified-Since |
---|
575 | date, the server &SHOULD; return a 304 (Not |
---|
576 | Modified) response.</t> |
---|
577 | </list> |
---|
578 | </t> |
---|
579 | <t> |
---|
580 | The purpose of this feature is to allow efficient updates of cached |
---|
581 | information with a minimum amount of transaction overhead. |
---|
582 | <list><t> |
---|
583 | <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since; |
---|
584 | see &header-range; for full details. |
---|
585 | </t><t> |
---|
586 | <x:h>Note:</x:h> If-Modified-Since times are interpreted by the server, whose |
---|
587 | clock might not be synchronized with the client. |
---|
588 | </t><t> |
---|
589 | <x:h>Note:</x:h> When handling an If-Modified-Since header field, some |
---|
590 | servers will use an exact date comparison function, rather than a |
---|
591 | less-than function, for deciding whether to send a 304 (Not |
---|
592 | Modified) response. To get best results when sending an If-Modified-Since |
---|
593 | header field for cache validation, clients are |
---|
594 | advised to use the exact date string received in a previous Last-Modified |
---|
595 | header field whenever possible. |
---|
596 | </t><t> |
---|
597 | <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since |
---|
598 | header instead of a date taken from the Last-Modified header for |
---|
599 | the same request, the client should be aware of the fact that this |
---|
600 | date is interpreted in the server's understanding of time. The |
---|
601 | client should consider unsynchronized clocks and rounding problems |
---|
602 | due to the different encodings of time between the client and |
---|
603 | server. This includes the possibility of race conditions if the |
---|
604 | document has changed between the time it was first requested and |
---|
605 | the If-Modified-Since date of a subsequent request, and the |
---|
606 | possibility of clock-skew-related problems if the If-Modified-Since |
---|
607 | date is derived from the client's clock without correction |
---|
608 | to the server's clock. Corrections for different time bases |
---|
609 | between client and server are at best approximate due to network |
---|
610 | latency. |
---|
611 | </t> |
---|
612 | </list> |
---|
613 | </t> |
---|
614 | <t> |
---|
615 | The result of a request having both an If-Modified-Since header field |
---|
616 | and either an If-Match or an If-Unmodified-Since header fields is |
---|
617 | undefined by this specification. |
---|
618 | </t> |
---|
619 | </section> |
---|
620 | |
---|
621 | <section title="If-None-Match" anchor="header.if-none-match"> |
---|
622 | <iref primary="true" item="If-None-Match header" x:for-anchor=""/> |
---|
623 | <iref primary="true" item="Headers" subitem="If-None-Match" x:for-anchor=""/> |
---|
624 | <t> |
---|
625 | The If-None-Match request-header field is used with a method to make |
---|
626 | it conditional. A client that has one or more entities previously |
---|
627 | obtained from the resource can verify that none of those entities is |
---|
628 | current by including a list of their associated entity tags in the |
---|
629 | If-None-Match header field. The purpose of this feature is to allow |
---|
630 | efficient updates of cached information with a minimum amount of |
---|
631 | transaction overhead. It is also used to prevent a method (e.g. PUT) |
---|
632 | from inadvertently modifying an existing resource when the client |
---|
633 | believes that the resource does not exist. |
---|
634 | </t> |
---|
635 | <t> |
---|
636 | As a special case, the value "*" matches any current entity of the |
---|
637 | resource. |
---|
638 | </t> |
---|
639 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/> |
---|
640 | If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) |
---|
641 | </artwork></figure> |
---|
642 | <t> |
---|
643 | If any of the entity tags match the entity tag of the entity that |
---|
644 | would have been returned in the response to a similar GET request |
---|
645 | (without the If-None-Match header) on that resource, or if "*" is |
---|
646 | given and any current entity exists for that resource, then the |
---|
647 | server &MUST-NOT; perform the requested method, unless required to do |
---|
648 | so because the resource's modification date fails to match that |
---|
649 | supplied in an If-Modified-Since header field in the request. |
---|
650 | Instead, if the request method was GET or HEAD, the server &SHOULD; |
---|
651 | respond with a 304 (Not Modified) response, including the cache-related |
---|
652 | header fields (particularly ETag) of one of the entities that |
---|
653 | matched. For all other request methods, the server &MUST; respond with |
---|
654 | a status of 412 (Precondition Failed). |
---|
655 | </t> |
---|
656 | <t> |
---|
657 | See <xref target="weak.and.strong.validators"/> for rules on how to determine if two entities tags |
---|
658 | match. The weak comparison function can only be used with GET or HEAD |
---|
659 | requests. |
---|
660 | </t> |
---|
661 | <t> |
---|
662 | If none of the entity tags match, then the server &MAY; perform the |
---|
663 | requested method as if the If-None-Match header field did not exist, |
---|
664 | but &MUST; also ignore any If-Modified-Since header field(s) in the |
---|
665 | request. That is, if no entity tags match, then the server &MUST-NOT; |
---|
666 | return a 304 (Not Modified) response. |
---|
667 | </t> |
---|
668 | <t> |
---|
669 | If the request would, without the If-None-Match header field, result |
---|
670 | in anything other than a 2xx or 304 status, then the If-None-Match |
---|
671 | header &MUST; be ignored. (See <xref target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for a discussion of |
---|
672 | server behavior when both If-Modified-Since and If-None-Match appear |
---|
673 | in the same request.) |
---|
674 | </t> |
---|
675 | <t> |
---|
676 | The meaning of "If-None-Match: *" is that the method &MUST-NOT; be |
---|
677 | performed if the representation selected by the origin server (or by |
---|
678 | a cache, possibly using the Vary mechanism, see &header-vary;) |
---|
679 | exists, and &SHOULD; be performed if the representation does not exist. |
---|
680 | This feature is intended to be useful in preventing races between PUT |
---|
681 | operations. |
---|
682 | </t> |
---|
683 | <t> |
---|
684 | Examples: |
---|
685 | </t> |
---|
686 | <figure><artwork type="example"> |
---|
687 | If-None-Match: "xyzzy" |
---|
688 | If-None-Match: W/"xyzzy" |
---|
689 | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
---|
690 | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
---|
691 | If-None-Match: * |
---|
692 | </artwork></figure> |
---|
693 | <t> |
---|
694 | The result of a request having both an If-None-Match header field and |
---|
695 | either an If-Match or an If-Unmodified-Since header fields is |
---|
696 | undefined by this specification. |
---|
697 | </t> |
---|
698 | </section> |
---|
699 | |
---|
700 | <section title="If-Unmodified-Since" anchor="header.if-unmodified-since"> |
---|
701 | <iref primary="true" item="If-Unmodified-Since header" x:for-anchor=""/> |
---|
702 | <iref primary="true" item="Headers" subitem="If-Unmodified-Since" x:for-anchor=""/> |
---|
703 | <t> |
---|
704 | The If-Unmodified-Since request-header field is used with a method to |
---|
705 | make it conditional. If the requested resource has not been modified |
---|
706 | since the time specified in this field, the server &SHOULD; perform the |
---|
707 | requested operation as if the If-Unmodified-Since header were not |
---|
708 | present. |
---|
709 | </t> |
---|
710 | <t> |
---|
711 | If the requested variant has been modified since the specified time, |
---|
712 | the server &MUST-NOT; perform the requested operation, and &MUST; return |
---|
713 | a 412 (Precondition Failed). |
---|
714 | </t> |
---|
715 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Unmodified-Since"/> |
---|
716 | If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date |
---|
717 | </artwork></figure> |
---|
718 | <t> |
---|
719 | An example of the field is: |
---|
720 | </t> |
---|
721 | <figure><artwork type="example"> |
---|
722 | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
---|
723 | </artwork></figure> |
---|
724 | <t> |
---|
725 | If the request normally (i.e., without the If-Unmodified-Since |
---|
726 | header) would result in anything other than a 2xx or 412 status, the |
---|
727 | If-Unmodified-Since header &SHOULD; be ignored. |
---|
728 | </t> |
---|
729 | <t> |
---|
730 | If the specified date is invalid, the header is ignored. |
---|
731 | </t> |
---|
732 | <t> |
---|
733 | The result of a request having both an If-Unmodified-Since header |
---|
734 | field and either an If-None-Match or an If-Modified-Since header |
---|
735 | fields is undefined by this specification. |
---|
736 | </t> |
---|
737 | </section> |
---|
738 | |
---|
739 | <section title="Last-Modified" anchor="header.last-modified"> |
---|
740 | <iref primary="true" item="Last-Modified header" x:for-anchor=""/> |
---|
741 | <iref primary="true" item="Headers" subitem="Last-Modified" x:for-anchor=""/> |
---|
742 | <t> |
---|
743 | The Last-Modified entity-header field indicates the date and time at |
---|
744 | which the origin server believes the variant was last modified. |
---|
745 | </t> |
---|
746 | <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/> |
---|
747 | Last-Modified = "Last-Modified" ":" HTTP-date |
---|
748 | </artwork></figure> |
---|
749 | <t> |
---|
750 | An example of its use is |
---|
751 | </t> |
---|
752 | <figure><artwork type="example"> |
---|
753 | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
---|
754 | </artwork></figure> |
---|
755 | <t> |
---|
756 | The exact meaning of this header field depends on the implementation |
---|
757 | of the origin server and the nature of the original resource. For |
---|
758 | files, it may be just the file system last-modified time. For |
---|
759 | entities with dynamically included parts, it may be the most recent |
---|
760 | of the set of last-modify times for its component parts. For database |
---|
761 | gateways, it may be the last-update time stamp of the record. For |
---|
762 | virtual objects, it may be the last time the internal state changed. |
---|
763 | </t> |
---|
764 | <t> |
---|
765 | An origin server &MUST-NOT; send a Last-Modified date which is later |
---|
766 | than the server's time of message origination. In such cases, where |
---|
767 | the resource's last modification would indicate some time in the |
---|
768 | future, the server &MUST; replace that date with the message |
---|
769 | origination date. |
---|
770 | </t> |
---|
771 | <t> |
---|
772 | An origin server &SHOULD; obtain the Last-Modified value of the entity |
---|
773 | as close as possible to the time that it generates the Date value of |
---|
774 | its response. This allows a recipient to make an accurate assessment |
---|
775 | of the entity's modification time, especially if the entity changes |
---|
776 | near the time that the response is generated. |
---|
777 | </t> |
---|
778 | <t> |
---|
779 | HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible. |
---|
780 | </t> |
---|
781 | </section> |
---|
782 | |
---|
783 | </section> |
---|
784 | |
---|
785 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
786 | <t> |
---|
787 | TBD. |
---|
788 | </t> |
---|
789 | </section> |
---|
790 | |
---|
791 | <section title="Security Considerations" anchor="security.considerations"> |
---|
792 | <t> |
---|
793 | No additional security considerations have been identified beyond |
---|
794 | those applicable to HTTP in general &messaging;. |
---|
795 | </t> |
---|
796 | </section> |
---|
797 | |
---|
798 | <section title="Acknowledgments" anchor="ack"> |
---|
799 | <t> |
---|
800 | Based on an XML translation of RFC 2616 by Julian Reschke. |
---|
801 | </t> |
---|
802 | </section> |
---|
803 | </middle> |
---|
804 | <back> |
---|
805 | <references> |
---|
806 | <reference anchor="Part1"> |
---|
807 | <front> |
---|
808 | <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
809 | |
---|
810 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
811 | <organization abbrev="Day Software">Day Software</organization> |
---|
812 | <address> |
---|
813 | <email>fielding@gbiv.com</email> |
---|
814 | </address> |
---|
815 | </author> |
---|
816 | |
---|
817 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
818 | <organization>One Laptop per Child</organization> |
---|
819 | <address> |
---|
820 | <email>jg@laptop.org</email> |
---|
821 | </address> |
---|
822 | </author> |
---|
823 | |
---|
824 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
825 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
826 | <address> |
---|
827 | <email>JeffMogul@acm.org</email> |
---|
828 | </address> |
---|
829 | </author> |
---|
830 | |
---|
831 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
832 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
833 | <address> |
---|
834 | <email>henrikn@microsoft.com</email> |
---|
835 | </address> |
---|
836 | </author> |
---|
837 | |
---|
838 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
839 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
840 | <address> |
---|
841 | <email>LMM@acm.org</email> |
---|
842 | </address> |
---|
843 | </author> |
---|
844 | |
---|
845 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
846 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
847 | <address> |
---|
848 | <email>paulle@microsoft.com</email> |
---|
849 | </address> |
---|
850 | </author> |
---|
851 | |
---|
852 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
853 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
854 | <address> |
---|
855 | <email>timbl@w3.org</email> |
---|
856 | </address> |
---|
857 | </author> |
---|
858 | |
---|
859 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
860 | </front> |
---|
861 | <seriesInfo name="Internet-Draft" value="draft-fielding-p1-messaging-&ID-VERSION;"/> |
---|
862 | <x:source href="p1-messaging.xml" basename="p1-messaging"/> |
---|
863 | </reference> |
---|
864 | |
---|
865 | <reference anchor="Part5"> |
---|
866 | <front> |
---|
867 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
868 | |
---|
869 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
870 | <organization abbrev="Day Software">Day Software</organization> |
---|
871 | <address> |
---|
872 | <email>fielding@gbiv.com</email> |
---|
873 | </address> |
---|
874 | </author> |
---|
875 | |
---|
876 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
877 | <organization>One Laptop per Child</organization> |
---|
878 | <address> |
---|
879 | <email>jg@laptop.org</email> |
---|
880 | </address> |
---|
881 | </author> |
---|
882 | |
---|
883 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
884 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
885 | <address> |
---|
886 | <email>JeffMogul@acm.org</email> |
---|
887 | </address> |
---|
888 | </author> |
---|
889 | |
---|
890 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
891 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
892 | <address> |
---|
893 | <email>henrikn@microsoft.com</email> |
---|
894 | </address> |
---|
895 | </author> |
---|
896 | |
---|
897 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
898 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
899 | <address> |
---|
900 | <email>LMM@acm.org</email> |
---|
901 | </address> |
---|
902 | </author> |
---|
903 | |
---|
904 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
905 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
906 | <address> |
---|
907 | <email>paulle@microsoft.com</email> |
---|
908 | </address> |
---|
909 | </author> |
---|
910 | |
---|
911 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
912 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
913 | <address> |
---|
914 | <email>timbl@w3.org</email> |
---|
915 | </address> |
---|
916 | </author> |
---|
917 | |
---|
918 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
919 | </front> |
---|
920 | <seriesInfo name="Internet-Draft" value="draft-fielding-p5-range-&ID-VERSION;"/> |
---|
921 | <x:source href="p5-range.xml" basename="p5-range"/> |
---|
922 | </reference> |
---|
923 | |
---|
924 | <reference anchor="Part6"> |
---|
925 | <front> |
---|
926 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
927 | |
---|
928 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
929 | <organization abbrev="Day Software">Day Software</organization> |
---|
930 | <address> |
---|
931 | <email>fielding@gbiv.com</email> |
---|
932 | </address> |
---|
933 | </author> |
---|
934 | |
---|
935 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
936 | <organization>One Laptop per Child</organization> |
---|
937 | <address> |
---|
938 | <email>jg@laptop.org</email> |
---|
939 | </address> |
---|
940 | </author> |
---|
941 | |
---|
942 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
943 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
944 | <address> |
---|
945 | <email>JeffMogul@acm.org</email> |
---|
946 | </address> |
---|
947 | </author> |
---|
948 | |
---|
949 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
950 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
951 | <address> |
---|
952 | <email>henrikn@microsoft.com</email> |
---|
953 | </address> |
---|
954 | </author> |
---|
955 | |
---|
956 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
957 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
958 | <address> |
---|
959 | <email>LMM@acm.org</email> |
---|
960 | </address> |
---|
961 | </author> |
---|
962 | |
---|
963 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
964 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
965 | <address> |
---|
966 | <email>paulle@microsoft.com</email> |
---|
967 | </address> |
---|
968 | </author> |
---|
969 | |
---|
970 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
971 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
972 | <address> |
---|
973 | <email>timbl@w3.org</email> |
---|
974 | </address> |
---|
975 | </author> |
---|
976 | |
---|
977 | <date month="&ID-MONTH;" year="&ID-YEAR;"/> |
---|
978 | </front> |
---|
979 | <seriesInfo name="Internet-Draft" value="draft-fielding-p6-cache-&ID-VERSION;"/> |
---|
980 | <x:source href="p6-cache.xml" basename="p6-cache"/> |
---|
981 | </reference> |
---|
982 | |
---|
983 | |
---|
984 | <reference anchor="RFC2616"> |
---|
985 | <front> |
---|
986 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
987 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
988 | <organization>University of California, Irvine</organization> |
---|
989 | <address><email>fielding@ics.uci.edu</email></address> |
---|
990 | </author> |
---|
991 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
992 | <organization>W3C</organization> |
---|
993 | <address><email>jg@w3.org</email></address> |
---|
994 | </author> |
---|
995 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
996 | <organization>Compaq Computer Corporation</organization> |
---|
997 | <address><email>mogul@wrl.dec.com</email></address> |
---|
998 | </author> |
---|
999 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
1000 | <organization>MIT Laboratory for Computer Science</organization> |
---|
1001 | <address><email>frystyk@w3.org</email></address> |
---|
1002 | </author> |
---|
1003 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
1004 | <organization>Xerox Corporation</organization> |
---|
1005 | <address><email>masinter@parc.xerox.com</email></address> |
---|
1006 | </author> |
---|
1007 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
1008 | <organization>Microsoft Corporation</organization> |
---|
1009 | <address><email>paulle@microsoft.com</email></address> |
---|
1010 | </author> |
---|
1011 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
1012 | <organization>W3C</organization> |
---|
1013 | <address><email>timbl@w3.org</email></address> |
---|
1014 | </author> |
---|
1015 | <date month="June" year="1999"/> |
---|
1016 | </front> |
---|
1017 | <seriesInfo name="RFC" value="2616"/> |
---|
1018 | </reference> |
---|
1019 | </references> |
---|
1020 | </back> |
---|
1021 | </rfc> |
---|