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