1 |
|
2 |
HTTP Working Group R. Fielding, UC Irvine |
3 |
INTERNET-DRAFT H. Frystyk, MIT/LCS |
4 |
<draft-ietf-http-v11-spec-02.txt> T. Berners-Lee, MIT/LCS |
5 |
J. Gettys, DEC |
6 |
Jeffrey C. Mogul, DEC |
7 |
Expires September 23, 1996 April 23, 1996 |
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
Hypertext Transfer Protocol -- HTTP/1.1 |
14 |
|
15 |
Status of this Memo |
16 |
|
17 |
This document is an Internet-Draft. Internet-Drafts are working |
18 |
documents of the Internet Engineering Task Force (IETF), its areas, and |
19 |
its working groups. Note that other groups may also distribute working |
20 |
documents as Internet-Drafts. |
21 |
|
22 |
Internet-Drafts are draft documents valid for a maximum of six months |
23 |
and may be updated, replaced, or made obsolete by other documents at any |
24 |
time. It is inappropriate to use Internet-Drafts as reference material |
25 |
or to cite them other than as _work in progress_. |
26 |
|
27 |
To learn the current status of any Internet-Draft, please check the |
28 |
_1id-abstracts.txt_ listing contained in the Internet-Drafts Shadow |
29 |
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
30 |
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or |
31 |
ftp.isi.edu (US West Coast). |
32 |
|
33 |
Distribution of this document is unlimited. Please send comments to the |
34 |
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the |
35 |
working group are archived at |
36 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about |
37 |
HTTP and the applications which use HTTP should take place on the <www- |
38 |
talk@w3.org> mailing list. |
39 |
|
40 |
NOTE: This specification is for discussion purposes only. It is |
41 |
not claimed to represent the consensus of the HTTP working |
42 |
group, and contains a number of proposals that either have not |
43 |
been discussed or are controversial. The working group is |
44 |
discussing significant changes in many areas, including - |
45 |
support for caching, persistent connections, range retrieval, |
46 |
content negotiation, MIME compatibility, authentication, timing |
47 |
of the PUT operation. |
48 |
|
49 |
|
50 |
Abstract |
51 |
The Hypertext Transfer Protocol (HTTP) is an application-level protocol |
52 |
for distributed, collaborative, hypermedia information systems. It is a |
53 |
generic, stateless, object-oriented protocol which can be used for many |
54 |
tasks, such as name servers and distributed object management systems, |
55 |
through extension of its request methods (commands). A feature of HTTP |
56 |
is the typing and negotiation of data representation, allowing systems |
57 |
to be built independently of the data being transferred. |
58 |
|
59 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 1] |
60 |
|
61 |
|
62 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
63 |
|
64 |
|
65 |
HTTP has been in use by the World-Wide Web global information initiative |
66 |
since 1990. This specification defines the protocol referred to as |
67 |
_HTTP/1.1_. |
68 |
|
69 |
Note to Readers of This Document |
70 |
This document is still organized to minimize changes from the previous |
71 |
draft, to ease reviewers work in finding new material (and because the |
72 |
editor has not had time to reorganize it).. However, the current |
73 |
organization is now quite poor for new readers of this document. We |
74 |
recommend that new readers of this document not read it in the current |
75 |
order of presentation, but may want to skip ahead after reading sections |
76 |
1-9 and read sections 11, 12 13 and 14 before reading section 10 which |
77 |
defines the header field definitions. Section 10 itself is now also not |
78 |
in alphabetical order, again, to avoid renumbering sections to be able |
79 |
to easily compare between drafts. |
80 |
|
81 |
If you are reading the version of this document showing revision markup, |
82 |
note that we've tried to preserve significant changes from the previous |
83 |
version, though a few changes may have slipped through unmarked. We make |
84 |
no guarantees that all changes have revision marks, though we've tried |
85 |
to preserve them as an aid to those who wish to check a specific change |
86 |
has been reflected in this draft. |
87 |
|
88 |
Note that some sections are still marked as SLUSHY and a few are marked |
89 |
FLUID; these are still undergoing drafting. |
90 |
|
91 |
Note that text in bold in the text are as yet incompletely resolved |
92 |
issues. Opinions are solicited_ |
93 |
|
94 |
|
95 |
|
96 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 |
|
112 |
|
113 |
|
114 |
|
115 |
|
116 |
|
117 |
|
118 |
|
119 |
|
120 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 2] |
121 |
|
122 |
|
123 |
|
124 |
|
125 |
|
126 |
|
127 |
Table of Contents |
128 |
|
129 |
|
130 |
|
131 |
|
132 |
HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1................................1 |
133 |
|
134 |
Status of this Memo....................................................1 |
135 |
|
136 |
Abstract...............................................................1 |
137 |
|
138 |
Note to Readers of This Document.......................................2 |
139 |
|
140 |
Table of Contents......................................................3 |
141 |
|
142 |
1. Introduction........................................................9 |
143 |
1.1 Purpose ..........................................................9 |
144 |
1.2 Requirements .....................................................9 |
145 |
1.3 Terminology .....................................................10 |
146 |
1.4 Overall Operation ...............................................12 |
147 |
1.4 HTTP and MIME ...................................................14 |
148 |
|
149 |
2. Notational Conventions and Generic Grammar.........................14 |
150 |
2.1 Augmented BNF ...................................................14 |
151 |
2.2 Basic Rules .....................................................16 |
152 |
|
153 |
3. Protocol Parameters................................................18 |
154 |
3.1 HTTP Version ....................................................18 |
155 |
3.2 Uniform Resource Identifiers ....................................19 |
156 |
3.2.1 General Syntax ...............................................19 |
157 |
3.2.2 http URL .....................................................21 |
158 |
3.3 Date/Time Formats ...............................................22 |
159 |
3.3.1 Full Date ....................................................22 |
160 |
3.3.2 Delta Seconds ................................................24 |
161 |
3.4 Character Sets ..................................................24 |
162 |
3.5 Content Codings .................................................25 |
163 |
3.6 Transfer Codings ................................................26 |
164 |
3.7 Media Types .....................................................27 |
165 |
3.7.1 Canonicalization and Text Defaults ...........................28 |
166 |
3.7.2 Multipart Types ..............................................29 |
167 |
3.8 Product Tokens ..................................................29 |
168 |
3.9 Quality Values ..................................................30 |
169 |
3.10 Language Tags ..................................................30 |
170 |
3.12 Full Date Values ...............................................31 |
171 |
3.13 Opaque Validators ..............................................31 |
172 |
3.14 Variant IDs ....................................................32 |
173 |
3.15 Validator Sets .................................................32 |
174 |
3.16 Variant Sets ...................................................32 |
175 |
3.17 HTTP Protocol Parameters Related to Ranges .....................32 |
176 |
3.17.1SLUSHY Range Units ...........................................32 |
177 |
3.17.2 SLUSHY Byte Ranges ..........................................33 |
178 |
3.17.3 SLUSHY: Content Ranges ......................................34 |
179 |
|
180 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3] |
181 |
|
182 |
|
183 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
184 |
|
185 |
|
186 |
4. HTTP Message.......................................................35 |
187 |
4.1 Message Types ...................................................35 |
188 |
4.2 Message Headers .................................................36 |
189 |
4.3 General Header Fields ...........................................37 |
190 |
|
191 |
5. Request............................................................38 |
192 |
5.1 Request-Line ....................................................38 |
193 |
5.1.1 Method .......................................................38 |
194 |
5.1.2 Request-URI ..................................................39 |
195 |
5.2 Request Header Fields ...........................................41 |
196 |
|
197 |
6. Response...........................................................42 |
198 |
6.1 Status-Line .....................................................43 |
199 |
6.1.1 Status Code and Reason Phrase ................................43 |
200 |
6.2 Response Header Fields ..........................................46 |
201 |
|
202 |
7. Entity.............................................................46 |
203 |
7.1 Entity Header Fields ............................................46 |
204 |
7.2 Entity Body .....................................................47 |
205 |
7.2.1 Type .........................................................48 |
206 |
7.2.2 Length .......................................................48 |
207 |
|
208 |
8. Method Definitions.................................................49 |
209 |
8.1 OPTIONS .........................................................49 |
210 |
8.2 GET .............................................................50 |
211 |
8.3 HEAD ............................................................50 |
212 |
8.4 POST ............................................................51 |
213 |
8.4.1 SLUSHY: Entity Transmission Requirements .....................52 |
214 |
8.5 PUT .............................................................53 |
215 |
8.9 DELETE ..........................................................54 |
216 |
8.12 TRACE ..........................................................54 |
217 |
|
218 |
9. Status Code Definitions............................................55 |
219 |
9.1 Informational 1xx ...............................................55 |
220 |
9.2 Successful 2xx ..................................................56 |
221 |
9.3 Redirection 3xx .................................................58 |
222 |
9.4 Client Error 4xx ................................................60 |
223 |
9.5 Server Error 5xx ................................................63 |
224 |
|
225 |
10. Header Field Definitions..........................................65 |
226 |
10.1 Accept .........................................................65 |
227 |
10.2 Accept-Charset .................................................67 |
228 |
10.3 Accept-Encoding ................................................67 |
229 |
10.4 Accept-Language ................................................68 |
230 |
10.5 Allow ..........................................................69 |
231 |
10.6 Authorization ..................................................70 |
232 |
10.7 Cache-Control ..................................................70 |
233 |
Check: is this true? ...............................................72 |
234 |
10.7.1 SLUSHY: Restrictions on What is Cachable ....................72 |
235 |
10.7.2 Restrictions On What May be Stored by a Cache ...............73 |
236 |
10.7.3 Modifications of the Basic Expiration Mechanism .............73 |
237 |
10.7.4 SLUSHY: Controls over cache revalidation and reload .........74 |
238 |
10.7.5 FLUID: Restrictions on use count and demographic reporting ..76 |
239 |
10.7.6 Miscellaneous restrictions ..................................77 |
240 |
|
241 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4] |
242 |
|
243 |
|
244 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
245 |
|
246 |
|
247 |
10.8 Connection .....................................................77 |
248 |
10.8.1 Persist ......................................................78 |
249 |
10.9 Content-Base ...................................................78 |
250 |
10.10 Content-Encoding ..............................................78 |
251 |
10.11 Content-Language ..............................................79 |
252 |
10.12 Content-Length ................................................80 |
253 |
10.13 Content-MD5 ...................................................80 |
254 |
10.14 SLUSHY Content-Range ..........................................82 |
255 |
10.14.1 MIME multipart/byteranges content-type .....................82 |
256 |
10.14.2 Additional rules for Content-Range .........................83 |
257 |
10.15 Content-Type ..................................................83 |
258 |
10.16 Content-Location ..............................................84 |
259 |
10.17 Date ..........................................................84 |
260 |
10.19 SLUSHY Expires ................................................85 |
261 |
10.20 Via ...........................................................86 |
262 |
10.21 From ..........................................................88 |
263 |
10.22 Host ..........................................................88 |
264 |
10.23 If-Modified-Since .............................................89 |
265 |
10.25 Last-Modified .................................................90 |
266 |
10.27 Location ......................................................91 |
267 |
10.29 Pragma ........................................................91 |
268 |
10.30 Proxy-Authenticate ............................................92 |
269 |
10.31 Proxy-Authorization ...........................................92 |
270 |
10.32 Public ........................................................93 |
271 |
10.33 Range .........................................................93 |
272 |
10.34 Referer .......................................................94 |
273 |
10.36 Retry-After ...................................................95 |
274 |
10.37 Server ........................................................95 |
275 |
10.38 Title .........................................................95 |
276 |
10.39 Transfer Encoding .............................................96 |
277 |
10.41 Upgrade .......................................................96 |
278 |
10.43 User-Agent ....................................................97 |
279 |
10.44 WWW-Authenticate ..............................................98 |
280 |
10.45 Max-Forwards ..................................................98 |
281 |
10.46 Age ...........................................................99 |
282 |
10.47 CVal ..........................................................99 |
283 |
10.48 If-Invalid ....................................................99 |
284 |
10.49 If-Valid .....................................................100 |
285 |
10.50 If-Unmodified-Since ..........................................101 |
286 |
10.51 Warning ......................................................102 |
287 |
10.52 Vary .........................................................103 |
288 |
10.53 Alternates ...................................................106 |
289 |
10.54 SLUSHY: Accept-Ranges ........................................107 |
290 |
10.55 SLUSHY: Range-If .............................................107 |
291 |
|
292 |
11. Access Authentication............................................108 |
293 |
11.1 Basic Authentication Scheme ...................................109 |
294 |
11.2 Digest Authentication Scheme ..................................110 |
295 |
|
296 |
12. Content Negotiation..............................................111 |
297 |
12.1 Negotiation facilities defined in this specification .........111 |
298 |
|
299 |
13 Caching in HTTP...................................................112 |
300 |
13.1 Semantic Transparency .........................................112 |
301 |
|
302 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5] |
303 |
|
304 |
|
305 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
306 |
|
307 |
|
308 |
13.2 Expiration Model ..............................................113 |
309 |
13.2.1 Server-Specified Expiration ................................113 |
310 |
13.2.2 Limitations on the Effect of Expiration Times ..............114 |
311 |
13.2.3 Heuristic Expiration .......................................114 |
312 |
13.2.4 Client-controlled Behavior .................................114 |
313 |
13.2.5 Exceptions to the Rules and Warnings .......................115 |
314 |
13.2.6 Age Calculations ...........................................115 |
315 |
13.2.7 Expiration Calculations ....................................117 |
316 |
13.2.8 UT Mandatory ................................................118 |
317 |
13.3 Validation Model ..............................................118 |
318 |
13.3.1 Last-modified Dates ........................................119 |
319 |
13.3.2 Opaque Validators ..........................................119 |
320 |
13.3.3 Weak and Strong Validators .................................120 |
321 |
13.3.4 Rules for When to Use Opaque Validators and Last-modified |
322 |
Dates .............................................................122 |
323 |
13.3.5 SLUSHY: Non-validating conditionals ........................123 |
324 |
13.3.6 FLUID: Other Issues ........................................123 |
325 |
13.4 Cache-control Mechanisms ......................................123 |
326 |
13.5 Warnings ......................................................124 |
327 |
13.6 Explicit Indications Regarding User-specified Overrides .......124 |
328 |
13.7 Constructing Responses From Caches ............................125 |
329 |
13.7.1 End-to-end and Hop-by-hop Headers ..........................125 |
330 |
13.7.2 Non-modifiable Headers .....................................126 |
331 |
13.7.3 Combining Headers ..........................................126 |
332 |
13.7.4 Combining Byte Ranges ......................................126 |
333 |
13.7.5 SLUSHY: Scope of Expiration ................................127 |
334 |
13.8 Caching and Content Negotiation ...............................127 |
335 |
13.8.1 Use of the Vary header .....................................127 |
336 |
13.8.2 SLUSHY: Use of the Alternates header .......................128 |
337 |
13.8.3 Use of Variant-IDs .........................................128 |
338 |
13.8.4 Use of Selecting Opaque Validators .........................129 |
339 |
13.10 Shared and Non-Shared Caches .................................130 |
340 |
13.11 SLUSHY: Miscellaneous Considerations .........................130 |
341 |
13.11.1 Detecting Firsthand Responses .............................130 |
342 |
13.11.2 Disambiguating Expiration values ..........................130 |
343 |
13.11.3 Disambiguating Multiple Responses .........................131 |
344 |
13.12 SLUSHY: Cache Keys ...........................................131 |
345 |
13.12.1 Non-varying Resources .....................................132 |
346 |
13.12.2 SLUSHY: Varying Resources .................................132 |
347 |
13.12.3 SLUSHY: Key-Matching Procedure ............................133 |
348 |
13.12.4 Canonicalization of URIs ..................................134 |
349 |
13.13 FLUID: Cache-Related Problems Not Addressed in HTTP/1.1 ......134 |
350 |
13.14 Cache Operation When Receiving Errors or Incomplete Responses 134 |
351 |
13.14.1 Caching and Status Codes ..................................135 |
352 |
13.14.2 Handling of Retry-After ...................................135 |
353 |
13.15 FLUID: Compatibility With Earlier Versions of HTTP ...........135 |
354 |
13.16 SLUSHY: Side Effects of GET and HEAD .........................135 |
355 |
13.17 SLUSHY: Invalidation After Updates or Deletions ..............136 |
356 |
13.18 Write-Through Mandatory ......................................136 |
357 |
13.19 Interoperability of Varying Resources with HTTP/1.0 Proxy |
358 |
Caches .............................................................136 |
359 |
13.20 Cache Replacement for Varying Resources ......................137 |
360 |
13.22 FLUID: Network Partitions ....................................138 |
361 |
13.23 FLUID: Caching of Negative Responses .........................138 |
362 |
|
363 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6] |
364 |
|
365 |
|
366 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
367 |
|
368 |
|
369 |
13.24 History Lists ................................................138 |
370 |
|
371 |
14 Persistent Connections............................................138 |
372 |
14.1 Purpose .......................................................138 |
373 |
14.2 Overall Operation .............................................139 |
374 |
14.2.3 Negotiation ................................................139 |
375 |
14.2.4 Pipe-lining ................................................139 |
376 |
14.2.5 Delimiting Entity-Bodies ...................................139 |
377 |
14.3 Proxy Servers .................................................140 |
378 |
14.4 Interaction with Security Protocols ...........................140 |
379 |
14.5 Practical Considerations ......................................140 |
380 |
|
381 |
15. Security Considerations..........................................141 |
382 |
15.1 Authentication of Clients .....................................141 |
383 |
15.2 Safe Methods ..................................................142 |
384 |
15.3 Abuse of Server Log Information ...............................143 |
385 |
15.4 Transfer of Sensitive Information .............................143 |
386 |
15.5 Attacks Based On File and Path Names ..........................143 |
387 |
15.6 Personal Information ..........................................144 |
388 |
15.7 Privacy issues connected to Accept headers ....................144 |
389 |
15.8 DNS Spoofing ..................................................145 |
390 |
15.9 SLUSHY: Location Headers and Spoofing .........................145 |
391 |
|
392 |
16. Acknowledgments..................................................145 |
393 |
|
394 |
17. References.......................................................147 |
395 |
|
396 |
18. Authors' Addresses...............................................150 |
397 |
|
398 |
Appendices...........................................................151 |
399 |
|
400 |
A. Internet Media Type message/http..................................151 |
401 |
|
402 |
B. Tolerant Applications.............................................152 |
403 |
|
404 |
C. Differences Between HTTP Bodies and RFC 1521 Internet Message Bodies |
405 |
.....................................................................152 |
406 |
C.1 Conversion to Canonical Form ...................................153 |
407 |
C.2 Conversion of Date Formats .....................................153 |
408 |
C.3 Introduction of Content-Encoding ...............................153 |
409 |
C.4 No Content-Transfer-Encoding ...................................154 |
410 |
C.5 HTTP Header Fields in Multipart Body-Parts .....................154 |
411 |
C.6 Introduction of Transfer-Encoding ..............................154 |
412 |
C.7 MIME-Version ...................................................155 |
413 |
|
414 |
D. Changes from HTTP/1.0.............................................155 |
415 |
D.1 Changes to Simplify Multi-homed Web Servers and Conserve IP |
416 |
Addresses ..........................................................155 |
417 |
|
418 |
E. Additional Features...............................................156 |
419 |
E.1 Additional Request Methods .....................................156 |
420 |
E.1.1 PATCH .......................................................156 |
421 |
E.1.2 LINK ........................................................157 |
422 |
E.1.3 UNLINK ......................................................157 |
423 |
|
424 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 7] |
425 |
|
426 |
|
427 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
428 |
|
429 |
|
430 |
E.2 Additional Header Field Definitions ............................157 |
431 |
E.2.1 Content-Version .............................................157 |
432 |
E.2.2 Derived-From ................................................158 |
433 |
E.2.3 Link ........................................................158 |
434 |
E.2.4 URI .........................................................159 |
435 |
E.2.5 Compatibility with HTTP/1.0 Persistent Connections ..........160 |
436 |
F.1 Compatibility with Previous Versions ...........................160 |
437 |
G. Proxy Cache Implementation Guidelines ...........................161 |
438 |
G.1 Support for Content Negotiation by Proxy Caches ................161 |
439 |
G.2 Propagation of Changes in Opaque Selection ....................163 |
440 |
G.3 SLUSHY: State ..................................................163 |
441 |
G.4 FLUID: Cache Replacement Algorithms ............................163 |
442 |
G.5 FLUID: Bypassing in Caching Hierarchies ........................164 |
443 |
|
444 |
|
445 |
|
446 |
|
447 |
|
448 |
|
449 |
|
450 |
|
451 |
|
452 |
|
453 |
|
454 |
|
455 |
|
456 |
|
457 |
|
458 |
|
459 |
|
460 |
|
461 |
|
462 |
|
463 |
|
464 |
|
465 |
|
466 |
|
467 |
|
468 |
|
469 |
|
470 |
|
471 |
|
472 |
|
473 |
|
474 |
|
475 |
|
476 |
|
477 |
|
478 |
|
479 |
|
480 |
|
481 |
|
482 |
|
483 |
|
484 |
|
485 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8] |
486 |
|
487 |
|
488 |
|
489 |
|
490 |
|
491 |
1. Introduction |
492 |
1.1 Purpose |
493 |
The Hypertext Transfer Protocol (HTTP) is an application-level protocol |
494 |
for distributed, collaborative, hypermedia information systems. HTTP has |
495 |
been in use by the World-Wide Web global information initiative since |
496 |
1990. The first version of HTTP, referred to as HTTP/0.9, was a simple |
497 |
protocol for raw data transfer across the Internet. HTTP/1.0, as defined |
498 |
by RFC xxxx [6], improved the protocol by allowing messages to be in the |
499 |
format of MIME-like entities, containing metainformation about the data |
500 |
transferred and modifiers on the request/response semantics. However, |
501 |
HTTP/1.0 does not sufficiently take into consideration the effect of |
502 |
hierarchical proxies and caching, the desire for persistent connections |
503 |
and virtual hosts, and a number of other details that slipped through |
504 |
the cracks of existing implementations. In addition, the proliferation |
505 |
of incompletely-implemented applications calling themselves _HTTP/1.0_ |
506 |
has necessitated a protocol version change in order for two |
507 |
communicating applications to determine each other's true capabilities. |
508 |
|
509 |
This specification defines the protocol referred to as _HTTP/1.1_. This |
510 |
protocol is backwards-compatible with HTTP/1.0, but includes more |
511 |
stringent requirements in order to ensure reliable implementation of its |
512 |
features. |
513 |
|
514 |
Practical information systems require more functionality than simple |
515 |
retrieval, including search, front-end update, and annotation. HTTP |
516 |
allows an open-ended set of methods that indicate the purpose of a |
517 |
request. It builds on the discipline of reference provided by the |
518 |
Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name |
519 |
(URN) [20], for indicating the resource on which a method is to be |
520 |
applied. Messages are passed in a format similar to that used by |
521 |
Internet Mail [9] and the Multipurpose Internet Mail Extensions (MIME) |
522 |
[7]. |
523 |
|
524 |
HTTP is also used as a generic protocol for communication between user |
525 |
agents and proxies/gateways to other Internet protocols, such as SMTP |
526 |
[16], NNTP [13], FTP [18], Gopher [2], and WAIS [10], allowing basic |
527 |
|
528 |
hypermedia access to resources available from diverse applications and |
529 |
simplifying the implementation of user agents. |
530 |
|
531 |
|
532 |
1.2 Requirements |
533 |
This specification uses the same words as RFC 1123 [8] for defining the |
534 |
|
535 |
significance of each particular requirement. These words are: |
536 |
|
537 |
|
538 |
MUST |
539 |
This word or the adjective _required_ means that the item is an |
540 |
absolute requirement of the specification. |
541 |
|
542 |
SHOULD |
543 |
This word or the adjective _recommended_ means that there may exist |
544 |
valid reasons in particular circumstances to ignore this item, but |
545 |
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 9] |
546 |
|
547 |
|
548 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
549 |
|
550 |
|
551 |
the full implications should be understood and the case carefully |
552 |
weighed before choosing a different course. |
553 |
|
554 |
MAY |
555 |
This word or the adjective _optional_ means that this item is truly |
556 |
optional. One vendor may choose to include the item because a |
557 |
particular marketplace requires it or because it enhances the |
558 |
product, for example; another vendor may omit the same item. |
559 |
An implementation is not compliant if it fails to satisfy one or more of |
560 |
the MUST requirements for the protocols it implements. An implementation |
561 |
that satisfies all the MUST and all the SHOULD requirements for its |
562 |
protocols is said to be _unconditionally compliant_; one that satisfies |
563 |
all the MUST requirements but not all the SHOULD requirements for its |
564 |
protocols is said to be _conditionally compliant_. |
565 |
|
566 |
|
567 |
1.3 Terminology |
568 |
This specification uses a number of terms to refer to the roles played |
569 |
by participants in, and objects of, the HTTP communication. |
570 |
|
571 |
|
572 |
connection |
573 |
A transport layer virtual circuit established between two |
574 |
application programs for the purpose of communication. |
575 |
|
576 |
|
577 |
message |
578 |
The basic unit of HTTP communication, consisting of a structured |
579 |
sequence of octets matching the syntax defined in Section 4 and |
580 |
|
581 |
transmitted via the connection. |
582 |
|
583 |
|
584 |
request |
585 |
An HTTP request message (as defined in Section 5). |
586 |
|
587 |
|
588 |
|
589 |
response |
590 |
An HTTP response message (as defined in Section 6). |
591 |
|
592 |
|
593 |
|
594 |
resource |
595 |
A network data object or service that can be identified by a URI |
596 |
(Section 3.2). |
597 |
|
598 |
|
599 |
|
600 |
entity |
601 |
A particular representation, rendition, encoding, or presentation |
602 |
of a resource. Resources not supporting content negotiation are |
603 |
bound to a single entity. Resources supporting content negotiation |
604 |
|
605 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10] |
606 |
|
607 |
|
608 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
609 |
|
610 |
|
611 |
are bound to a set of one or more entities, whose membership may |
612 |
vary over time. |
613 |
|
614 |
entity instance |
615 |
The definite value of an entity at a given |
616 |
point in time. The HTTP protocol transfers |
617 |
entity instances in request or response |
618 |
messages. An entity instance is transferred as |
619 |
metainformation in the form of entity headers |
620 |
and content in the form of an entity body. |
621 |
|
622 |
|
623 |
client |
624 |
An application program that establishes connections for the purpose |
625 |
of sending requests. |
626 |
|
627 |
|
628 |
user agent |
629 |
The client which initiates a request. These are often browsers, |
630 |
editors, spiders (web-traversing robots), or other end user tools. |
631 |
|
632 |
|
633 |
server |
634 |
An application program that accepts connections in order to service |
635 |
requests by sending back responses. |
636 |
|
637 |
|
638 |
origin server |
639 |
The server on which a given resource resides or is to be created. |
640 |
|
641 |
|
642 |
proxy |
643 |
An intermediary program which acts as both a server and a client |
644 |
for the purpose of making requests on behalf of other clients. |
645 |
Requests are serviced internally or by passing them, with possible |
646 |
translation, on to other servers. A proxy MUST interpret and, if |
647 |
necessary, rewrite a request message before forwarding it. Proxies |
648 |
are often used as client-side portals through network firewalls and |
649 |
as helper applications for handling requests via protocols not |
650 |
implemented by the user agent. |
651 |
|
652 |
|
653 |
gateway |
654 |
A server which acts as an intermediary for some other server. |
655 |
Unlike a proxy, a gateway receives requests as if it were the |
656 |
origin server for the requested resource; the requesting client may |
657 |
not be aware that it is communicating with a gateway. Gateways are |
658 |
often used as server-side portals through network firewalls and as |
659 |
protocol translators for access to resources stored on non-HTTP |
660 |
systems. |
661 |
|
662 |
|
663 |
tunnel |
664 |
A tunnel is an intermediary program which is acting as a blind |
665 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11] |
666 |
|
667 |
|
668 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
669 |
|
670 |
|
671 |
relay between two connections. Once active, a tunnel is not |
672 |
considered a party to the HTTP communication, though the tunnel may |
673 |
have been initiated by an HTTP request. The tunnel ceases to exist |
674 |
when both ends of the relayed connections are closed. Tunnels are |
675 |
used when a portal is necessary and the intermediary cannot, or |
676 |
should not, interpret the relayed communication. |
677 |
|
678 |
|
679 |
cache |
680 |
A program's local store of response messages and the subsystem that |
681 |
controls its message storage, retrieval, and deletion. A cache |
682 |
stores cachable responses in order to reduce the response time and |
683 |
network bandwidth consumption on future, equivalent requests. Any |
684 |
client or server MAY include a cache, though a cache cannot be used |
685 |
by a server while it is acting as a tunnel. |
686 |
Any given program MAY be capable of being both a client and a server; |
687 |
our use of these terms refers only to the role being performed by the |
688 |
program for a particular connection, rather than to the program's |
689 |
capabilities in general. Likewise, any server MAY act as an origin |
690 |
server, proxy, gateway, or tunnel, switching behavior based on the |
691 |
nature of each request. |
692 |
|
693 |
|
694 |
1.4 Overall Operation |
695 |
The HTTP protocol is based on a request/response paradigm. A client |
696 |
sends a request to the server in the form of a request method, URI, and |
697 |
protocol version, followed by a MIME-like message containing request |
698 |
modifiers, client information, and possible body content over a |
699 |
connection with a server. The server responds with a status line, |
700 |
including the message's protocol version and a success or error code, |
701 |
followed by a MIME-like message containing server information, entity |
702 |
metainformation, and possible body content. |
703 |
|
704 |
Most HTTP communication is initiated by a user agent and consists of a |
705 |
request to be applied to a resource on some origin server. In the |
706 |
simplest case, this may be accomplished via a single connection (v) |
707 |
between the user agent (UA) and the origin server (O). |
708 |
|
709 |
request chain ------------------------> |
710 |
UA -------------------v------------------- O |
711 |
<----------------------- response chain |
712 |
|
713 |
|
714 |
|
715 |
A more complicated situation occurs when one or more intermediaries are |
716 |
present in the request/response chain. There are three common forms of |
717 |
intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, |
718 |
receiving requests for a URI in its absolute form, rewriting all or |
719 |
parts of the message, and forwarding the reformatted request toward the |
720 |
server identified by the URI. A gateway is a receiving agent, acting as |
721 |
a layer above some other server(s) and, if necessary, translating the |
722 |
requests to the underlying server's protocol. A tunnel acts as a relay |
723 |
point between two connections without changing the messages; tunnels are |
724 |
used when the communication needs to pass through an intermediary (such |
725 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12] |
726 |
|
727 |
|
728 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
729 |
|
730 |
|
731 |
as a firewall) even when the intermediary cannot understand the contents |
732 |
of the messages. |
733 |
|
734 |
request chain --------------------------------------> |
735 |
UA -----v----- A -----v----- B -----v----- C -----v----- O |
736 |
<------------------------------------- response chain |
737 |
|
738 |
|
739 |
|
740 |
The figure above shows three intermediaries (A, B, and C) between the |
741 |
user agent and origin server. A request or response message that travels |
742 |
the whole chain MUST pass through four separate connections. This |
743 |
distinction is important because some HTTP communication options may |
744 |
apply only to the connection with the nearest, non-tunnel neighbor, only |
745 |
to the end-points of the chain, or to all connections along the chain. |
746 |
Although the diagram is linear, each participant may be engaged in |
747 |
multiple, simultaneous communications. For example, B may be receiving |
748 |
requests from many clients other than A, and/or forwarding requests to |
749 |
servers other than C, at the same time that it is handling A's request. |
750 |
|
751 |
Any party to the communication which is not acting as a tunnel may |
752 |
employ an internal cache for handling requests. The effect of a cache is |
753 |
that the request/response chain is shortened if one of the participants |
754 |
along the chain has a cached response applicable to that request. The |
755 |
following illustrates the resulting chain if B has a cached copy of an |
756 |
earlier response from O (via C) for a request which has not been cached |
757 |
by UA or A. |
758 |
|
759 |
request chain ----------> |
760 |
UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
761 |
<--------- response chain |
762 |
|
763 |
|
764 |
|
765 |
Not all responses are cachable, and some requests may contain modifiers |
766 |
which place special requirements on cache behavior. HTTP requirements |
767 |
for cache behavior and cachable responses are defined in Section 13. |
768 |
|
769 |
|
770 |
On the Internet, HTTP communication generally takes place over TCP/IP |
771 |
connections. The default port is TCP 80 [19], but other ports can be |
772 |
|
773 |
used. This does not preclude HTTP from being implemented on top of any |
774 |
other protocol on the Internet, or on other networks. HTTP only presumes |
775 |
a reliable transport; any protocol that provides such guarantees can be |
776 |
used; the mapping of the HTTP/1.1 request and response structures onto |
777 |
the transport data units of the protocol in question is outside the |
778 |
scope of this specification. |
779 |
|
780 |
However, HTTP/1.1 implementations SHOULD implement persistent |
781 |
connections (See section 14). Both clients and servers MUST be capable |
782 |
of handling cases where either party closes the connection prematurely, |
783 |
due to user action, automated time-out, or program failure. In any case, |
784 |
|
785 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13] |
786 |
|
787 |
|
788 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
789 |
|
790 |
|
791 |
the closing of the connection by either or both parties always |
792 |
terminates the current request, regardless of its status. |
793 |
|
794 |
|
795 |
1.4 HTTP and MIME |
796 |
HTTP/1.1 uses many of the constructs defined for MIME, as defined in RFC |
797 |
1521 [7]. Appendix C describes the ways in which the context of HTTP |
798 |
|
799 |
allows for different use of Internet Media Types than is typically found |
800 |
in Internet mail, and gives the rationale for those differences. |
801 |
|
802 |
|
803 |
2. Notational Conventions and Generic Grammar |
804 |
|
805 |
2.1 Augmented BNF |
806 |
All of the mechanisms specified in this document are described in both |
807 |
prose and an augmented Backus-Naur Form (BNF) similar to that used by |
808 |
RFC 822 [9]. Implementers will need to be familiar with the notation in |
809 |
|
810 |
order to understand this specification. The augmented BNF includes the |
811 |
following constructs: |
812 |
|
813 |
|
814 |
name = definition |
815 |
The name of a rule is simply the name itself (without any enclosing |
816 |
"<" and ">") and is separated from its definition by the equal |
817 |
character "=". Whitespace is only significant in that indentation |
818 |
of continuation lines is used to indicate a rule definition that |
819 |
spans more than one line. Certain basic rules are in uppercase, |
820 |
such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are |
821 |
used within definitions whenever their presence will facilitate |
822 |
discerning the use of rule names. |
823 |
|
824 |
|
825 |
"literal" |
826 |
Quotation marks surround literal text. Unless stated otherwise, the |
827 |
text is case-insensitive. |
828 |
|
829 |
|
830 |
rule1 | rule2 |
831 |
Elements separated by a bar ("I") are alternatives, e.g., "yes | |
832 |
no" will accept yes or no. |
833 |
|
834 |
|
835 |
(rule1 rule2) |
836 |
Elements enclosed in parentheses are treated as a single element. |
837 |
Thus, _(elem (foo | bar) elem)_ allows the token sequences _elem |
838 |
foo elem_ and _elem bar elem_. |
839 |
|
840 |
|
841 |
*rule |
842 |
The character _*_ preceding an element indicates repetition. The |
843 |
full form is _<n>*<m>element_ indicating at least <n> and at most |
844 |
<m> occurrences of element. Default values are 0 and infinity so |
845 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14] |
846 |
|
847 |
|
848 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
849 |
|
850 |
|
851 |
that _*(element)_ allows any number, including zero; _1*element_ |
852 |
requires at least one; and _1*2element_ allows one or two. |
853 |
|
854 |
|
855 |
[rule] |
856 |
Square brackets enclose optional elements; _[foo bar]_ is |
857 |
equivalent to _*1(foo bar)_. |
858 |
|
859 |
|
860 |
N rule |
861 |
Specific repetition: _<n>(element)_ is equivalent to |
862 |
_<n>*<n>(element)_; that is, exactly <n> occurrences of (element). |
863 |
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three |
864 |
alphabetic characters. |
865 |
|
866 |
|
867 |
#rule |
868 |
A construct "#" is defined, similar to "*", for defining lists of |
869 |
elements. The full form is "<n>#<m>element" indicating at least <n> |
870 |
and at most <m> elements, each separated by one or more commas |
871 |
(",") and optional linear whitespace (LWS). This makes the usual |
872 |
form of lists very easy; a rule such as "( *LWS element *( *LWS "," |
873 |
*LWS element ))" can be shown as "1#element". Wherever this |
874 |
construct is used, null elements are allowed, but do not contribute |
875 |
to the count of elements present. That is, "(element), , (element)" |
876 |
is permitted, but counts as only two elements. Therefore, where at |
877 |
least one element is required, at least one non-null element MUST |
878 |
be present. Default values are 0 and infinity so that "#(element)" |
879 |
allows any number, including zero; "1#element" requires at least |
880 |
one; and _1#2element_ allows one or two. |
881 |
|
882 |
|
883 |
; comment |
884 |
A semi-colon, set off some distance to the right of rule text, |
885 |
starts a comment that continues to the end of line. This is a |
886 |
simple way of including useful notes in parallel with the |
887 |
specifications. |
888 |
|
889 |
|
890 |
implied *LWS |
891 |
The grammar described by this specification is word-based. Except |
892 |
where noted otherwise, linear whitespace (LWS) can be included |
893 |
between any two adjacent words (token or quoted-string), and |
894 |
between adjacent tokens and delimiters (tspecials), without |
895 |
changing the interpretation of a field. At least one delimiter |
896 |
(tspecials) MUST exist between any two tokens, since they would |
897 |
otherwise be interpreted as a single token. However, applications |
898 |
SHOULD attempt to follow _common form_ when generating HTTP |
899 |
constructs, since there exist some implementations that fail to |
900 |
accept anything beyond the common forms. |
901 |
|
902 |
|
903 |
|
904 |
|
905 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15] |
906 |
|
907 |
|
908 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
909 |
|
910 |
|
911 |
2.2 Basic Rules |
912 |
The following rules are used throughout this specification to describe |
913 |
basic parsing constructs. The US-ASCII coded character set is defined by |
914 |
[21]. |
915 |
|
916 |
|
917 |
OCTET = <any 8-bit sequence of data> |
918 |
CHAR = <any US-ASCII character (octets 0 - 127)> |
919 |
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
920 |
LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
921 |
ALPHA = UPALPHA | LOALPHA |
922 |
DIGIT = <any US-ASCII digit "0".."9"> |
923 |
CTL = <any US-ASCII control character |
924 |
(octets 0 - 31) and DEL (127)> |
925 |
CR = <US-ASCII CR, carriage return (13)> |
926 |
LF = <US-ASCII LF, linefeed (10)> |
927 |
SP = <US-ASCII SP, space (32)> |
928 |
HT = <US-ASCII HT, horizontal-tab (9)> |
929 |
<"> = <US-ASCII double-quote mark (34)> |
930 |
|
931 |
|
932 |
|
933 |
HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker for |
934 |
all protocol elements except the Entity-Body (see Appendix B for |
935 |
|
936 |
tolerant applications). The end-of-line marker within an Entity-Body is |
937 |
defined by its associated media type, as described in Section 3.7. |
938 |
|
939 |
|
940 |
CRLF = CR LF |
941 |
|
942 |
|
943 |
|
944 |
HTTP/1.1 headers can be folded onto multiple lines if the continuation |
945 |
line begins with a space or horizontal tab. All linear whitespace, |
946 |
including folding, has the same semantics as SP. |
947 |
|
948 |
LWS = [CRLF] 1*( SP | HT ) |
949 |
|
950 |
|
951 |
|
952 |
The TEXT rule is only used for descriptive field contents and values |
953 |
that are not intended to be interpreted by the message parser. Words of |
954 |
*TEXT MAY contain octets from character sets other than US-ASCII only |
955 |
when encoded according to the rules of RFC 1522 [14]. |
956 |
|
957 |
|
958 |
TEXT = <any OCTET except CTLs, |
959 |
but including LWS> |
960 |
|
961 |
|
962 |
|
963 |
|
964 |
|
965 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16] |
966 |
|
967 |
|
968 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
969 |
|
970 |
|
971 |
Recipients of header field TEXT containing octets outside the US-ASCII |
972 |
character set range MAY assume that they represent ISO-8859-1 characters |
973 |
if there is no other encoding indicated by an RFC 1522 mechanism. |
974 |
|
975 |
Hexadecimal numeric characters are used in several protocol elements. |
976 |
|
977 |
HEX = "A" | "B" | "C" | "D" | "E" | "F" |
978 |
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
979 |
|
980 |
|
981 |
|
982 |
Many HTTP/1.1 header field values consist of words separated by LWS or |
983 |
special characters. These special characters MUST be in a quoted string |
984 |
to be used within a parameter value. |
985 |
|
986 |
word = token | quoted-string |
987 |
|
988 |
|
989 |
token = 1*<any CHAR except CTLs or tspecials> |
990 |
|
991 |
|
992 |
tspecials = "(" | ")" | "<" | ">" | "@" |
993 |
| "," | ";" | ":" | "\" | <"> |
994 |
| "/" | "[" | "]" | "?" | "=" |
995 |
| "{" | "}" | SP | HT |
996 |
|
997 |
|
998 |
|
999 |
Comments can be included in some HTTP header fields by surrounding the |
1000 |
comment text with parentheses. Comments are only allowed in fields |
1001 |
containing _comment_ as part of their field value definition. In all |
1002 |
other fields, parentheses are considered part of the field value. |
1003 |
|
1004 |
comment = "(" *( ctext | comment ) ")" |
1005 |
ctext = <any TEXT excluding "(" and ")"> |
1006 |
|
1007 |
|
1008 |
|
1009 |
A string of text is parsed as a single word if it is quoted using |
1010 |
double-quote marks. |
1011 |
|
1012 |
quoted-string = ( <"> *(qdtext) <"> ) |
1013 |
|
1014 |
|
1015 |
qdtext = <any CHAR except <"> and CTLs, |
1016 |
but including LWS> |
1017 |
|
1018 |
|
1019 |
|
1020 |
The backslash character (_\_) may be used as a single-character quoting |
1021 |
mechanism only within quoted-string and comment constructs. |
1022 |
|
1023 |
|
1024 |
|
1025 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17] |
1026 |
|
1027 |
|
1028 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1029 |
|
1030 |
|
1031 |
quoted-pair = "\" CHAR |
1032 |
|
1033 |
|
1034 |
|
1035 |
|
1036 |
|
1037 |
|
1038 |
|
1039 |
3. Protocol Parameters |
1040 |
|
1041 |
3.1 HTTP Version |
1042 |
HTTP uses a _<major>.<minor>_ numbering scheme to indicate versions of |
1043 |
the protocol. The protocol versioning policy is intended to allow the |
1044 |
sender to indicate the format of a message and its capacity for |
1045 |
understanding further HTTP communication, rather than the features |
1046 |
obtained via that communication. No change is made to the version number |
1047 |
for the addition of message components which do not affect communication |
1048 |
behavior or which only add to extensible field values. The <minor> |
1049 |
number is incremented when the changes made to the protocol add features |
1050 |
which do not change the general message parsing algorithm, but which may |
1051 |
add to the message semantics and imply additional capabilities of the |
1052 |
sender. The <major> number is incremented when the format of a message |
1053 |
within the protocol is changed. |
1054 |
|
1055 |
The version of an HTTP message is indicated by an HTTP-Version field in |
1056 |
the first line of the message. If the protocol version is not specified, |
1057 |
the recipient MUST assume that the message is in the simple HTTP/0.9 |
1058 |
format [6]. |
1059 |
|
1060 |
|
1061 |
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
1062 |
|
1063 |
|
1064 |
|
1065 |
Note that the major and minor numbers SHOULD be treated as separate |
1066 |
integers and that each MAY be incremented higher than a single digit. |
1067 |
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower |
1068 |
than HTTP/12.3. Leading zeros SHOULD be ignored by recipients and never |
1069 |
generated by senders. |
1070 |
|
1071 |
Applications sending Full-Request or Full-Response messages, as defined |
1072 |
by this specification, MUST include an HTTP-Version of _HTTP/1.1_. Use |
1073 |
of this version number indicates that the sending application is at |
1074 |
least conditionally compliant with this specification. |
1075 |
|
1076 |
Proxy and gateway applications MUST be careful in forwarding requests |
1077 |
that are received in a format different than that of the application's |
1078 |
native HTTP version. Since the protocol version indicates the protocol |
1079 |
capability of the sender, a proxy/gateway MUST never send a message with |
1080 |
a version indicator which is greater than its native version; if a |
1081 |
higher version request is received, the proxy/gateway MUST either |
1082 |
downgrade the request version, respond with an error, or switch to |
1083 |
tunnel behavior. Requests with a version lower than that of the |
1084 |
application's native format MAY be upgraded before being forwarded; the |
1085 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18] |
1086 |
|
1087 |
|
1088 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1089 |
|
1090 |
|
1091 |
proxy/gateway's response to that request MUST follow the server |
1092 |
requirements listed above. |
1093 |
|
1094 |
Note: Converting between versions of HTTP may involve addition |
1095 |
or deletion of headers required or forbidden by the version |
1096 |
involved. It is likely more involved than just changing the |
1097 |
version indicator. |
1098 |
|
1099 |
|
1100 |
3.2 Uniform Resource Identifiers |
1101 |
URIs have been known by many names: WWW addresses, Universal Document |
1102 |
Identifiers, Universal Resource Identifiers [3], and finally the |
1103 |
|
1104 |
combination of Uniform Resource Locators (URL) [4] and Names (URN) [20]. |
1105 |
|
1106 |
As far as HTTP is concerned, Uniform Resource Identifiers are simply |
1107 |
formatted strings which identify--via name, location, or any other |
1108 |
characteristic--a network resource. |
1109 |
|
1110 |
|
1111 |
3.2.1 General Syntax |
1112 |
URIs in HTTP can be represented in absolute form or relative to some |
1113 |
known base URI [11], depending upon the context of their use. The two |
1114 |
|
1115 |
forms are differentiated by the fact that absolute URIs always begin |
1116 |
with a scheme name followed by a colon. |
1117 |
|
1118 |
|
1119 |
|
1120 |
|
1121 |
|
1122 |
|
1123 |
|
1124 |
|
1125 |
|
1126 |
|
1127 |
|
1128 |
|
1129 |
|
1130 |
|
1131 |
|
1132 |
|
1133 |
|
1134 |
|
1135 |
|
1136 |
|
1137 |
|
1138 |
|
1139 |
|
1140 |
|
1141 |
|
1142 |
|
1143 |
|
1144 |
|
1145 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19] |
1146 |
|
1147 |
|
1148 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1149 |
|
1150 |
|
1151 |
URI = ( absoluteURI | relativeURI ) [ "#" fragment ] |
1152 |
|
1153 |
|
1154 |
absoluteURI = scheme ":" *( uchar | reserved ) |
1155 |
|
1156 |
|
1157 |
relativeURI = net_path | abs_path | rel_path |
1158 |
|
1159 |
|
1160 |
net_path = "//" net_loc [ abs_path ] |
1161 |
abs_path = "/" rel_path |
1162 |
rel_path = [ path ] [ ";" params ] [ "?" query ] |
1163 |
|
1164 |
|
1165 |
path = fsegment *( "/" segment ) |
1166 |
fsegment = 1*pchar |
1167 |
segment = *pchar |
1168 |
|
1169 |
|
1170 |
params = param *( ";" param ) |
1171 |
param = *( pchar | "/" ) |
1172 |
|
1173 |
|
1174 |
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) |
1175 |
net_loc = *( pchar | ";" | "?" ) |
1176 |
query = *( uchar | reserved ) |
1177 |
fragment = *( uchar | reserved ) |
1178 |
|
1179 |
|
1180 |
pchar = uchar | ":" | "@" | "&" | "=" | "+" |
1181 |
uchar = unreserved | escape |
1182 |
unreserved = ALPHA | DIGIT | safe | extra | national |
1183 |
|
1184 |
|
1185 |
escape = "%" HEX HEX |
1186 |
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" |
1187 |
extra = "!" | "*" | "'" | "(" | ")" | "," |
1188 |
safe = "$" | "-" | "_" | "." | "+" |
1189 |
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" |
1190 |
national = <any OCTET excluding ALPHA, DIGIT, |
1191 |
reserved, extra, safe, and unsafe> |
1192 |
|
1193 |
|
1194 |
|
1195 |
For definitive information on URL syntax and semantics, see RFC 1738 [4] |
1196 |
|
1197 |
and RFC 1808 [11]. The BNF above includes national characters not |
1198 |
|
1199 |
allowed in valid URLs as specified by RFC 1738, since HTTP servers are |
1200 |
not restricted in the set of unreserved characters allowed to represent |
1201 |
the rel_path part of addresses, and HTTP proxies may receive requests |
1202 |
for URIs not defined by RFC 1738. |
1203 |
|
1204 |
|
1205 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20] |
1206 |
|
1207 |
|
1208 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1209 |
|
1210 |
|
1211 |
The HTTP protocol does not place any a-priori limit on the length of a |
1212 |
URI. Servers MUST be able to handle the URI of any resource they |
1213 |
serve, and SHOULD be able to handle URIs of unbounded length if they |
1214 |
provide GET-based forms that could generate such URIs. A server SHOULD |
1215 |
return a status code of |
1216 |
|
1217 |
|
1218 |
|
1219 |
if a URI is longer than the server can handle. See section 9.4. |
1220 |
|
1221 |
|
1222 |
Note: Servers SHOULD be cautious about depending on URI lengths |
1223 |
above 255 bytes, because some older client or proxy 414 Request-URI Too Large |
1224 |
implementations may not properly support these. |
1225 |
|
1226 |
All client and proxy implementations MUST be able to handle a URI of |
1227 |
any finite length. |
1228 |
|
1229 |
|
1230 |
3.2.2 http URL |
1231 |
The _http_ scheme is used to locate network resources via the HTTP |
1232 |
protocol. This section defines the scheme-specific syntax and semantics |
1233 |
for http URLs. |
1234 |
|
1235 |
http_URL = "http:" "//" host [ ":" port ] [ abs_path ] |
1236 |
|
1237 |
|
1238 |
host = <A legal Internet host domain name |
1239 |
or IP address (in dotted-decimal form), |
1240 |
as defined by Section 2.1 of RFC 1123> |
1241 |
|
1242 |
|
1243 |
port = *DIGIT |
1244 |
|
1245 |
|
1246 |
|
1247 |
If the port is empty or not given, port 80 is assumed. The semantics are |
1248 |
that the identified resource is located at the server listening for TCP |
1249 |
connections on that port of that host, and the Request-URI for the |
1250 |
resource is abs_path. The use of IP addresses in URL's SHOULD be |
1251 |
avoided whenever possible. See RFC 1900[24]. If the abs_path is not |
1252 |
|
1253 |
present in the URL, it MUST be given as _/_ when used as a Request-URI |
1254 |
for a resource (Section 5.1.2). |
1255 |
|
1256 |
|
1257 |
Note: Although the HTTP protocol is independent of the transport |
1258 |
layer protocol, the http URL only identifies resources by their |
1259 |
TCP location, and thus non-TCP resources MUST be identified by |
1260 |
some other URI scheme. |
1261 |
|
1262 |
The canonical form for _http_ URLs is obtained by converting any UPALPHA |
1263 |
characters in host to their LOALPHA equivalent (hostnames are case- |
1264 |
|
1265 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21] |
1266 |
|
1267 |
|
1268 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1269 |
|
1270 |
|
1271 |
insensitive), eliding the [ ":" port ] if the port is 80, and replacing |
1272 |
an empty abs_path with _/_. |
1273 |
|
1274 |
|
1275 |
3.3 Date/Time Formats |
1276 |
|
1277 |
3.3.1 Full Date |
1278 |
HTTP applications have historically allowed three different formats for |
1279 |
the representation of date/time stamps: |
1280 |
|
1281 |
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
1282 |
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, made obsolete by RFC 1036 |
1283 |
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
1284 |
|
1285 |
|
1286 |
|
1287 |
The first format is preferred as an Internet standard and represents a |
1288 |
fixed-length subset of that defined by RFC 1123 [8] (an update to RFC |
1289 |
|
1290 |
822 [9]). The second format is in common use, but is based on the |
1291 |
|
1292 |
obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1 |
1293 |
|
1294 |
clients and servers that parse the date value MUST accept all three |
1295 |
formats, though they MUST only generate the RFC 1123 format for |
1296 |
representing date/time stamps in HTTP message fields. |
1297 |
|
1298 |
Note: Recipients of date values are encouraged to be robust in |
1299 |
accepting date values that may have been generated by non-HTTP |
1300 |
applications, as is sometimes the case when retrieving or |
1301 |
posting messages via proxies/gateways to SMTP or NNTP. |
1302 |
|
1303 |
All HTTP date/time stamps MUST be represented in Universal Time (UT), |
1304 |
also known as Greenwich Mean Time (GMT), without exception. This is |
1305 |
indicated in the first two formats by the inclusion of _GMT_ as the |
1306 |
three-letter abbreviation for time zone, and SHOULD be assumed when |
1307 |
reading the asctime format. |
1308 |
|
1309 |
|
1310 |
|
1311 |
|
1312 |
|
1313 |
|
1314 |
|
1315 |
|
1316 |
|
1317 |
|
1318 |
|
1319 |
|
1320 |
|
1321 |
|
1322 |
|
1323 |
|
1324 |
|
1325 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22] |
1326 |
|
1327 |
|
1328 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1329 |
|
1330 |
|
1331 |
HTTP-date = rfc1123-date | rfc850-date | asctime-date |
1332 |
|
1333 |
|
1334 |
rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
1335 |
rfc850-date = weekday "," SP date2 SP time SP "GMT" |
1336 |
asctime-date = wkday SP date3 SP time SP 4DIGIT |
1337 |
|
1338 |
|
1339 |
date1 = 2DIGIT SP month SP 4DIGIT |
1340 |
; day month year (e.g., 02 Jun 1982) |
1341 |
date2 = 2DIGIT "-" month "-" 2DIGIT |
1342 |
; day-month-year (e.g., 02-Jun-82) |
1343 |
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
1344 |
; month day (e.g., Jun 2) |
1345 |
|
1346 |
|
1347 |
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
1348 |
; 00:00:00 - 23:59:59 |
1349 |
|
1350 |
|
1351 |
wkday = "Mon" | "Tue" | "Wed" |
1352 |
| "Thu" | "Fri" | "Sat" | "Sun" |
1353 |
|
1354 |
|
1355 |
weekday = "Monday" | "Tuesday" | "Wednesday" |
1356 |
| "Thursday" | "Friday" | "Saturday" | "Sunday" |
1357 |
|
1358 |
|
1359 |
month = "Jan" | "Feb" | "Mar" | "Apr" |
1360 |
| "May" | "Jun" | "Jul" | "Aug" |
1361 |
| "Sep" | "Oct" | "Nov" | "Dec" |
1362 |
|
1363 |
|
1364 |
|
1365 |
Note: HTTP requirements for the date/time stamp format apply |
1366 |
only to their usage within the protocol stream. Clients and |
1367 |
servers are not required to use these formats for user |
1368 |
presentation, request logging, etc. |
1369 |
|
1370 |
Additional rules for requirements on parsing and representation of dates |
1371 |
and other potential problems with date representations include: |
1372 |
|
1373 |
. HTTP/1.1 clients and caches should assume that an RFC-850 date |
1374 |
which appears to be more than 50 years in the future is in fact in |
1375 |
the past (this helps solve the _year 2000_ problem). |
1376 |
. An HTTP/1.1 implementation may internally represent a parsed |
1377 |
Expires date as earlier than the proper value, but MUST NOT |
1378 |
internally represent a parsed Expires date as later than the proper |
1379 |
value. |
1380 |
|
1381 |
|
1382 |
|
1383 |
|
1384 |
|
1385 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23] |
1386 |
|
1387 |
|
1388 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1389 |
|
1390 |
|
1391 |
3.3.2 Delta Seconds |
1392 |
Some HTTP header fields allow a time value to be specified as an integer |
1393 |
number of seconds, represented in decimal, after the time that the |
1394 |
message was received. This format SHOULD only be used to represent short |
1395 |
time periods or periods that cannot start until receipt of the message. |
1396 |
|
1397 |
delta-seconds = 1*DIGIT |
1398 |
|
1399 |
|
1400 |
|
1401 |
|
1402 |
3.4 Character Sets |
1403 |
HTTP uses the same definition of the term _character set_ as that |
1404 |
described for MIME: |
1405 |
|
1406 |
The term _character set_ is used in this document to refer to a |
1407 |
method used with one or more tables to convert a sequence of |
1408 |
octets into a sequence of characters. Note that unconditional |
1409 |
conversion in the other direction is not required, in that not |
1410 |
all characters may be available in a given character set and a |
1411 |
character set may provide more than one sequence of octets to |
1412 |
represent a particular character. This definition is intended to |
1413 |
allow various kinds of character encodings, from simple single- |
1414 |
table mappings such as US-ASCII to complex table switching |
1415 |
methods such as those that use ISO 2022's techniques. However, |
1416 |
the definition associated with a MIME character set name MUST |
1417 |
fully specify the mapping to be performed from octets to |
1418 |
characters. In particular, use of external profiling information |
1419 |
to determine the exact mapping is not permitted. |
1420 |
|
1421 |
Note: This use of the term _character set_ is more commonly |
1422 |
referred to as a _character encoding._ However, since HTTP and |
1423 |
MIME share the same registry, it is important that the |
1424 |
terminology also be shared. |
1425 |
|
1426 |
HTTP character sets are identified by case-insensitive tokens. The |
1427 |
complete set of tokens is defined by the IANA Character Set registry |
1428 |
[19]. However, because that registry does not define a single, |
1429 |
|
1430 |
consistent token for each character set, we define here the preferred |
1431 |
names for those character sets most likely to be used with HTTP |
1432 |
entities. These character sets include those registered by RFC 1521 [7] |
1433 |
|
1434 |
-- the US-ASCII [21] and ISO-8859 [22] character sets -- and other names |
1435 |
|
1436 |
specifically recommended for use within MIME charset parameters. |
1437 |
|
1438 |
|
1439 |
|
1440 |
|
1441 |
|
1442 |
|
1443 |
|
1444 |
|
1445 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24] |
1446 |
|
1447 |
|
1448 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1449 |
|
1450 |
|
1451 |
charset = "US-ASCII" |
1452 |
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" |
1453 |
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" |
1454 |
|
1455 |
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" |
1456 |
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8" |
1457 |
| token |
1458 |
|
1459 |
|
1460 |
|
1461 |
|
1462 |
|
1463 |
registry [19] MUST represent the character set defined by that registry. |
1464 |
|
1465 |
Applications SHOULD limit their use of character sets to those defined |
1466 |
by the IANA registry. |
1467 |
|
1468 |
_ _ is more commonly Although HTTP allows an arbitrary token to be used as a charset value, | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" any token that has a predefined value within the IANA Character Set Note: This use of the term character set |
1469 |
referred to as a _character encoding._ However, since HTTP and |
1470 |
MIME share the same registry, it is important that the |
1471 |
terminology also be shared. |
1472 |
|
1473 |
The character set of an entity body SHOULD be labeled as the lowest |
1474 |
common denominator of the character codes used within that body, with |
1475 |
the exception that no label is preferred over the labels US-ASCII or |
1476 |
ISO-8859-1. |
1477 |
|
1478 |
|
1479 |
3.5 Content Codings |
1480 |
Content coding values indicate an encoding transformation that has been |
1481 |
or can be applied to a resource. Content codings are primarily used to |
1482 |
allow a document to be compressed or encrypted without losing the |
1483 |
identity of its underlying media type. Typically, the resource is stored |
1484 |
in this encoding and only decoded before rendering or analogous usage. |
1485 |
|
1486 |
content-coding = "gzip" | "x-gzip" | "compress" | "x-compress" | token |
1487 |
|
1488 |
|
1489 |
|
1490 |
Note: For historical reasons, HTTP applications SHOULD consider |
1491 |
_x-gzip_ and |
1492 |
_x-compress_ to be equivalent to _gzip_ and _compress_, |
1493 |
respectively. |
1494 |
|
1495 |
All content-coding values are case-insensitive. HTTP/1.1 uses content- |
1496 |
coding values in the Accept-Encoding (Section 10.3) and Content-Encoding |
1497 |
|
1498 |
(Section 10.10) header fields. Although the value describes the content- |
1499 |
|
1500 |
coding, what is more important is that it indicates what decoding |
1501 |
mechanism will be required to remove the encoding. Note that a single |
1502 |
program MAY be capable of decoding multiple content-coding formats. Two |
1503 |
values are defined by this specification: |
1504 |
|
1505 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25] |
1506 |
|
1507 |
|
1508 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1509 |
|
1510 |
|
1511 |
gzip |
1512 |
An encoding format produced by the file compression program _gzip_ |
1513 |
(GNU zip) developed by Jean-loup Gailly[25]. This format is |
1514 |
|
1515 |
typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. |
1516 |
|
1517 |
compress |
1518 |
The encoding format produced by the file compression program |
1519 |
_compress_. This format is an adaptive Lempel-Ziv-Welch coding |
1520 |
(LZW). |
1521 |
Note: Use of program names for the identification of encoding |
1522 |
formats is not desirable and should be discouraged for future |
1523 |
encodings. Their use here is representative of historical |
1524 |
practice, not good design. |
1525 |
|
1526 |
HTTP defines a registration process which uses the Internet Assigned |
1527 |
Numbers Authority (IANA) as a central registry for content-coding value |
1528 |
tokens. Additional content-coding value tokens beyond the four defined |
1529 |
in this document (gzip x-gzip compress x-compress) SHOULD be registered |
1530 |
with the IANA. To allow interoperability between clients and servers, |
1531 |
specifications of the content coding algorithms used to implement a new |
1532 |
value SHOULD be publicly available and adequate for independent |
1533 |
implementation, and MUST conform to the purpose of content coding |
1534 |
defined in this section. |
1535 |
|
1536 |
|
1537 |
3.6 Transfer Codings |
1538 |
Transfer coding values are used to indicate an encoding transformation |
1539 |
that has been, can be, or may need to be applied to an Entity-Body in |
1540 |
order to ensure safe transport through the network. This differs from a |
1541 |
content coding in that the transfer coding is a property of the message, |
1542 |
not of the original resource. |
1543 |
|
1544 |
transfer-coding = "chunked" | transfer-extension |
1545 |
|
1546 |
transfer-extension = token |
1547 |
|
1548 |
|
1549 |
|
1550 |
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer |
1551 |
coding values in the Transfer-Encoding header field (Section 10.39). |
1552 |
|
1553 |
|
1554 |
Transfer codings are analogous to the Content-Transfer-Encoding values |
1555 |
of MIME [7], which were designed to enable safe transport of binary data |
1556 |
|
1557 |
over a 7-bit transport service. However, _safe transport_ has a |
1558 |
different focus for an 8bit-clean transfer protocol. In HTTP, the only |
1559 |
unsafe characteristic of message bodies is the difficulty in determining |
1560 |
the exact body length (Section 7.2.2), or the desire to encrypt data |
1561 |
|
1562 |
over a shared transport. |
1563 |
|
1564 |
|
1565 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26] |
1566 |
|
1567 |
|
1568 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1569 |
|
1570 |
|
1571 |
All HTTP/1.1 applications MUST be able to receive and decode the |
1572 |
_chunked_ transfer coding , and MUST ignore chunked extensions they do |
1573 |
not understand. The chunked encoding modifies the body of a message in |
1574 |
order to transfer it as a series of chunks, each with its own size |
1575 |
indicator, followed by an optional footer containing entity-header |
1576 |
fields. This allows dynamically-produced content to be transferred along |
1577 |
with the information necessary for the recipient to verify that it has |
1578 |
received the full message. |
1579 |
|
1580 |
Chunked-Body = *chunk |
1581 |
"0" CRLF |
1582 |
footer |
1583 |
CRLF |
1584 |
|
1585 |
|
1586 |
chunk = chunk-size [ chunk-ext ] CRLF |
1587 |
chunk-data CRLF |
1588 |
|
1589 |
|
1590 |
chunk-size = hex-no-zero *HEX |
1591 |
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) |
1592 |
chunk-ext-name = token |
1593 |
chunk-ext-val = token | quoted-string |
1594 |
chunk-data = chunk-size(OCTET) |
1595 |
|
1596 |
|
1597 |
footer = *< Content-MD5 and future headers that specify |
1598 |
they are allowed in footer>> |
1599 |
|
1600 |
|
1601 |
hex-no-zero = <HEX excluding "0"> |
1602 |
|
1603 |
|
1604 |
|
1605 |
Note that the chunks are ended by a zero-sized chunk, followed by the |
1606 |
footer and terminated by an empty line. An example process for decoding |
1607 |
a Chunked-Body is presented in Appendix C.5. |
1608 |
|
1609 |
|
1610 |
|
1611 |
3.7 Media Types |
1612 |
HTTP uses Internet Media Types [17] in the Content-Type (Section 10.15) |
1613 |
|
1614 |
and Accept (Section 10.1) header fields in order to provide open and |
1615 |
|
1616 |
extensible data typing and type negotiation. |
1617 |
|
1618 |
media-type = type "/" subtype *( ";" parameter ) |
1619 |
type = token |
1620 |
subtype = token |
1621 |
|
1622 |
|
1623 |
|
1624 |
|
1625 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27] |
1626 |
|
1627 |
|
1628 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1629 |
|
1630 |
|
1631 |
Parameters may follow the type/subtype in the form of attribute/value |
1632 |
pairs. |
1633 |
|
1634 |
parameter = attribute "=" value |
1635 |
attribute = token |
1636 |
value = token | quoted-string |
1637 |
|
1638 |
|
1639 |
|
1640 |
The type, subtype, and parameter attribute names are case-insensitive. |
1641 |
Parameter values may or may not be case-sensitive, depending on the |
1642 |
semantics of the parameter name. LWS MUST NOT be generated between the |
1643 |
type and subtype, nor between an attribute and its value. Upon receipt |
1644 |
of a media type with an unrecognized parameter, a user agent SHOULD |
1645 |
treat the media type as if the unrecognized parameter and its value were |
1646 |
not present. |
1647 |
|
1648 |
Some older HTTP applications do not recognize media type parameters. |
1649 |
HTTP/1.1 applications SHOULD only use media type parameters when they |
1650 |
are necessary to define the content of a message. |
1651 |
|
1652 |
Media-type values are registered with the Internet Assigned Number |
1653 |
Authority (IANA [19]). The media type registration process is outlined |
1654 |
|
1655 |
in RFC 1590 [17]. Use of non-registered media types is discouraged. |
1656 |
|
1657 |
|
1658 |
|
1659 |
3.7.1 Canonicalization and Text Defaults |
1660 |
Internet media types are registered with a canonical form. In general, |
1661 |
an Entity-Body transferred via HTTP MUST be represented in the |
1662 |
appropriate canonical form prior to its transmission. If the body has |
1663 |
been encoded with a Content-Encoding, the underlying data SHOULD be in |
1664 |
canonical form prior to being encoded. |
1665 |
|
1666 |
Media subtypes of the _text_ type use CRLF as the text line break when |
1667 |
in canonical form. However, HTTP allows the transport of text media with |
1668 |
plain CR or LF alone representing a line break when used consistently |
1669 |
within the Entity-Body. HTTP applications MUST accept CRLF, bare CR, and |
1670 |
bare LF as being representative of a line break in text media received |
1671 |
via HTTP. |
1672 |
|
1673 |
In addition, if the text media is represented in a character set that |
1674 |
does not use octets 13 and 10 for CR and LF respectively, as is the case |
1675 |
for some multi-byte character sets, HTTP allows the use of whatever |
1676 |
octet sequences are defined by that character set to represent the |
1677 |
equivalent of CR and LF for line breaks. This flexibility regarding line |
1678 |
breaks applies only to text media in the Entity-Body; a bare CR or LF |
1679 |
SHOULD NOT be substituted for CRLF within any of the HTTP control |
1680 |
structures (such as header fields and multipart boundaries). |
1681 |
|
1682 |
The _charset_ parameter is used with some media types to define the |
1683 |
character set (Section 3.4) of the data. When no explicit charset |
1684 |
|
1685 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28] |
1686 |
|
1687 |
|
1688 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1689 |
|
1690 |
|
1691 |
parameter is provided by the sender, media subtypes of the _text_ type |
1692 |
are defined to have a default charset value of _ISO-8859-1_ when |
1693 |
received via HTTP. Data in character sets other than _ISO-8859-1_ or its |
1694 |
subsets MUST be labeled with an appropriate charset value in order to be |
1695 |
consistently interpreted by the recipient. |
1696 |
|
1697 |
Note: Many current HTTP servers provide data using charsets |
1698 |
other than _ISO-8859-1_ without proper labeling. This situation |
1699 |
reduces interoperability and is not recommended. To compensate |
1700 |
for this, some HTTP user agents provide a configuration option |
1701 |
to allow the user to change the default interpretation of the |
1702 |
media type character set when no charset parameter is given. |
1703 |
|
1704 |
|
1705 |
|
1706 |
|
1707 |
|
1708 |
|
1709 |
3.7.2 Multipart Types |
1710 |
MIME provides for a number of _multipart_ types -- encapsulations of one |
1711 |
or more entities within a single message's Entity-Body. All multipart |
1712 |
types share a common syntax, as defined in Section 7.2.1 of RFC 1521 [7] |
1713 |
|
1714 |
, and MUST include a boundary parameter as part of the media type value. |
1715 |
The message body is itself a protocol element and MUST therefore use |
1716 |
only CRLF to represent line breaks between body-parts. Unlike in RFC |
1717 |
1521, the epilogue of any multipart message MUST be empty; HTTP |
1718 |
applications MUST NOT transmit the epilogue even if the original |
1719 |
resource contains an epilogue. |
1720 |
|
1721 |
In HTTP, multipart body-parts MAY contain header fields which are |
1722 |
significant to the meaning of that part. |
1723 |
|
1724 |
In general, an HTTP user agent SHOULD follow the same or similar |
1725 |
behavior as a MIME user agent would upon receipt of a multipart type. If |
1726 |
an application receives an unrecognized multipart subtype, the |
1727 |
application MUST treat it as being equivalent to _multipart/mixed_. |
1728 |
|
1729 |
Note: The "multipart/form-data" type has been specifically |
1730 |
defined for carrying form data suitable for processing via the |
1731 |
POST request method, as described in RFC 1867 [15]. |
1732 |
|
1733 |
|
1734 |
|
1735 |
|
1736 |
|
1737 |
3.8 Product Tokens |
1738 |
Product tokens are used to allow communicating applications to identify |
1739 |
themselves via a simple product token, with an optional slash and |
1740 |
version designator. Most fields using product tokens also allow sub- |
1741 |
products which form a significant part of the application to be listed, |
1742 |
separated by whitespace. By convention, the products are listed in order |
1743 |
of their significance for identifying the application. |
1744 |
|
1745 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29] |
1746 |
|
1747 |
|
1748 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1749 |
|
1750 |
|
1751 |
product = token ["/" product-version] |
1752 |
product-version = token |
1753 |
|
1754 |
|
1755 |
|
1756 |
Examples: |
1757 |
|
1758 |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
1759 |
|
1760 |
Server: Apache/0.8.4 |
1761 |
|
1762 |
|
1763 |
|
1764 |
Product tokens SHOULD be short and to the point -- use of them for |
1765 |
advertising or other non-essential information is explicitly forbidden. |
1766 |
Although any token character may appear in a product-version, this token |
1767 |
SHOULD only be used for a version identifier (i.e., successive versions |
1768 |
of the same product SHOULD only differ in the product-version portion of |
1769 |
the product value). |
1770 |
|
1771 |
|
1772 |
3.9 Quality Values |
1773 |
HTTP content negotiation (Section 12) uses short _floating point_ |
1774 |
|
1775 |
numbers to indicate the relative importance (_weight_) of various |
1776 |
negotiable parameters. The weights are normalized to a real number in |
1777 |
the range 0 through 1, where 0 is the minimum and 1 the maximum value. |
1778 |
In order to discourage misuse of this feature, HTTP/1.1 applications |
1779 |
MUST not generate more than three digits after the decimal point. User |
1780 |
configuration of these values SHOULD also be limited in this fashion. |
1781 |
|
1782 |
qvalue = ( "0" [ "." 0*3DIGIT ] ) |
1783 |
| ( "." 0*3DIGIT ) |
1784 |
| ( "1" [ "." 0*3("0") ] ) |
1785 |
|
1786 |
|
1787 |
|
1788 |
_Quality values_ is a slight misnomer, since these values actually |
1789 |
measure relative degradation in perceived quality. Thus, a value of |
1790 |
_0.8_ represents a 20% degradation from the optimum rather than a |
1791 |
statement of 80% quality. |
1792 |
|
1793 |
|
1794 |
3.10 Language Tags |
1795 |
A language tag identifies a natural language spoken, written, or |
1796 |
otherwise conveyed by human beings for communication of information to |
1797 |
other human beings. Computer languages are explicitly excluded. HTTP |
1798 |
uses language tags within the Accept-Language, and Content-Language |
1799 |
fields. |
1800 |
|
1801 |
The syntax and registry of HTTP language tags is the same as that |
1802 |
defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or |
1803 |
|
1804 |
|
1805 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30] |
1806 |
|
1807 |
|
1808 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1809 |
|
1810 |
|
1811 |
more parts: A primary language tag and a possibly empty series of |
1812 |
subtags: |
1813 |
|
1814 |
language-tag = primary-tag *( "-" subtag ) |
1815 |
|
1816 |
|
1817 |
primary-tag = 1*8ALPHA |
1818 |
subtag = 1*8ALPHA |
1819 |
|
1820 |
|
1821 |
|
1822 |
Whitespace is not allowed within the tag and all tags are case- |
1823 |
insensitive. The namespace of language tags is administered by the IANA. |
1824 |
Example tags include: |
1825 |
|
1826 |
en, en-US, en-cockney, i-cherokee, x-pig-latin |
1827 |
|
1828 |
|
1829 |
|
1830 |
where any two-letter primary-tag is an ISO 639 language abbreviation and |
1831 |
any two-letter initial subtag is an ISO 3166 country code. The last |
1832 |
three tags above are not registered tags, but examples of tags which |
1833 |
could be registered in future. |
1834 |
|
1835 |
|
1836 |
|
1837 |
|
1838 |
3.12 Full Date Values |
1839 |
Contents moved to section 3.3. |
1840 |
|
1841 |
|
1842 |
3.13 Opaque Validators |
1843 |
Opaque validators are quoted strings whose internal structure is not |
1844 |
visible to clients or caches. |
1845 |
|
1846 |
opaque-validator = strong-opaque-validator | weak-opaque-validator |
1847 |
| null-validator |
1848 |
strong-opaque-validator = quoted-string |
1849 |
weak-opaque-validator = quoted-string "/W" |
1850 |
null-validator = <"> <"> |
1851 |
|
1852 |
|
1853 |
|
1854 |
Note that the _/W_ tag is considered part of a weak opaque |
1855 |
validator; it MUST NOT be removed by any cache or client. |
1856 |
|
1857 |
There are two comparison functions on opaque validators: |
1858 |
|
1859 |
. The strong comparison function: in order to be considered equal, |
1860 |
both validators must be identical in every way, and neither may be |
1861 |
weak. |
1862 |
. The weak comparison function: in order to be considered equal, both |
1863 |
validators must be identical in every way, except for the presence |
1864 |
or absence of a _weak_ tag. |
1865 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31] |
1866 |
|
1867 |
|
1868 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1869 |
|
1870 |
|
1871 |
The weak comparison function MAY be used for simple (non-subrange) GET |
1872 |
requests. The strong comparison function MUST be used in all other |
1873 |
cases. |
1874 |
|
1875 |
The null validator is a special value, defined as never matching the |
1876 |
current validator of an existing resource, and always matching the |
1877 |
_current_ validator of a resource that does not exist. |
1878 |
|
1879 |
|
1880 |
3.14 Variant IDs |
1881 |
Variant-IDs are used to identify specific entities (variants) of a |
1882 |
varying resource; see section 13.8.3 for how they are used. |
1883 |
|
1884 |
variant-id = quoted-string |
1885 |
|
1886 |
|
1887 |
|
1888 |
Variant-IDs are compared using string octet-equality; case is |
1889 |
significant. |
1890 |
|
1891 |
|
1892 |
3.15 Validator Sets |
1893 |
Validator sets are used for doing conditional retrievals on varying |
1894 |
resources; see section 13.8.4. |
1895 |
|
1896 |
validator-set = 1#validator-set-item |
1897 |
validator-set-item = opaque-validator |
1898 |
|
1899 |
|
1900 |
|
1901 |
|
1902 |
3.16 Variant Sets |
1903 |
Validator sets are used for doing conditional retrievals on varying |
1904 |
resources; see section 13.8.3. |
1905 |
|
1906 |
variant-set = 1#variant-set-item |
1907 |
variant-set-item = opaque-validator ";" variant-id |
1908 |
|
1909 |
|
1910 |
|
1911 |
|
1912 |
3.17 HTTP Protocol Parameters Related to Ranges |
1913 |
This section defines certain HTTP protocol parameters used in range |
1914 |
requests and related responses. |
1915 |
|
1916 |
|
1917 |
3.17.1SLUSHY Range Units |
1918 |
A resource may be broken down into subranges according to various |
1919 |
structural units. |
1920 |
|
1921 |
|
1922 |
|
1923 |
|
1924 |
|
1925 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32] |
1926 |
|
1927 |
|
1928 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1929 |
|
1930 |
|
1931 |
|
1932 |
|
1933 |
|
1934 |
|
1935 |
bytes-unit = "bytes" |
1936 |
|
1937 |
The only range unit defined by HTTP/1.1 is . HTTP/1.1 range-unit = bytes-unit other-range-unit _bytes_ |
1938 |
implementations may ignore ranges specified using other units. other- |
1939 |
range-unit = token |
1940 |
|
1941 |
|
1942 |
3.17.2 SLUSHY Byte Ranges |
1943 |
Since all HTTP entities are represented in HTTP messages as sequences of |
1944 |
bytes, the concept of a byte range is meaningful for any HTTP entity. |
1945 |
(However, not all clients and servers need to support byte-range |
1946 |
operations.) |
1947 |
|
1948 |
Byte range specifications in HTTP apply to the sequence of bytes that |
1949 |
would be transferred by the protocol if no transfer-encoding were being |
1950 |
applied. |
1951 |
|
1952 |
This means that if Content-encoding is applied to the data, the |
1953 |
byte range specification applies to the resulting content- |
1954 |
encoded byte stream, not to the unencoded byte stream. It also |
1955 |
means that if the entity-body's media-type is a composite type |
1956 |
(e.g., multipart/* and message/rfc822), then the composite's |
1957 |
body-parts may have their own content-encoding and content- |
1958 |
transfer-encoding, and the byte range applies to the result of |
1959 |
the those encodings. |
1960 |
|
1961 |
A byte range operation may specify a single range of bytes, or a set of |
1962 |
ranges within a single entity. |
1963 |
|
1964 |
ranges-specifier = byte-ranges-specifier |
1965 |
|
1966 |
byte-ranges-specifier = bytes-unit "=" byte-range-set |
1967 |
|
1968 |
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) |
1969 |
|
1970 |
byte-range-spec = first-byte-pos "-" [last-byte-pos] |
1971 |
|
1972 |
first-byte-pos = 1*DIGIT |
1973 |
|
1974 |
last-byte-pos = 1*DIGIT |
1975 |
|
1976 |
The first-byte-pos value in a byte-range-spec gives the byte-offset of |
1977 |
the first byte in a range. The last-byte-pos value gives the byte- |
1978 |
offset of the last byte in the range; that is, the byte positions |
1979 |
specified are inclusive. Byte offsets start at zero. |
1980 |
|
1981 |
If the last-byte-pos value is present, it must be greater than or equal |
1982 |
to the first-byte-pos in that byte-range-spec, or the byte-range-spec is |
1983 |
invalid. The recipient of an invalid byte-range-spec must ignore it. |
1984 |
|
1985 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33] |
1986 |
|
1987 |
|
1988 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
1989 |
|
1990 |
|
1991 |
If the last-byte-pos value is absent, it is assumed to be equal to the |
1992 |
current length of the entity in bytes. |
1993 |
|
1994 |
If the last-byte-pos value is larger than the current length of the |
1995 |
entity, it is assumed to be equal to the current length of the entity. |
1996 |
|
1997 |
suffix-byte-range-spec = "-" suffix-length |
1998 |
|
1999 |
suffix-length = 1*DIGIT |
2000 |
|
2001 |
A suffix-byte-range-spec is used to specify the suffix of the entity, of |
2002 |
a length given by the suffix-length value. (That is, this form |
2003 |
specifies the last N bytes of an entity.) If the entity is shorter than |
2004 |
the specified suffix-length, the entire entity is used. |
2005 |
|
2006 |
Examples of byte-ranges-specifier values (assuming an entity of length |
2007 |
10000): |
2008 |
|
2009 |
. The first 500 bytes (byte offsets 0-499, inclusive): |
2010 |
bytes=0-499 |
2011 |
|
2012 |
. The second 500 bytes (byte offsets 500-999, inclusive): |
2013 |
bytes=500-999 |
2014 |
|
2015 |
. The final 500 bytes (byte offsets 9500-9999, inclusive): |
2016 |
bytes=-500 |
2017 |
|
2018 |
. Or |
2019 |
bytes=9500- |
2020 |
|
2021 |
. The first and last bytes only (bytes 0 and 9999): |
2022 |
bytes=0-0,-1 |
2023 |
|
2024 |
. Several legal but not canonical specifications of the second 500 |
2025 |
bytes (byte offsets 500-999, inclusive): |
2026 |
bytes=500-600,601-999 |
2027 |
|
2028 |
bytes=500-700,601-999 |
2029 |
|
2030 |
|
2031 |
3.17.3 SLUSHY: Content Ranges |
2032 |
When a server returns a partial response to a client, it must describe |
2033 |
both the extent of the range covered by the response, and the length of |
2034 |
the entire entity. |
2035 |
|
2036 |
content-range-spec = byte-content-range-spec |
2037 |
|
2038 |
byte-content-range-spec = bytes-unit SP first-byte-pos "-" |
2039 |
|
2040 |
last-byte-pos "/" entity-length |
2041 |
|
2042 |
entity-length = 1*DIGIT |
2043 |
|
2044 |
|
2045 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34] |
2046 |
|
2047 |
|
2048 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2049 |
|
2050 |
|
2051 |
Unlike byte-ranges-specifier values, a byte-content-range-spec may only |
2052 |
specify one range, and must contain absolute byte positions for both the |
2053 |
first and last byte of the range. |
2054 |
|
2055 |
A byte-content-range-spec whose last-byte-pos value, is less than its |
2056 |
first-byte-pos value, or whose entity-length value is less than its |
2057 |
last-byte-pos value, is invalid. The recipient of an invalid byte- |
2058 |
content-range-spec must ignore it and any content transferred along with |
2059 |
it. |
2060 |
|
2061 |
Examples of byte-content-range-spec values, assuming that the entity |
2062 |
contains a total of 1234 bytes: |
2063 |
|
2064 |
. The first 500 bytes: |
2065 |
bytes 0-499/1234 |
2066 |
|
2067 |
. The second 500 bytes: |
2068 |
bytes 500-999/1234 |
2069 |
|
2070 |
. All except for the first 500 bytes: |
2071 |
bytes 500-1233/1234 |
2072 |
|
2073 |
. The last 500 bytes: |
2074 |
bytes 734-1233/1234 |
2075 |
|
2076 |
|
2077 |
4. HTTP Message |
2078 |
|
2079 |
4.1 Message Types |
2080 |
HTTP messages consist of requests from client to server and responses |
2081 |
from server to client. |
2082 |
|
2083 |
HTTP-message = Full-Request ; HTTP/1.1 messages |
2084 |
| Full-Response |
2085 |
| NULL-Request |
2086 |
|
2087 |
A NULL-Request (an empty line where a request would normally be |
2088 |
expected) MUST be ignored. Clients SHOULD NOT send a NULL-Request, but |
2089 |
there are some error and testing circumstances in which a NULL-Request |
2090 |
might be sent by mistake and MUST NOT cause failure on the server. |
2091 |
|
2092 |
NULL-Request = CRLF |
2093 |
|
2094 |
Full-Request and Full-Response use the generic message format of RFC 822 |
2095 |
[9] for transferring entities. Both messages may include optional header |
2096 |
|
2097 |
fields (also known as _headers_) and an entity body. The entity body is |
2098 |
separated from the headers by a null line (i.e., a line with nothing |
2099 |
preceding the CRLF). |
2100 |
|
2101 |
|
2102 |
|
2103 |
|
2104 |
|
2105 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35] |
2106 |
|
2107 |
|
2108 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2109 |
|
2110 |
|
2111 |
Full-Request = Request-Line ; Section 5.1 |
2112 |
|
2113 |
*( General-Header ; Section 4.3 |
2114 |
|
2115 |
| Request-Header ; Section 5.2 |
2116 |
|
2117 |
| Entity-Header ) ; Section 7.1 |
2118 |
|
2119 |
CRLF |
2120 |
[ Entity-Body ] ; Section 7.2 |
2121 |
|
2122 |
|
2123 |
|
2124 |
Full-Response = Status-Line ; Section 6.1 |
2125 |
|
2126 |
*( General-Header ; Section 4.3 |
2127 |
|
2128 |
| Response-Header ; Section 6.2 |
2129 |
|
2130 |
| Entity-Header ) ; Section 7.1 |
2131 |
|
2132 |
CRLF |
2133 |
[ Entity-Body ] ; Section 7.2 |
2134 |
|
2135 |
|
2136 |
|
2137 |
|
2138 |
|
2139 |
4.2 Message Headers |
2140 |
HTTP header fields, which include (Section 4.3), Request- |
2141 |
|
2142 |
Header ( General-Header (Section 5.2), Response-Header Section 6.2), and Entity-Header |
2143 |
|
2144 |
(Section 7.1) fields, follow the same generic format as that given in |
2145 |
|
2146 |
Section 3.1 of RFC 822 [9]. Each header field consists of a name |
2147 |
|
2148 |
followed by a colon (":") and the field value. Field names are case- |
2149 |
insensitive. The field value may be preceded by any amount of LWS, |
2150 |
though a single SP is preferred. Header fields can be extended over |
2151 |
multiple lines by preceding each extra line with at least one SP or HT. |
2152 |
|
2153 |
|
2154 |
|
2155 |
|
2156 |
|
2157 |
|
2158 |
|
2159 |
|
2160 |
|
2161 |
|
2162 |
|
2163 |
|
2164 |
|
2165 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36] |
2166 |
|
2167 |
|
2168 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2169 |
|
2170 |
|
2171 |
HTTP-header = field-name ":" [ field-value ] CRLF |
2172 |
|
2173 |
|
2174 |
|
2175 |
|
2176 |
|
2177 |
|
2178 |
|
2179 |
and consisting of either *TEXT or combinations |
2180 |
|
2181 |
|
2182 |
|
2183 |
|
2184 |
The order in which header fields with differing field names are received |
2185 |
_ field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value of token, tspecials, and quoted-string> is not significant. However, it is good practice_ to send General- |
2186 |
Header fields first, followed by Request-Header or Response-Header |
2187 |
fields, and ending with the Entity-Header fields. |
2188 |
|
2189 |
Multiple HTTP-header fields with the same field-name may be present in a |
2190 |
message if and only if the entire field-value for that header field is |
2191 |
defined as a comma-separated list [i.e., #(values)]. It MUST be possible |
2192 |
to combine the multiple header fields into one _field-name: field-value_ |
2193 |
pair, without changing the semantics of the message, by appending each |
2194 |
subsequent field-value to the first, each separated by a comma. Thus, |
2195 |
the order in which multiple header fields with the same field-name are |
2196 |
received may be significant to the interpretation of the combined field- |
2197 |
value. |
2198 |
|
2199 |
|
2200 |
4.3 General Header Fields |
2201 |
There are a few header fields which have general applicability for both |
2202 |
request and response messages, but which do not apply to the entity |
2203 |
being transferred. These headers apply only to the message being |
2204 |
transmitted. |
2205 |
|
2206 |
General-Header = Cache-Control ; Section 10.8 |
2207 |
|
2208 |
| Connection ; Section 10.9 |
2209 |
|
2210 |
| Date ; Section 10.17 |
2211 |
|
2212 |
| Via ; Section 10.20 |
2213 |
|
2214 |
| Keep-Alive ; Section 10.24 |
2215 |
|
2216 |
| Pragma ; Section 10.29 |
2217 |
|
2218 |
| Upgrade ; Section 10.41 |
2219 |
|
2220 |
|
2221 |
|
2222 |
|
2223 |
General header field names can be extended reliably only in combination |
2224 |
with a change in the protocol version. However, new or experimental |
2225 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37] |
2226 |
|
2227 |
|
2228 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2229 |
|
2230 |
|
2231 |
header fields may be given the semantics of general header fields if all |
2232 |
parties in the communication recognize them to be general header fields. |
2233 |
Unrecognized header fields are treated as Entity-Header fields. |
2234 |
|
2235 |
|
2236 |
5. Request |
2237 |
A request message from a client to a server includes, within the first |
2238 |
line of that message, the method to be applied to the resource, the |
2239 |
identifier of the resource, and the protocol version in use. For |
2240 |
backwards compatibility with the more limited HTTP/0.9 protocol, there |
2241 |
are two valid formats for an HTTP request: |
2242 |
|
2243 |
|
2244 |
|
2245 |
|
2246 |
Full-Request = Request-Line ; Section 5.1 |
2247 |
|
2248 |
*( General-Header ; Section 4.3 |
2249 |
|
2250 |
| Request-Header ; Section 5.2 |
2251 |
|
2252 |
| Entity-Header ) ; Section 7.1 |
2253 |
|
2254 |
CRLF |
2255 |
[ Entity-Body ] ; Section 7.2 |
2256 |
|
2257 |
|
2258 |
NULL-Request = CRLF |
2259 |
|
2260 |
A NULL-Request MUST be ignored. |
2261 |
|
2262 |
|
2263 |
5.1 Request-Line Request = Full-Request | NULL-Request |
2264 |
The Request-Line begins with a method token, followed by the Request-URI |
2265 |
and the protocol version, and ending with CRLF. The elements are |
2266 |
separated by SP characters. No CR or LF are allowed except in the final |
2267 |
CRLF sequence. |
2268 |
|
2269 |
Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
2270 |
|
2271 |
|
2272 |
|
2273 |
|
2274 |
5.1.1 Method |
2275 |
The Method token indicates the method to be performed on the resource |
2276 |
identified by the Request-URI. The method is case-sensitive. |
2277 |
|
2278 |
|
2279 |
|
2280 |
|
2281 |
|
2282 |
|
2283 |
|
2284 |
|
2285 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38] |
2286 |
|
2287 |
|
2288 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2289 |
|
2290 |
|
2291 |
Method = "OPTIONS" ; |
2292 |
|
2293 |
| "GET" ; |
2294 |
|
2295 |
| "HEAD" ; Section 8.3 |
2296 |
|
2297 |
| "POST" ; Section 8.4 |
2298 |
|
2299 |
| "PUT" ; Section 8.5 |
2300 |
|
2301 |
| "DELETE" ; | |
2302 |
"TRACE" ; Section 8.12 |
2303 |
|
2304 |
| extension-method |
2305 |
|
2306 |
|
2307 |
extension-method = token |
2308 |
|
2309 |
|
2310 |
|
2311 |
The list of methods acceptable by a specific resource can be specified |
2312 |
Allow ). However, the client is always Section 8.1 Section 8.2 in an header field (Section 10.5 |
2313 |
|
2314 |
notified through the return code of the response whether a method is |
2315 |
currently allowed on a specific resource, as this can change |
2316 |
dynamically. Servers SHOULD return the status code 405 (method not |
2317 |
allowed) if the method is known by the server but not allowed for the |
2318 |
requested resource, and 501 (not implemented) if the method is |
2319 |
unrecognized or not implemented by the server. The list of methods known |
2320 |
by a server can be listed in a Public response header field |
2321 |
(Section 10.32). |
2322 |
|
2323 |
|
2324 |
The methods GET and HEAD MUST be supported by all general-purpose |
2325 |
servers. Servers which provide Last-Modified dates for resources MUST |
2326 |
also support the conditional GET method. All other methods are optional; |
2327 |
however, if the above methods are implemented, they MUST be implemented |
2328 |
with the same semantics as those specified in Section 8. |
2329 |
|
2330 |
|
2331 |
|
2332 |
5.1.2 Request-URI |
2333 |
The Request-URI is a Uniform Resource Identifier (Section 3.2) and |
2334 |
|
2335 |
identifies the resource upon which to apply the request. |
2336 |
|
2337 |
Request-URI = "*" | absoluteURI | abs_path |
2338 |
|
2339 |
|
2340 |
|
2341 |
To allow for transition to absoluteURIs in all requests in future |
2342 |
versions of HTTP, HTTP/1.1 servers MUST accept the absoluteURI form in |
2343 |
requests, even though HTTP/1.1 clients will not normally generate them. |
2344 |
Versions of HTTP after HTTP/1.1 may require absoluteURIs everywhere, |
2345 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39] |
2346 |
|
2347 |
|
2348 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2349 |
|
2350 |
|
2351 |
after HTTP/1.1 or later have become the dominant implementations. The |
2352 |
three options for Request-URI are dependent on the nature of the |
2353 |
request. The asterisk _*_ means that the request does not apply to a |
2354 |
particular resource, but to the server itself, and is only allowed when |
2355 |
the Method used does not necessarily apply to a resource. One example |
2356 |
would be |
2357 |
|
2358 |
OPTIONS * HTTP/1.1 |
2359 |
|
2360 |
|
2361 |
|
2362 |
The absoluteURI form is only allowed to an origin server if the client |
2363 |
knows the server supports HTTP/1.1 or later. If the absoluteURI form is |
2364 |
used, any Host request-header included with the request MUST be ignored. |
2365 |
The absoluteURI form is required when the request is being made to a |
2366 |
proxy. The proxy is requested to forward the request and return the |
2367 |
response. If the request is GET or HEAD and a prior response is cached, |
2368 |
the proxy may use the cached message if it passes any restrictions in |
2369 |
the Cache-Control and Expires header fields. Note that the proxy MAY |
2370 |
forward the request on to another proxy or directly to the server |
2371 |
specified by the absoluteURI. In order to avoid request loops, a proxy |
2372 |
MUST be able to recognize all of its server names, including any |
2373 |
aliases, local variations, and the numeric IP address. An example |
2374 |
Request-Line would be: |
2375 |
|
2376 |
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |
2377 |
|
2378 |
|
2379 |
|
2380 |
The most common form of Request-URI is that used to identify a resource |
2381 |
on an origin server or gateway. In this case, only the absolute path of |
2382 |
the URI is transmitted (see Section 3.2.1, abs_path). For example, a |
2383 |
|
2384 |
client wishing to retrieve the resource above directly from the origin |
2385 |
server would create a TCP connection to port 80 of the host _www.w3.org_ |
2386 |
and send the lines: |
2387 |
|
2388 |
GET /pub/WWW/TheProject.html HTTP/1.1 |
2389 |
Host:www.w3.org |
2390 |
|
2391 |
|
2392 |
followed by the remainder of the Full-Request. Note that the absolute |
2393 |
path cannot be empty; if none is present in the original URI, it MUST be |
2394 |
given as _/_ (the server root). |
2395 |
|
2396 |
If a proxy receives a request without any path in the Request-URI and |
2397 |
the method used is capable of supporting the asterisk form of request, |
2398 |
then the last proxy on the request chain MUST forward the request with |
2399 |
_*_ as the final Request-URI. For example, the request |
2400 |
|
2401 |
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 |
2402 |
|
2403 |
|
2404 |
|
2405 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40] |
2406 |
|
2407 |
|
2408 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2409 |
|
2410 |
|
2411 |
would be forwarded by the proxy as |
2412 |
|
2413 |
OPTIONS * HTTP/1.1 |
2414 |
|
2415 |
|
2416 |
|
2417 |
_www.ics.uci.edu_. |
2418 |
|
2419 |
is transmitted as an encoded string, where some after connecting to port 8001 of host The Request-URI |
2420 |
characters may be escaped using the _% HEX HEX_ encoding defined by RFC |
2421 |
1738 [4]. The origin server MUST decode the Request-URI in order to |
2422 |
|
2423 |
properly interpret the request. In requests that they forward, proxies |
2424 |
MUST NOT rewrite the _abs_path_ part of a Request-URI in any way except |
2425 |
as noted above to replace a null abs_path with _*_. Illegal Request-URIs |
2426 |
SHOULD be responded to with an appropriate status code. (Proxies MAY |
2427 |
transform the Request-URI for internal processing purposes, but SHOULD |
2428 |
NOT send such a transformed Request-URI in forwarded requests. |
2429 |
Transformations for use in cache updates and lookups are subject to |
2430 |
additional requirements; see section 13 on caching. The main reason for |
2431 |
this rule is to make sure that the form of Request-URIs is well |
2432 |
specified, to enable future extensions without fear that they will break |
2433 |
in the face of some rewritings. Another is that one consequence of |
2434 |
rewriting the Request-URI is that integrity or authentication checks by |
2435 |
the server may fail; since rewriting MUST be avoided in this case, it |
2436 |
may as well be proscribed in general. |
2437 |
|
2438 |
Note: servers writers SHOULD be aware that some existing proxies |
2439 |
do some rewriting. |
2440 |
|
2441 |
|
2442 |
5.2 Request Header Fields |
2443 |
The request header fields allow the client to pass additional |
2444 |
information about the request, and about the client itself, to the |
2445 |
server. These fields act as request modifiers, with semantics equivalent |
2446 |
to the parameters on a programming language method (procedure) |
2447 |
invocation. |
2448 |
|
2449 |
|
2450 |
|
2451 |
|
2452 |
|
2453 |
|
2454 |
|
2455 |
|
2456 |
|
2457 |
|
2458 |
|
2459 |
|
2460 |
|
2461 |
|
2462 |
|
2463 |
|
2464 |
|
2465 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41] |
2466 |
|
2467 |
|
2468 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2469 |
|
2470 |
|
2471 |
Request-Header = Accept ; Section 10.1 |
2472 |
|
2473 |
| Accept-Charset ; Section 10.2 |
2474 |
|
2475 |
| Accept-Encoding ; Section 10.3 |
2476 |
|
2477 |
| Accept-Language ; Section 10.4 |
2478 |
|
2479 |
| Authorization ; Section 10.6 |
2480 |
|
2481 |
| From ; Section 10.21 |
2482 |
|
2483 |
| Host ; Section 10.22 |
2484 |
|
2485 |
| If-Modified-Since ; Section 10.23 |
2486 |
|
2487 |
| Proxy-Authorization ; Section 10.31 |
2488 |
|
2489 |
| Range ; Section 10.33 |
2490 |
|
2491 |
| Referer ; Section 10.34 |
2492 |
|
2493 |
| User-Agent ; Section 10.43 |
2494 |
|
2495 |
| Max-Forwards ; Section 10.45 |
2496 |
|
2497 |
|
2498 |
|
2499 |
|
2500 |
Request-Header field names can be extended reliably only in combination |
2501 |
with a change in the protocol version. However, new or experimental |
2502 |
header fields MAY be given the semantics of request header fields if all |
2503 |
parties in the communication recognize them to be request header fields. |
2504 |
Unrecognized header fields are treated as Entity-Header fields. |
2505 |
|
2506 |
|
2507 |
6. Response |
2508 |
After receiving and interpreting a request message, a server responds in |
2509 |
the form of an HTTP response message. |
2510 |
|
2511 |
|
2512 |
|
2513 |
|
2514 |
|
2515 |
|
2516 |
|
2517 |
|
2518 |
|
2519 |
|
2520 |
|
2521 |
|
2522 |
|
2523 |
|
2524 |
|
2525 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42] |
2526 |
|
2527 |
|
2528 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2529 |
|
2530 |
|
2531 |
Response = Full-Response |
2532 |
|
2533 |
|
2534 |
Full-Response = Status-Line ; Section 6.1 |
2535 |
|
2536 |
*( General-Header ; Section 4.3 |
2537 |
|
2538 |
| Response-Header ; Section 6.2 |
2539 |
|
2540 |
| Entity-Header ) ; Section 7.1 |
2541 |
|
2542 |
CRLF |
2543 |
[ Entity-Body ] ; Section 7.2 |
2544 |
|
2545 |
|
2546 |
|
2547 |
|
2548 |
|
2549 |
6.1 Status-Line |
2550 |
The first line of a Full-Response message is the Status-Line, consisting |
2551 |
|
2552 |
associated textual phrase, with each element separated by SP characters. |
2553 |
No CR or LF is allowed except in the final CRLF sequence. |
2554 |
|
2555 |
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
2556 |
|
2557 |
|
2558 |
|
2559 |
|
2560 |
6.1.1 Status Code and Reason Phrase |
2561 |
element is a 3-digit integer result code of the attempt of the protocol version followed by a numeric status code and its The Status-Code |
2562 |
to understand and satisfy the request. The Reason-Phrase is intended to |
2563 |
give a short textual description of the Status-Code. The Status-Code is |
2564 |
intended for use by automata and the Reason-Phrase is intended for the |
2565 |
human user. The client is not required to examine or display the Reason- |
2566 |
Phrase. |
2567 |
|
2568 |
The first digit of the Status-Code defines the class of response. The |
2569 |
last two digits do not have any categorization role. There are 5 values |
2570 |
for the first digit: |
2571 |
|
2572 |
|
2573 |
. 1xx: Informational - Request received, continuing process |
2574 |
|
2575 |
. 2xx: Success - The action was successfully received, understood, |
2576 |
and accepted |
2577 |
|
2578 |
. 3xx: Redirection - Further action must be taken in order to |
2579 |
complete the request |
2580 |
|
2581 |
. 4xx: Client Error - The request contains bad syntax or cannot be |
2582 |
fulfilled |
2583 |
|
2584 |
|
2585 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43] |
2586 |
|
2587 |
|
2588 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2589 |
|
2590 |
|
2591 |
. 5xx: Server Error - The server failed to fulfill an apparently |
2592 |
valid request |
2593 |
The individual values of the numeric status codes defined for HTTP/1.1, |
2594 |
and an example set of corresponding Reason-Phrase's, are presented |
2595 |
below. The reason phrases listed here are only recommended -- they may |
2596 |
be replaced by local equivalents without affecting the protocol. These |
2597 |
codes are fully defined in Section 9. |
2598 |
|
2599 |
|
2600 |
|
2601 |
|
2602 |
|
2603 |
|
2604 |
|
2605 |
|
2606 |
|
2607 |
|
2608 |
|
2609 |
|
2610 |
|
2611 |
|
2612 |
|
2613 |
|
2614 |
|
2615 |
|
2616 |
|
2617 |
|
2618 |
|
2619 |
|
2620 |
|
2621 |
|
2622 |
|
2623 |
|
2624 |
|
2625 |
|
2626 |
|
2627 |
|
2628 |
|
2629 |
|
2630 |
|
2631 |
|
2632 |
|
2633 |
|
2634 |
|
2635 |
|
2636 |
|
2637 |
|
2638 |
|
2639 |
|
2640 |
|
2641 |
|
2642 |
|
2643 |
|
2644 |
|
2645 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44] |
2646 |
|
2647 |
|
2648 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2649 |
|
2650 |
|
2651 |
Status-Code = "100" ; Continue |
2652 |
| "101" ; Switching Protocols |
2653 |
| "200" ; OK |
2654 |
| "201" ; Created |
2655 |
| "202" ; Accepted |
2656 |
| "203" ; Non-Authoritative Information |
2657 |
| "204" ; No Content |
2658 |
| "205" ; Reset Content |
2659 |
| "206" ; Partial Content |
2660 |
| "300" ; Multiple Choices |
2661 |
| "301" ; Moved Permanently |
2662 |
| "302" ; Moved Temporarily |
2663 |
| "303" ; See Other |
2664 |
| "304" ; Not Modified |
2665 |
| "305" ; Use Proxy |
2666 |
| "400" ; Bad Request |
2667 |
| "401" ; Unauthorized |
2668 |
| "402" ; Payment Required |
2669 |
| "403" ; Forbidden |
2670 |
| "404" ; Not Found |
2671 |
| "405" ; Method Not Allowed |
2672 |
| "406" ; Not Acceptable |
2673 |
| "407" ; Proxy Authentication Required |
2674 |
| "408" ; Request Time-out |
2675 |
| "409" ; Conflict |
2676 |
| "410" ; Gone |
2677 |
| "411" ; Length Required |
2678 |
| "412" ; Precondition Failed |
2679 |
| "413" ; Request Entity Too Large |
2680 |
| "414" ; Request URI Too Large |
2681 |
| "415" ; Unsupported Media Type |
2682 |
| "416" ; None Acceptable |
2683 |
| "500" ; Internal Server Error |
2684 |
| "501" ; Not Implemented |
2685 |
| "502" ; Bad Gateway |
2686 |
| "503" ; Service Unavailable |
2687 |
| "504" ; Gateway Time-out |
2688 |
| "505" ; HTTP Version not supported |
2689 |
| extension-code |
2690 |
|
2691 |
|
2692 |
extension-code = 3DIGIT |
2693 |
|
2694 |
|
2695 |
Reason-Phrase = *<TEXT, excluding CR, LF> |
2696 |
|
2697 |
|
2698 |
|
2699 |
HTTP status codes are extensible. HTTP applications are not required to |
2700 |
understand the meaning of all registered status codes, though such |
2701 |
understanding is obviously desirable. However, applications MUST |
2702 |
understand the class of any status code, as indicated by the first |
2703 |
digit, and treat any unrecognized response as being equivalent to the |
2704 |
x00 status code of that class, with the exception that an unrecognized |
2705 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45] |
2706 |
|
2707 |
|
2708 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2709 |
|
2710 |
|
2711 |
response MUST not be cached. For example, if an unrecognized status code |
2712 |
of 431 is received by the client, it can safely assume that there was |
2713 |
something wrong with its request and treat the response as if it had |
2714 |
received a 400 status code. In such cases, user agents SHOULD present to |
2715 |
the user the entity returned with the response, since that entity is |
2716 |
likely to include human-readable information which will explain the |
2717 |
unusual status. |
2718 |
|
2719 |
|
2720 |
6.2 Response Header Fields |
2721 |
The response header fields allow the server to pass additional |
2722 |
information about the response which cannot be placed in the Status- |
2723 |
Line. These header fields give information about the server and about |
2724 |
further access to the resource identified by the Request-URI. |
2725 |
|
2726 |
Response-Header = Location ; Section 10.27 |
2727 |
|
2728 |
| Proxy-Authenticate ; Section 10.30 |
2729 |
|
2730 |
| Public ; Section 10.32 |
2731 |
|
2732 |
| Retry-After ; Section 10.36 |
2733 |
|
2734 |
| Server ; Section 10.37 |
2735 |
|
2736 |
| WWW-Authenticate ; Section 10.44 |
2737 |
|
2738 |
|
2739 |
|
2740 |
|
2741 |
Response-Header field names can be extended reliably only in combination |
2742 |
with a change in the protocol version. However, new or experimental |
2743 |
header fields MAY be given the semantics of response header fields if |
2744 |
all parties in the communication recognize them to be response header |
2745 |
fields. Unrecognized header fields are treated as Entity-Header fields. |
2746 |
|
2747 |
|
2748 |
7. Entity |
2749 |
Full-Request and Full-Response messages MAY transfer an entity within |
2750 |
some requests and responses. An entity consists of Entity-Header fields |
2751 |
and (usually) an Entity-Body. In this section, both sender and recipient |
2752 |
refer to either the client or the server, depending on who sends and who |
2753 |
receives the entity. |
2754 |
|
2755 |
|
2756 |
7.1 Entity Header Fields |
2757 |
Entity-Header fields define optional metainformation about the Entity- |
2758 |
Body or, if no body is present, about the resource identified by the |
2759 |
request. |
2760 |
|
2761 |
|
2762 |
|
2763 |
|
2764 |
|
2765 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46] |
2766 |
|
2767 |
|
2768 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2769 |
|
2770 |
|
2771 |
Entity-Header = Allow ; Section 10.5 |
2772 |
|
2773 |
| Content-Base ; Section 10.9 |
2774 |
|
2775 |
| Content-Encoding ; Section 10.10 |
2776 |
|
2777 |
| Content-Language ; Section 10.11 |
2778 |
|
2779 |
| Content-Length ; Section 10.12 |
2780 |
|
2781 |
| Content-Location ; Section 10.16 |
2782 |
|
2783 |
| Content-MD5 ; Section 10.13 |
2784 |
|
2785 |
| Content-Range ; Section 10.14 |
2786 |
|
2787 |
| Content-Type ; Section 10.15 |
2788 |
|
2789 |
| Expires ; Section 10.19 |
2790 |
|
2791 |
| Last-Modified ; Section 10.25 |
2792 |
|
2793 |
| Title ; Section 10.38 |
2794 |
|
2795 |
| Transfer-Encoding ; Section 10.39 |
2796 |
|
2797 |
| extension-header |
2798 |
|
2799 |
|
2800 |
extension-header = HTTP-header |
2801 |
|
2802 |
|
2803 |
|
2804 |
The extension-header mechanism allows additional Entity-Header fields to |
2805 |
be defined without changing the protocol, but these fields cannot be |
2806 |
assumed to be recognizable by the recipient. Unrecognized header fields |
2807 |
SHOULD be ignored by the recipient and forwarded by proxies. |
2808 |
|
2809 |
|
2810 |
7.2 Entity Body |
2811 |
The entity body (if any) sent with an HTTP request or response is in a |
2812 |
format and encoding defined by the Entity-Header fields. |
2813 |
|
2814 |
Entity-Body = *OCTET |
2815 |
|
2816 |
|
2817 |
|
2818 |
An entity body is included with a request message only when the request |
2819 |
method calls for one. The presence of an entity body in a request is |
2820 |
signaled by the inclusion of a Content-Length and/or Content-Type header |
2821 |
field in the request message headers. |
2822 |
|
2823 |
For response messages, whether or not an entity body is included with a |
2824 |
message is dependent on both the request method and the response code. |
2825 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47] |
2826 |
|
2827 |
|
2828 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2829 |
|
2830 |
|
2831 |
All responses to the HEAD request method MUST not include a body, even |
2832 |
though the presence of entity header fields may lead one to believe they |
2833 |
do. All 1xx (informational), 204 (no content), and 304 (not modified) |
2834 |
responses MUST not include a body. All other responses MUST include an |
2835 |
entity body or a Content-Length header field defined with a value of |
2836 |
zero (0). |
2837 |
|
2838 |
|
2839 |
7.2.1 Type |
2840 |
When an entity body is included with a message, the data type of that |
2841 |
body is determined via the header fields Content-Type, Content-Encoding, |
2842 |
and Transfer-Encoding. These define a three-layer, ordered encoding |
2843 |
model: |
2844 |
|
2845 |
entity-body := |
2846 |
Transfer-Encoding( Content-Encoding( Content-Type( data ) ) ) |
2847 |
|
2848 |
|
2849 |
|
2850 |
The default for both encodings is none (i.e., the identity function). |
2851 |
Content-Type specifies the media type of the underlying data. Content- |
2852 |
Encoding may be used to indicate any additional content codings applied |
2853 |
to the type, usually for the purpose of data compression, that are a |
2854 |
property of the resource requested. Transfer-Encoding may be used to |
2855 |
indicate any additional transfer codings applied by an application to |
2856 |
ensure safe and proper transfer of the message. Note that Transfer- |
2857 |
Encoding is a property of the message, not of the resource. |
2858 |
|
2859 |
Any HTTP/1.1 message containing an entity body SHOULD include a Content- |
2860 |
Type header field defining the media type of that body. If and only if |
2861 |
the media type is not given by a Content-Type header, the recipient may |
2862 |
attempt to guess the media type via inspection of its content and/or the |
2863 |
name extension(s) of the URL used to identify the resource. If the media |
2864 |
type remains unknown, the recipient SHOULD treat it as type |
2865 |
_application/octet-stream_. |
2866 |
|
2867 |
|
2868 |
7.2.2 Length |
2869 |
When an entity body is included with a message, the length of that body |
2870 |
may be determined in one of several ways. If a Content-Length header |
2871 |
field is present, its value in bytes represents the length of the entity |
2872 |
body. Otherwise, the body length is determined by the Transfer-Encoding |
2873 |
(if the _chunked_ transfer coding has been applied) or by the server |
2874 |
closing the connection. |
2875 |
|
2876 |
Note: Any response message which MUST NOT include an entity body |
2877 |
(such as the 1xx, 204, and 304 responses and any response to a |
2878 |
HEAD request) is always terminated by the first empty line after |
2879 |
the header fields, regardless of the entity header fields |
2880 |
present in the message. |
2881 |
|
2882 |
Closing the connection cannot be used to indicate the end of a request |
2883 |
body, since it leaves no possibility for the server to send back a |
2884 |
response. For compatibility with HTTP/1.0 applications, HTTP/1.1 |
2885 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48] |
2886 |
|
2887 |
|
2888 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2889 |
|
2890 |
|
2891 |
requests containing an entity body MUST include a valid Content-Length |
2892 |
header field unless the server is known to be HTTP/1.1 compliant. |
2893 |
HTTP/1.1 servers MUST accept the _chunked_ transfer coding (Section 3.6 |
2894 |
|
2895 |
), thus allowing this mechanism to be used for a request when Content- |
2896 |
Length is unknown. |
2897 |
|
2898 |
If a request contains an entity body and Content-Length is not |
2899 |
specified, the server SHOULD respond with 400 (bad request) if it cannot |
2900 |
determine the length of the request message's content, or with 411 |
2901 |
(length required) if it wishes to insist on receiving a valid Content- |
2902 |
Length. |
2903 |
|
2904 |
Messages MUST NOT include both a Content-Length header field and the |
2905 |
_chunked_ transfer coding. If both are received, the Content-Length MUST |
2906 |
be ignored. |
2907 |
|
2908 |
When a Content-Length is given in a message where an entity body is |
2909 |
allowed, its field value MUST exactly match the number of OCTETs in the |
2910 |
entity body. HTTP/1.1 user agents MUST notify the user when an invalid |
2911 |
length is received and detected. |
2912 |
|
2913 |
|
2914 |
8. Method Definitions |
2915 |
The set of common methods for HTTP/1.1 is defined below. Although this |
2916 |
set can be expanded, additional methods cannot be assumed to share the |
2917 |
same semantics for separately extended clients and servers. |
2918 |
|
2919 |
The Host request-header field (Section 10.22) MUST accompany all |
2920 |
|
2921 |
HTTP/1.1 requests. |
2922 |
|
2923 |
|
2924 |
8.1 OPTIONS |
2925 |
The OPTIONS method represents a request for information about the |
2926 |
communication options available on the request/response chain identified |
2927 |
by the Request-URI. This method allows the client to determine the |
2928 |
options and/or requirements associated with a resource, or the |
2929 |
capabilities of a server, without implying a resource action or |
2930 |
initiating a resource retrieval. |
2931 |
|
2932 |
Unless the server's response is an error, the response MUST NOT include |
2933 |
entity information other than what can be considered as communication |
2934 |
options (e.g., Allow is appropriate, but Content-Type is not) and MUST |
2935 |
include a Content-Length with a value of zero (0). Responses to this |
2936 |
method are not cachable. |
2937 |
|
2938 |
If the Request-URI is an asterisk (_*_), the OPTIONS request is intended |
2939 |
to apply to the server as a whole. A 200 response SHOULD include any |
2940 |
header fields which indicate optional features implemented by the server |
2941 |
(e.g., Public), including any extensions not defined by this |
2942 |
specification, in addition to any applicable general or response header |
2943 |
fields. As described in Section 5.1.2, an _OPTIONS *_ request can be |
2944 |
|
2945 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49] |
2946 |
|
2947 |
|
2948 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
2949 |
|
2950 |
|
2951 |
applied through a proxy by specifying the destination server in the |
2952 |
Request-URI without any path information. |
2953 |
|
2954 |
If the Request-URI is not an asterisk, the OPTIONS request applies only |
2955 |
to the options that are available when communicating with that resource. |
2956 |
A 200 response SHOULD include any header fields which indicate optional |
2957 |
features implemented by the server and applicable to that resource |
2958 |
(e.g., Allow), including any extensions not defined by this |
2959 |
specification, in addition to any applicable general or response header |
2960 |
fields. If the OPTIONS request passes through a proxy, the proxy MUST |
2961 |
edit the response to exclude those options known to be unavailable |
2962 |
through that proxy. |
2963 |
|
2964 |
|
2965 |
8.2 GET |
2966 |
The GET method means retrieve whatever information (in the form of an |
2967 |
entity) is identified by the Request-URI. If the Request-URI refers to a |
2968 |
data-producing process, it is the produced data which shall be returned |
2969 |
as the entity in the response and not the source text of the process, |
2970 |
unless that text happens to be the output of the process. |
2971 |
|
2972 |
The semantics of the GET method change to a _conditional GET_ if the |
2973 |
request message includes an If-Modified-Since header field. A |
2974 |
conditional GET method requests that the identified resource be |
2975 |
transferred only if it has been modified since the date given by the If- |
2976 |
Modified-Since header, as described in Section 10.23. The conditional |
2977 |
|
2978 |
GET method is intended to reduce unnecessary network usage by allowing |
2979 |
cached entities to be refreshed without requiring multiple requests or |
2980 |
transferring data already held by the client. |
2981 |
|
2982 |
The semantics of the GET method change to a _partial GET_ if the request |
2983 |
message includes a Range header field. A partial GET requests that only |
2984 |
part of the identified resource be transferred, as described in |
2985 |
Section 10.33. The partial GET method is intended to reduce unnecessary |
2986 |
|
2987 |
network usage by allowing partially-retrieved entities to be completed |
2988 |
without transferring data already held by the client. |
2989 |
|
2990 |
The response to a GET request may be cachable if and only if it meets |
2991 |
the requirements for HTTP caching described in Section 13. |
2992 |
|
2993 |
|
2994 |
|
2995 |
8.3 HEAD |
2996 |
The HEAD method is identical to GET except that the server MUST not |
2997 |
return any Entity-Body in the response. The metainformation contained in |
2998 |
the HTTP headers in response to a HEAD request SHOULD be identical to |
2999 |
the information sent in response to a GET request. This method can be |
3000 |
used for obtaining metainformation about the resource identified by the |
3001 |
Request-URI without transferring the Entity-Body itself. This method is |
3002 |
often used for testing hypertext links for validity, accessibility, and |
3003 |
recent modification. |
3004 |
|
3005 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50] |
3006 |
|
3007 |
|
3008 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3009 |
|
3010 |
|
3011 |
The response to a HEAD request may be cachable in the sense that the |
3012 |
information contained in the response may be used to update a previously |
3013 |
cached entity from that resource. If the new field values indicate that |
3014 |
the cached entity differs from the current resource (as would be |
3015 |
indicated by a change in Content-Length, Content-MD5, or Content- |
3016 |
Version), then the cache MUST discard the cached entity. |
3017 |
|
3018 |
There is no _conditional HEAD_ or _partial HEAD_ request analogous to |
3019 |
those associated with the GET method. If an If-Modified-Since and/or |
3020 |
Range header field is included with a HEAD request, they SHOULD be |
3021 |
ignored. |
3022 |
|
3023 |
|
3024 |
8.4 POST |
3025 |
The POST method is used to request that the destination server accept |
3026 |
the entity enclosed in the request as a new subordinate of the resource |
3027 |
identified by the Request-URI in the Request-Line. POST is designed to |
3028 |
allow a uniform method to cover the following functions: |
3029 |
|
3030 |
|
3031 |
. Annotation of existing resources; |
3032 |
|
3033 |
. Posting a message to a bulletin board, newsgroup, mailing list, or |
3034 |
similar group of articles; |
3035 |
|
3036 |
. Providing a block of data, such as the result of submitting a form |
3037 |
[5], to a data-handling process; |
3038 |
|
3039 |
|
3040 |
. Extending a database through an append operation. |
3041 |
The actual function performed by the POST method is determined by the |
3042 |
server and is usually dependent on the Request-URI. The posted entity is |
3043 |
subordinate to that URI in the same way that a file is subordinate to a |
3044 |
directory containing it, a news article is subordinate to a newsgroup to |
3045 |
which it is posted, or a record is subordinate to a database. |
3046 |
|
3047 |
For compatibility with HTTP/1.0 applications, all POST requests MUST |
3048 |
include a valid Content-Length header field unless the server is known |
3049 |
to be HTTP/1.1 compliant. When sending a POST request to an HTTP/1.1 |
3050 |
server, a client MUST use a valid Content-Length or the _chunked_ |
3051 |
Transfer-Encoding. The server SHOULD respond with a 400 (bad request) |
3052 |
message if it cannot determine the length of the request message's |
3053 |
content, or with 411 (length required) if it wishes to insist on |
3054 |
receiving a valid Content-Length. |
3055 |
|
3056 |
A successful POST does not require that the entity be created as a |
3057 |
resource on the origin server or made accessible for future reference. |
3058 |
That is, the action performed by the POST method might not result in a |
3059 |
resource that can be identified by a URI. In this case, either 200 (ok) |
3060 |
or 204 (no content) is the appropriate response status, depending on |
3061 |
whether or not the response includes an entity that describes the |
3062 |
result. |
3063 |
|
3064 |
|
3065 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51] |
3066 |
|
3067 |
|
3068 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3069 |
|
3070 |
|
3071 |
If a resource has been created on the origin server, the response SHOULD |
3072 |
be 201 (created) and contain an entity (preferably of type _text/html_) |
3073 |
which describes the status of the request and refers to the new |
3074 |
resource. |
3075 |
|
3076 |
Responses to this method are not cachable. However, the 303 (see other) |
3077 |
response can be used to direct the user agent to retrieve a cachable |
3078 |
resource. |
3079 |
|
3080 |
POST requests must obey the entity transmission requirements set out in |
3081 |
section 8.4.1. |
3082 |
|
3083 |
|
3084 |
8.4.1 SLUSHY: Entity Transmission Requirements |
3085 |
The following rules apply to any method that is subject to the two-phase |
3086 |
mechanism. |
3087 |
|
3088 |
Upon receiving such a method from an HTTP/1.1 (or later) client, an |
3089 |
HTTP/1.1 (or later) server immediately either respond with _100 |
3090 |
Continue_ and continue to read from the input stream, or respond with an |
3091 |
error status. If it responds with an error status, it MAY close the |
3092 |
transport (TCP) connection or it MAY continue to read and discard the |
3093 |
rest of the request. It MUST not perform the requested action if |
3094 |
returns an error status. |
3095 |
|
3096 |
HTTP/1.1 servers are encouraged to maintain persistent connections and |
3097 |
use TCP's flow control mechanisms to resolve temporary overloads, rather |
3098 |
than terminating connections with the expectation that clients will |
3099 |
retry. The latter technique can exacerbate network congestion. |
3100 |
|
3101 |
An HTTP/1.1 (or later) client doing a PUT-like method SHOULD monitor the |
3102 |
network connection for an error status while it is transmitting the body |
3103 |
of the request including any encoding mechanism used to transmit the |
3104 |
body. If the client sees an error status, it SHOULD immediately cease |
3105 |
transmitting the body. If the body was proceeded by a Content-length |
3106 |
header, the client MUST either close the connection or if the body is |
3107 |
being sent using a Chunked encoding, use a 0 length chunk, to mark the |
3108 |
end of the message. |
3109 |
|
3110 |
An HTTP/1.1 (or later) client MUST be prepared to accept a 100 Continue |
3111 |
status followed by a regular response. |
3112 |
|
3113 |
An HTTP/1.1 (or later) client that sees the connection close before |
3114 |
receiving any status from the server SHOULD retry the request, but if it |
3115 |
does so, it MUST use the two-phase mechanism. In the two-phase |
3116 |
mechanism, the client first sends the request headers, then waits for |
3117 |
the server to respond with either a 100 Continue, in which case the |
3118 |
client SHOULD continue, or an error status, in which case the client |
3119 |
MUST NOT continue and MUST close the connection if it has not already |
3120 |
completed sending the full request body including any encoding mechanism |
3121 |
used to transmit the body. |
3122 |
|
3123 |
If the client knows that the server is an HTTP/1.1 (or later) server, |
3124 |
because of the server protocol version returned with a previous request |
3125 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52] |
3126 |
|
3127 |
|
3128 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3129 |
|
3130 |
|
3131 |
on the same persistent connection [alternatively: within the past <N> |
3132 |
hours], it MUST wait for a response. If the client believes that the |
3133 |
server is a 1.0 or earlier server, it SHOULD continue transmitting |
3134 |
its request after waiting at least [5] seconds for a status response. |
3135 |
|
3136 |
An HTTP/1.1 (or later) client that sees the connection close after |
3137 |
receiving a _100 Continue_ but before receiving any other status SHOULD |
3138 |
retry the request, and need not use the two-phase method (but MAY do so |
3139 |
if this simplifies the implementation). |
3140 |
|
3141 |
An HTTP/1.1 (or later) server that receives a request from a 1.0 (or |
3142 |
earlier) client MUST NOT transmit the _100 Continue_ response; it SHOULD |
3143 |
either wait for the request to be completed normally (thus avoiding an |
3144 |
interrupted request) or close the connection prematurely. |
3145 |
|
3146 |
|
3147 |
8.5 PUT |
3148 |
The PUT method requests that the enclosed entity be stored under the |
3149 |
supplied Request-URI. If the Request-URI refers to an already existing |
3150 |
resource, the enclosed entity SHOULD be considered as a modified version |
3151 |
of the one residing on the origin server. If the Request-URI does not |
3152 |
point to an existing resource, and that URI is capable of being defined |
3153 |
as a new resource by the requesting user agent, the origin server can |
3154 |
create the resource with that URI. If a new resource is created, the |
3155 |
origin server MUST inform the user agent via the 201 (created) response. |
3156 |
If an existing resource is modified, either the 200 (ok) or 204 (no |
3157 |
content) response codes SHOULD be sent to indicate successful completion |
3158 |
of the request. If the resource could not be created or modified with |
3159 |
the Request-URI, an appropriate error response SHOULD be given that |
3160 |
reflects the nature of the problem. |
3161 |
|
3162 |
If the request passes through a cache and the Request-URI identifies a |
3163 |
currently cached entity, that entity MUST be removed from the cache. |
3164 |
Responses to this method are not cachable. |
3165 |
|
3166 |
The fundamental difference between the POST and PUT requests is |
3167 |
reflected in the different meaning of the Request-URI. The URI in a POST |
3168 |
request identifies the resource that will handle the enclosed entity as |
3169 |
an appendage. That resource may be a data-accepting process, a gateway |
3170 |
to some other protocol, or a separate entity that accepts annotations. |
3171 |
In contrast, the URI in a PUT request identifies the entity enclosed |
3172 |
with the request -- the user agent knows what URI is intended and the |
3173 |
server MUST NOT attempt to apply the request to some other resource. If |
3174 |
the server desires that the request be applied to a different URI, it |
3175 |
MUST send a 301 (moved permanently) response; the user agent MAY then |
3176 |
make its own decision regarding whether or not to redirect the request. |
3177 |
|
3178 |
A single resource MAY be identified by many different URIs. For example, |
3179 |
an article may have a URI for identifying _the current version_ which is |
3180 |
separate from the URI identifying each particular version. In this case, |
3181 |
a PUT request on a general URI may result in several other URIs being |
3182 |
defined by the origin server. |
3183 |
|
3184 |
|
3185 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53] |
3186 |
|
3187 |
|
3188 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3189 |
|
3190 |
|
3191 |
For compatibility with HTTP/1.0 applications, all PUT requests MUST |
3192 |
include a valid Content-Length header field unless the server is known |
3193 |
to be HTTP/1.1 compliant. When sending a PUT request to an HTTP/1.1 |
3194 |
server, a client MUST use a valid Content-Length or the _chunked_ |
3195 |
Transfer-Encoding. The server SHOULD respond with a 400 (bad request) |
3196 |
message if it cannot determine the length of the request message's |
3197 |
content, or with 411 (length required) if it wishes to insist on |
3198 |
receiving a valid Content-Length. |
3199 |
|
3200 |
The actual method for determining how the resource is placed, and what |
3201 |
happens to its predecessor, is defined entirely by the origin server. If |
3202 |
the entity being PUT was derived from an existing resource which |
3203 |
included a Content-Version header field, the new entity MUST include a |
3204 |
Derived-From header field corresponding to the value of the original |
3205 |
Content-Version header field. Multiple Derived-From values may be |
3206 |
included if the entity was derived from multiple resources with Content- |
3207 |
Version information. Applications are encouraged to use these fields for |
3208 |
constructing versioning relationships and resolving version conflicts. |
3209 |
|
3210 |
PUT requests must obey the entity transmission requirements set out in |
3211 |
section 8.4.1. |
3212 |
|
3213 |
|
3214 |
8.9 DELETE |
3215 |
The DELETE method requests that the origin server delete the resource |
3216 |
identified by the Request-URI. This method MAY be overridden by human |
3217 |
intervention (or other means) on the origin server. The client cannot be |
3218 |
guaranteed that the operation has been carried out, even if the status |
3219 |
code returned from the origin server indicates that the action has been |
3220 |
completed successfully. However, the server SHOULD not indicate success |
3221 |
unless, at the time the response is given, it intends to delete the |
3222 |
resource or move it to an inaccessible location. |
3223 |
|
3224 |
A successful response SHOULD be 200 (OK) if the response includes an |
3225 |
entity describing the status, 202 (accepted) if the action has not yet |
3226 |
been enacted, or 204 (no content) if the response is OK but does not |
3227 |
include an entity. |
3228 |
|
3229 |
If the request passes through a cache and the Request-URI identifies a |
3230 |
currently cached entity, that entity MUST be removed from the cache. |
3231 |
Responses to this method are not cachable. |
3232 |
|
3233 |
|
3234 |
8.12 TRACE |
3235 |
The TRACE method is used to invoke a remote, application-layer loop back |
3236 |
of the request message. The final recipient of the request SHOULD |
3237 |
reflect the message received back to the client as the entity body of a |
3238 |
200 (OK) response. The final recipient is either the origin server or |
3239 |
the first proxy or gateway to receive a Max-Forwards value of zero (0) |
3240 |
in the request (see Section 10.45). A TRACE request MUST NOT include an |
3241 |
|
3242 |
entity body and MUST include a Content-Length header field with a value |
3243 |
of zero (0). |
3244 |
|
3245 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54] |
3246 |
|
3247 |
|
3248 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3249 |
|
3250 |
|
3251 |
TRACE allows the client to see what is being received at the other end |
3252 |
of the request chain and use that data for testing or diagnostic |
3253 |
information. The value of the Via header field (Section 10.20) is of |
3254 |
|
3255 |
particular interest, since it acts as a trace of the request chain. Use |
3256 |
of the Max-Forwards header field allows the client to limit the length |
3257 |
of the request chain, which is useful for testing a chain of proxies |
3258 |
forwarding messages in an infinite loop. |
3259 |
|
3260 |
If successful, the response SHOULD contain the entire request message in |
3261 |
the entity body, with a Content-Type of _message/http_, |
3262 |
_application/http_, or _text/plain_. Responses to this method MUST NOT |
3263 |
be cached. |
3264 |
|
3265 |
|
3266 |
9. Status Code Definitions |
3267 |
Each Status-Code is described below, including a description of which |
3268 |
method(s) it can follow and any metainformation required in the |
3269 |
response. |
3270 |
|
3271 |
|
3272 |
9.1 Informational 1xx |
3273 |
This class of status code indicates a provisional response, consisting |
3274 |
only of the Status-Line and optional headers, and is terminated by an |
3275 |
empty line. Since HTTP/1.0 did not define any 1xx status codes, servers |
3276 |
MUST NOT send a 1xx response to an HTTP/1.0 client except under |
3277 |
experimental conditions. |
3278 |
|
3279 |
|
3280 |
100 Continue |
3281 |
The client may continue with its request. This interim response is used |
3282 |
to inform the client that the initial part of the request has been |
3283 |
received and has not yet been rejected by the server. The client SHOULD |
3284 |
continue by sending the remainder of the request or, if the request has |
3285 |
already been completed, ignore this response. The server MUST send a |
3286 |
final response after the request has been completed. |
3287 |
|
3288 |
|
3289 |
101 Switching Protocols |
3290 |
The server understands and is willing to comply with the client's |
3291 |
request, via the Upgrade message header field (Section 10.41), for a |
3292 |
|
3293 |
change in the application protocol being used on this connection. The |
3294 |
server will switch protocols to those defined by the response's Upgrade |
3295 |
header field immediately after the empty line which terminates the 101 |
3296 |
response. |
3297 |
|
3298 |
The protocol should only be switched when it is advantageous to do so. |
3299 |
For example, switching to a newer version of HTTP is advantageous over |
3300 |
older versions, and switching to a real-time, synchronous protocol may |
3301 |
be advantageous when delivering resources that use such features. |
3302 |
|
3303 |
|
3304 |
|
3305 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55] |
3306 |
|
3307 |
|
3308 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3309 |
|
3310 |
|
3311 |
9.2 Successful 2xx |
3312 |
This class of status code indicates that the client's request was |
3313 |
successfully received, understood, and accepted. |
3314 |
|
3315 |
|
3316 |
200 OK |
3317 |
The request has succeeded. The information returned with the response is |
3318 |
dependent on the method used in the request, as follows: |
3319 |
|
3320 |
|
3321 |
GET |
3322 |
an entity corresponding to the requested resource is sent in the |
3323 |
response; |
3324 |
|
3325 |
HEAD |
3326 |
the response MUST only contain the header information and no Entity- |
3327 |
Body; |
3328 |
|
3329 |
POST |
3330 |
an entity describing or containing the result of the action; |
3331 |
|
3332 |
TRACE |
3333 |
an entity containing the request message as received by the end |
3334 |
server; |
3335 |
|
3336 |
otherwise, |
3337 |
an entity describing the result of the action; |
3338 |
If the entity corresponds to a resource, the response MAY include a |
3339 |
Content-Location header field giving the actual location of that |
3340 |
specific resource for later reference. |
3341 |
|
3342 |
|
3343 |
201 Created |
3344 |
The request has been fulfilled and resulted in a new resource being |
3345 |
created. The newly created resource can be referenced by the URI(s) |
3346 |
returned in the entity of the response, with the most specific URL for |
3347 |
the resource given by a Location header field. The origin server SHOULD |
3348 |
create the resource before using this Status-Code. If the action cannot |
3349 |
be carried out immediately, the server MUST include in the response body |
3350 |
a description of when the resource will be available; otherwise, the |
3351 |
server SHOULD respond with 202 (accepted). |
3352 |
|
3353 |
|
3354 |
202 Accepted |
3355 |
The request has been accepted for processing, but the processing has not |
3356 |
been completed. The request MAY or MAY NOT eventually be acted upon, as |
3357 |
it MAY be disallowed when processing actually takes place. There is no |
3358 |
facility for re-sending a status code from an asynchronous operation |
3359 |
such as this. |
3360 |
|
3361 |
The 202 response is intentionally non-committal. Its purpose is to allow |
3362 |
a server to accept a request for some other process (perhaps a batch- |
3363 |
oriented process that is only run once per day) without requiring that |
3364 |
the user agent's connection to the server persist until the process is |
3365 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56] |
3366 |
|
3367 |
|
3368 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3369 |
|
3370 |
|
3371 |
completed. The entity returned with this response SHOULD include an |
3372 |
indication of the request's current status and either a pointer to a |
3373 |
status monitor or some estimate of when the user can expect the request |
3374 |
to be fulfilled. |
3375 |
|
3376 |
|
3377 |
203 Non-Authoritative Information |
3378 |
The returned metainformation in the Entity-Header is not the definitive |
3379 |
set as available from the origin server, but is gathered from a local or |
3380 |
a third-party copy. The set presented MAY be a subset or superset of the |
3381 |
original version. For example, including local annotation information |
3382 |
about the resource MAY result in a superset of the metainformation known |
3383 |
by the origin server. Use of this response code is not required and is |
3384 |
only appropriate when the response would otherwise be 200 (OK). |
3385 |
|
3386 |
|
3387 |
204 No Content |
3388 |
The server has fulfilled the request but there is no new information to |
3389 |
send back. If the client is a user agent, it SHOULD not change its |
3390 |
document view from that which caused the request to be generated. This |
3391 |
response is primarily intended to allow input for actions to take place |
3392 |
without causing a change to the user agent's active document view. The |
3393 |
response MAY include new metainformation in the form of entity headers, |
3394 |
which SHOULD apply to the document currently in the user agent's active |
3395 |
view. |
3396 |
|
3397 |
The 204 response MUST not include an entity body, and thus is always |
3398 |
terminated by the first empty line after the header fields. |
3399 |
|
3400 |
|
3401 |
205 Reset Content |
3402 |
The server has fulfilled the request and the user agent SHOULD reset the |
3403 |
document view which caused the request to be generated. This response is |
3404 |
primarily intended to allow input for actions to take place via user |
3405 |
input, followed by a clearing of the form in which the input is given so |
3406 |
that the user can easily initiate another input action. The response |
3407 |
MUST include a Content-Length with a value of zero (0) and no entity |
3408 |
body. |
3409 |
|
3410 |
|
3411 |
206 Partial Content |
3412 |
The server has fulfilled the partial GET request for the resource. The |
3413 |
request MUST have included a Range header field (Section 10.33) |
3414 |
|
3415 |
indicating the desired range. The response MUST include a Content-Range |
3416 |
header field (Section 10.14) indicating the range included with this |
3417 |
|
3418 |
response. All entity header fields in the response MUST describe the |
3419 |
partial entity transmitted rather than what would have been transmitted |
3420 |
in a full response. In particular, the Content-Length header field in |
3421 |
the response MUST match the actual number of OCTETs transmitted in the |
3422 |
entity body. It is assumed that the client already has the complete |
3423 |
entity's header field data. |
3424 |
|
3425 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57] |
3426 |
|
3427 |
|
3428 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3429 |
|
3430 |
|
3431 |
207 Range Out Of Bounds |
3432 |
The server has determined that the requested range(s) are not present in |
3433 |
the requested resource, and so there is no content to return. This |
3434 |
status code should be handled by the client the same as 204 No Content. |
3435 |
|
3436 |
This could be a compatibility problem if there is an installed |
3437 |
base. If treating this status code as the generic 2xx code by |
3438 |
such implementations would lead to an error, it will have to be |
3439 |
replace by 204. |
3440 |
|
3441 |
|
3442 |
9.3 Redirection 3xx |
3443 |
This class of status code indicates that further action needs to be |
3444 |
taken by the user agent in order to fulfill the request. The action |
3445 |
required MAY be carried out by the user agent without interaction with |
3446 |
the user if and only if the method used in the second request is GET or |
3447 |
HEAD. A user agent SHOULD NOT automatically redirect a request more than |
3448 |
5 times, since such redirections usually indicate an infinite loop. |
3449 |
|
3450 |
|
3451 |
300 Multiple Choices |
3452 |
This status code is reserved for future use by a planned content |
3453 |
negotiation mechanism. HTTP/1.1 user agents receiving a 300 response |
3454 |
which includes a Location header field can treat this response as they |
3455 |
would treat a 303 (See Other) response. If no Location header field is |
3456 |
included, the appropriate action is to display the entity enclosed in |
3457 |
the response to the user. |
3458 |
|
3459 |
|
3460 |
301 Moved Permanently |
3461 |
The requested resource has been assigned a new permanent URI and any |
3462 |
future references to this resource SHOULD be done using one of the |
3463 |
returned URIs. Clients with link editing capabilities SHOULD |
3464 |
automatically re-link references to the Request-URI to one or more of |
3465 |
the new references returned by the server, where possible. This response |
3466 |
is cachable unless indicated otherwise. |
3467 |
|
3468 |
If the new URI is a location, its URL MUST be given by the Location |
3469 |
field in the response. Unless it was a HEAD request, the Entity-Body of |
3470 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3471 |
the new URI(s). |
3472 |
|
3473 |
If the 301 status code is received in response to a request other than |
3474 |
GET or HEAD, the user agent MUST NOT automatically redirect the request |
3475 |
unless it can be confirmed by the user, since this might change the |
3476 |
conditions under which the request was issued. |
3477 |
|
3478 |
Note: When automatically redirecting a POST request after |
3479 |
receiving a 301 status code, some existing HTTP/1.0 user agents |
3480 |
will erroneously change it into a GET request. |
3481 |
|
3482 |
|
3483 |
302 Moved Temporarily |
3484 |
|
3485 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58] |
3486 |
|
3487 |
|
3488 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3489 |
|
3490 |
|
3491 |
The requested resource resides temporarily under a different URI. Since |
3492 |
the redirection MAY be altered on occasion, the client SHOULD continue |
3493 |
to use the Request-URI for future requests. This response is only |
3494 |
cachable if indicated by a Cache-Control or Expires header field. |
3495 |
|
3496 |
If the new URI is a location, its URL MUST be given by the Location |
3497 |
field in the response. Unless it was a HEAD request, the Entity-Body of |
3498 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3499 |
the new URI(s). |
3500 |
|
3501 |
If the 302 status code is received in response to a request other than |
3502 |
GET or HEAD, the user agent MUST NOT automatically redirect the request |
3503 |
unless it can be confirmed by the user, since this might change the |
3504 |
conditions under which the request was issued. |
3505 |
|
3506 |
|
3507 |
303 See Other |
3508 |
The response to the request can be found under a different URI and |
3509 |
SHOULD be retrieved using a GET method on that resource. This method |
3510 |
exists primarily to allow the output of a POST-activated script to |
3511 |
redirect the user agent to a selected resource. The new resource is not |
3512 |
a update reference for the original Request-URI. The 303 response is not |
3513 |
cachable, but the response to the second request MAY be cachable. |
3514 |
|
3515 |
If the new URI is a location, its URL MUST be given by the Location |
3516 |
field in the response. Unless it was a HEAD request, the Entity-Body of |
3517 |
the response SHOULD contain a short hypertext note with a hyperlink to |
3518 |
the new URI(s). |
3519 |
|
3520 |
Note: When automatically redirecting a POST request after |
3521 |
receiving a 302 status code, some existing HTTP/1.0 user agents |
3522 |
will erroneously change it into a GET request. |
3523 |
|
3524 |
|
3525 |
|
3526 |
|
3527 |
304 Not Modified |
3528 |
If the client has performed a conditional GET request and access is |
3529 |
allowed, but the document has not been modified since the date and time |
3530 |
specified in the If-Modified-Since field, the server MUST respond with |
3531 |
this status code and not send an Entity-Body to the client. Header |
3532 |
fields contained in the response SHOULD only include information which |
3533 |
is relevant to cache managers or which MAY have changed independently of |
3534 |
the entity's Last-Modified date. Examples of relevant header fields |
3535 |
include: Date, Server, Content-Length, Content-MD5, Content-Version, |
3536 |
Cache-Control and Expires. |
3537 |
|
3538 |
A cache SHOULD update its cached entity to reflect any new field values |
3539 |
given in the 304 response. If the new field values indicate that the |
3540 |
cached entity differs from the current resource (as would be indicated |
3541 |
by a change in Content-Length, Content-MD5, or Content-Version), then |
3542 |
the cache MUST disregard the 304 response and repeat the request without |
3543 |
an If-Modified-Since field. |
3544 |
|
3545 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59] |
3546 |
|
3547 |
|
3548 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3549 |
|
3550 |
|
3551 |
The 304 response MUST NOT include an entity body, and thus is always |
3552 |
terminated by the first empty line after the header fields. |
3553 |
|
3554 |
|
3555 |
305 Use Proxy |
3556 |
The requested resource MUST be accessed through the proxy given by the |
3557 |
Location field in the response. In other words, this is a proxy |
3558 |
redirect. |
3559 |
|
3560 |
|
3561 |
9.4 Client Error 4xx |
3562 |
The 4xx class of status code is intended for cases in which the client |
3563 |
seems to have erred. If the client has not completed the request when a |
3564 |
4xx code is received, it SHOULD immediately cease sending data to the |
3565 |
server. Except when responding to a HEAD request, the server SHOULD |
3566 |
include an entity containing an explanation of the error situation, and |
3567 |
whether it is a temporary or permanent condition. These status codes are |
3568 |
applicable to any request method. |
3569 |
|
3570 |
Note: If the client is sending data, server implementations on |
3571 |
TCP SHOULD be careful to ensure that the client acknowledges |
3572 |
receipt of the packet(s) containing the response prior to |
3573 |
closing the input connection. If the client continues sending |
3574 |
data to the server after the close, the server's controller will |
3575 |
send a reset packet to the client, which may erase the client's |
3576 |
unacknowledged input buffers before they can be read and |
3577 |
interpreted by the HTTP application. |
3578 |
|
3579 |
|
3580 |
400 Bad Request |
3581 |
The request could not be understood by the server due to malformed |
3582 |
syntax. The client SHOULD not repeat the request without modifications. |
3583 |
|
3584 |
|
3585 |
401 Unauthorized |
3586 |
The request requires user authentication. The response MUST include a |
3587 |
WWW-Authenticate header field (Section 10.44) containing a challenge |
3588 |
|
3589 |
applicable to the requested resource. The client MAY repeat the request |
3590 |
with a suitable Authorization header field (Section 10.6). If the |
3591 |
|
3592 |
request already included Authorization credentials, then the 401 |
3593 |
response indicates that authorization has been refused for those |
3594 |
credentials. If the 401 response contains the same challenge as the |
3595 |
prior response, and the user agent has already attempted authentication |
3596 |
at least once, then the user SHOULD be presented the entity that was |
3597 |
given in the response, since that entity MAY include relevant diagnostic |
3598 |
information. HTTP access authentication is explained in Section 11. |
3599 |
|
3600 |
|
3601 |
|
3602 |
402 Payment Required |
3603 |
This code is reserved for future use. |
3604 |
|
3605 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60] |
3606 |
|
3607 |
|
3608 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3609 |
|
3610 |
|
3611 |
403 Forbidden |
3612 |
The server understood the request, but is refusing to fulfill it. |
3613 |
Authorization will not help and the request SHOULD not be repeated. If |
3614 |
the request method was not HEAD and the server wishes to make public why |
3615 |
the request has not been fulfilled, it SHOULD describe the reason for |
3616 |
the refusal in the entity body. This status code is commonly used when |
3617 |
the server does not wish to reveal exactly why the request has been |
3618 |
refused, or when no other response is applicable. |
3619 |
|
3620 |
|
3621 |
404 Not Found |
3622 |
The server has not found anything matching the Request-URI. No |
3623 |
indication is given of whether the condition is temporary or permanent. |
3624 |
If the server does not wish to make this information available to the |
3625 |
client, the status code 403 (forbidden) can be used instead. The 410 |
3626 |
(gone) status code SHOULD be used if the server knows, through some |
3627 |
internally configurable mechanism, that an old resource is permanently |
3628 |
unavailable and has no forwarding address. |
3629 |
|
3630 |
|
3631 |
405 Method Not Allowed |
3632 |
The method specified in the Request-Line is not allowed for the resource |
3633 |
identified by the Request-URI. The response MUST include an Allow header |
3634 |
containing a list of valid methods for the requested resource. |
3635 |
|
3636 |
|
3637 |
406 Not Acceptable |
3638 |
The resource identified by the request is only capable of generating |
3639 |
response entities which have content characteristics not acceptable |
3640 |
according to the accept headers sent in the request. |
3641 |
|
3642 |
HTTP/1.1 servers are allowed to return responses which are not |
3643 |
acceptable according to the accept headers sent in the request. In some |
3644 |
cases, this may even be preferable over sending a 406 response. User |
3645 |
agents are encouraged to inspect the headers of an incoming response to |
3646 |
determine if it is acceptable. If the response is not acceptable, user |
3647 |
agents SHOULD interrupt the receipt of the response if doing so would |
3648 |
save network resources. If it is unknown whether an incoming response |
3649 |
would be acceptable, a user agent SHOULD temporarily stop receipt of |
3650 |
more data and query the user for a decision on further |
3651 |
|
3652 |
actions. |
3653 |
|
3654 |
|
3655 |
407 Proxy Authentication Required |
3656 |
This code is similar to 401 (unauthorized), but indicates that the |
3657 |
client MUST first authenticate itself with the proxy. The proxy MUST |
3658 |
return a Proxy-Authenticate header field (Section 10.30) containing a |
3659 |
|
3660 |
challenge applicable to the proxy for the requested resource. The client |
3661 |
MAY repeat the request with a suitable Proxy-Authorization header field |
3662 |
(Section 10.31). HTTP access authentication is explained in Section 11. |
3663 |
|
3664 |
|
3665 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61] |
3666 |
|
3667 |
|
3668 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3669 |
|
3670 |
|
3671 |
408 Request Timeout |
3672 |
The client did not produce a request within the time that the server was |
3673 |
prepared to wait. The client MAY repeat the request without |
3674 |
modifications at any later time. |
3675 |
|
3676 |
|
3677 |
409 Conflict |
3678 |
The request could not be completed due to a conflict with the current |
3679 |
state of the resource. This code is only allowed in situations where it |
3680 |
is expected that the user MAY be able to resolve the conflict and |
3681 |
resubmit the request. The response body SHOULD include enough |
3682 |
information for the user to recognize the source of the conflict. |
3683 |
Ideally, the response entity would include enough information for the |
3684 |
user or user-agent to fix the problem; however, that MAY not be possible |
3685 |
and is not required. |
3686 |
|
3687 |
Conflicts are most likely to occur in response to a PUT request. If |
3688 |
versioning is being used and the entity being PUT includes changes to a |
3689 |
resource which conflict with those made by an earlier (third-party) |
3690 |
request, the server MAY use the 409 response to indicate that it can't |
3691 |
complete the request. In this case, the response entity SHOULD contain a |
3692 |
list of the differences between the two versions in a format defined by |
3693 |
the response Content-Type. |
3694 |
|
3695 |
|
3696 |
410 Gone |
3697 |
The requested resource is no longer available at the server and no |
3698 |
forwarding address is known. This condition SHOULD be considered |
3699 |
permanent. Clients with link editing capabilities SHOULD delete |
3700 |
references to the Request-URI after user approval. If the server does |
3701 |
not know, or has no facility to determine, whether or not the condition |
3702 |
is permanent, the status code 404 (not found) SHOULD be used instead. |
3703 |
This response is cachable unless indicated otherwise. |
3704 |
|
3705 |
The 410 response is primarily intended to assist the task of web |
3706 |
maintenance by notifying the recipient that the resource is |
3707 |
intentionally unavailable and that the server owners desire that remote |
3708 |
links to that resource be removed. Such an event is common for limited- |
3709 |
time, promotional services and for resources belonging to individuals no |
3710 |
longer working at the server's site. It is not necessary to mark all |
3711 |
permanently unavailable resources as _gone_ or to keep the mark for any |
3712 |
length of time -- that is left to the discretion of the server owner. |
3713 |
|
3714 |
|
3715 |
411 Length Required |
3716 |
The server refuses to accept the request without a defined Content- |
3717 |
Length. The client MAY repeat the request if it adds a valid Content- |
3718 |
Length header field containing the length of the entity body in the |
3719 |
request message. |
3720 |
|
3721 |
|
3722 |
412 Precondition Failed |
3723 |
The precondition given in one or more of the request header fields |
3724 |
evaluated to false when it was tested on the server. This response code |
3725 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62] |
3726 |
|
3727 |
|
3728 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3729 |
|
3730 |
|
3731 |
allows the client to place preconditions on the current resource |
3732 |
metainformation (header field data) and thus prevent the requested |
3733 |
method from being applied to a resource other than the one intended. |
3734 |
|
3735 |
|
3736 |
413 Request Entity Too Large |
3737 |
The server is refusing to process a request because it considers the |
3738 |
request entity to be larger than it is willing or able to process. The |
3739 |
server SHOULD close the connection if that is necessary to prevent the |
3740 |
client from continuing the request. |
3741 |
|
3742 |
If the client manages to read the 413 response, it MUST honor it and |
3743 |
SHOULD reflect it to the user. |
3744 |
|
3745 |
If this restriction is considered temporary, the server MAY include a |
3746 |
Retry-After header field to indicate that it is temporary and after what |
3747 |
time the client MAY try again. |
3748 |
|
3749 |
|
3750 |
414 Request-URI Too Large |
3751 |
The server is refusing to service the request because the Request-URI is |
3752 |
longer than the server is willing to interpret. This rare condition is |
3753 |
only likely to occur when a client has improperly converted a POST |
3754 |
request to a GET request with long query information, when the client |
3755 |
has descended into a URL _black hole_ of redirection (e.g., a redirected |
3756 |
URL prefix that points to a suffix of itself), or when the server is |
3757 |
under attack by a client attempting to exploit security holes present in |
3758 |
some servers using fixed-length buffers for reading or manipulating the |
3759 |
Request-URI. |
3760 |
|
3761 |
|
3762 |
415 Unsupported Media Type |
3763 |
The server is refusing to service the request because the entity body of |
3764 |
the request is in a format not supported by the requested resource for |
3765 |
the requested method. |
3766 |
|
3767 |
|
3768 |
416 None Acceptable |
3769 |
This status code is reserved for future use by a planned content |
3770 |
negotiation mechanism. HTTP/1.1 user agents receiving a 416 response |
3771 |
which includes a Location header can treat this response as they would |
3772 |
treat a 303 (See Other) response. If no Location header is included, the |
3773 |
appropriate action is to display the entity enclosed in the response to |
3774 |
the user. |
3775 |
|
3776 |
|
3777 |
|
3778 |
|
3779 |
|
3780 |
|
3781 |
9.5 Server Error 5xx |
3782 |
Response status codes beginning with the digit _5_ indicate cases in |
3783 |
which the server is aware that it has erred or is incapable of |
3784 |
performing the request. If the client has not completed the request when |
3785 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 63] |
3786 |
|
3787 |
|
3788 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3789 |
|
3790 |
|
3791 |
a 5xx code is received, it SHOULD immediately cease sending data to the |
3792 |
server. Except when responding to a HEAD request, the server SHOULD |
3793 |
include an entity containing an explanation of the error situation, and |
3794 |
whether it is a temporary or permanent condition. These response codes |
3795 |
are applicable to any request method and there are no required header |
3796 |
fields. |
3797 |
|
3798 |
|
3799 |
500 Internal Server Error |
3800 |
The server encountered an unexpected condition which prevented it from |
3801 |
fulfilling the request. |
3802 |
|
3803 |
|
3804 |
501 Not Implemented |
3805 |
The server does not support the functionality required to fulfill the |
3806 |
request. This is the appropriate response when the server does not |
3807 |
recognize the request method and is not capable of supporting it for any |
3808 |
resource. |
3809 |
|
3810 |
|
3811 |
502 Bad Gateway |
3812 |
The server, while acting as a gateway or proxy, received an invalid |
3813 |
response from the upstream server it accessed in attempting to fulfill |
3814 |
the request. |
3815 |
|
3816 |
|
3817 |
503 Service Unavailable |
3818 |
The server is currently unable to handle the request due to a temporary |
3819 |
overloading or maintenance of the server. The implication is that this |
3820 |
is a temporary condition which will be alleviated after some delay. If |
3821 |
known, the length of the delay MAY be indicated in a Retry-After header. |
3822 |
If no Retry-After is given, the client SHOULD handle the response as it |
3823 |
would for a 500 response. |
3824 |
|
3825 |
Note: The existence of the 503 status code does not imply that a |
3826 |
server must use it when becoming overloaded. Some servers MAY |
3827 |
wish to simply refuse the connection. |
3828 |
|
3829 |
|
3830 |
504 Gateway Timeout |
3831 |
The server, while acting as a gateway or proxy, did not receive a timely |
3832 |
response from the upstream server it accessed in attempting to complete |
3833 |
the request. |
3834 |
|
3835 |
|
3836 |
505 HTTP Version Not Supported |
3837 |
The server does not support, or refuses to support, the HTTP protocol |
3838 |
version that was used in the request message. The server is indicating |
3839 |
that it is unable or unwilling to complete the request using the same |
3840 |
major version as the client, as described in Section 3.1, other than |
3841 |
|
3842 |
with this error message. The response SHOULD contain an entity |
3843 |
describing why that version is not supported and what other protocols |
3844 |
are supported by that server. |
3845 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64] |
3846 |
|
3847 |
|
3848 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3849 |
|
3850 |
|
3851 |
10. Header Field Definitions |
3852 |
This section defines the syntax and semantics of all standard HTTP/1.1 |
3853 |
header fields. For Entity-Header fields, both sender and recipient refer |
3854 |
to either the client or the server, depending on who sends and who |
3855 |
receives the entity. |
3856 |
|
3857 |
|
3858 |
10.1 Accept |
3859 |
The Accept request-header field can be used to specify certain media |
3860 |
types which are acceptable for the response. Accept headers can be used |
3861 |
to indicate that the request is specifically limited to a small set of |
3862 |
desired types, as in the case of a request for an in-line image. |
3863 |
|
3864 |
The field MAY be folded onto several lines and more than one occurrence |
3865 |
of the field is allowed, with the semantics being the same as if all the |
3866 |
entries had been in one field value. |
3867 |
|
3868 |
Accept = "Accept" ":" #( |
3869 |
media-range |
3870 |
[ ( ":" | ";" ) |
3871 |
|
3872 |
range-parameter |
3873 |
|
3874 |
*( ";" range-parameter ) ] |
3875 |
|
3876 |
| extension-token ) |
3877 |
|
3878 |
|
3879 |
|
3880 |
|
3881 |
media-range = ( "*/*" |
3882 |
| ( type "/" "*" ) |
3883 |
| ( type "/" subtype ) |
3884 |
) *( ";" parameter ) |
3885 |
|
3886 |
|
3887 |
range-parameter = ( "q" "=" qvalue ) |
3888 |
| extension-range-parameter |
3889 |
|
3890 |
extension-range-parameter = ( token "=" token ) |
3891 |
|
3892 |
extension-token = token |
3893 |
|
3894 |
|
3895 |
The asterisk _*_ character is used to group media types into ranges, |
3896 |
with _*/*_ indicating all media types and _type/*_ indicating all |
3897 |
subtypes of that type. The range-parameter q is used to indicate the |
3898 |
media type quality factor for the range, which represents the user's |
3899 |
preference for that range of media types. The default value is q=1. In |
3900 |
Accept headers generated by HTTP/1.1 clients, the character separating |
3901 |
media-ranges from range-parameters SHOULD be a _:_. HTTP/1.1 servers |
3902 |
SHOULD be tolerant of use of the _;_ separator by HTTP/1.0 clients. |
3903 |
|
3904 |
The example |
3905 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65] |
3906 |
|
3907 |
|
3908 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3909 |
|
3910 |
|
3911 |
Accept: audio/*: q=0.2, audio/basic |
3912 |
|
3913 |
|
3914 |
|
3915 |
SHOULD be interpreted as _I prefer audio/basic, but send me any audio |
3916 |
type if it is the best available after an 80% mark-down in quality._ |
3917 |
|
3918 |
If no Accept header is present, then it is assumed that the client |
3919 |
accepts all media types. If Accept headers are present, and if the |
3920 |
server cannot send a response which is acceptable according to the |
3921 |
Accept headers, then the server SHOULD send an error response with the |
3922 |
406 (not acceptable) status code, though the sending of an unacceptable |
3923 |
response is also allowed. |
3924 |
|
3925 |
A more elaborate example is |
3926 |
|
3927 |
Accept: text/plain: q=0.5, text/html, |
3928 |
text/x-dvi: q=0.8, text/x-c |
3929 |
|
3930 |
|
3931 |
|
3932 |
Verbally, this would be interpreted as _text/html and text/x-c are the |
3933 |
preferred media types, but if they do not exist, then send the text/x- |
3934 |
dvi entity, and if that does not exist, send the text/plain entity._ |
3935 |
|
3936 |
Media ranges can be overridden by more specific media ranges or specific |
3937 |
media types. If more than one media range applies to a given type, the |
3938 |
most specific reference has precedence. For example, |
3939 |
|
3940 |
Accept: text/*, text/html, text/html;level=1, */* |
3941 |
|
3942 |
|
3943 |
|
3944 |
have the following precedence: |
3945 |
|
3946 |
1) text/html;level=1 |
3947 |
2) text/html |
3948 |
3) text/* |
3949 |
4) */* |
3950 |
|
3951 |
|
3952 |
|
3953 |
The media type quality factor associated with a given type is determined |
3954 |
by finding the media range with the highest precedence which matches |
3955 |
that type. For example, |
3956 |
|
3957 |
Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1, |
3958 |
*/*:q=0.5 |
3959 |
|
3960 |
|
3961 |
|
3962 |
would cause the following values to be associated: |
3963 |
|
3964 |
|
3965 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66] |
3966 |
|
3967 |
|
3968 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
3969 |
|
3970 |
|
3971 |
text/html;level=1 = 1 |
3972 |
|
3973 |
|
3974 |
image/jpeg = 0.5 |
3975 |
text/html;level=3 = 0.7 |
3976 |
|
3977 |
|
3978 |
|
3979 |
Note: A user agent MAY be provided with a default set of quality |
3980 |
values for certain media ranges. However, unless the user agent |
3981 |
is a closed system which cannot interact with other rendering text/html = 0.7 text/plain = 0.3 |
3982 |
agents, this default set SHOULD be configurable by the user. |
3983 |
|
3984 |
|
3985 |
10.2 Accept-Charset |
3986 |
The Accept-Charset request-header field can be used to indicate what |
3987 |
character sets are acceptable for the response. This field allows |
3988 |
clients capable of understanding more comprehensive or special-purpose |
3989 |
character sets to signal that capability to a server which is capable of |
3990 |
representing documents in those character sets. The ISO-8859-1 character |
3991 |
set can be assumed to be acceptable to all user agents. |
3992 |
|
3993 |
Accept-Charset = "Accept-Charset" ":" |
3994 |
|
3995 |
1#( charset [ ";" "q" "=" qvalue ] ) |
3996 |
|
3997 |
|
3998 |
|
3999 |
Character set values are described in Section 3.4. Each charset may be |
4000 |
|
4001 |
given an associated quality value which represents the user's preference |
4002 |
for that charset. The default value is q=1. An example is |
4003 |
|
4004 |
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
4005 |
|
4006 |
|
4007 |
If no Accept-Charset header is present, the default is that any |
4008 |
character set is acceptable. If an Accept-Charset header is present, and |
4009 |
if the server cannot send a response which is acceptable according to |
4010 |
the Accept-Charset header, then the server SHOULD send an error response |
4011 |
with the 406 (not acceptable) status code, though the sending of an |
4012 |
unacceptable response is also allowed. |
4013 |
|
4014 |
|
4015 |
|
4016 |
|
4017 |
10.3 Accept-Encoding |
4018 |
The Accept-Encoding request-header field is similar to Accept, but |
4019 |
restricts the content-coding values (Section 3.5) which are acceptable |
4020 |
|
4021 |
in the response. |
4022 |
|
4023 |
|
4024 |
|
4025 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 67] |
4026 |
|
4027 |
|
4028 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4029 |
|
4030 |
|
4031 |
Accept-Encoding = "Accept-Encoding" ":" |
4032 |
#( content-coding ) |
4033 |
|
4034 |
|
4035 |
|
4036 |
An example of its use is |
4037 |
|
4038 |
Accept-Encoding: compress, gzip |
4039 |
|
4040 |
|
4041 |
|
4042 |
If no Accept-Encoding header is present in a request, the server MAY |
4043 |
assume that the client will accept any content coding. If an Accept- |
4044 |
Encoding header is present, and if the server cannot send a response |
4045 |
which is acceptable according to the Accept-Encoding header, then the |
4046 |
server SHOULD send an error response with the 406 (not acceptable) |
4047 |
status code. |
4048 |
|
4049 |
|
4050 |
10.4 Accept-Language |
4051 |
The Accept-Language request-header field is similar to Accept, but |
4052 |
restricts the set of natural languages that are preferred as a response |
4053 |
to the request. |
4054 |
|
4055 |
Accept-Language = "Accept-Language" ":" |
4056 |
1#( language-range [ ";" "q" "=" qvalue ] ) |
4057 |
|
4058 |
|
4059 |
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) |
4060 |
| "*" ) |
4061 |
|
4062 |
|
4063 |
Each language-range MAY be given an associated quality value which |
4064 |
represents an estimate of the user's comprehension of the languages |
4065 |
specified by that range. The quality value defaults to _q=1_ (100% |
4066 |
comprehension).For example, |
4067 |
|
4068 |
Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
4069 |
|
4070 |
|
4071 |
|
4072 |
would mean: _I prefer Danish, but will accept British English (with 80% |
4073 |
comprehension) and other types of English(with 70% comprehension)._ A |
4074 |
language-range matches a language-tag if it exactly equals the tag, or |
4075 |
if it exactly equals a prefix (a sub-sequence starting at the first |
4076 |
character) of the tag such that the first tag character following the |
4077 |
prefix is _-_. The special range _*_, if present in the Accept-Language |
4078 |
field, matches every tag not matched by any other ranges present in the |
4079 |
Accept-Language field. |
4080 |
|
4081 |
Note: This use of a prefix matching rule does not imply that |
4082 |
language tags are assigned to languages in such a way that it is |
4083 |
always true that if a user understands a language with a certain |
4084 |
tag, then this user will also understand all languages with tags |
4085 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68] |
4086 |
|
4087 |
|
4088 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4089 |
|
4090 |
|
4091 |
for which this tag is a prefix. The prefix rule simply allows |
4092 |
the use of prefix tags if this is the case. |
4093 |
|
4094 |
The language quality factor assigned to a language-tag by the Accept- |
4095 |
Language field is the quality value of the longest language-range in the |
4096 |
field that matches the language-range. If no language-range in the |
4097 |
field matches the tag, the language quality factor assigned is 0. If no |
4098 |
Accept-Language header is present in the request, the server SHOULD |
4099 |
assume that all languages are equally acceptable. If an Accept-Language |
4100 |
header is present, then all languages which are assigned a quality |
4101 |
factor greater than 0 are acceptable. If the server cannot generate a |
4102 |
response for an audience capable of understanding at least one |
4103 |
acceptable language, it can send a response that uses one or more un- |
4104 |
accepted languages. |
4105 |
|
4106 |
It may be contrary to the privacy expectations of the user to send an |
4107 |
Accept-Language header with the complete linguistic preferences of the |
4108 |
user in every request. For a discussion of this issue, see Section 14.7 |
4109 |
|
4110 |
. |
4111 |
|
4112 |
Note: As intelligibility is highly dependent on the individual |
4113 |
user, it is recommended that client applications make the choice |
4114 |
of linguistic preference available to the user. If the choice is |
4115 |
not made available, then the Accept-Language header field MUST |
4116 |
not be given in the request. |
4117 |
|
4118 |
|
4119 |
|
4120 |
|
4121 |
10.5 Allow |
4122 |
The Allow entity-header field lists the set of methods supported by the |
4123 |
resource identified by the Request-URI. The purpose of this field is |
4124 |
strictly to inform the recipient of valid methods associated with the |
4125 |
resource. An Allow header field MUST be present in a 405 (method not |
4126 |
allowed) response. The Allow header field is not permitted in a request |
4127 |
using the POST method, and thus SHOULD be ignored if it is received as |
4128 |
part of a POST entity. |
4129 |
|
4130 |
Allow = "Allow" ":" 1#method |
4131 |
|
4132 |
|
4133 |
|
4134 |
Example of use: |
4135 |
|
4136 |
Allow: GET, HEAD, PUT |
4137 |
|
4138 |
|
4139 |
|
4140 |
This field cannot prevent a client from trying other methods. However, |
4141 |
the indications given by the Allow header field value SHOULD be |
4142 |
followed. The actual set of allowed methods is defined by the origin |
4143 |
server at the time of each request. |
4144 |
|
4145 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 69] |
4146 |
|
4147 |
|
4148 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4149 |
|
4150 |
|
4151 |
The Allow header field MAY be provided with a PUT request to recommend |
4152 |
the methods to be supported by the new or modified resource. The server |
4153 |
is not required to support these methods and SHOULD include an Allow |
4154 |
header in the response giving the actual supported methods. |
4155 |
|
4156 |
A proxy MUST not modify the Allow header field even if it does not |
4157 |
understand all the methods specified, since the user agent MAY have |
4158 |
other means of communicating with the origin server. |
4159 |
|
4160 |
The Allow header field does not indicate what methods are implemented at |
4161 |
the server level. Servers MAY use the Public response header field |
4162 |
(Section 10.32) to describe what methods are implemented on the server |
4163 |
|
4164 |
as a whole. |
4165 |
|
4166 |
|
4167 |
10.6 Authorization |
4168 |
A user agent that wishes to authenticate itself with a server--usually, |
4169 |
but not necessarily, after receiving a 401 response--MAY do so by |
4170 |
including an Authorization request-header field with the request. The |
4171 |
Authorization field value consists of credentials containing the |
4172 |
authentication information of the user agent for the realm of the |
4173 |
resource being requested. |
4174 |
|
4175 |
Authorization = "Authorization" ":" credentials |
4176 |
|
4177 |
|
4178 |
|
4179 |
HTTP access authentication is described in Section 11. If a request is |
4180 |
|
4181 |
authenticated and a realm specified, the same credentials SHOULD be |
4182 |
valid for all other requests within this realm. |
4183 |
|
4184 |
When a shared cache (see section 13.10) receives a request containing an |
4185 |
Authorization field, it MUST NOT return the corresponding response as a |
4186 |
reply to any other request, unless one of the following specific |
4187 |
exceptions holds: |
4188 |
|
4189 |
1. If the response includes the _proxy-revalidate_ Cache-Control |
4190 |
directive, the cache MAY use that response in replying to a |
4191 |
subsequent request, but a proxy cache MUST first revalidate it with |
4192 |
the origin server, using the request headers from the new request |
4193 |
to allow the origin server to authenticate the new request. |
4194 |
2. If the response includes the _must-revalidate_ Cache-Control |
4195 |
directive, the cache MAY use that response in replying to a |
4196 |
subsequent request, but all caches MUST first revalidate it with |
4197 |
the origin server, using the request headers from the new request |
4198 |
to allow the origin server to authenticate the new request. |
4199 |
3. If the response includes the _public_ Cache-Control directive, it |
4200 |
may be returned in reply to any subsequent request. |
4201 |
|
4202 |
10.7 Cache-Control |
4203 |
The Cache-Control general-header field is used to specify directives |
4204 |
that MUST be obeyed by all caching mechanisms along the request/response |
4205 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70] |
4206 |
|
4207 |
|
4208 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4209 |
|
4210 |
|
4211 |
chain. The directives specify behavior intended to prevent caches from |
4212 |
adversely interfering with the request or response. . These directives |
4213 |
typically override the default caching algorithms. Cache directives are |
4214 |
unidirectional in that the presence of a directive in a request does not |
4215 |
imply that the same directive should be given in the response. |
4216 |
|
4217 |
Cache directives must be passed through by a proxy or gateway |
4218 |
application, regardless of their significance to that application, since |
4219 |
the directives may be applicable to all recipients along the |
4220 |
request/response chain. It is not possible to specify a cache-directive |
4221 |
for a specific cache. |
4222 |
|
4223 |
Cache-Control = "Cache-Control" ":" 1#cache-directive |
4224 |
|
4225 |
|
4226 |
cache-directive = "public" |
4227 |
| "private" [ "=" <"> 1#field-name <"> ] |
4228 |
| "no-cache" [ "=" <"> 1#field-name <"> ] |
4229 |
| "no-store" |
4230 |
| "no-transform" |
4231 |
| "must-revalidate" |
4232 |
| "proxy-revalidate" |
4233 |
| "only-if-cached" |
4234 |
| "max-age" "=" delta-seconds |
4235 |
| "max-stale" "=" delta-seconds |
4236 |
| "min-fresh" "=" delta-seconds |
4237 |
| "min-vers" "=" HTTP-Version |
4238 |
|
4239 |
and perhaps |
4240 |
| "max-uses" "=" 1*DIGIT |
4241 |
| "use-count" "=" 1*DIGIT |
4242 |
|
4243 |
|
4244 |
When a directive appears without any 1#field-name parameter, the |
4245 |
directive applies to the entire request or response. When such a |
4246 |
directive appears with a 1#field-name parameter, it applies only to the |
4247 |
named field or fields, and not to the rest of the request or response. |
4248 |
This mechanism supports extensibility; implementations of future |
4249 |
versions of the HTTP protocol may apply these directives to header |
4250 |
fields not defined in HTTP/1.1. |
4251 |
|
4252 |
The cache-control directives can be broken down into these general |
4253 |
categories: |
4254 |
|
4255 |
. Restrictions on what is cachable; these may only be imposed by the |
4256 |
origin server. |
4257 |
. Restrictions on what may be stored by a cache; these may be imposed |
4258 |
by either the origin server or the end-user client. |
4259 |
. Modifications of the basic expiration mechanism; these may be |
4260 |
imposed by either the origin server or the end-user client. |
4261 |
. Controls over cache revalidation and reload; these may only be |
4262 |
imposed by an end-user client. |
4263 |
. Restrictions on the number of times a cache entry may be used, and |
4264 |
related demographic reporting mechanisms. |
4265 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71] |
4266 |
|
4267 |
|
4268 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4269 |
|
4270 |
|
4271 |
. Miscellaneous restrictions |
4272 |
Caches never add or remove Cache-Control directives to requests or |
4273 |
responses. |
4274 |
|
4275 |
|
4276 |
Check: is this true? |
4277 |
|
4278 |
10.7.1 SLUSHY: Restrictions on What is Cachable |
4279 |
Unless specifically constrained by a Cache-Control directive, a caching |
4280 |
system may always store a successful response as a cache entry, may |
4281 |
return it without validation if it is fresh, and may return it after |
4282 |
successful validation. If there is neither a cache validator nor an |
4283 |
explicit expiration time associated with a response, we do not expect it |
4284 |
to be cached, but certain caches may violate this expectation (for |
4285 |
example, when little or no network connectivity is available) as long as |
4286 |
they explicit mark their responses using the Warning mechanism describe |
4287 |
in section 10.51. |
4288 |
|
4289 |
Note that some HTTP/1.0 caches are known to violate this |
4290 |
expectation without providing any Warning. |
4291 |
|
4292 |
However, in some cases it may be inappropriate for a cache to retain a |
4293 |
resource value, or to return it in response to a subsequent request. |
4294 |
This may be because absolute semantic transparency is deemed necessary |
4295 |
by the service author, or because of security or privacy considerations. |
4296 |
Certain Cache-Control directives are therefore provided so that the |
4297 |
server can indicate that certain resources, or portions thereof, may not |
4298 |
be cached regardless of other considerations. |
4299 |
|
4300 |
Note that section 10.6 normally prevents a shared cache from saving and |
4301 |
returning a response to a previous request if that request included an |
4302 |
Authorization header. |
4303 |
|
4304 |
The following Cache-Control response directives add or remove |
4305 |
restrictions on what is cachable: |
4306 |
|
4307 |
public |
4308 |
Overrides the restriction in section 10.6 that prevents a shared |
4309 |
cache from saving and returning a response to a previous request if |
4310 |
that request included an Authorization header. However, any other |
4311 |
constraints on caching still apply. |
4312 |
private |
4313 |
Indicates that all or parts of the response message are intended for |
4314 |
a single user and MUST NOT be cached by a shared cache. This allows |
4315 |
an origin server to state that the specified parts of the response |
4316 |
are intended for only one user and are not a valid response for |
4317 |
requests by other users. applicable to responses and must not be |
4318 |
generated by clients. A private (non-shared) cache may ignore this |
4319 |
directive. |
4320 |
Note: This usage of the word _private_ only controls where the |
4321 |
response may cached, and cannot ensure the privacy of the |
4322 |
message content. Note in particular that HTTP/1.0 caches will |
4323 |
not recognize or obey this directive. |
4324 |
|
4325 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72] |
4326 |
|
4327 |
|
4328 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4329 |
|
4330 |
|
4331 |
no-cache |
4332 |
indicates that all or parts of the response message MUST NOT be |
4333 |
cached. This allows an origin server to prevent caching even by |
4334 |
caches that have been configured to return stale responses to client |
4335 |
requests. |
4336 |
Note: HTTP/1.0 caches will not recognize or obey this directive. |
4337 |
|
4338 |
TBS: precedence relations between public, private, and no-cache. |
4339 |
|
4340 |
|
4341 |
10.7.2 Restrictions On What May be Stored by a Cache |
4342 |
The _no-store_ directive applies to the entire message, and may be sent |
4343 |
either in a response or in a request. If sent in a request, a cache MUST |
4344 |
NOT store any part of either this request or any response to it. If sent |
4345 |
in a response, a cache MUST NOT store any part of either this response |
4346 |
or the request that elicited it. This directive applies to both non- |
4347 |
shared and shared caches. |
4348 |
|
4349 |
Even when this directive is associated with a response, users may |
4350 |
explicitly store such a response outside of the caching system (e.g., |
4351 |
with a _Save As_ dialog). History buffers may store such responses as |
4352 |
part of their normal operation. |
4353 |
|
4354 |
The purpose of this directive is to meet the stated requirements of |
4355 |
certain users and service authors who are concerned about accidental |
4356 |
releases of information via unanticipated accesses to cache data |
4357 |
structures. While the use of this directive may improve privacy in some |
4358 |
cases, we caution that it is NOT in any way a reliable or sufficient |
4359 |
mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not |
4360 |
recognize or obey this directive, malicious or compromised caches may |
4361 |
not recognize or obey this directive, and all communications networks |
4362 |
may be vulnerable to eavesdropping. |
4363 |
|
4364 |
The _min-vers_ directive applies to the entire message, and may be sent |
4365 |
either in a response or in a request. If sent in a request, a cache |
4366 |
whose HTTP version number is less than the specified version MUST NOT |
4367 |
store any part of either this request or any response to it. If sent in |
4368 |
a response, a cache whose HTTP version number is less than the specified |
4369 |
version MUST NOT store any part of either this response or the request |
4370 |
that elicited it, nor may any cache transmit a stored (non-firsthand) |
4371 |
copy of the response to any client with a lower HTTP version number. |
4372 |
This directive applies to both non-shared and shared caches, and is made |
4373 |
mandatory to allow for future protocol extensions that may affect |
4374 |
caching. |
4375 |
|
4376 |
Note that the lowest version that can be sensibly included in a |
4377 |
_min-vers_ directive is HTTP/1.1, since HTTP/1.0 caches do not |
4378 |
obey it. |
4379 |
|
4380 |
|
4381 |
10.7.3 Modifications of the Basic Expiration Mechanism |
4382 |
The expiration time of a resource may be specified by the origin server |
4383 |
using the Expires header (see section TBS). Alternatively, it may be |
4384 |
specified using the _max-age_ directive in a response. |
4385 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73] |
4386 |
|
4387 |
|
4388 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4389 |
|
4390 |
|
4391 |
If a response includes both an Expires header and a max-age: directive, |
4392 |
the max-age: directive overrides the Expires header, even if the Expires |
4393 |
header is more restrictive. This rule allows an origin server to |
4394 |
provide, for a given response, a longer expiration time to an HTTP/1.1 |
4395 |
(or later) cache than to an HTTP/1.0 cache. This may be useful if |
4396 |
certain HTTP/1.0 caches improperly calculate ages or expiration times, |
4397 |
perhaps due to badly unsynchronized clocks. |
4398 |
|
4399 |
Other directives allow an end-user client to modify the basic expiration |
4400 |
mechanism, making it either stricter or looser. These directives may be |
4401 |
specified on a request: |
4402 |
|
4403 |
max-age Indicates that the client is willing to accept a response whose |
4404 |
age is no greater than the specified time in seconds. Unless _max-stale_ |
4405 |
is also included, the client is not willing to accept a stale response. |
4406 |
This directive overrides any policy of the cache. |
4407 |
|
4408 |
min-fresh Indicates that the client is willing to accept a response |
4409 |
whose freshness lifetime is no less than its current age plus the |
4410 |
specified time in seconds. That is, the client wants a that response |
4411 |
will still be fresh for at least the specified number of seconds. |
4412 |
|
4413 |
max-stale Indicates that the client is willing to accept a response that |
4414 |
has exceeded its expiration time by no more than the specified number of |
4415 |
seconds. If a cache returns a stale response in response to such a |
4416 |
request, it MUST mark it as stale using the Warning header. |
4417 |
|
4418 |
Note that HTTP/1.0 caches will ignore these directives. |
4419 |
|
4420 |
If a cache returns a stale response, either because of a max-stale |
4421 |
directive on a request, or because the cache is configured to override |
4422 |
the expiration time of a response, the cache MUST attach a Warning |
4423 |
header to the stale response, using Warning 10 (Response is stale). |
4424 |
|
4425 |
|
4426 |
10.7.4 SLUSHY: Controls over cache revalidation and reload |
4427 |
Sometimes an end-user client may want or need to insist that a cache |
4428 |
revalidate its cache entry with the origin server (and not just with the |
4429 |
next cache along the path to the origin server), or to reload its cache |
4430 |
entry from the origin server. End-to-end revalidation may be necessary |
4431 |
if either the cache or the origin server has overestimated the |
4432 |
expiration time of the cached response. End-to-end reload may be |
4433 |
necessary if the response value has become corrupted for some reason, |
4434 |
and the fact that its validator is up-to-date is irrelevant. |
4435 |
|
4436 |
End-to-end revalidation may be requested either when the client does not |
4437 |
have its own local cached copy, in which case we call it _unspecified |
4438 |
end-to-end revalidation_, or when the client does have a local cached |
4439 |
copy, in which case we call it _specific end-to-end revalidation._ |
4440 |
|
4441 |
The client can specify these three kinds of action using Cache-Control |
4442 |
request directives: |
4443 |
|
4444 |
|
4445 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74] |
4446 |
|
4447 |
|
4448 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4449 |
|
4450 |
|
4451 |
End-to-end reload The request includes _Cache-Control: no-cache_ or, for |
4452 |
compatibility with HTTP/1.0 clients, _Pragma: no-cache_. No field names |
4453 |
may be included with the _no-cache_ directive in a request. The server |
4454 |
MUST NOT use a cached copy when responding to such a request. |
4455 |
|
4456 |
Specific end-to-end revalidation The request includes _Cache-Control: |
4457 |
max-age=0_, which forces each cache along the path to the origin server |
4458 |
to revalidate its own entry, if any, with the next cache or server. The |
4459 |
initial request includes a cache-validating conditional with the |
4460 |
client's current validator. |
4461 |
|
4462 |
Unspecified end-to-end revalidation The request includes _Cache-Control: |
4463 |
max-age=0_, which forces each cache along the path to the origin server |
4464 |
to revalidate its own entry, if any, with the next cache or server. The |
4465 |
initial request does not include a cache-validating conditional; the |
4466 |
first cache along the path (if any) that holds a cache entry for this |
4467 |
resource includes a cache-validating conditional with its current |
4468 |
validator. |
4469 |
|
4470 |
Note that HTTP/1.0 caches will ignore these directives, except |
4471 |
perhaps for _Pragma: no-cache_. |
4472 |
|
4473 |
When an intermediate cache is forced, by means of a _max-age=0_ |
4474 |
directive, to revalidate its own cache entry, and the client has |
4475 |
supplied its own validator in the request, the supplied validator may |
4476 |
differ from the validator currently stored with the cache entry. In this |
4477 |
case, the cache may use either validator in making its own request |
4478 |
without affecting semantic transparency. |
4479 |
|
4480 |
However, the choice of validator may affect performance. The best |
4481 |
approach is for the intermediate cache to use its own validator when |
4482 |
making its request. If the server replies with 304 (Not Modified), then |
4483 |
the cache should return its now validated copy to the client with a 200 |
4484 |
(OK) response. If the server replies with a new Entity-body and cache |
4485 |
validator, however, the intermediate cache should compare the returned |
4486 |
validator with the one provided in the client's request, using the |
4487 |
strong comparison function. If the client's validator is equal to the |
4488 |
origin server's, then the intermediate cache simply returns 304 (Not |
4489 |
Modified). Otherwise, it returns the new Entity-body with a 200 (OK) |
4490 |
response. |
4491 |
|
4492 |
If a request includes the _no-cache_ directive, it should not include |
4493 |
_fresh-min_, _max-stale_, or _max-age_. |
4494 |
|
4495 |
In some cases, such as times of extremely poor network connectivity, a |
4496 |
client may want a cache to return only those responses that it currently |
4497 |
has stored, and not to reload or revalidate with the origin server. To |
4498 |
do this, the client may include the _only-if-cached_ directive in a |
4499 |
request. If it receives this directive, a cache SHOULD either respond |
4500 |
using a cached value that is consistent with the other constraints of |
4501 |
the request, or respond with a 504 (Gateway Timeout) status. However, if |
4502 |
a group of caches is being operated as a unified system with good |
4503 |
internal connectivity, such a request MAY be forwarded within that group |
4504 |
of caches. |
4505 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75] |
4506 |
|
4507 |
|
4508 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4509 |
|
4510 |
|
4511 |
Because a cache may be configured to ignore a server's specified |
4512 |
expiration time, and because a client request may include a max-stale |
4513 |
directive, which has a similar effect, the protocol also includes a |
4514 |
mechanism for the origin server to require revalidation of a cache entry |
4515 |
on any subsequent use. When the _must-revalidate_ directive is present |
4516 |
in a response received by a cache, that cache MUST NOT use the value |
4517 |
after it becomes stale to respond to a subsequent request without first |
4518 |
revalidating it with the origin server. (I.e., the cache must do an end- |
4519 |
to-end revalidation every time.) |
4520 |
|
4521 |
The _must-revalidate_ directive is necessary to support reliable |
4522 |
operation for cookies and certain other protocol features. In all |
4523 |
circumstances an HTTP/1.1 cache MUST obey the _must-revalidate_ |
4524 |
directive; in particular, if the cache cannot reach the origin server |
4525 |
for any reason, it MUST generate a 504 (Gateway Timeout) response. Note |
4526 |
that HTTP/1.0 caches will ignore this directive. |
4527 |
|
4528 |
Servers should send the _must-revalidate_ directive if and only if |
4529 |
failure to revalidate a request on the entity could result in |
4530 |
significantly incorrect operation, such as a silently unexecuted |
4531 |
financial transaction. Recipients MUST NOT take any automated action |
4532 |
that violates this directive, and MUST NOT automatically provide an |
4533 |
unvalidated copy of the entity if revalidation fails. |
4534 |
|
4535 |
Although this is not recommended, user agents operating under severe |
4536 |
connectivity constraints may violate this directive but if so, MUST |
4537 |
explicitly warn the user that an unvalidated response has been provided. |
4538 |
The warning MUST be provided on each unvalidated access, and SHOULD |
4539 |
require explicit user confirmation. |
4540 |
|
4541 |
The _proxy-revalidate_ directive has the same meaning as the _must- |
4542 |
revalidate_ directive, except that it does not apply to user-agent |
4543 |
caches. This directive is meant to support digest authentication. |
4544 |
|
4545 |
|
4546 |
10.7.5 FLUID: Restrictions on use count and demographic reporting |
4547 |
This section is highly debatable and is likely to be removed to a |
4548 |
separate I.D. |
4549 |
|
4550 |
The _max-uses_ response directive allows a cache to use a response at |
4551 |
most a certain limited number of times. For example, _max-uses=10_ |
4552 |
means that the response should be returned in reply to the current |
4553 |
request, and may be returned in reply to no more than nine subsequent |
4554 |
requests (subject to other caching constraints), unless revalidated. |
4555 |
|
4556 |
A cache may subdivide its remaining use-count among several of its own |
4557 |
clients. For example, if the incoming response includes _max-uses=10_, |
4558 |
the recipient may forward this as two responses, each with _max-uses=5_. |
4559 |
The idea is that the total number of uses allowed in a cache hierarchy |
4560 |
should not exceed the specified limit. (The heuristics a cache uses to |
4561 |
sub-allocate its max-uses value are beyond the scope of the HTTP spec.) |
4562 |
|
4563 |
The _use-count_ request directive allows a cache to tell a server how |
4564 |
many times it has actually used the cache entry specified in the |
4565 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76] |
4566 |
|
4567 |
|
4568 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4569 |
|
4570 |
|
4571 |
associated request. If a cache receives a use-count value from one of |
4572 |
its clients, and it has a corresponding cache entry, it should add the |
4573 |
incoming use-count to its local count. |
4574 |
|
4575 |
When a cache removes an entry, it MAY first send a HEAD request on the |
4576 |
associated URI, including its use-count value, to inform the server of |
4577 |
the actual use-count. If the server has sent a max-uses limit, the |
4578 |
cache SHOULD perform this notification. |
4579 |
|
4580 |
A cache that is willing to perform such notifications and that is |
4581 |
willing to obey the max-uses limit SHOULD send a ``use-count=0'' |
4582 |
directive on its first (non-conditional) request on a resource. This |
4583 |
informs the server that the cache intends to use these two directives in |
4584 |
the manner described here. |
4585 |
|
4586 |
|
4587 |
10.7.6 Miscellaneous restrictions |
4588 |
In certain circumstances, an intermediate cache (proxy) may find it |
4589 |
useful to convert the encoding of an entity body. For example, a proxy |
4590 |
might use a compressed content-coding to transfer the body to a client |
4591 |
on a slow link. |
4592 |
|
4593 |
Because end-to-end authentication of entity bodies and/or entity headers |
4594 |
relies on the specific encoding of these values, such transformations |
4595 |
may cause authentication failures. Therefore, an intermediate cache MUST |
4596 |
NOT change the encoding of an entity body if the response includes the |
4597 |
_no-transform_ directive. |
4598 |
|
4599 |
|
4600 |
10.8 Connection |
4601 |
HTTP version 1.1 provides a new request and response header field called |
4602 |
_Connection_. This header field allows the client and server to specify |
4603 |
options which should only exist over that particular connection and MUST |
4604 |
NOT be communicated by proxies over further connections. The connection |
4605 |
header field MAY have multiple tokens separated by commas (referred to |
4606 |
as connection-tokens). |
4607 |
|
4608 |
HTTP version 1.1 proxies MUST parse the Connection header field and for |
4609 |
every connection-token in this field, remove a corresponding header |
4610 |
field from the request before the request is forwarded. The use of a |
4611 |
connection option is specified by the presence of a connection token in |
4612 |
the Connection header field, not by the corresponding additional header |
4613 |
field (which may not be present). |
4614 |
|
4615 |
When a client wishes to establish a persistent connection it MUST send a |
4616 |
_Persist_ connection-token: |
4617 |
|
4618 |
Connection: persist |
4619 |
|
4620 |
The Connection header has the following grammar: |
4621 |
|
4622 |
|
4623 |
|
4624 |
|
4625 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 77] |
4626 |
|
4627 |
|
4628 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4629 |
|
4630 |
|
4631 |
Connection-header = "Connection" ":" |
4632 |
|
4633 |
connection-token 0#( "," connection-token ) |
4634 |
|
4635 |
|
4636 |
|
4637 |
|
4638 |
When the Persist connection-token has been transmitted with a request or |
4639 |
a response a Persist header field MAY also be included. The 10.8.1 Persist Persist |
4640 |
header field takes the following form: |
4641 |
|
4642 |
Persist-header = "Persist" ":" 0#pers-param |
4643 |
|
4644 |
pers-param = param-name "=" value |
4645 |
|
4646 |
The Persist header itself is optional, and is used only if a parameter |
4647 |
is being sent. HTTP/1.1 does not define any parameters. |
4648 |
|
4649 |
If the Persist header is sent, the corresponding connection token MUST |
4650 |
be transmitted. The Persist header MUST be ignored if received without |
4651 |
the connection token. |
4652 |
|
4653 |
|
4654 |
10.9 Content-Base |
4655 |
The Content-Base entity-header field may be used to specify the base URI |
4656 |
for resolving relative URLs within the entity. This header field is |
4657 |
described as "Base" in RFC 1808 [11], which is expected to be revised |
4658 |
|
4659 |
soon. |
4660 |
|
4661 |
Content-Base = "Content-Base" ":" absoluteURI |
4662 |
|
4663 |
If no Content-Base field is present, the base URI of an entity is |
4664 |
defined either by its Content-Location or the URI used to initiate the |
4665 |
request, in that order of precedence. Note, however, that the base URI |
4666 |
of the contents within the entity body may be redefined within that |
4667 |
entity body. |
4668 |
|
4669 |
|
4670 |
10.10 Content-Encoding |
4671 |
The Content-Encoding entity-header field is used as a modifier to the |
4672 |
media-type. When present, its value indicates what additional content |
4673 |
codings have been applied to the resource, and thus what decoding |
4674 |
mechanisms MUST be applied in order to obtain the media-type referenced |
4675 |
by the Content-Type header field. Content-Encoding is primarily used to |
4676 |
allow a document to be compressed without losing the identity of its |
4677 |
underlying media type. |
4678 |
|
4679 |
Content-Encoding = "Content-Encoding" ":" 1#content-coding |
4680 |
|
4681 |
|
4682 |
|
4683 |
|
4684 |
|
4685 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 78] |
4686 |
|
4687 |
|
4688 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4689 |
|
4690 |
|
4691 |
Content codings are defined in Section 3.5. An example of its use is |
4692 |
|
4693 |
|
4694 |
Content-Encoding: gzip |
4695 |
|
4696 |
|
4697 |
|
4698 |
The Content-Encoding is a characteristic of the resource identified by |
4699 |
the Request-URI. Typically, the resource is stored with this encoding |
4700 |
and is only decoded before rendering or analogous usage. |
4701 |
|
4702 |
If multiple encodings have been applied to a resource, the content |
4703 |
codings MUST be listed in the order in which they were applied. |
4704 |
Additional information about the encoding parameters MAY be provided by |
4705 |
other Entity-Header fields not defined by this specification. |
4706 |
|
4707 |
|
4708 |
10.11 Content-Language |
4709 |
The Content-Language entity-header field describes the natural |
4710 |
language(s) of the intended audience for the enclosed entity. Note that |
4711 |
this may not be equivalent to all the languages used within the entity. |
4712 |
|
4713 |
Content-Language = "Content-Language" ":" 1#language-tag |
4714 |
|
4715 |
|
4716 |
|
4717 |
Language tags are defined in Section 3.10. The primary purpose of |
4718 |
|
4719 |
Content-Language is to allow a selective consumer to identify and |
4720 |
differentiate resources according to the consumer's own preferred |
4721 |
language. Thus, if the body content is intended only for a Danish- |
4722 |
literate audience, the appropriate field is |
4723 |
|
4724 |
Content-Language: dk |
4725 |
|
4726 |
|
4727 |
|
4728 |
If no Content-Language is specified, the default is that the content is |
4729 |
intended for all language audiences. This may mean that the sender does |
4730 |
not consider it to be specific to any natural language, or that the |
4731 |
sender does not know for which language it is intended. |
4732 |
|
4733 |
Multiple languages MAY be listed for content that is intended for |
4734 |
multiple audiences. For example, a rendition of the _Treaty of |
4735 |
Waitangi,_ presented simultaneously in the original Maori and English |
4736 |
versions, would call for |
4737 |
|
4738 |
Content-Language: mi, en |
4739 |
|
4740 |
|
4741 |
|
4742 |
However, just because multiple languages are present within an entity |
4743 |
does not mean that it is intended for multiple linguistic audiences. An |
4744 |
example would be a beginner's language primer, such as _A First Lesson |
4745 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79] |
4746 |
|
4747 |
|
4748 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4749 |
|
4750 |
|
4751 |
in Latin,_ which is clearly intended to be used by an English-literate |
4752 |
audience. In this case, the Content-Language should only include _en_. |
4753 |
|
4754 |
Content-Language MAY be applied to any media type -- it SHOULD not be |
4755 |
limited to textual documents. |
4756 |
|
4757 |
|
4758 |
10.12 Content-Length |
4759 |
The Content-Length entity-header field indicates the size of the Entity- |
4760 |
Body, in decimal number of octets, sent to the recipient or, in the case |
4761 |
of the HEAD method, the size of the Entity-Body that would have been |
4762 |
sent had the request been a GET. |
4763 |
|
4764 |
Content-Length = "Content-Length" ":" 1*DIGIT |
4765 |
|
4766 |
|
4767 |
|
4768 |
An example is |
4769 |
|
4770 |
Content-Length: 3495 |
4771 |
|
4772 |
|
4773 |
|
4774 |
Applications SHOULD use this field to indicate the size of the Entity- |
4775 |
Body to be transferred, regardless of the media type of the entity. A |
4776 |
valid Content-Length field value is required on all HTTP/1.1 request |
4777 |
messages containing an entity body. |
4778 |
|
4779 |
Any Content-Length greater than or equal to zero is a valid value. |
4780 |
Section 7.2.2 describes how to determine the length of an Entity-Body if |
4781 |
|
4782 |
a Content-Length is not given. |
4783 |
|
4784 |
Note: The meaning of this field is significantly different from |
4785 |
the corresponding definition in MIME, where it is an optional |
4786 |
field used within the _message/external-body_ content-type. In |
4787 |
HTTP, it SHOULD be used whenever the entity's length can be |
4788 |
determined prior to being transferred. |
4789 |
|
4790 |
|
4791 |
10.13 Content-MD5 |
4792 |
The Content-MD5 entity-header field is an MD5 digest of the entity-body, |
4793 |
as defined in RFC 1864 [23], for the purpose of providing an end-to-end |
4794 |
|
4795 |
message integrity check (MIC) of the entity-body. (Note: an MIC is good |
4796 |
for detecting accidental modification of the entity-body in transit, but |
4797 |
is not proof against malicious attacks.) |
4798 |
|
4799 |
ContentMD5 = "Content-MD5" ":" md5-digest |
4800 |
|
4801 |
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> |
4802 |
|
4803 |
|
4804 |
|
4805 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80] |
4806 |
|
4807 |
|
4808 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4809 |
|
4810 |
|
4811 |
The Content-MD5 header may be generated by an origin server to function |
4812 |
as an integrity check of the entity-body. Only origin-servers may |
4813 |
generate the Content-MD5 header field; proxies and gateways MUST NOT |
4814 |
generate it, as this would defeat its value as an end-to-end integrity |
4815 |
check. Any recipient of the entity-body, including gateways and proxies, |
4816 |
MAY check that the digest value in this header field matches that of the |
4817 |
entity-body as received. |
4818 |
|
4819 |
The MD5 digest is computed based on the content of the entity body, |
4820 |
including any Content-Encoding that has been applied, but not including |
4821 |
any Transfer-Encoding. If the entity is received with a Transfer- |
4822 |
Encoding, that encoding must be removed prior to checking the Content- |
4823 |
MD5 value against the received entity. |
4824 |
|
4825 |
This has the result that the digest is computed on the octets of the |
4826 |
entity body exactly as, and in the order that, they would be sent if no |
4827 |
Transfer-Encoding were being applied. |
4828 |
|
4829 |
HTTP extends RFC 1864 to permit the digest to be computed for MIME |
4830 |
composite media-types (e.g., multipart/* and message/rfc822), but this |
4831 |
does not change how the digest is computed as defined in the preceding |
4832 |
paragraph. |
4833 |
|
4834 |
Note: There are several consequences of this. The entity-body |
4835 |
for composite types many contain many body-parts, each with its |
4836 |
own MIME and HTTP headers (including Content-MD5, Content- |
4837 |
Transfer-Encoding, and Content-Encoding headers). If a body-part |
4838 |
has a Content-Transfer-Encoding or Content-Encoding header, it |
4839 |
is assumed that the content of the body-part has had the |
4840 |
encoding applied, and the body-part is included in the Content- |
4841 |
MD5 digest as is -- i.e., after the application. Also, the HTTP |
4842 |
Transfer-Encoding header makes no sense within body-parts; if it |
4843 |
is present, it is ignored -- i.e. treated as ordinary text. |
4844 |
|
4845 |
Note: while the definition of Content-MD5 is exactly the same |
4846 |
for HTTP as in RFC 1864 for MIME entity-bodies, there are |
4847 |
several ways in which the application of Content-MD5 to HTTP |
4848 |
entity-bodies differs from its application to MIME entity- |
4849 |
bodies. One is that HTTP, unlike MIME, does not use Content- |
4850 |
Transfer-Encoding, and does use Transfer-Encoding and Content- |
4851 |
Encoding. Another is that HTTP more frequently uses binary |
4852 |
content types than MIME, so it is worth noting that in such |
4853 |
cases, the byte order used to compute the digest is the |
4854 |
transmission byte order defined for the type. Lastly, HTTP |
4855 |
allows transmission of text types with any of several line break |
4856 |
conventions and not just the canonical form using CR-LF. |
4857 |
Conversion of all line breaks to CR-LF should not be done before |
4858 |
computing or checking the digest: the line break convention used |
4859 |
in the text actually transmitted should be left unaltered when |
4860 |
computing the digest. |
4861 |
|
4862 |
|
4863 |
|
4864 |
|
4865 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 81] |
4866 |
|
4867 |
|
4868 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4869 |
|
4870 |
|
4871 |
10.14 SLUSHY Content-Range |
4872 |
The Content-Range header is sent with a partial entity body to specify |
4873 |
where in the full entity body the partial body should be inserted. It |
4874 |
also indicates the total size of the entity. |
4875 |
|
4876 |
Content-Range = "Content-Range" ":" content-range-spec |
4877 |
|
4878 |
When an HTTP message includes the content of a single range (for |
4879 |
example, a response to a request for a single range, or to request for a |
4880 |
set of ranges that overlap without any holes), this content is |
4881 |
transmitted with a Content-Range header, and a Content-length header |
4882 |
showing the number of bytes actually transferred. |
4883 |
|
4884 |
For example, |
4885 |
|
4886 |
HTTP/1.0 206 Partial content |
4887 |
|
4888 |
Date: Wed, 15 Nov 1995 06:25:24 GMT |
4889 |
|
4890 |
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
4891 |
|
4892 |
Content-range: 21010-47021/47022 |
4893 |
|
4894 |
Content-length: 26012 |
4895 |
|
4896 |
Content-type: image/gif |
4897 |
|
4898 |
|
4899 |
10.14.1 MIME multipart/byteranges content-type |
4900 |
When an HTTP message includes the content of multiple ranges (for |
4901 |
example, a response to a request for multiple non-overlapping ranges), |
4902 |
these are transmitted as a multipart MIME message. The multipart MIME |
4903 |
content-type used for this purpose is defined in this specification to |
4904 |
be "multipart/byteranges". |
4905 |
|
4906 |
The MIME multipart/byteranges content-type includes two or more parts, |
4907 |
each with its own Content-type and Content-Range fields. The parts are |
4908 |
separated using a MIME boundary parameter. |
4909 |
|
4910 |
|
4911 |
|
4912 |
For example: |
4913 |
|
4914 |
|
4915 |
|
4916 |
|
4917 |
|
4918 |
|
4919 |
|
4920 |
|
4921 |
|
4922 |
|
4923 |
|
4924 |
|
4925 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82] |
4926 |
|
4927 |
|
4928 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4929 |
|
4930 |
|
4931 |
HTTP/1.0 206 Partial content |
4932 |
|
4933 |
Date: Wed, 15 Nov 1995 06:25:24 GMT |
4934 |
|
4935 |
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT |
4936 |
|
4937 |
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES |
4938 |
|
4939 |
|
4940 |
|
4941 |
--THIS_STRING_SEPARATES |
4942 |
|
4943 |
Content-type: application/pdf |
4944 |
|
4945 |
Content-range: bytes 500-999/8000 |
4946 |
|
4947 |
|
4948 |
|
4949 |
...the first range... |
4950 |
|
4951 |
--THIS_STRING_SEPARATES |
4952 |
|
4953 |
Content-type: application/pdf |
4954 |
|
4955 |
Content-range: bytes 7000-7999/8000 |
4956 |
|
4957 |
|
4958 |
|
4959 |
...the second range... |
4960 |
|
4961 |
--THIS_STRING_SEPARATES_ |
4962 |
|
4963 |
|
4964 |
10.14.2 Additional rules for Content-Range |
4965 |
A client that cannot decode a MIME multipart/byteranges message should |
4966 |
not ask for multiple byte-ranges in a single request. |
4967 |
|
4968 |
When a client requests multiple byte-ranges in one request, the server |
4969 |
SHOULD return them in the order that they appeared in the request. |
4970 |
|
4971 |
If the server ignores a byte-range-spec because it is invalid, or |
4972 |
because it specifies a range that starts beyond the end of the entity, |
4973 |
it may omit the corresponding Content-Range field and partial entity |
4974 |
body. |
4975 |
|
4976 |
If none of the byte-range-spec values in a request specify part of the |
4977 |
current entity (i.e., start before the last byte of the entity), then |
4978 |
the server should return a status of 207 (Range Out Of Bounds). |
4979 |
|
4980 |
|
4981 |
10.15 Content-Type |
4982 |
The Content-Type entity-header field indicates the media type of the |
4983 |
Entity-Body sent to the recipient or, in the case of the HEAD method, |
4984 |
the media type that would have been sent had the request been a GET. |
4985 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83] |
4986 |
|
4987 |
|
4988 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
4989 |
|
4990 |
|
4991 |
Content-Type = "Content-Type" ":" media-type |
4992 |
|
4993 |
|
4994 |
|
4995 |
Media types are defined in Section 3.7. An example of the field is |
4996 |
|
4997 |
|
4998 |
|
4999 |
|
5000 |
|
5001 |
|
5002 |
Further discussion of methods for identifying the media type of an |
5003 |
entity is provided in Section 7.2.1. Content-Type: text/html; charset=ISO-8859-4 |
5004 |
|
5005 |
|
5006 |
|
5007 |
10.16 Content-Location |
5008 |
The Content-Location entity-header field is used to define the location |
5009 |
of the specific resource associated with the entity enclosed in the |
5010 |
message. A server SHOULD provide a Content-Location if, when including |
5011 |
an entity in response to a GET request on a negotiated resource, the |
5012 |
entity corresponds to a specific, non-negotiated location which can be |
5013 |
accessed via the Content-Location URI. A server SHOULD provide a |
5014 |
Content-Location with any 200 (OK) response which was internally (not |
5015 |
visible to the client) redirected to a resource other than the one |
5016 |
identified by the request and for which correct interpretation of that |
5017 |
resource MAY require knowledge of its actual location. The recipient MAY |
5018 |
make future requests on this location instead of on the Request-URI. |
5019 |
|
5020 |
Content-Location = "Content-Location" ":" absoluteURI |
5021 |
|
5022 |
If no Content-Base header field is present, the value of Content- |
5023 |
Location also defines the base URL for the entity (see Section 10.9). |
5024 |
|
5025 |
Note: Since the Content-Location field re-interprets the source |
5026 |
of an entity, recipients must take care in not allowing a |
5027 |
_spoofed_ location to deny access to the real resource. This is |
5028 |
described in Section 15.9. |
5029 |
|
5030 |
|
5031 |
10.17 Date |
5032 |
The Date general-header field represents the date and time at which the |
5033 |
message was originated, having the same semantics as orig-date in RFC |
5034 |
822. The field value is an HTTP-date, as described in Section 3.3. |
5035 |
|
5036 |
|
5037 |
Date = "Date" ":" HTTP-date |
5038 |
|
5039 |
|
5040 |
|
5041 |
An example is |
5042 |
|
5043 |
|
5044 |
|
5045 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 84] |
5046 |
|
5047 |
|
5048 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5049 |
|
5050 |
|
5051 |
Date: Tue, 15 Nov 1994 08:12:31 GMT |
5052 |
|
5053 |
|
5054 |
|
5055 |
If a message is received via direct connection with the user agent (in |
5056 |
the case of requests) or the origin server (in the case of responses), |
5057 |
then the date can be assumed to be the current date at the receiving |
5058 |
end. However, since the date--as it is believed by the origin--is |
5059 |
important for evaluating cached responses, origin servers SHOULD always |
5060 |
include a Date header. Clients SHOULD only send a Date header field in |
5061 |
messages that include an entity body, as in the case of the PUT and POST |
5062 |
requests, and even then it is optional. A received message which does |
5063 |
not have a Date header field SHOULD be assigned one by the recipient if |
5064 |
the message will be cached by that recipient or gatewayed via a protocol |
5065 |
which requires a Date. |
5066 |
|
5067 |
In theory, the date SHOULD represent the moment just before the entity |
5068 |
is generated. In practice, the date can be generated at any time during |
5069 |
the message origination without affecting its semantic value. |
5070 |
|
5071 |
Note: An earlier version of this document incorrectly specified |
5072 |
that this field SHOULD contain the creation date of the enclosed |
5073 |
Entity-Body. This has been changed to reflect actual (and |
5074 |
proper) usage. |
5075 |
|
5076 |
Origin servers MUST send a Date field in every response. However, if a |
5077 |
cache receives a response without a Date field, it SHOULD attach one |
5078 |
with the cache's best estimate of the time at which the response was |
5079 |
originally generated. |
5080 |
|
5081 |
The format of the Date is an absolute date and time as defined by HTTP- |
5082 |
date in Section 3.3; it MUST be in RFC1123-date format. |
5083 |
|
5084 |
|
5085 |
|
5086 |
|
5087 |
10.19 SLUSHY Expires |
5088 |
The Expires entity-header field gives the date/time after which the |
5089 |
entity should be considered stale. A stale cache entry may not normally |
5090 |
be returned by a cache (either a proxy cache or an end-user cache) |
5091 |
unless it is first validated with the origin server (or with an |
5092 |
intermediate cache that has a fresh copy of the resource). See section |
5093 |
13.2 for further discussion of the expiration model. |
5094 |
|
5095 |
The presence of an Expires field does not imply that the original |
5096 |
resource will change or cease to exist at, before, or after that time. |
5097 |
|
5098 |
The format is an absolute date and time as defined by HTTP-date in |
5099 |
Section 3.3; it MUST be in rfc1123-date format: |
5100 |
|
5101 |
Expires = "Expires" ":" HTTP-date |
5102 |
|
5103 |
|
5104 |
|
5105 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 85] |
5106 |
|
5107 |
|
5108 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5109 |
|
5110 |
|
5111 |
An example of its use is |
5112 |
|
5113 |
Expires: Thu, 01 Dec 1994 16:00:00 GMT |
5114 |
|
5115 |
|
5116 |
|
5117 |
Note: if a response includes a Cache-Control field with the max- |
5118 |
age directive, that directive overrides the Expires field. |
5119 |
|
5120 |
|
5121 |
HTTP/1.1 clients and caches MUST treat other invalid date formats, |
5122 |
especially including the value _0_, as in the past (i.e., _already |
5123 |
expired_). |
5124 |
|
5125 |
To mark a response as _already expired,_ an origin server should use an |
5126 |
Expires date that is equal to the Date header value. (See the rules for |
5127 |
expiration calculations in section 13.2.7.) |
5128 |
|
5129 |
To mark a response as _never expires,_ an origin server should use |
5130 |
Expires date approximately one year from the time the response is |
5131 |
generated. HTTP/1.1 servers should not send Expires dates more than one |
5132 |
year in the future. |
5133 |
|
5134 |
|
5135 |
10.20 Via |
5136 |
The Via general-header field MUST be used by gateways and proxies to |
5137 |
indicate the intermediate protocols and recipients between the user |
5138 |
agent and the server on requests, and between the origin server and the |
5139 |
client on responses. It is analogous to the _Received_ field of RFC 822 |
5140 |
[9]and is intended to be used for tracking message forwards, avoiding |
5141 |
|
5142 |
request loops, and identifying the protocol capabilities of all senders |
5143 |
along the request/response chain. |
5144 |
|
5145 |
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
5146 |
|
5147 |
|
5148 |
|
5149 |
received-protocol = [ protocol-name "/" ] protocol-version |
5150 |
|
5151 |
protocol-name = token |
5152 |
|
5153 |
protocol-version = token |
5154 |
|
5155 |
|
5156 |
|
5157 |
received-by = ( host [ ":" port ] ) | pseudonym |
5158 |
|
5159 |
pseudonym = token |
5160 |
|
5161 |
|
5162 |
|
5163 |
The received-protocol indicates the protocol version of the message |
5164 |
received by the server or client along each segment of the |
5165 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 86] |
5166 |
|
5167 |
|
5168 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5169 |
|
5170 |
|
5171 |
request/response chain. The received-protocol version is appended to |
5172 |
the Via field value when the message is forwarded so that information |
5173 |
about the protocol capabilities of upstream applications remains visible |
5174 |
to all recipients. |
5175 |
|
5176 |
The protocol-name is optional if and only if it would be _HTTP_. The |
5177 |
received-by field is normally the host and optional port number of a |
5178 |
recipient server or client that subsequently forwarded the message. |
5179 |
However, if the real host is considered to be sensitive information, it |
5180 |
MAY be replaced by a pseudonym. If the port is not given, it MAY be |
5181 |
assumed to be the default port of the received-protocol. |
5182 |
|
5183 |
Multiple Via field values represent each proxy or gateway that has |
5184 |
forwarded the message. Each recipient MUST append their information |
5185 |
such that the end result is ordered according to the sequence of |
5186 |
forwarding applications. |
5187 |
|
5188 |
Comments MAY be used in the Via header field to identify the software of |
5189 |
the recipient proxy or gateway, analogous to the User-Agent and Server |
5190 |
header fields. However, all comments in the Via field are optional and |
5191 |
MAY be removed by any recipient prior to forwarding the message. |
5192 |
|
5193 |
For example, a request message could be sent from an HTTP/1.0 user agent |
5194 |
to an internal proxy code-named _fred_, which uses HTTP/1.1 to forward |
5195 |
the request to a public proxy at nowhere.com, which completes the |
5196 |
request by forwarding it to the origin server at www.ics.uci.edu. The |
5197 |
request received by www.ics.uci.edu would then have the following Via |
5198 |
header field: |
5199 |
|
5200 |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
5201 |
|
5202 |
|
5203 |
|
5204 |
Proxies and gateways used as a portal through a network firewall SHOULD |
5205 |
NOT, by default, forward the names and ports of hosts within the |
5206 |
firewall region. This information SHOULD only be propagated if |
5207 |
explicitly enabled. If not enabled, the received-by host of any host |
5208 |
behind the firewall SHOULD be replaced by an appropriate pseudonym for |
5209 |
that host. |
5210 |
|
5211 |
For organizations that have strong privacy requirements for hiding |
5212 |
internal structures, a proxy MAY combine an ordered subsequence of Via |
5213 |
header field entries with identical received-protocol values into a |
5214 |
single such entry. For example, |
5215 |
|
5216 |
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
5217 |
|
5218 |
|
5219 |
|
5220 |
could be collapsed to |
5221 |
|
5222 |
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
5223 |
|
5224 |
|
5225 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 87] |
5226 |
|
5227 |
|
5228 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5229 |
|
5230 |
|
5231 |
|
5232 |
|
5233 |
Applications SHOULD NOT combine multiple entries unless they are all |
5234 |
under the same organizational control and the hosts have already been |
5235 |
replaced by pseudonyms. Applications MUST NOT combine entries which |
5236 |
have different received-protocol values. |
5237 |
|
5238 |
Note: The Via header field replaces the Forwarded header field |
5239 |
which was present in earlier drafts of this specification. |
5240 |
|
5241 |
|
5242 |
10.21 From |
5243 |
The From request-header field, if given, SHOULD contain an Internet e- |
5244 |
mail address for the human user who controls the requesting user agent. |
5245 |
The address SHOULD be machine-usable, as defined by mailbox in RFC 822 |
5246 |
[9] (as updated by RFC 1123 [8]): |
5247 |
|
5248 |
|
5249 |
From = "From" ":" mailbox |
5250 |
|
5251 |
|
5252 |
|
5253 |
An example is: |
5254 |
|
5255 |
From: webmaster@w3.org |
5256 |
|
5257 |
|
5258 |
|
5259 |
This header field MAY be used for logging purposes and as a means for |
5260 |
identifying the source of invalid or unwanted requests. It SHOULD NOT be |
5261 |
used as an insecure form of access protection. The interpretation of |
5262 |
this field is that the request is being performed on behalf of the |
5263 |
person given, who accepts responsibility for the method performed. In |
5264 |
particular, robot agents SHOULD include this header so that the person |
5265 |
responsible for running the robot can be contacted if problems occur on |
5266 |
the receiving end. |
5267 |
|
5268 |
The Internet e-mail address in this field MAY be separate from the |
5269 |
Internet host which issued the request. For example, when a request is |
5270 |
passed through a proxy the original issuer's address SHOULD be used. |
5271 |
|
5272 |
Note: The client SHOULD not send the From header field without |
5273 |
the user's approval, as it may conflict with the user's privacy |
5274 |
interests or their site's security policy. It is strongly |
5275 |
recommended that the user be able to disable, enable, and modify |
5276 |
the value of this field at any time prior to a request. |
5277 |
|
5278 |
|
5279 |
10.22 Host |
5280 |
The Host request-header field specifies the Internet host and port |
5281 |
number of the resource being requested, as obtained from the original |
5282 |
URL given by the user or referring resource (generally an HTTP URL, as |
5283 |
described in Section 3.2.2). The Host field value MUST represent the |
5284 |
|
5285 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 88] |
5286 |
|
5287 |
|
5288 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5289 |
|
5290 |
|
5291 |
network location of the origin server or gateway given by the original |
5292 |
URL. This allows the origin server or gateway to differentiate between |
5293 |
internally-ambiguous URLs, such as the root _/_ URL of a server for |
5294 |
multiple host names on a single IP address. |
5295 |
|
5296 |
Host = "Host" ":" host [ ":" port ] ; see Section 3.2.2 |
5297 |
|
5298 |
|
5299 |
|
5300 |
|
5301 |
_host_ without any trailing port information implies the default port |
5302 |
for the service requested (e.g., _80_ for an HTTP URL). For example, a |
5303 |
request on the origin server for <http://www.w3.org/pub/WWW/> MUST |
5304 |
include: |
5305 |
|
5306 |
GET /pub/WWW/ HTTP/1.1 |
5307 |
|
5308 |
Host: www.w3.org |
5309 |
|
5310 |
|
5311 |
|
5312 |
The header field MUST be included in all HTTP/1.1 request messages A Host |
5313 |
on the Internet (i.e., on any message corresponding to a request for a |
5314 |
URL which includes an Internet host address for the service being |
5315 |
requested). If the Host field is not already present, an HTTP/1.1 proxy |
5316 |
MUST add a Host field to the request message prior to forwarding it on |
5317 |
the Internet. All Internet-based HTTP/1.1 servers MUST respond with a |
5318 |
400 status code to any HTTP/1.1 request message which lacks a Host |
5319 |
header field. |
5320 |
|
5321 |
|
5322 |
10.23 If-Modified-Since |
5323 |
The If-Modified-Since request-header field is used with the GET method |
5324 |
to make it conditional: if the requested resource has not been modified |
5325 |
since the time specified in this field, a copy of the resource will not |
5326 |
be returned from the server; instead, a 304 (not modified) response will |
5327 |
be returned without any Entity-Body. |
5328 |
|
5329 |
If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
5330 |
|
5331 |
|
5332 |
|
5333 |
An example of the field is: |
5334 |
|
5335 |
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
5336 |
|
5337 |
|
5338 |
|
5339 |
A GET method with an If-Modified-Since header and no Range header |
5340 |
requests that the identified resource be transferred only if it has been |
5341 |
modified since the date given by the If-Modified-Since header. The |
5342 |
algorithm for determining this includes the following cases: |
5343 |
|
5344 |
|
5345 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 89] |
5346 |
|
5347 |
|
5348 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5349 |
|
5350 |
|
5351 |
a) |
5352 |
If the request would normally result in anything other than a 200 |
5353 |
(ok) status, or if the passed If-Modified-Since date is invalid, the |
5354 |
response is exactly the same as for a normal GET. A date which is |
5355 |
later than the server's current time is invalid. |
5356 |
|
5357 |
b) |
5358 |
If the resource has been modified since the If-Modified-Since date, |
5359 |
the response is exactly the same as for a normal GET. |
5360 |
|
5361 |
c) |
5362 |
If the resource has not been modified since a valid If-Modified-Since |
5363 |
date, the server MUST return a 304 (not modified) response. |
5364 |
The purpose of this feature is to allow efficient updates of cached |
5365 |
information with a minimum amount of transaction overhead. |
5366 |
|
5367 |
Note that the Range request-header field modifies the meaning of |
5368 |
If-Modified-Since; see section 13.9 for full details. |
5369 |
|
5370 |
Note that If-Modified-Since is ignored for varying resources. |
5371 |
|
5372 |
Note that If-Modified-Since times are interpreted by the server, |
5373 |
whose clock may not be synchronized with the client. |
5374 |
|
5375 |
Note that if a client uses an arbitrary date in the If-Modified- |
5376 |
Since header instead of a date taken from the Last-Modified |
5377 |
header for the same request, the client should be aware of the |
5378 |
fact that this date is interpreted in the server's understanding |
5379 |
of time. The client should consider unsynchronized clocks and |
5380 |
rounding problems due to the different representations of time |
5381 |
between the client and server. This includes the possibility of |
5382 |
race conditions if the document has changed between the time it |
5383 |
was first request and the If-Modified-Since date of a subsequent |
5384 |
request, and the possibility of clock-skew-related problems if |
5385 |
the If-Modified-Date date is derived from the client's clock |
5386 |
without correction to the server's clock. Corrections for |
5387 |
different time bases between client and server are at best |
5388 |
approximate due to network latency. |
5389 |
|
5390 |
|
5391 |
|
5392 |
|
5393 |
10.25 Last-Modified |
5394 |
The Last-Modified entity-header field indicates the date and time at |
5395 |
which the sender believes the resource was last modified. The exact |
5396 |
semantics of this field are defined in terms of how the recipient SHOULD |
5397 |
interpret it: if the recipient has a copy of this resource which is |
5398 |
older than the date given by the Last-Modified field, that copy SHOULD |
5399 |
be considered stale. |
5400 |
|
5401 |
Last-Modified = "Last-Modified" ":" HTTP-date |
5402 |
|
5403 |
|
5404 |
|
5405 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 90] |
5406 |
|
5407 |
|
5408 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5409 |
|
5410 |
|
5411 |
An example of its use is |
5412 |
|
5413 |
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
5414 |
|
5415 |
|
5416 |
|
5417 |
The exact meaning of this header field depends on the implementation of |
5418 |
the sender and the nature of the original resource. For files, it may be |
5419 |
just the file system last-modified time. For entities with dynamically |
5420 |
included parts, it may be the most recent of the set of last-modify |
5421 |
times for its component parts. For database gateways, it may be the |
5422 |
last-update time stamp of the record. For virtual objects, it may be the |
5423 |
last time the internal state changed. |
5424 |
|
5425 |
An origin server MUST not send a Last-Modified date which is later than |
5426 |
the server's time of message origination. In such cases, where the |
5427 |
resource's last modification would indicate some time in the future, the |
5428 |
server MUST replace that date with the message origination date. |
5429 |
|
5430 |
An origin server should obtain the Last-Modified value of the entity as |
5431 |
close as possible to the time that it generates the Date value of its |
5432 |
response. This allows a recipient to make an accurate assessment of the |
5433 |
entity's modification time, especially if the entity changes near the |
5434 |
time that the response is generated. |
5435 |
|
5436 |
|
5437 |
10.27 Location |
5438 |
The Location response-header field is used to redirect the recipient to |
5439 |
a location other than the Request-URI for completion of the request or |
5440 |
identification of a new resource. For 201 responses, the Location is |
5441 |
that of the new resource which was created by the request. For 3xx |
5442 |
responses, the location SHOULD indicate the server's preferred URL for |
5443 |
automatic redirection to the resource. The field value consists of a |
5444 |
single absolute URL. |
5445 |
|
5446 |
Location = "Location" ":" absoluteURI |
5447 |
|
5448 |
|
5449 |
An example is |
5450 |
|
5451 |
Location: http://www.w3.org/pub/WWW/People.html |
5452 |
|
5453 |
|
5454 |
Note: The Content-Location header field (Section 10.16) differs |
5455 |
from Location in that the former identifies the original |
5456 |
location of the entity enclosed in the request. It is therefore |
5457 |
possible for a response to contain header fields for both |
5458 |
Location and Content-Location. |
5459 |
|
5460 |
|
5461 |
10.29 Pragma |
5462 |
The Pragma general-header field is used to include implementation- |
5463 |
specific directives that may apply to any recipient along the |
5464 |
request/response chain. All pragma directives specify optional behavior |
5465 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 91] |
5466 |
|
5467 |
|
5468 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5469 |
|
5470 |
|
5471 |
from the viewpoint of the protocol; however, some systems MAY require |
5472 |
that behavior be consistent with the directives. |
5473 |
|
5474 |
|
5475 |
|
5476 |
|
5477 |
|
5478 |
|
5479 |
|
5480 |
|
5481 |
|
5482 |
When the _no-cache_ directive is present in a request message, an |
5483 |
application SHOULD forward the request toward the origin server even if |
5484 |
it has a cached copy of what is being requested. This pragma directive Pragma = "Pragma" ":" 1#pragma-directive extension-pragma = token [ "=" word ] |
5485 |
has the same semantics as the _no-cache_ cache-directive (see pragma-directive = "no-cache" | extension-pragma |
5486 |
Section 10.8) and is defined here for backwards compatibility with |
5487 |
|
5488 |
HTTP/1.0. Clients SHOULD include both header fields when a _no-cache_ |
5489 |
request is sent to a server not known to be HTTP/1.1 compliant. |
5490 |
|
5491 |
Pragma directives MUST be passed through by a proxy or gateway |
5492 |
application, regardless of their significance to that application, since |
5493 |
the directives may be applicable to all recipients along the |
5494 |
request/response chain. It is not possible to specify a pragma for a |
5495 |
specific recipient; however, any pragma directive not relevant to a |
5496 |
recipient SHOULD be ignored by that recipient. |
5497 |
|
5498 |
HTTP/1.1 clients SHOULD NOT send the Pragma request header. HTTP/1.1 |
5499 |
caches SHOULD treat _Pragma: no-cache_ as if the client had sent _Cache- |
5500 |
control: no-cache_. No new Pragma directives will be defined in HTTP. |
5501 |
|
5502 |
|
5503 |
|
5504 |
|
5505 |
10.30 Proxy-Authenticate |
5506 |
The Proxy-Authenticate response-header field MUST be included as part of |
5507 |
a 407 (proxy authentication required) response. The field value consists |
5508 |
of a challenge that indicates the authentication scheme and parameters |
5509 |
applicable to the proxy for this Request-URI. |
5510 |
|
5511 |
Proxy-Authentication = "Proxy-Authentication" ":" challenge |
5512 |
|
5513 |
|
5514 |
|
5515 |
The HTTP access authentication process is described in Section 11. |
5516 |
|
5517 |
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
5518 |
only to the current connection and MUST not be passed on to downstream |
5519 |
clients. |
5520 |
|
5521 |
|
5522 |
10.31 Proxy-Authorization |
5523 |
The Proxy-Authorization request-header field allows the client to |
5524 |
identify itself (or its user) to a proxy which requires authentication. |
5525 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 92] |
5526 |
|
5527 |
|
5528 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5529 |
|
5530 |
|
5531 |
The Proxy-Authorization field value consists of credentials containing |
5532 |
the authentication information of the user agent for the proxy and/or |
5533 |
realm of the resource being requested. |
5534 |
|
5535 |
Proxy-Authorization = "Proxy-Authorization" ":" credentials |
5536 |
|
5537 |
|
5538 |
|
5539 |
The HTTP access authentication process is described in Section 11. |
5540 |
|
5541 |
Unlike Authorization, the Proxy-Authorization applies only to the |
5542 |
current connection and MUST not be passed on to upstream servers. If a |
5543 |
request is authenticated and a realm specified, the same credentials |
5544 |
SHOULD be valid for all other requests within this realm. |
5545 |
|
5546 |
|
5547 |
10.32 Public |
5548 |
The Public response-header field lists the set of non-standard methods |
5549 |
supported by the server. The purpose of this field is strictly to inform |
5550 |
the recipient of the capabilities of the server regarding unusual |
5551 |
methods. The methods listed may or may not be applicable to the Request- |
5552 |
URI; the Allow header field (Section 10.5) SHOULD be used to indicate |
5553 |
|
5554 |
methods allowed for a particular URI. This does not prevent a client |
5555 |
from trying other methods. The field value SHOULD not include the |
5556 |
methods predefined for HTTP/1.1 in Section 5.1.1. |
5557 |
|
5558 |
|
5559 |
Public = "Public" ":" 1#method |
5560 |
|
5561 |
|
5562 |
|
5563 |
Example of use: |
5564 |
|
5565 |
Public: OPTIONS, MGET, MHEAD |
5566 |
|
5567 |
|
5568 |
|
5569 |
This header field applies only to the server directly connected to the |
5570 |
client (i.e., the nearest neighbor in a chain of connections). If the |
5571 |
response passes through a proxy, the proxy MUST either remove the Public |
5572 |
header field or replace it with one applicable to its own capabilities. |
5573 |
|
5574 |
|
5575 |
10.33 Range |
5576 |
HTTP retrieval requests using conditional or unconditional GET methods |
5577 |
may request one or more sub-ranges of the entity, instead of the entire |
5578 |
entity. This is done using the Range request header: |
5579 |
|
5580 |
Range = "Range" ":" ranges-specifier |
5581 |
|
5582 |
A server MAY ignore the Range header. However, HTTP/1.1 origin servers |
5583 |
and intermediate caches SHOULD support byte ranges whenever possible, |
5584 |
|
5585 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 93] |
5586 |
|
5587 |
|
5588 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5589 |
|
5590 |
|
5591 |
since this supports efficient recovery from partially failed transfers, |
5592 |
and it supports efficient partial retrieval of large entities. |
5593 |
|
5594 |
I the server supports the Range header and the specified range or ranges |
5595 |
are appropriate for the entity: |
5596 |
|
5597 |
. The presence of a Range header in an unconditional GET modifies |
5598 |
what is returned if the GET is otherwise successful. In other |
5599 |
words, the response carries a status code of 206 (Partial content) |
5600 |
instead of 200 (OK). |
5601 |
. The presence of a Range header in a conditional GET (a request |
5602 |
using one or both of If-Modified-Since and If-Invalid, or one or |
5603 |
both of If-Unmodified-Since and If-Valid) modifies what is returned |
5604 |
if the GET is otherwise successful and the condition is true. It |
5605 |
does not affect the 304 (Not Modified) response returned if the |
5606 |
conditional is false. |
5607 |
In some cases, it may be more appropriate to use the Range-If header |
5608 |
(see section 10.104) instead of the Range header. |
5609 |
|
5610 |
|
5611 |
10.34 Referer |
5612 |
The Referer(sic) request-header field allows the client to specify, for |
5613 |
the server's benefit, the address (URI) of the resource from which the |
5614 |
Request-URI was obtained. This allows a server to generate lists of |
5615 |
back-links to resources for interest, logging, optimized caching, etc. |
5616 |
It also allows obsolete or mistyped links to be traced for maintenance. |
5617 |
The Referer field MUST not be sent if the Request-URI was obtained from |
5618 |
a source that does not have its own URI, such as input from the user |
5619 |
keyboard. |
5620 |
|
5621 |
Referer = "Referer" ":" ( absoluteURI | relativeURI ) |
5622 |
|
5623 |
|
5624 |
|
5625 |
Example: |
5626 |
|
5627 |
Referer: http://www.w3.org/hypertext/DataSources/Overview.html |
5628 |
|
5629 |
|
5630 |
|
5631 |
If a partial URI is given, it SHOULD be interpreted relative to the |
5632 |
Request-URI. The URI MUST not include a fragment. |
5633 |
|
5634 |
Note: Because the source of a link may be private information or |
5635 |
may reveal an otherwise private information source, it is |
5636 |
strongly recommended that the user be able to select whether or |
5637 |
not the Referer field is sent. For example, a browser client |
5638 |
could have a toggle switch for browsing openly/anonymously, |
5639 |
which would respectively enable/disable the sending of Referer |
5640 |
and From information. |
5641 |
|
5642 |
|
5643 |
|
5644 |
|
5645 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 94] |
5646 |
|
5647 |
|
5648 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5649 |
|
5650 |
|
5651 |
10.36 Retry-After |
5652 |
The Retry-After response-header field can be used with a 503 (service |
5653 |
unavailable) response to indicate how long the service is expected to be |
5654 |
unavailable to the requesting client. The value of this field can be |
5655 |
either an HTTP-date or an integer number of seconds (in decimal) after |
5656 |
the time of the response. |
5657 |
|
5658 |
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
5659 |
|
5660 |
|
5661 |
|
5662 |
Two examples of its use are |
5663 |
|
5664 |
Retry-After: Wed, 14 Dec 1994 18:22:54 GMT |
5665 |
Retry-After: 120 |
5666 |
|
5667 |
|
5668 |
|
5669 |
In the latter example, the delay is 2 minutes. |
5670 |
|
5671 |
|
5672 |
10.37 Server |
5673 |
The Server response-header field contains information about the software |
5674 |
used by the origin server to handle the request. The field can contain |
5675 |
multiple product tokens (Section 3.8) and comments identifying the |
5676 |
|
5677 |
server and any significant subproducts. By convention, the product |
5678 |
tokens are listed in order of their significance for identifying the |
5679 |
application. |
5680 |
|
5681 |
Server = "Server" ":" 1*( product | comment ) |
5682 |
|
5683 |
|
5684 |
|
5685 |
Example: |
5686 |
|
5687 |
Server: CERN/3.0 libwww/2.17 |
5688 |
|
5689 |
|
5690 |
|
5691 |
If the response is being forwarded through a proxy, the proxy |
5692 |
application MUST not add its data to the product list. Instead, it |
5693 |
SHOULD include a Via field (as described in Section 10.20). |
5694 |
|
5695 |
|
5696 |
Note: Revealing the specific software version of the server may |
5697 |
allow the server machine to become more vulnerable to attacks |
5698 |
against software that is known to contain security holes. Server |
5699 |
implementers are encouraged to make this field a configurable |
5700 |
option. |
5701 |
|
5702 |
|
5703 |
10.38 Title |
5704 |
The Title entity-header field indicates the title of the entity |
5705 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 95] |
5706 |
|
5707 |
|
5708 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5709 |
|
5710 |
|
5711 |
Title = "Title" ":" *TEXT |
5712 |
|
5713 |
|
5714 |
|
5715 |
An example of the field is |
5716 |
|
5717 |
Title: Hypertext Transfer Protocol -- HTTP/1.1 |
5718 |
|
5719 |
|
5720 |
|
5721 |
This field is isomorphic with the <TITLE> element in HTML [5]. |
5722 |
|
5723 |
|
5724 |
|
5725 |
10.39 Transfer Encoding |
5726 |
The Transfer-Encoding general-header field indicates what (if any) type |
5727 |
of transformation has been applied to the message body in order to |
5728 |
safely transfer it between the sender and the recipient. This differs |
5729 |
from the Content-Encoding in that the transfer coding is a property of |
5730 |
the message, not of the original resource. |
5731 |
|
5732 |
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding |
5733 |
|
5734 |
|
5735 |
|
5736 |
Transfer codings are defined in Section 3.6. An example is: |
5737 |
|
5738 |
|
5739 |
Transfer-Encoding: chunked |
5740 |
|
5741 |
|
5742 |
|
5743 |
Many older HTTP/1.0 applications do not understand the Transfer-Encoding |
5744 |
header. |
5745 |
|
5746 |
|
5747 |
|
5748 |
|
5749 |
10.41 Upgrade |
5750 |
The Upgrade general-header allows the client to specify what additional |
5751 |
communication protocols it supports and would like to use if the server |
5752 |
finds it appropriate to switch protocols. The server MUST use the |
5753 |
Upgrade header field within a 101 (switching protocols) response to |
5754 |
indicate which protocol(s) are being switched. |
5755 |
|
5756 |
Upgrade = "Upgrade" ":" 1#product |
5757 |
|
5758 |
|
5759 |
|
5760 |
For example, |
5761 |
|
5762 |
|
5763 |
|
5764 |
|
5765 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 96] |
5766 |
|
5767 |
|
5768 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5769 |
|
5770 |
|
5771 |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
5772 |
|
5773 |
|
5774 |
|
5775 |
The Upgrade header field is intended to provide a simple mechanism for |
5776 |
transition from HTTP/1.1 to some other, incompatible protocol. It does |
5777 |
so by allowing the client to advertise its desire to use another |
5778 |
protocol, such as a later version of HTTP with a higher major version |
5779 |
number, even though the current request has been made using HTTP/1.1. |
5780 |
This eases the difficult transition between incompatible protocols by |
5781 |
allowing the client to initiate a request in the more commonly supported |
5782 |
protocol while indicating to the server that it would like to use a |
5783 |
_better_ protocol if available (where _better_ is determined by the |
5784 |
server, possibly according to the nature of the method and/or resource |
5785 |
being requested). |
5786 |
|
5787 |
The Upgrade header field only applies to switching application-layer |
5788 |
protocols upon the existing transport-layer connection. Upgrade cannot |
5789 |
be used to insist on a protocol change; its acceptance and use by the |
5790 |
server is optional. The capabilities and nature of the application- |
5791 |
layer communication after the protocol change is entirely dependent upon |
5792 |
the new protocol chosen, although the first action after changing the |
5793 |
protocol MUST be a response to the initial HTTP request containing the |
5794 |
Upgrade header field. |
5795 |
|
5796 |
The Upgrade header field only applies to the immediate connection. |
5797 |
Therefore, the _upgrade_ keyword MUST be supplied within a Connection |
5798 |
header field (Section 10.8) whenever Upgrade is present in an HTTP/1.1 |
5799 |
message. |
5800 |
|
5801 |
The Upgrade header field cannot be used to indicate a switch to a |
5802 |
protocol on a different connection. For that purpose, it is more |
5803 |
appropriate to use a 301, 302, 303, or 305 redirection response. |
5804 |
|
5805 |
This specification only defines the protocol name _HTTP_ for use by the |
5806 |
family of Hypertext Transfer Protocols, as defined by the HTTP version |
5807 |
rules of Section 3.1 and future updates to this specification. Any |
5808 |
token can be used as a protocol name; however, it will only be useful if |
5809 |
both the client and server associate the name with the same protocol. |
5810 |
|
5811 |
|
5812 |
10.43 User-Agent |
5813 |
The User-Agent request-header field contains information about the user |
5814 |
agent originating the request. This is for statistical purposes, the |
5815 |
tracing of protocol violations, and automated recognition of user agents |
5816 |
for the sake of tailoring responses to avoid particular user agent |
5817 |
limitations. Although it is not required, user agents SHOULD include |
5818 |
this field with requests. The field can contain multiple product tokens |
5819 |
(Section 3.8) and comments identifying the agent and any subproducts |
5820 |
|
5821 |
which form a significant part of the user agent. By convention, the |
5822 |
product tokens are listed in order of their significance for identifying |
5823 |
the application. |
5824 |
|
5825 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 97] |
5826 |
|
5827 |
|
5828 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5829 |
|
5830 |
|
5831 |
User-Agent = "User-Agent" ":" 1*( product | comment ) |
5832 |
|
5833 |
|
5834 |
|
5835 |
Example: |
5836 |
|
5837 |
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
5838 |
|
5839 |
|
5840 |
|
5841 |
|
5842 |
10.44 WWW-Authenticate |
5843 |
The WWW-Authenticate response-header field MUST be included in 401 |
5844 |
(unauthorized) response messages. The field value consists of at least |
5845 |
one that indicates the authentication scheme(s) and parameters |
5846 |
applicable to the Request-URI. |
5847 |
|
5848 |
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |
5849 |
|
5850 |
|
5851 |
|
5852 |
The HTTP access authentication process is described in Section 11. User |
5853 |
|
5854 |
agents MUST take special care in parsing the WWW-Authenticate field |
5855 |
value if it contains more than one challenge, or if more than one WWW- |
5856 |
Authenticate challenge header field is provided, since the contents of a challenge |
5857 |
may itself contain a comma-separated list of authentication parameters. |
5858 |
|
5859 |
|
5860 |
10.45 Max-Forwards |
5861 |
[JG17]The Max-Forwards general-header field may be used with the TRACE |
5862 |
method (Section 8.12) to limit the number of times that a proxy or |
5863 |
|
5864 |
gateway can forward the request to the next inbound server. This can be |
5865 |
useful when the client is attempting to trace a request chain which |
5866 |
appears to be failing or looping in mid-chain. |
5867 |
|
5868 |
Max-Forwards = "Max-Forwards" ":" 1*DIGIT |
5869 |
|
5870 |
|
5871 |
|
5872 |
The Max-Forwards value is a decimal integer indicating the remaining |
5873 |
number of times this request message may be forwarded. |
5874 |
|
5875 |
Each proxy or gateway recipient of a TRACE request containing a Max- |
5876 |
Forwards header field SHOULD check and update its value prior to |
5877 |
forwarding the request. If the received value is zero (0), the |
5878 |
recipient SHOULD NOT forward the request; instead, it SHOULD respond as |
5879 |
the final recipient with a 200 response containing the received request |
5880 |
message as the response entity body (as described in Section 8.12). If |
5881 |
the received Max-Forwards value is greater than zero, then the forwarded |
5882 |
message SHOULD contain an updated Max-Forwards field with a value |
5883 |
decremented by one (1). |
5884 |
|
5885 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 98] |
5886 |
|
5887 |
|
5888 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5889 |
|
5890 |
|
5891 |
The Max-Forwards header field SHOULD be ignored for all other methods |
5892 |
defined by this specification and for any extension methods for which it |
5893 |
is not explicitly referred to as part of that method definition. |
5894 |
|
5895 |
|
5896 |
10.46 Age |
5897 |
Caches transmit age values using: |
5898 |
|
5899 |
Age = "Age" ":" age-value |
5900 |
|
5901 |
age-value = delta-seconds |
5902 |
|
5903 |
|
5904 |
|
5905 |
Age values are non-negative decimal integers, representing time in |
5906 |
seconds. |
5907 |
|
5908 |
If a cache receives a value larger than the largest positive integer it |
5909 |
can represent, or if any of its age calculations overflows, it MUST NOT |
5910 |
transmit an Age header. Otherwise, HTTP/1.1 caches MUST send an Age |
5911 |
header in every response. Caches SHOULD use a representation with at |
5912 |
least 31 bits of range. |
5913 |
|
5914 |
|
5915 |
10.47 CVal |
5916 |
The CVal header is used to transmit opaque cache validators in HTTP/1.1 |
5917 |
responses. |
5918 |
|
5919 |
CVal = "CVal" ":" cval-info |
5920 |
cval-info = opaque-validator [ ";" variant-id ] |
5921 |
|
5922 |
|
5923 |
|
5924 |
Examples: |
5925 |
|
5926 |
CVal: "xyzzy" |
5927 |
CVal: "xyzzy"/W |
5928 |
CVal: "xyzzy";3 |
5929 |
CVal: "xyzzy"/W;3 |
5930 |
CVal: "" |
5931 |
|
5932 |
|
5933 |
|
5934 |
Note that the variant-id is not part of the opaque validator. |
5935 |
The CVal field is used to transmit a variant-id simply as a |
5936 |
matter of compact representation of responses. |
5937 |
|
5938 |
TBS: does the protocol allow the combination of a null validator and a |
5939 |
variant-ID? |
5940 |
|
5941 |
|
5942 |
10.48 If-Invalid |
5943 |
The If-Invalid request-header field is used with a method to make it |
5944 |
conditional. A client that has a cache entry for the relevant entity |
5945 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 99] |
5946 |
|
5947 |
|
5948 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
5949 |
|
5950 |
|
5951 |
supplies the associated validator using the If-Invalid header; if this |
5952 |
validator matches the server's current validator for the entity, the |
5953 |
server SHOULD return a 304 (Not modified) response without any Entity- |
5954 |
Body. |
5955 |
|
5956 |
If the validators do not match, the server should treat the request as |
5957 |
if the If-Invalid header was not present. |
5958 |
|
5959 |
See section 13.3.3 for rules on how to determine if two validators |
5960 |
match. |
5961 |
|
5962 |
If the If-Invalid header is used to make a conditional request on |
5963 |
varying resource, it may be used to pass a set of validators. This is |
5964 |
done using the variant-set mechanism if the client has variant IDs for |
5965 |
the corresponding cache entries (see sections 13.8.3 and 3.16), or the |
5966 |
validator-set mechanism if the client has no variant IDs (see sections |
5967 |
13.8.4 and 3.15). |
5968 |
|
5969 |
If-Invalid = "If-Invalid" ":" if-invalid-rhs |
5970 |
if-invalid-rhs = variant-set | validator-set |
5971 |
|
5972 |
|
5973 |
|
5974 |
Examples of single-entity form: |
5975 |
|
5976 |
If-Invalid: "xyzzy" |
5977 |
If-Invalid: "xyzzy"/W |
5978 |
|
5979 |
|
5980 |
|
5981 |
Examples of multiple-entity form: |
5982 |
|
5983 |
If-Invalid: "xyzzy";4 |
5984 |
If-Invalid: "xyzzy";3, "r2d2xxxx";5, "c3piozzzz";7 |
5985 |
If-Invalid: "xyzzy"/W;3, "r2d2xxxx"/W;5, "c3piozzzz"/W;7 |
5986 |
If-Invalid: "xyzzy", "r2d2xxxx", "c3piozzzz" |
5987 |
|
5988 |
|
5989 |
|
5990 |
If the request would, without the If-Invalid header, result in anything |
5991 |
other than a 2xx status, then the If-Invalid header is ignored. |
5992 |
|
5993 |
The purpose of this feature is to allow efficient updates of cached |
5994 |
information with a minimum amount of transaction overhead. |
5995 |
|
5996 |
|
5997 |
10.49 If-Valid |
5998 |
The If-Valid request-header field is used with a method to make it |
5999 |
conditional. A client that has a cache entry for the relevant entity |
6000 |
supplies the associated validator using the If-Valid header; if this |
6001 |
validator matches the server's current validator for the entity, the |
6002 |
server SHOULD perform the requested operation as if the If-Valid header |
6003 |
were not present. |
6004 |
|
6005 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 100] |
6006 |
|
6007 |
|
6008 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6009 |
|
6010 |
|
6011 |
If the validators do not match, the server MUST NOT perform the |
6012 |
requested operation, and MUST return a 412 (Precondition failed) |
6013 |
response with no Entity-Body. This behavior is most useful when the |
6014 |
client wants to prevent an updating method, such as PUT or POST, from |
6015 |
modifying a resource whose value has changed since the client last |
6016 |
checked it. |
6017 |
|
6018 |
When the If-Valid header is used, the server should use the strong |
6019 |
comparison function (see section 3.13) to compare validators. |
6020 |
|
6021 |
If the If-Valid header is used to make a conditional request on varying |
6022 |
resource, it may be used to pass a set of validators. This is done using |
6023 |
the variant-set mechanism if the client has variant IDs for the |
6024 |
corresponding cache entries (see sections 13.8.3 and 3.16), or the |
6025 |
validator-set mechanism if the client has no variant IDs (see sections |
6026 |
13.8.4 and 3.15). |
6027 |
|
6028 |
If-Valid = "If-Valid" ":" if-valid-rhs |
6029 |
if-valid-rhs = validator-set | variant-set |
6030 |
|
6031 |
|
6032 |
|
6033 |
An updating request (e.g., a PUT or POST) on a multi-entity resource |
6034 |
should include only one variant-set-item, the one associated with the |
6035 |
particular variant whose value is being conditionally updated. |
6036 |
|
6037 |
Examples of single-entity form: |
6038 |
|
6039 |
- If-Valid: "xyzzy" |
6040 |
- If-Valid: "xyzzy"/W |
6041 |
|
6042 |
|
6043 |
|
6044 |
Examples of multiple-entity form: |
6045 |
|
6046 |
- If-Valid: "xyzzy";4 |
6047 |
- If-Valid: "xyzzy";3, "r2d2xxxx";5, "c3piozzzz";7 |
6048 |
- If-Valid: "xyzzy", "r2d2xxxx", "c3piozzzz" |
6049 |
- If-Valid: "xyzzy"/W;3, "r2d2xxxx"/W;5, "c3piozzzz"/W;7 |
6050 |
|
6051 |
|
6052 |
|
6053 |
If the request would, without the If-Valid header, result in anything |
6054 |
other than a 2xx status, then the If-Valid header is ignored. |
6055 |
|
6056 |
The purpose of this feature is to allow efficient updates of cached |
6057 |
information with a minimum amount of transaction overhead. It is also |
6058 |
used, on updating requests, to prevent inadvertent modification of the |
6059 |
wrong instance of a resource. |
6060 |
|
6061 |
|
6062 |
10.50 If-Unmodified-Since |
6063 |
The If-Unmodified-Since request-header field is used with a method to |
6064 |
make it conditional. If the requested resource has not been modified |
6065 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 101] |
6066 |
|
6067 |
|
6068 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6069 |
|
6070 |
|
6071 |
since the time specified in this field, the server should perform the |
6072 |
requested operation as if the If-Unmodified-Since header were not |
6073 |
present. |
6074 |
|
6075 |
If the requested resource has been modified since the specified time, |
6076 |
the server MUST NOT perform the requested operation, and MUST return a |
6077 |
412 (Precondition failed) response with no Entity-Body. |
6078 |
|
6079 |
|
6080 |
|
6081 |
|
6082 |
|
6083 |
An example of the field is: |
6084 |
|
6085 |
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
6086 |
|
6087 |
If the request normally (i.e., without the If-Unmodified-Since header) |
6088 |
would result in anything other than a 2xx status, the If-Unmodified- |
6089 |
Since header should be ignored. |
6090 |
|
6091 |
If the specified date is invalid, the header is ignored. |
6092 |
|
6093 |
|
6094 |
10.51 Warning If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date |
6095 |
Warning headers are sent with responses using: |
6096 |
|
6097 |
Warning = "Warning" ":" warn-code SP warn-agent SP warn-text |
6098 |
[SP language-tag [SP charset]] |
6099 |
warn-code = 2DIGIT |
6100 |
warn-agent = ( host [ ":" port ] ) | pseudonym |
6101 |
; the name or pseudonym of the server adding |
6102 |
; the Warning header, for use in debugging |
6103 |
warn-text = quoted-string |
6104 |
|
6105 |
|
6106 |
|
6107 |
A response may carry more than one Warning header. |
6108 |
|
6109 |
The warn-text should be in a natural language and character set that is |
6110 |
most likely to be intelligible to the human user receiving the response. |
6111 |
This decision may be based on any available knowledge, such as the |
6112 |
location of the cache or user, the Accept-Language field in a request, |
6113 |
the Content-Language field in a response, etc. The default language is |
6114 |
English and the default character set is ISO-8599-1. |
6115 |
|
6116 |
Any server or cache may add Warning headers to a response. New Warning |
6117 |
headers should be added after any existing Warning headers. A cache MUST |
6118 |
NOT delete any Warning header that it received with a response. However, |
6119 |
if a cache successfully validates a cache entry, it SHOULD remove any |
6120 |
Warning headers previously attached to that entry. It MUST then add any |
6121 |
Warning headers received in the validating response. In other words, |
6122 |
Warning headers are those that would be attached to the most recent |
6123 |
relevant response. |
6124 |
|
6125 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 102] |
6126 |
|
6127 |
|
6128 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6129 |
|
6130 |
|
6131 |
This needs clarification. Someplace else in the specification, we need |
6132 |
to make a clear distinction between headers that are stored with a cache |
6133 |
entry and those that aren't, and we have to define carefully what |
6134 |
headers are simply deleted when a cache entry is updated. Section 13.7.3 |
6135 |
already talks about combining headers, but doesn't provide a way to |
6136 |
remove, say, a _Response is stale_ Warning after a fresh response is |
6137 |
received. |
6138 |
|
6139 |
When multiple Warning headers are attached to a response, the user agent |
6140 |
SHOULD display as many of them as possible, in the order that they |
6141 |
appear in the response. If it is not possible to display all of the |
6142 |
warnings, the user agent should follow these heuristics: |
6143 |
|
6144 |
. Warnings that appear early in the response take priority over those |
6145 |
appearing later in the response. |
6146 |
. Warnings in the user's preferred language and character set take |
6147 |
priority over warnings in other languages or character sets but |
6148 |
with identical warn-codes and warn-agents. |
6149 |
. TBS |
6150 |
This is a list of the currently-defined warn-codes, each with a |
6151 |
recommended warn-text in English, and a description of its meaning. |
6152 |
|
6153 |
10 _Response is stale_ |
6154 |
MUST be included whenever the returned response is stale. A cache may |
6155 |
add this warning to any response, but may never remove it until the |
6156 |
response is known to be fresh. |
6157 |
11 _Revalidation failed_ |
6158 |
MUST be included if a cache returns a stale response because an |
6159 |
attempt to revalidate the response failed, due to an inability to |
6160 |
reach the server. A cache may add this warning to any response, but |
6161 |
may never remove it until the response is successfully revalidated. |
6162 |
13 _Disconnected operation_ |
6163 |
SHOULD be included if the cache is intentionally disconnected from |
6164 |
the rest of the network for a period of time. |
6165 |
99 Miscellaneous warning |
6166 |
The warning text may include arbitrary information to be presented to |
6167 |
a human user, or logged. A system receiving this warning MUST NOT |
6168 |
take any automated action. |
6169 |
TBS XXX anything else? |
6170 |
|
6171 |
|
6172 |
10.52 Vary |
6173 |
The Vary response-header field is used by an origin server to signal |
6174 |
that the resource identified by the current request is a varying |
6175 |
resource. A varying resource has multiple entities associated with it, |
6176 |
all of which are representations of the content of the resource. If a |
6177 |
GET or HEAD request on a varying resource is received, the origin server |
6178 |
will select one of the associated entities as the entity best matching |
6179 |
the request. Selection of this entity is based on the contents of |
6180 |
particular header fields in the request message, or on other information |
6181 |
pertaining to the request, like the network address of the sending |
6182 |
client. |
6183 |
|
6184 |
|
6185 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 103] |
6186 |
|
6187 |
|
6188 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6189 |
|
6190 |
|
6191 |
If a resource is varying, this has an important effect on cache |
6192 |
management, particularly for caching proxies which service a diverse set |
6193 |
of user agents. All 200 (OK) responses from varying resources MUST |
6194 |
contain at least one Vary header or Alternates header (Section 10.53) to |
6195 |
signal variance. |
6196 |
|
6197 |
If no Vary headers and no Alternates headers are present in a 200 (OK) |
6198 |
response, then caches may assume, as long as the response is fresh, that |
6199 |
the resource in question is not varying, and has only one associated |
6200 |
entity. Note however that this entity can still change through time, as |
6201 |
possibly indicated by a Cache-Control response header (section 10.cc). |
6202 |
|
6203 |
After selection of the entity best matching the current request, the |
6204 |
origin server will usually generate a 200 (OK) response, but it can also |
6205 |
generate other responses like 206 (Partial Content) or 304 (Not |
6206 |
modified) if headers which modify the semantics of the request, like |
6207 |
Range (Section 10.ran) or If-Valid (Section 10.ifva), are present. An |
6208 |
origin server need not be capable of selecting an entity for every |
6209 |
possible incoming request on a varying resource; it can choose to |
6210 |
generate a 3xx (redirection) or 4xx (client error) type response for |
6211 |
some requests. |
6212 |
|
6213 |
In a request message on a varying resource, the selecting request |
6214 |
headers are those request headers whose contents were used by the origin |
6215 |
server to select the entity best matching the request. The Vary header |
6216 |
field specifies the selecting request headers and any other selection |
6217 |
parameters that were used by the origin server. |
6218 |
|
6219 |
Vary = "Vary" ":" 1#selection-parameter |
6220 |
|
6221 |
selection-parameter = request-header-name |
6222 |
| "{accept-headers}" |
6223 |
| "{other}" |
6224 |
| "{" extension-parameter "}" |
6225 |
|
6226 |
request-header-name = field-name |
6227 |
|
6228 |
extension-parameter = token |
6229 |
|
6230 |
|
6231 |
|
6232 |
The presence of a request-header-name signals that the request-header |
6233 |
field with this name is selecting. Note that the name need not belong |
6234 |
to a request-header field defined in this specification, and that header |
6235 |
names are case-insensitive. The presence of the _{accept-headers}_ |
6236 |
parameter signals that all request headers whose names start with |
6237 |
_accept_ are selecting. |
6238 |
|
6239 |
The inclusion of the _{other}_ parameter in a Vary field signals that |
6240 |
parameters other than the contents of request headers, for example the |
6241 |
network address of the sending party, play a role in the selection of |
6242 |
the response. |
6243 |
|
6244 |
|
6245 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 104] |
6246 |
|
6247 |
|
6248 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6249 |
|
6250 |
|
6251 |
Note: This specification allows the origin server to express |
6252 |
that other parameters were used, but does not allow the origin |
6253 |
server to specify the exact nature of these parameters. This is |
6254 |
left to future extensions. |
6255 |
|
6256 |
If an extension-parameter unknown to the cache is present in a Vary |
6257 |
header, the cache MUST treat it as the _{other}_ parameter. If multiple |
6258 |
Vary and Alternates header fields are present in a response, these MUST |
6259 |
be combined to give all selecting parameters. |
6260 |
|
6261 |
The field name _Host_ MUST never be included into a Vary header; clients |
6262 |
MUST ignore it if it is present. The names of fields which change the |
6263 |
semantics of a GET request, like _Range_ and _If-Valid_ MUST also never |
6264 |
be included, and MUST be ignored when present. |
6265 |
|
6266 |
Servers which use access authentication are not obliged to send _Vary: |
6267 |
Authorization_ headers in responses. It MUST be assumed that requests |
6268 |
on authenticated resources can always produce different responses for |
6269 |
different users. Note that servers can signal the absence of |
6270 |
authentication by including a _Cache-Control: public_ header in the |
6271 |
response. |
6272 |
|
6273 |
A cache MAY store and refresh 200 (OK) responses from a varying resource |
6274 |
according to the rules in Section 13.7.2. The partial entities in 206 |
6275 |
(Partial Content) responses from varying resources MAY also be used by |
6276 |
the cache. |
6277 |
|
6278 |
When getting a request on a varying resource, a cache can only return a |
6279 |
cached 200 (OK) response to one of its clients in two particular cases. |
6280 |
|
6281 |
First, if a cache gets a request on a varying resource for which it has |
6282 |
cached one or more responses with Vary or Alternates headers, it can |
6283 |
relay that request towards the origin server, adding an If-Invalid |
6284 |
header listing the cval-info values in the CVal headers (Section 10.47) |
6285 |
of the cached responses. If it then gets back a 304 (Not Modified) |
6286 |
response with the cval-info of a cached 200 (OK) response in its CVal |
6287 |
header, it can return this cached 200 (OK) response to its client, after |
6288 |
merging in any of the 304 response headers as specified in Section |
6289 |
13.7.2. |
6290 |
|
6291 |
Second, if a cache gets a request on a varying resource, it can return |
6292 |
to its client a cached, fresh 200 (OK) response which has Vary or |
6293 |
Alternates headers, provided that |
6294 |
|
6295 |
|
6296 |
. the Vary and Alternates headers of this fresh response specify that |
6297 |
only request header fields are selecting parameters, |
6298 |
|
6299 |
. the specified selecting request header fields of the current |
6300 |
request match the specified selecting request header fields of a |
6301 |
previous request on the resource relayed towards the origin server, |
6302 |
|
6303 |
|
6304 |
|
6305 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 105] |
6306 |
|
6307 |
|
6308 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6309 |
|
6310 |
|
6311 |
. this previous request got a 200 (OK) or 304 (Not Modified) response |
6312 |
which had the same cval-info value in its CVal header as the |
6313 |
cached, fresh 200 (OK) response. |
6314 |
Two sequences of selecting request header fields match if and only if |
6315 |
the first sequence can be transformed into the second sequence by only |
6316 |
adding or removing whitespace at places in fields where this is allowed |
6317 |
according to the syntax rules in this specification. |
6318 |
|
6319 |
If a cached 200 (OK) response MAY be returned to a request on a varying |
6320 |
resource which includes a Range request header, then a cache MAY also |
6321 |
use this 200 (OK) response to construct and return a 206 (Partial |
6322 |
Content) response with the requested range. |
6323 |
|
6324 |
Note: Implementation of support for the second case above is |
6325 |
mainly interesting in user agent caches, as a user agent cache |
6326 |
will generally have an easy way of determining whether the |
6327 |
sequence of request header fields of the current request equals |
6328 |
the sequence sent in an earlier request on the same resource. |
6329 |
Proxy caches supporting the second case would have to record |
6330 |
diverse sequences of request header fields previously relayed; |
6331 |
the implementation effort associated with this may not be |
6332 |
balanced by a sufficient payoff in traffic savings. A planned |
6333 |
specification of a content negotiation mechanism will define |
6334 |
additional cases in which proxy caches can return a cached 200 |
6335 |
(OK) response without contacting the origin server. The |
6336 |
implementation effort associated with support for these |
6337 |
additional cases is expected to have a much better cost/benefit |
6338 |
ratio. |
6339 |
|
6340 |
|
6341 |
10.53 Alternates |
6342 |
The Alternates response-header field is used by origin servers to signal |
6343 |
that the resource identified by the current request has the capability |
6344 |
to send different responses depending on the accept headers in the |
6345 |
request message. This has an important effect on cache management, |
6346 |
particularly for caching proxies which service a diverse set of user |
6347 |
agents. This effect is covered in Section 10.v. |
6348 |
|
6349 |
Alternates = "Alternates" ":" opaque-field |
6350 |
|
6351 |
opaque-field = field-value |
6352 |
|
6353 |
|
6354 |
|
6355 |
The Alternates header is included into HTTP/1.1 to make HTTP/1.1 caches |
6356 |
compatible with a planned content negotiation mechanism. HTTP/1.1 |
6357 |
allows a future content negotiation standard to define the format of the |
6358 |
Alternates header field-value, as long as the defined format satisfies |
6359 |
the general rules in Section 4.2. |
6360 |
|
6361 |
To ensure compatibility with future experimental or standardized |
6362 |
software, caching HTTP/1.1 clients MUST treat all Alternates headers in |
6363 |
a response as synonymous to the following Vary header: |
6364 |
|
6365 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 106] |
6366 |
|
6367 |
|
6368 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6369 |
|
6370 |
|
6371 |
Vary: {accept-headers} |
6372 |
|
6373 |
and follow the caching rules associated with the presence of this Vary |
6374 |
header, as covered in Section 10.v. HTTP/1.1 allows origin servers to |
6375 |
send Alternates headers under experimental conditions. |
6376 |
|
6377 |
|
6378 |
10.54 SLUSHY: Accept-Ranges |
6379 |
In some cases, a client may want to know if the server accepts range |
6380 |
requests using a certain range unit. The server may indicate its |
6381 |
acceptance of range requests for a resource by providing this header in |
6382 |
a response for that resource: |
6383 |
|
6384 |
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges |
6385 |
|
6386 |
acceptable-ranges = 1#range-unit | "none" |
6387 |
|
6388 |
Origin servers that accept byte-range requests MAY send |
6389 |
|
6390 |
Accept-Ranges: bytes |
6391 |
|
6392 |
but are not required to do so. Clients MAY generate byte-range requests |
6393 |
without having received this header for the specific resource involved, |
6394 |
but the server MAY ignore such requests. |
6395 |
|
6396 |
Should this say that the server SHOULD send "Accept-Ranges: |
6397 |
bytes", or is MAY good enough |
6398 |
|
6399 |
Origin servers that do not accept any kind of range request for a |
6400 |
specific resource MAY send |
6401 |
|
6402 |
Accept-Ranges: none |
6403 |
|
6404 |
to advise the client not to attempt a range request. |
6405 |
|
6406 |
We're still not quite sure why this header is in the protocol. |
6407 |
We gather that Netscape uses it for something, but nobody from |
6408 |
Netscape has even tried to explain to me whether it is necessary |
6409 |
for anything. The only thing we can think of is that a client |
6410 |
would have to know in advance if a server accepted partial- |
6411 |
content PUTs (i.e., PUT+Content-Range), but we don't see any |
6412 |
indication that this is what Netscape wants. |
6413 |
|
6414 |
|
6415 |
|
6416 |
|
6417 |
10.55 SLUSHY: Range-If |
6418 |
If a client has a partial copy of an entity in its cache, and wished to |
6419 |
have an up-to-date copy of the entire entity in its cache, it could use |
6420 |
Range request header with a conditional GET (using either of both of If- |
6421 |
Unmodified-Since and If-Valid.) However, if the condition fails because |
6422 |
the entity has been modified, the client would then have to make a |
6423 |
second request to obtain the entire current entity body. |
6424 |
|
6425 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 107] |
6426 |
|
6427 |
|
6428 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6429 |
|
6430 |
|
6431 |
The Range-If header allows a client to ``short-circuit'' the second |
6432 |
request. Informally, its meaning is ``if the entity is unchanged, send |
6433 |
me the part(s) that I am missing; otherwise, send me the entire new |
6434 |
entity.'' |
6435 |
|
6436 |
Range-If: if-valid-rhs |
6437 |
|
6438 |
The Range-If header should only be used together with a Range header,and |
6439 |
must be ignored if the request does not include a Range header, or if |
6440 |
the server does not support the sub-range operation. |
6441 |
|
6442 |
If the validator given in the Range-If header matches the current |
6443 |
validator for the entity, then the server should provide the specified |
6444 |
sub-range of the entity using a 206 (Partial content) response. If the |
6445 |
validator does not match, then the server should return the entire |
6446 |
entity using a 200 (OK) response. |
6447 |
|
6448 |
This description may need slight modification to deal with(1) |
6449 |
the use of a last-modified date as a validator (but this |can |
6450 |
perhaps be hidden in the definition of if-valid-rhs), and|(2) |
6451 |
its application to multi-entity resources. |
6452 |
|
6453 |
|
6454 |
11. Access Authentication |
6455 |
HTTP provides a simple challenge-response authentication mechanism which |
6456 |
MAY be used by a server to challenge a client request and by a client to |
6457 |
provide authentication information. It uses an extensible, case- |
6458 |
insensitive token to identify the authentication scheme, followed by a |
6459 |
comma-separated list of attribute-value pairs which carry the parameters |
6460 |
necessary for achieving authentication via that scheme. |
6461 |
|
6462 |
auth-scheme = token |
6463 |
|
6464 |
|
6465 |
auth-param = token "=" quoted-string |
6466 |
|
6467 |
|
6468 |
|
6469 |
The 401 (unauthorized) response message is used by an origin server to |
6470 |
challenge the authorization of a user agent. This response MUST include |
6471 |
a WWW-Authenticate header field containing at least one challenge |
6472 |
applicable to the requested resource. |
6473 |
|
6474 |
challenge = auth-scheme 1*SP realm *( "," auth-param ) |
6475 |
|
6476 |
|
6477 |
realm = "realm" "=" realm-value |
6478 |
realm-value = quoted-string |
6479 |
|
6480 |
|
6481 |
|
6482 |
The realm attribute (case-insensitive) is required for all |
6483 |
authentication schemes which issue a challenge. The realm value (case- |
6484 |
sensitive), in combination with the canonical root URL of the server |
6485 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 108] |
6486 |
|
6487 |
|
6488 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6489 |
|
6490 |
|
6491 |
being accessed, defines the protection space. These realms allow the |
6492 |
protected resources on a server to be partitioned into a set of |
6493 |
protection spaces, each with its own authentication scheme and/or |
6494 |
authorization database. The realm value is a string, generally assigned |
6495 |
by the origin server, which may have additional semantics specific to |
6496 |
the authentication scheme. |
6497 |
|
6498 |
A user agent that wishes to authenticate itself with a server--usually, |
6499 |
but not necessarily, after receiving a 401 or 411 response--MAY do so by |
6500 |
including an Authorization header field with the request. The |
6501 |
Authorization field value consists of credentials containing the |
6502 |
authentication information of the user agent for the realm of the |
6503 |
resource being requested. |
6504 |
|
6505 |
credentials = basic-credentials |
6506 |
| auth-scheme *("," auth-param ) |
6507 |
|
6508 |
|
6509 |
|
6510 |
The domain over which credentials can be automatically applied by a user |
6511 |
agent is determined by the protection space. If a prior request has been |
6512 |
authorized, the same credentials MAY be reused for all other requests |
6513 |
within that protection space for a period of time determined by the |
6514 |
authentication scheme, parameters, and/or user preference. Unless |
6515 |
otherwise defined by the authentication scheme, a single protection |
6516 |
space cannot extend outside the scope of its server. |
6517 |
|
6518 |
If the server does not wish to accept the credentials sent with a |
6519 |
request, it SHOULD return a 401 (unauthorized) response. The response |
6520 |
MUST include a WWW-Authenticate header field containing the (possibly |
6521 |
new) challenge applicable to the requested resource and an entity |
6522 |
explaining the refusal. |
6523 |
|
6524 |
The HTTP protocol does not restrict applications to this simple |
6525 |
challenge-response mechanism for access authentication. Additional |
6526 |
mechanisms MAY be used, such as encryption at the transport level or via |
6527 |
message encapsulation, and with additional header fields specifying |
6528 |
authentication information. However, these additional mechanisms are not |
6529 |
defined by this specification. |
6530 |
|
6531 |
Proxies MUST be completely transparent regarding user agent |
6532 |
authentication. That is, they MUST forward the WWW-Authenticate and |
6533 |
Authorization headers untouched, and MUST not cache the response to a |
6534 |
request containing Authorization. |
6535 |
|
6536 |
HTTP/1.1 allows a client to pass authentication information to and from |
6537 |
a proxy via the Proxy-Authenticate and Proxy-Authorization headers. |
6538 |
|
6539 |
|
6540 |
11.1 Basic Authentication Scheme |
6541 |
The _basic_ authentication scheme is based on the model that the user |
6542 |
agent must authenticate itself with a user-ID and a password for each |
6543 |
realm. The realm value should be considered an opaque string which can |
6544 |
only be compared for equality with other realms on that server. The |
6545 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 109] |
6546 |
|
6547 |
|
6548 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6549 |
|
6550 |
|
6551 |
server will service the request only if it can validate the user-ID and |
6552 |
password for the protection space of the Request-URI. There are no |
6553 |
optional authentication parameters. |
6554 |
|
6555 |
Upon receipt of an unauthorized request for a URI within the protection |
6556 |
space, the server SHOULD respond with a challenge like the following: |
6557 |
|
6558 |
WWW-Authenticate: Basic realm="WallyWorld" |
6559 |
|
6560 |
|
6561 |
|
6562 |
where _WallyWorld_ is the string assigned by the server to identify the |
6563 |
protection space of the Request-URI. |
6564 |
|
6565 |
To receive authorization, the client sends the user-ID and password, |
6566 |
separated by a single colon (_:_) character, within a base64 [7] encoded |
6567 |
|
6568 |
string in the credentials. |
6569 |
|
6570 |
basic-credentials = "Basic" SP basic-cookie |
6571 |
|
6572 |
|
6573 |
basic-cookie = <base64 [7] encoding of userid-password, |
6574 |
|
6575 |
except not limited to 76 char/line> |
6576 |
|
6577 |
|
6578 |
userid-password = [ token ] ":" *TEXT |
6579 |
|
6580 |
|
6581 |
|
6582 |
If the user agent wishes to send the user-ID _Aladdin_ and password |
6583 |
_open sesame_, it would use the following header field: |
6584 |
|
6585 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
6586 |
|
6587 |
|
6588 |
|
6589 |
The basic authentication scheme is a non-secure method of filtering |
6590 |
unauthorized access to resources on an HTTP server. It is based on the |
6591 |
assumption that the connection between the client and the server can be |
6592 |
regarded as a trusted carrier. As this is not generally true on an open |
6593 |
network, the basic authentication scheme should be used accordingly. In |
6594 |
spite of this, clients SHOULD implement the scheme in order to |
6595 |
communicate with servers that use it. |
6596 |
|
6597 |
|
6598 |
11.2 Digest Authentication Scheme |
6599 |
The _digest_ authentication scheme is [currently described in an expired |
6600 |
Internet-Draft, and this description will have to be improved to |
6601 |
reference a new draft or include the old one]. |
6602 |
|
6603 |
|
6604 |
|
6605 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 110] |
6606 |
|
6607 |
|
6608 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6609 |
|
6610 |
|
6611 |
12. Content Negotiation |
6612 |
A varying resource has multiple entities associated with it, all of |
6613 |
which are representations of the content of the resource. Content |
6614 |
negotiation is the process of selecting the best representation when a |
6615 |
GET or HEAD request is made on the varying resource. HTTP/1.1 has |
6616 |
provisions for two kinds of content negotiation: opaque negotiation and |
6617 |
transparent negotiation. |
6618 |
|
6619 |
With opaque negotiation, the selection of the best representation is |
6620 |
done by an algorithm located at the origin server, and unknown to the |
6621 |
proxies and user agents involved. Selection is based on the contents of |
6622 |
particular header fields in the request message, or on other information |
6623 |
pertaining to the request, like the network address of the sending |
6624 |
client. A typical example of opaque negotiation would be the selection |
6625 |
of a text/html response in a particular language based on the contents |
6626 |
of the Accept-Language request header field. A disadvantage of opaque |
6627 |
negotiation is that the request headers may not always contain enough |
6628 |
information to allow for selection. If the Accept header |
6629 |
|
6630 |
Accept: text/*: q=0.3, text/html, */*: q=0.5 |
6631 |
|
6632 |
is sent in a request on a varying resource which has a video/mpeg and a |
6633 |
video/quicktime representation, the selection algorithm in the origin |
6634 |
server will either have to make a default choice, or return an error |
6635 |
response which allows the user to decide on further actions. |
6636 |
|
6637 |
With transparent negotiation, the selection of the best representation |
6638 |
is done by a distributed algorithm which can perform computation steps |
6639 |
in the origin server, in proxies, or in the user agent. Transparent |
6640 |
negotiation guarantees that, if the user agent supports the transparent |
6641 |
negotiation algorithm and is correctly configured, the request will |
6642 |
always correctly yield either the video/mpeg representation, the |
6643 |
video/quicktime representation, or an error message indicating that the |
6644 |
resource cannot be displayed by the user agent. |
6645 |
|
6646 |
|
6647 |
12.1 Negotiation facilities defined in this specification |
6648 |
This specification defines all protocol facilities for opaque |
6649 |
negotiation, but does not define the distributed algorithm for |
6650 |
transparent negotiation. This specification only defines the basic |
6651 |
facilities (Vary, Alternates, Accept) in the core protocol allowing |
6652 |
requests on transparently negotiated resources to be correctly handled |
6653 |
by HTTP/1.1 caches. All other information about transparent content |
6654 |
negotiation is found in a separate document[29]. |
6655 |
|
6656 |
If a varying resource is opaquely negotiated, successful responses to |
6657 |
requests on the resource will always include a Vary header. If a |
6658 |
varying resource is transparently negotiated, successful responses to |
6659 |
requests on the resource will always include an Alternates header. If a |
6660 |
successful response contains an Alternates header, it will also always |
6661 |
contain a Content-Location header. A future specification may allow a |
6662 |
combination of opaque and transparent negotiation that would lead to the |
6663 |
inclusion of both a Vary header and an Alternates header in a response. |
6664 |
|
6665 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 111] |
6666 |
|
6667 |
|
6668 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6669 |
|
6670 |
|
6671 |
. |
6672 |
|
6673 |
|
6674 |
13 Caching in HTTP |
6675 |
The World Wide Web is a distributed system, and so its performance can |
6676 |
be improved by the use of caches. These caches are typically placed at |
6677 |
proxies and in the clients themselves. The HTTP/1.1 protocol includes a |
6678 |
number of elements intended to make caching work as well as possible. |
6679 |
Because these elements are inextricable from other aspects of the |
6680 |
protocol, and because they interact with each other, it is useful to |
6681 |
describe the basic caching design of HTTP separately from the detailed |
6682 |
descriptions of methods, headers, response codes, etc. |
6683 |
|
6684 |
|
6685 |
13.1 Semantic Transparency |
6686 |
Ideally, an HTTP/1.1 cache would be _semantically transparent._ That is, |
6687 |
use of the cache would not affect either the clients or the servers in |
6688 |
any way except to improve performance. When a client makes a request via |
6689 |
a semantically transparent cache, it receives exactly the same entity |
6690 |
headers and entity body it would have received if it had made the same |
6691 |
request to the origin server, at the same time. |
6692 |
|
6693 |
In the real world, requirements for performance, availability, and |
6694 |
disconnected operation require us to relax the goal of semantic |
6695 |
transparency in many cases. The HTTP/1.1 protocol allows origin servers, |
6696 |
caches, and clients to explicitly reduce transparency when necessary. |
6697 |
However, because non-transparent operation may confuse non-expert users, |
6698 |
and may be incompatible with certain server applications (such as those |
6699 |
for ordering merchandise), the protocol requires that transparency may |
6700 |
not be relaxed |
6701 |
|
6702 |
. without an explicit protocol-level request (when relaxed by client |
6703 |
or origin server) |
6704 |
. without a means for warning the end user (when relaxed by cache or |
6705 |
client) |
6706 |
Therefore, the HTTP/1.1 protocol provides these important elements: |
6707 |
|
6708 |
1. Protocol features that provide full semantic transparency when this |
6709 |
is desired by all parties. |
6710 |
2. Protocol features that allow an origin server or end-user client to |
6711 |
explicitly request and control non-transparent operation. |
6712 |
3. Protocol features that allow a cache to attach warnings to |
6713 |
responses that do not preserve semantic transparency. |
6714 |
A basic principle is that it must be possible for the clients to detect |
6715 |
any potential breakdown of semantic transparency. |
6716 |
|
6717 |
Caching would be useless if it did not significantly improve performance |
6718 |
in many cases. The goal of caching in HTTP/1.1 is to eliminate the need |
6719 |
to send requests in many cases, and to eliminate the need to send full |
6720 |
responses in many other cases. The former reduces the number of network |
6721 |
round-trips required for many operations; we use an _expiration_ |
6722 |
mechanism for this purpose (see section 13.2). The latter reduces |
6723 |
network bandwidth requirements; we use a _validation_ mechanism for this |
6724 |
purpose (see section 13.3). |
6725 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 112] |
6726 |
|
6727 |
|
6728 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6729 |
|
6730 |
|
6731 |
The server, cache, or client implementer may be faced with design |
6732 |
decisions not explicitly discussed in this specification. If decision |
6733 |
may affect semantic transparency, the implementer ought to err on the |
6734 |
side of maintaining transparency unless a careful and complete analysis |
6735 |
shows significant benefits in breaking transparency. |
6736 |
|
6737 |
A note on terminology: we say that a resource is _cachable_ if a cache |
6738 |
is allowed to store a copy of this resource, when it arrives in a |
6739 |
response message, and then later use that copy to respond to a |
6740 |
subsequent request. Even if a resource is cachable, there may be |
6741 |
additional constraints on when and whether a cache can use a cached copy |
6742 |
of it. |
6743 |
|
6744 |
|
6745 |
13.2 Expiration Model |
6746 |
In order to describe the associated mechanisms, we introduce several |
6747 |
terms for describing responses returned by a cache in response to a |
6748 |
client's request: |
6749 |
|
6750 |
firsthand |
6751 |
A response is firsthand if it comes directly and without unnecessary |
6752 |
delay from the origin server, perhaps via one or more proxies. A |
6753 |
response is also firsthand if its validity has just been checked |
6754 |
directly with the origin server. |
6755 |
explicit expiration time |
6756 |
The time at which the origin server intends that an entity should no |
6757 |
longer be returned by a cache without further validation. |
6758 |
heuristic expiration time |
6759 |
An expiration time assigned by a cache when no explicit expiration |
6760 |
time is available. |
6761 |
age |
6762 |
The age of a response is the time since it was generated by, or |
6763 |
successfully validated with, the origin server. |
6764 |
freshness lifetime |
6765 |
The length of time between the generation of a response and its |
6766 |
expiration time. |
6767 |
fresh |
6768 |
A response is fresh if its age has not yet reached its freshness |
6769 |
lifetime. |
6770 |
stale |
6771 |
A response is stale if its age has passed its freshness lifetime. |
6772 |
|
6773 |
13.2.1 Server-Specified Expiration |
6774 |
HTTP caching works best when caches can entirely avoid making requests |
6775 |
to the origin server. The primary mechanism for avoiding requests is for |
6776 |
an origin server to provide an explicit expiration time in the future, |
6777 |
indicating that a response may be used to satisfy subsequent requests. |
6778 |
In other words, a cache can return a fresh response without first |
6779 |
contacting the server. |
6780 |
|
6781 |
Our expectation is that servers will assign future explicit expiration |
6782 |
times to responses in the belief that the entity is not likely to |
6783 |
change, in a semantically significant way, before the expiration time is |
6784 |
|
6785 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 113] |
6786 |
|
6787 |
|
6788 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6789 |
|
6790 |
|
6791 |
reached. This normally preserves semantic transparency, as long as the |
6792 |
server's expiration times are carefully chosen. |
6793 |
|
6794 |
If an origin server wishes to force a semantically transparent cache to |
6795 |
validate every request, it may assign an explicit expiration time in the |
6796 |
past. This means that the response is always stale, and so the cache |
6797 |
SHOULD validate it before using it for subsequent requests. (Note that a |
6798 |
firsthand response MUST always be returned to the requesting client, |
6799 |
independent of its expiration time, unless the connection to the client |
6800 |
is lost.) |
6801 |
|
6802 |
If an origin server wishes to force any HTTP/1.1 cache, no matter how it |
6803 |
is configured, to validate every request, it should use the _must- |
6804 |
revalidate_ Cache-Control directive (see section 10.8). |
6805 |
|
6806 |
Servers specify explicit expiration times using either the Expires |
6807 |
header, or the max-age directive of the Cache-Control header. |
6808 |
|
6809 |
|
6810 |
13.2.2 Limitations on the Effect of Expiration Times |
6811 |
An expiration time cannot be used to force a user agent to refresh its |
6812 |
display or reload a resource; its semantics apply only to caching |
6813 |
mechanisms, and such mechanisms need only check a resource's expiration |
6814 |
status when a new request for that resource is initiated. |
6815 |
|
6816 |
User agents often have history mechanisms, such as _Back_ buttons and |
6817 |
history lists, which can be used to redisplay an entity retrieved |
6818 |
earlier in a session. By default, an expiration time does not apply to |
6819 |
history mechanisms. If the entity is still in storage, a history |
6820 |
mechanism should display it even if the entity has expired, unless the |
6821 |
user has specifically configured the agent to refresh expired history |
6822 |
documents. |
6823 |
|
6824 |
|
6825 |
13.2.3 Heuristic Expiration |
6826 |
Since origin servers do not always provide explicit expiration times, |
6827 |
HTTP caches typically assign heuristic expiration times, employing |
6828 |
algorithms that use other header values (such as the Last-Modified time) |
6829 |
to estimate a plausible expiration time. The HTTP/1.1 specification does |
6830 |
not provide specific algorithms, but does impose worst-case constraints |
6831 |
on their results. Since heuristic expiration times may compromise |
6832 |
semantic transparency, they should be used cautiously, and we encourage |
6833 |
origin servers to provide explicit expiration times as much as possible. |
6834 |
|
6835 |
|
6836 |
13.2.4 Client-controlled Behavior |
6837 |
While the origin server (and to a lesser extent, intermediate caches) |
6838 |
are the primary source of expiration information, in some cases the |
6839 |
client may need to control a cache's decision about whether to return a |
6840 |
cached response without validating it. Clients do this using several |
6841 |
directives of the Cache-Control header. |
6842 |
|
6843 |
A client's request may specify the maximum age it is willing to accept |
6844 |
for an unvalidated response; specifying a value of zero forces the |
6845 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 114] |
6846 |
|
6847 |
|
6848 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6849 |
|
6850 |
|
6851 |
cache(s) to revalidate all responses. A client may also specify the |
6852 |
minimum time remaining before a response expires. Both of these options |
6853 |
increase constraints on the behavior of caches, and so cannot decrease |
6854 |
semantic transparency. |
6855 |
|
6856 |
A client may also specify that it will accept stale responses, up to |
6857 |
some maximum amount of staleness. This loosens the constraints on the |
6858 |
caches, and so may violate semantic transparency, but may be necessary |
6859 |
to support disconnected operation, or high availability in the face of |
6860 |
poor connectivity. |
6861 |
|
6862 |
|
6863 |
13.2.5 Exceptions to the Rules and Warnings |
6864 |
In some cases, the operator of a cache may choose to configure it to |
6865 |
return stale responses even when not requested by clients. This decision |
6866 |
not be made lightly, but may be necessary for reasons of availability or |
6867 |
performance, especially when the cache is poorly connected to the origin |
6868 |
server. Whenever a cache returns a stale response, it MUST mark it as |
6869 |
such (using a Warning header). This allows the client software to alert |
6870 |
the user that there may be a potential problem. |
6871 |
|
6872 |
It also allows the user to take steps to obtain a firsthand or fresh |
6873 |
response, if the user so desires. For this reason, a cache MUST NOT |
6874 |
return a stale response if the client explicitly requests a first-hand |
6875 |
or fresh one, unless it is impossible to comply. |
6876 |
|
6877 |
|
6878 |
13.2.6 Age Calculations |
6879 |
In order to know if a cached entry is fresh, a cache needs to know if |
6880 |
its age exceeds its freshness lifetime. We discuss how to calculate the |
6881 |
latter in section 13.2.7; this section describes how to calculate the |
6882 |
age of a response or cache entry. |
6883 |
|
6884 |
In this discussion, we use the term _now_ to mean _the current value of |
6885 |
the clock at the host performing the calculation._ All HTTP |
6886 |
implementations, but especially origin servers and caches, should use |
6887 |
NTP [RFC1305] or some similar protocol to synchronize their clocks to a |
6888 |
globally accurate time standard. |
6889 |
|
6890 |
Also note that HTTP/1.1 requires origin servers to send a Date header |
6891 |
with every response, giving the time at which the response was |
6892 |
generated. We use the term _date_value_ to denote a representation of |
6893 |
the value of the Date header, in a form appropriate for arithmetic |
6894 |
operations. |
6895 |
|
6896 |
HTTP/1.1 uses the _Age_ response header to help convey age information |
6897 |
between caches. The Age header value is the sender's estimate of the |
6898 |
amount of time since the response was generated at the origin server. In |
6899 |
the case of a cached response that has been revalidated with the origin |
6900 |
server, the Age value is based on the time of revalidation, not of the |
6901 |
original response. |
6902 |
|
6903 |
In essence, the Age value is the sum of the time that the response has |
6904 |
been resident in each of the caches along the path from the origin |
6905 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 115] |
6906 |
|
6907 |
|
6908 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6909 |
|
6910 |
|
6911 |
server, plus the amount of time it has been in transit along network |
6912 |
paths. |
6913 |
|
6914 |
We use the term _age_value_ to denote a representation of the value of |
6915 |
the Age header, in a form appropriate for arithmetic operations. |
6916 |
|
6917 |
An response's age can be calculated in two entirely independent ways: |
6918 |
|
6919 |
1. now - date_value, if the local clock is reasonably well |
6920 |
synchronized to the origin server's clock. If the result is |
6921 |
negative, this is replaced by zero. |
6922 |
2. age_value, if all of the caches along the response path implement |
6923 |
HTTP/1.1. |
6924 |
Given that we have two independent ways to compute the age of a response |
6925 |
when it is received, we can combine these as |
6926 |
|
6927 |
|
6928 |
|
6929 |
|
6930 |
|
6931 |
and as long as we have either nearly synchronized clocks or all-HTTP/1.1 corrected_received_age = max(now - date_value, age_value) |
6932 |
paths, one gets a reliable (conservative) result. |
6933 |
|
6934 |
Note that this correction is applied at each HTTP/1.1 cache along the |
6935 |
path, so that if there is an HTTP/1.0 cache in the path, the correct |
6936 |
received age is computed as long as the receiving cache's clock is |
6937 |
nearly in sync. We don't need end-to-end clock synchronization (although |
6938 |
it is good to have), and there is no explicit clock synchronization |
6939 |
step. |
6940 |
|
6941 |
Because of network-imposed delays, some significant interval may pass |
6942 |
from the time that a server generates a response, and the time it is |
6943 |
received at the next outbound cache or client. If uncorrected, this |
6944 |
delay could result in improperly low ages. |
6945 |
|
6946 |
Because the request that resulted in the returned Age value must have |
6947 |
been initiated prior to that Age value's generation, we can correct for |
6948 |
delays imposed by the network by recording the time at which the request |
6949 |
was initiated. Then, when an Age value is received, it MUST be |
6950 |
interpreted relative to the time the request was initiated, not the time |
6951 |
that the response was received. This algorithm results in conservative |
6952 |
behavior no matter how much delay is experienced. So, we compute: |
6953 |
|
6954 |
corrected_initial_age = corrected_received_age + (now - request_time) |
6955 |
|
6956 |
|
6957 |
|
6958 |
where _request_time_ is the time (according to the local clock) when the |
6959 |
request that elicited this response was sent. |
6960 |
|
6961 |
Summary of age calculation algorithm, when a cache receives a response: |
6962 |
|
6963 |
|
6964 |
|
6965 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 116] |
6966 |
|
6967 |
|
6968 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
6969 |
|
6970 |
|
6971 |
/* |
6972 |
* age_value |
6973 |
* is the value of Age: header received by the cache with |
6974 |
* this response. |
6975 |
* date_value |
6976 |
* is the value of the origin server's Date: header |
6977 |
* request_time |
6978 |
* is the (local) time when the cache made the request |
6979 |
* that resulted in this cached response |
6980 |
* response_time |
6981 |
* is the (local) time when the cache received the |
6982 |
* response |
6983 |
* now |
6984 |
* is the current (local) time |
6985 |
*/ |
6986 |
apparent_age = max(0, now - date_value); |
6987 |
corrected_received_age = max(apparent_age, age_value); |
6988 |
response_delay = now - request_time; |
6989 |
corrected_initial_age = corrected_received_age + response_delay; |
6990 |
resident_time = now - response_time; |
6991 |
current_age = corrected_initial_age + resident_time; |
6992 |
|
6993 |
|
6994 |
|
6995 |
When a cache sends a response, it must add to the corrected_initial_age |
6996 |
the amount of time that the response was resident locally. It must then |
6997 |
Age header, to the next recipient |
6998 |
cache. |
6999 |
|
7000 |
|
7001 |
13.2.7 Expiration Calculations |
7002 |
In order to decide whether a response is fresh or stale, we need to |
7003 |
compare its freshness lifetime to its age. The age is calculated as |
7004 |
described in section 13.2.6; this section describes how to calculate the |
7005 |
freshness lifetime, and to determine if a response has expired. |
7006 |
|
7007 |
_ transmit this total age, using the We use the term expires_value_ to denote a representation of the value |
7008 |
of the Expires header, in a form appropriate for arithmetic operations. |
7009 |
We use the term _max_age_value_ to denote an appropriate representation |
7010 |
of the number of seconds carried by the max-age directive of the Cache- |
7011 |
Control header in a response (see section 10.8). |
7012 |
|
7013 |
The max-age directive takes priority over Expires, so if max-age is |
7014 |
present in a response, the calculation is simply: |
7015 |
|
7016 |
freshness_lifetime = max_age_value |
7017 |
|
7018 |
|
7019 |
|
7020 |
Otherwise, if Expires is present in the response, the calculation is: |
7021 |
|
7022 |
|
7023 |
|
7024 |
|
7025 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 117] |
7026 |
|
7027 |
|
7028 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7029 |
|
7030 |
|
7031 |
freshness_lifetime = expires_value - date_value |
7032 |
|
7033 |
|
7034 |
|
7035 |
Note that neither of these calculations is vulnerable to clock skew, |
7036 |
since all of the information comes from the origin server. |
7037 |
|
7038 |
If neither Expires nor Cache-Control max-age appears in the response, |
7039 |
and the response does not include other restrictions on caching, the |
7040 |
cache MAY compute a freshness lifetime using a heuristic. This heuristic |
7041 |
is subject to certain limitations; the minimum value may be zero, and |
7042 |
the maximum value MUST be no more than 24 hours. |
7043 |
|
7044 |
Also, if the response does have a Last-Modified time, the heuristic |
7045 |
expiration value SHOULD be no more than some fraction of the interval |
7046 |
since that time. A typical setting of this fraction might be 10%. |
7047 |
|
7048 |
The calculation to determine if a response has expired is quite simple: |
7049 |
|
7050 |
response_is_fresh = (freshness_lifetime > current_age) |
7051 |
|
7052 |
|
7053 |
|
7054 |
|
7055 |
13.2.8 UT Mandatory |
7056 |
All expiration-related calculations must be done in Universal Time |
7057 |
(GMT). The local time zone MUST not influence the calculation or |
7058 |
comparison of an age or expiration time. |
7059 |
|
7060 |
If an HTTP header incorrectly carries a date value with a time zone |
7061 |
other than GMT, it must be converted into GMT using the most |
7062 |
conservative possible conversion. |
7063 |
|
7064 |
|
7065 |
13.3 Validation Model |
7066 |
When a cache has a stale value that it would like to use as a response |
7067 |
to a client's request, it first has to check with the origin server (or |
7068 |
possibly an intermediate cache with a fresh response) to see if its |
7069 |
cached value is still usable. We call this _validating_ the cache entry. |
7070 |
Since we do not want to have to pay the overhead of retransmitting the |
7071 |
full response if the cached value is good, and we do not want to pay the |
7072 |
overhead of an extra round trip if the cached value is invalid, the |
7073 |
HTTP/1.1 protocol supports the use of conditional methods. |
7074 |
|
7075 |
The key protocol features for supporting conditional methods are those |
7076 |
concerned with _cache validators._ When an origin server generates a |
7077 |
full response, it attaches some sort of validator to it, which is kept |
7078 |
with the cache entry. When a client (end-user or cache) makes a |
7079 |
conditional request for a resource for which it has a cache entry, it |
7080 |
includes the associated validator in the request. |
7081 |
|
7082 |
The server then checks that validator against the current validator for |
7083 |
the resource, and if they match, it responds with a special status code |
7084 |
(usually, _304 Not Modified_) and no entity body. Otherwise, it returns |
7085 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 118] |
7086 |
|
7087 |
|
7088 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7089 |
|
7090 |
|
7091 |
a full response (including entity body). Thus, we avoid transmitting the |
7092 |
full response if the validator matches, and we avoid an extra round trip |
7093 |
if it does not match. |
7094 |
|
7095 |
Note: the comparison functions used to decide if validators |
7096 |
match are defined in section 13.3.3. |
7097 |
|
7098 |
In HTTP/1.1, a conditional request looks exactly the same as a normal |
7099 |
request for the same resource, except that it carries a special header |
7100 |
(which includes the validator) that implicitly turns the method |
7101 |
(usually, GET) into a conditional. |
7102 |
|
7103 |
The protocol includes both positive and negative senses of cache- |
7104 |
validating conditions. That is, it is possible to request either that a |
7105 |
method be performed if and only if the validators match, or if and only |
7106 |
if the validators do not match. |
7107 |
|
7108 |
Note: a response that lacks a cache validator may still be |
7109 |
cached, and served from cache until it expires, unless this is |
7110 |
explicitly prohibited by a Cache-Control directive. However, a |
7111 |
cache cannot do a conditional retrieval if it does not have a |
7112 |
cache validator for the entity, which means it will not be |
7113 |
refreshable after it expires. |
7114 |
|
7115 |
|
7116 |
|
7117 |
|
7118 |
13.3.1 Last-modified Dates |
7119 |
In HTTP/1.0, the only cache validator is the Last-Modified time carried |
7120 |
by a response. Clients validate entities using the If-Modified-Since |
7121 |
header. In simple terms, a cache entry is considered to be valid if the |
7122 |
actual resource has not been modified since the original response was |
7123 |
generated. |
7124 |
|
7125 |
|
7126 |
13.3.2 Opaque Validators |
7127 |
HTTP/1.1 introduces the possibility of using an _opaque_ validator, for |
7128 |
situations where the Last-Modified date is not appropriate. This may |
7129 |
include server implementations where it is not convenient to store |
7130 |
modification dates, or where the one-second resolution of HTTP date |
7131 |
values is insufficient, or where the origin server wishes to avoid |
7132 |
certain paradoxes that may arise from the use of modification dates. |
7133 |
|
7134 |
An opaque validator is simply a string of octets whose internal |
7135 |
structure is not known to clients or caches. Caches store opaque |
7136 |
validators and return them when making conditional requests. Also, when |
7137 |
a cache receives a conditional request for a resource for which it has a |
7138 |
fresh cache entry, it may compare opaque validators using strict octet- |
7139 |
equality. Otherwise, opaque validators have no semantic value to clients |
7140 |
or caches. |
7141 |
|
7142 |
To preserve compatibility with HTTP/1.0 clients and caches, and because |
7143 |
the Last-Modified date may be useful for purposes other than cache |
7144 |
|
7145 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 119] |
7146 |
|
7147 |
|
7148 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7149 |
|
7150 |
|
7151 |
validation, HTTP/1.1 servers SHOULD send Last-Modified whenever |
7152 |
feasible. |
7153 |
|
7154 |
The headers used to convey opaque validators are described in sections |
7155 |
10.47, 10.48, 10.49, and 10.55. |
7156 |
|
7157 |
|
7158 |
13.3.3 Weak and Strong Validators |
7159 |
Since both origin servers and caches will compare two validator values |
7160 |
to decide if they represent the same or different values for the entire |
7161 |
resource, one normally would expect that if the resource value (the |
7162 |
entity body or any entity headers) changes in any way, then the |
7163 |
associated validator would change as well. If this is true, then we call |
7164 |
this validator a _strong validator._ |
7165 |
|
7166 |
However, there may be cases when a server prefers to change the |
7167 |
validator only on semantically significant changes, and not when |
7168 |
insignificant aspects of the resource change. A validator that does not |
7169 |
always change when the resource changes is a _weak validator._ |
7170 |
|
7171 |
One can think of a strong validator as one that changes whenever the |
7172 |
bits of an entity changes, while a weak value changes whenever the |
7173 |
meaning of an entity changes. Alternatively, one can think of a strong |
7174 |
validator as part of an identifier for a specific instance of an entity, |
7175 |
while a weak validator is part of an identifier for a set of |
7176 |
semantically equivalent instances of an entity. |
7177 |
|
7178 |
Note: One example of a strong validator is an integer that is |
7179 |
incremented in stable storage every time an entity is changed. |
7180 |
|
7181 |
An entity's modification time, if represented with one-second |
7182 |
resolution, could be a weak validator, since it is possible that |
7183 |
the resource may be modified twice during a single second. |
7184 |
|
7185 |
Opaque validators are normally _strong,_ but the protocol provides a |
7186 |
mechanism to tag an opaque validator as _weak._ |
7187 |
|
7188 |
A _use_ of a validator is either when a client generates a request and |
7189 |
includes the validator in a validating header field, or when a server |
7190 |
compares two validators. |
7191 |
|
7192 |
Strong validators are usable in any context. Weak validators are only |
7193 |
usable in contexts that do not depend on exact equality of an entity. |
7194 |
For example, either kind is usable for a conditional GET of a full |
7195 |
entity. However, only a strong validator is usable for a sub-range |
7196 |
retrieval, since otherwise the client may end up with an internally |
7197 |
inconsistent entity body. |
7198 |
|
7199 |
The only function that the HTTP/1.1 protocol defines on validators is |
7200 |
comparison. There are two validator comparison functions, depending on |
7201 |
whether the comparison context allows the use of weak validators or not: |
7202 |
|
7203 |
|
7204 |
|
7205 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 120] |
7206 |
|
7207 |
|
7208 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7209 |
|
7210 |
|
7211 |
. The strong comparison function: in order to be considered equal, |
7212 |
both validators must be identical in every way, and neither may be |
7213 |
weak. |
7214 |
. The weak comparison function: in order to be considered equal, both |
7215 |
validators must be identical in every way, but either or both of |
7216 |
them may be tagged as _weak_ without affecting the result. |
7217 |
The weak comparison function should be used for simple (non-subrange) |
7218 |
GET requests. The strong comparison function must be used in all other |
7219 |
cases. |
7220 |
|
7221 |
An opaque validator is strong unless it is explicitly tagged as weak. |
7222 |
Section 3.13 gives the syntax for opaque validators. |
7223 |
|
7224 |
A Last-Modified time, when used as a validator in a request, is |
7225 |
implicitly weak unless it is possible to deduce that it is strong, using |
7226 |
the following rules: |
7227 |
|
7228 |
. The validator is being compared by an origin server to the actual |
7229 |
current validator for the entity and, |
7230 |
. That origin server reliably knows that the associated entity did |
7231 |
not change twice during the second covered by the presented |
7232 |
validator. |
7233 |
or |
7234 |
|
7235 |
. The validator is about to be used by a client in an If-Modified- |
7236 |
Since or If-Unmodified-Since header, because the client has a cache |
7237 |
entry for the associated entity, and |
7238 |
. That cache entry include a Date value, which gives the time when |
7239 |
the origin server generated the original response, and |
7240 |
. The presented Last-Modified time is at least 60 seconds before the |
7241 |
Date value. |
7242 |
or |
7243 |
|
7244 |
. The validator is being compared by an intermediate cache to the |
7245 |
validator stored in its cache entry for the entity, and |
7246 |
. That cache entry include a Date value, which gives the time when |
7247 |
the origin server generated the original response, and |
7248 |
. The presented Last-Modified time is at least 60 seconds before the |
7249 |
Date value. |
7250 |
This method relies on the fact that if two different responses were |
7251 |
generated by the origin server during the same second, but both had the |
7252 |
same Last-Modified time, then at least one of those responses would have |
7253 |
a Date value equal to its Last-Modified time. The arbitrary 60-second |
7254 |
limit guards against the possibility that the Date and Last-Modified |
7255 |
values are generated from different clocks, or at somewhat different |
7256 |
times during the preparation of the response. An implementation may use |
7257 |
a value larger than 60 seconds, if it is believed that 60 seconds is too |
7258 |
short. |
7259 |
|
7260 |
If a client wishes to perform a sub-range retrieval on a value for which |
7261 |
it has only a Last-Modified time and no opaque validator, it may do this |
7262 |
only if the Last-Modified time is strong in the sense described here. |
7263 |
|
7264 |
|
7265 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 121] |
7266 |
|
7267 |
|
7268 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7269 |
|
7270 |
|
7271 |
A cache or origin server receiving a cache-conditional request, other |
7272 |
than a full-body GET request, must use the strong comparison function to |
7273 |
evaluate the condition. |
7274 |
|
7275 |
This allows HTTP/1.1 caches and clients to safely perform sub-range |
7276 |
retrievals on values that have been obtained from HTTP/1.0 servers. |
7277 |
|
7278 |
|
7279 |
13.3.4 Rules for When to Use Opaque Validators and Last-modified Dates |
7280 |
We adopt a set of rules and recommendations for origin servers, clients, |
7281 |
and caches regarding when various validator types should be used, and |
7282 |
for what purposes. |
7283 |
|
7284 |
HTTP/1.1 origin servers: |
7285 |
|
7286 |
. SHOULD send a strong opaque validator unless performance |
7287 |
considerations support the use of weak opaque validators, or unless |
7288 |
it is unfeasible to send a strong opaque validator. |
7289 |
. MAY send a weak opaque validator instead of a strong one. |
7290 |
. MAY send no opaque validator if it is infeasible to generate one. |
7291 |
. SHOULD send a Last-Modified value if it is feasible to send one, |
7292 |
unless the risk of a breakdown in semantic transparency that could |
7293 |
result from using this date in an If-Modified-Since header would |
7294 |
lead to serious problems. |
7295 |
In other words, the preferred behavior for an HTTP/1.1 origin server is |
7296 |
to send both a strong opaque validator and a Last-Modified value. |
7297 |
|
7298 |
In order to be legal, a strong opaque validator MUST change whenever the |
7299 |
associated entity value changes in any way. A weak opaque validator |
7300 |
SHOULD change whenever the associated entity value changes in a |
7301 |
semantically significant way. |
7302 |
|
7303 |
Note: in order to provide semantically transparent caching, an |
7304 |
origin server should avoid reusing a specific strong opaque |
7305 |
validator value for two different instances of an entity, or |
7306 |
reusing a specific weak opaque validator value for two |
7307 |
semantically different instances of an entity. Caches entries |
7308 |
may persist for arbitrarily long periods, regardless of |
7309 |
expiration times, so it may be inappropriate to expect that a |
7310 |
cache will never again attempt to validate an entry using a |
7311 |
validator that it obtained at some point in the past. |
7312 |
|
7313 |
HTTP/1.1 clients: |
7314 |
|
7315 |
. If an opaque validator has been provided by the origin server, MUST |
7316 |
use that validator in any cache-conditional request (using If-Valid |
7317 |
or If-Invalid). |
7318 |
. If only a Last-Modified value has been provided by the origin |
7319 |
server, SHOULD use that value in non-subrange cache-conditional |
7320 |
requests (using If-Modified-Since). |
7321 |
. If only a Last-Modified value has been provided by an HTTP/1.0 |
7322 |
origin server, MAY use that value in subrange cache-conditional |
7323 |
requests (using If-Unmodified-Since:). The user agent should |
7324 |
provide a way to disable this, in case of difficulty. |
7325 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 122] |
7326 |
|
7327 |
|
7328 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7329 |
|
7330 |
|
7331 |
. If both an opaque validator and a Last-Modified value have been |
7332 |
provided by the origin server, SHOULD use both validators in cache- |
7333 |
conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches |
7334 |
to respond appropriately. |
7335 |
An HTTP/1.1 cache, upon receiving a request, MUST use the most |
7336 |
restrictive validator when deciding whether the client's cache entry |
7337 |
matches the cache's own cache entry. This is only an issue when the |
7338 |
request contains both an opaque validator and a last-modified-date |
7339 |
validator (If-Modified-Since or If-Unmodified-Since:). |
7340 |
|
7341 |
A note on rationale: The general principle behind these rules is |
7342 |
that HTTP/1.1 servers and clients should transmit as much non- |
7343 |
redundant information as is available in their responses and |
7344 |
requests. HTTP/1.1 systems receiving this information will make |
7345 |
the most conservative assumptions about the validators they |
7346 |
receive. |
7347 |
|
7348 |
HTTP/1.0 clients and caches will ignore opaque validators. |
7349 |
Generally, last-modified values received or used by these |
7350 |
systems will support transparent and efficient caching, and so |
7351 |
HTTP/1.1 origin servers should provide Last-Modified values. In |
7352 |
those rare cases where the use of a Last-Modified value as a |
7353 |
validator by an HTTP/1.0 system could result in a serious |
7354 |
problem, then HTTP/1.1 origin servers should not provide one. |
7355 |
|
7356 |
|
7357 |
13.3.5 SLUSHY: Non-validating conditionals |
7358 |
TBS |
7359 |
|
7360 |
The principle behind opaque validators is that only the service author |
7361 |
knows the semantics of a resource well enough to select an appropriate |
7362 |
cache validation mechanism, and the specification of any validator |
7363 |
comparison function more complex than byte-equality would open up a can |
7364 |
of worms. Thus, comparisons of any other headers (except Last-Modified, |
7365 |
for compatibility with HTTP/1.0) are never used for purposes of |
7366 |
validating a cache entry. |
7367 |
|
7368 |
|
7369 |
13.3.6 FLUID: Other Issues |
7370 |
TBS: what if no validator present in response? |
7371 |
|
7372 |
|
7373 |
13.4 Cache-control Mechanisms |
7374 |
The basic cache mechanisms in HTTP/1.1 (server-specified expiration |
7375 |
times and validators) are implicit directives to caches. In some cases, |
7376 |
a server or client may need to provide explicit directives to the HTTP |
7377 |
caches. We use the Cache-Control header for this purpose. |
7378 |
|
7379 |
The Cache-Control header allows a client or server to transmit a variety |
7380 |
of directives in either requests or responses. These directives |
7381 |
typically override the default caching algorithms. As a general rule, if |
7382 |
there is any apparent conflict between header values, the most |
7383 |
restrictive interpretation should be applied (that is, the one that is |
7384 |
most likely to preserve semantic transparency). However, in some cases, |
7385 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 123] |
7386 |
|
7387 |
|
7388 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7389 |
|
7390 |
|
7391 |
Cache-Control directives are explicitly specified as weakening semantic |
7392 |
transparency (for example, _max-stale_ or _public_). |
7393 |
|
7394 |
The Cache-Control directives are described in detail in section 10.7. |
7395 |
|
7396 |
|
7397 |
|
7398 |
|
7399 |
13.5 Warnings |
7400 |
Whenever a cache returns a response that is not semantically |
7401 |
transparent, it must attach a warning to that effect, using a Warning |
7402 |
response header. This warning allows clients and user agents to take |
7403 |
appropriate action. |
7404 |
|
7405 |
Warnings may be used for other purposes, both cache-related and |
7406 |
otherwise. The use of a warning, rather than an error status code, |
7407 |
distinguish these responses from true failures. |
7408 |
|
7409 |
Warnings are always cachable, because they never weaken the transparency |
7410 |
of a response. This means that warnings can be passed to HTTP/1.0 caches |
7411 |
without danger; such caches will simply pass the warning along as a |
7412 |
entity header in the response. |
7413 |
|
7414 |
Warnings are assigned numbers between 0 and 99. This specification |
7415 |
defines the code numbers and meanings of each warning, allowing a client |
7416 |
or cache to take automated action in some (but not all) cases. |
7417 |
|
7418 |
Warnings also carry a warning message text in any appropriate natural |
7419 |
language (perhaps based on the client's Accept headers), and an optional |
7420 |
indication of what language and character set are used. |
7421 |
|
7422 |
Multiple warning messages may be attached to a response (either by the |
7423 |
origin server or by a cache), including multiple warnings with the same |
7424 |
code number. For example, a server may provide the same warning with |
7425 |
texts in both English and Basque. |
7426 |
|
7427 |
When multiple warnings are attached to a response, it may not be |
7428 |
practical or reasonable to display all of them to the user. This version |
7429 |
of HTTP does not specify strict priority rules for deciding which |
7430 |
warnings to display and in what order, but does suggest some heuristics. |
7431 |
|
7432 |
The Warning header and the currently defined warnings are described in |
7433 |
section 10.106. |
7434 |
|
7435 |
|
7436 |
13.6 Explicit Indications Regarding User-specified Overrides |
7437 |
Many user agents make it possible for users to override the basic |
7438 |
caching mechanisms. For example, the user agent may allow the user to |
7439 |
specify that cached entities (even explicitly stale ones) are never |
7440 |
validated. Or the user agent might habitually add _Cache-Control: max- |
7441 |
stale=3600_ or _Cache-Control: reload_ to every request. We recognize |
7442 |
that there may be situations which require such overrides, although user |
7443 |
agents SHOULD NOT default to any behavior contrary to the HTTP/1.1 |
7444 |
specification. That is, the user should have to explicitly request |
7445 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 124] |
7446 |
|
7447 |
|
7448 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7449 |
|
7450 |
|
7451 |
either non-transparent behavior, or behavior that results in abnormally |
7452 |
ineffective caching. |
7453 |
|
7454 |
If the user has overridden the basic caching mechanisms, the user agent |
7455 |
should explicitly indicate to the user whenever this results in the |
7456 |
display of information that might not meet the server's transparency |
7457 |
requirements (in particular, if the displayed resource is known to be |
7458 |
stale). Since the protocol normally allows the user agent to determine |
7459 |
if responses are stale or not, this indication need only be displayed |
7460 |
when this actually happens. The indication need not be a dialog box; it |
7461 |
could be an icon (for example, a picture of a rotting fish) or some |
7462 |
other visual indicator. |
7463 |
|
7464 |
If the user has overridden the caching mechanisms in a way that would |
7465 |
abnormally reduce the effectiveness of caches, the user agent should |
7466 |
continually display an indication (for example, a picture of currency in |
7467 |
flames) so that the user does not inadvertently consume excess resources |
7468 |
or suffer from excessive latency. |
7469 |
|
7470 |
|
7471 |
13.7 Constructing Responses From Caches |
7472 |
The purpose of an HTTP cache is to store information received in |
7473 |
response to requests, for use in responding to future requests. In many |
7474 |
cases, a cache simply returns the appropriate parts of a response to the |
7475 |
requester. However, if the cache holds a cache entry based on a previous |
7476 |
response, it may have to combine parts of a new response with what is |
7477 |
held in the cache entry. |
7478 |
|
7479 |
|
7480 |
13.7.1 End-to-end and Hop-by-hop Headers |
7481 |
For the purpose of defining the behavior of caches and non-caching |
7482 |
proxies, we divide HTTP headers into two categories: |
7483 |
|
7484 |
. End-to-end headers, which must be transmitted to the ultimate |
7485 |
recipient of a request or response. End-to-end headers in responses |
7486 |
must be stored as part of a cache entry and transmitted in any |
7487 |
response formed from a cache entry. |
7488 |
. Hop-by-hop headers, which are meaningful only for a single |
7489 |
transport-level connection, and are not stored by caches or |
7490 |
forwarded by proxies. |
7491 |
The following HTTP/1.1 headers are hop-by-hop headers: |
7492 |
|
7493 |
. Connection |
7494 |
. Keep-Alive |
7495 |
. Upgrade |
7496 |
. Public |
7497 |
. Proxy-Authenticate |
7498 |
. Transfer-Encoding |
7499 |
All other headers defined by HTTP/1.1 are end-to-end headers. |
7500 |
|
7501 |
Hop-by-hop headers introduced in future versions of HTTP MUST be listed |
7502 |
in a Connection header, as described in section 10.9. |
7503 |
|
7504 |
|
7505 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 125] |
7506 |
|
7507 |
|
7508 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7509 |
|
7510 |
|
7511 |
13.7.2 Non-modifiable Headers |
7512 |
Some features of the HTTP/1.1 protocol, such as Digest Authentication |
7513 |
(see TBS), depend on the value of certain end-to-end headers. A cache or |
7514 |
non-caching proxy SHOULD NOT modify an end-to-end header unless the |
7515 |
definition of that header requires or specifically allows that. |
7516 |
|
7517 |
A cache or non-caching proxy MUST NOT modify any of the following fields |
7518 |
in a request or response, nor may it add any of these fields if not |
7519 |
already present: |
7520 |
|
7521 |
. Content-Type |
7522 |
. Content-Encoding |
7523 |
. Content-Length |
7524 |
. Expires |
7525 |
. Last-Modified |
7526 |
. Content-Range |
7527 |
. Content-Location |
7528 |
Warning: unnecessary modification of end-to-end headers may |
7529 |
cause authentication failures if stronger authentication |
7530 |
mechanisms are introduced in later versions of HTTP. Such |
7531 |
authentication mechanisms may rely on the values of header |
7532 |
fields not listed here. |
7533 |
|
7534 |
|
7535 |
|
7536 |
|
7537 |
13.7.3 Combining Headers |
7538 |
When a cache makes a validating request to a server, and the server |
7539 |
provides a 304 Not Modified response, the cache must construct a |
7540 |
response to send to the requesting client. The cache uses the entity- |
7541 |
body stored in the cache entry as the entity-body of this outgoing |
7542 |
response. It uses the end-to-end headers from the incoming response, not |
7543 |
from the cache entry. Unless it decides to remove the cache entry, it |
7544 |
must also replace the end-to-end headers stored with the cache entry |
7545 |
with those received in the incoming response. |
7546 |
|
7547 |
In other words, the complete set of end-to-end headers received in the |
7548 |
incoming response overrides all end-to-end headers stored with the cache |
7549 |
entry. The cache may add Warning headers (see section 10.106) to this |
7550 |
set. |
7551 |
|
7552 |
A cache MUST preserve the order of all headers as received in an |
7553 |
incoming response. |
7554 |
|
7555 |
These rule allows an origin server to completely control the response |
7556 |
seen by the client of a cache when the cache revalidates an entry, and |
7557 |
may be necessary for preserving semantic transparency or for certain |
7558 |
kinds of security mechanisms or future extensions. |
7559 |
|
7560 |
|
7561 |
13.7.4 Combining Byte Ranges |
7562 |
A response may transfer only a subrange of the bytes of an entity, |
7563 |
either because the request included one or more Range specifications, or |
7564 |
|
7565 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 126] |
7566 |
|
7567 |
|
7568 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7569 |
|
7570 |
|
7571 |
because a connection was broken prematurely. After several such |
7572 |
transfers, a cache may have received several ranges of the same entity. |
7573 |
|
7574 |
If a cache has a stored non-empty set of subranges for an entity, and an |
7575 |
incoming response transfers another subrange, the cache MAY combine the |
7576 |
new subrange with the existing set if both the following conditions are |
7577 |
met: |
7578 |
|
7579 |
. Both the incoming response and the cache entry must have a cache |
7580 |
validator. |
7581 |
. The two validators must match using the strong comparison function |
7582 |
(see section 13.3.3). |
7583 |
If either requirement is not meant, the cache must use only the most |
7584 |
recent partial response (based on the Date values transmitted with every |
7585 |
response, and using the incoming response if these values are equal or |
7586 |
missing), and must discard the other partial information. |
7587 |
|
7588 |
|
7589 |
13.7.5 SLUSHY: Scope of Expiration |
7590 |
HTTP/1.1's expiration model is that as soon as any variant of a URI |
7591 |
becomes stale, all variants becomes stale as well. Thus, _freshness_ |
7592 |
applies to all the variants of URI, rather than any particular variant. |
7593 |
Dates and expires etc. apply to any cached variant that a proxy might |
7594 |
have with a URI and not just the one particular entity. |
7595 |
|
7596 |
|
7597 |
13.8 Caching and Content Negotiation |
7598 |
The HTTP content negotiation mechanism interacts with caching in several |
7599 |
ways: |
7600 |
|
7601 |
. A varying resource (one subject to content negotiation) may be |
7602 |
bound to more than one entity. Each of these entities is called a |
7603 |
_variant_ of the resource. |
7604 |
. The request-URI may be only one part of the cache key. |
7605 |
|
7606 |
13.8.1 Use of the Vary header |
7607 |
Origin servers may respond to requests for varying resources use the |
7608 |
Vary header (see section 10.vary for a full description) to inform the |
7609 |
cache which header fields of the request were used to select the variant |
7610 |
returned in the response. A cache can use that response to reply to a |
7611 |
subsequent request only if the two requests not only specify the same |
7612 |
URI, but also have the same value for all headers specified in the Vary |
7613 |
response-header. |
7614 |
|
7615 |
The Vary header may also inform the cache that the variant was selected |
7616 |
using criteria not limited to the request headers; in this case, the |
7617 |
response MUST NOT be used in a reply to a subsequent request except if |
7618 |
the cache relays the new request to the origin server in a conditional |
7619 |
request, and the origin server responds with 304 (Not Modified) and |
7620 |
includes the same variant-ID (see 13.8.3). |
7621 |
|
7622 |
|
7623 |
|
7624 |
|
7625 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 127] |
7626 |
|
7627 |
|
7628 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7629 |
|
7630 |
|
7631 |
13.8.2 SLUSHY: Use of the Alternates header |
7632 |
Origin servers may respond to requests for varying resources with a |
7633 |
status of 300 (Multiple choice), using the Alternates header (see |
7634 |
section 10.alternates) to inform the requesting client that describes |
7635 |
the set of possible choices, including specific URIs for each variant. |
7636 |
|
7637 |
Roy says this response also includes a Content-Location header. |
7638 |
|
7639 |
In this case, the client may choose one of the available variants and |
7640 |
make a subsequent request using the specific URI for that variant. Since |
7641 |
such an URI is bound to just one entity, the origin server's response to |
7642 |
this request includes neither a Vary header nor an Alternates header, |
7643 |
and a cache may treat it as it would any non-varying resource. |
7644 |
|
7645 |
If a cache receives an Alternates header in a response from the origin |
7646 |
server, it should act as if the response carried a "Vary:{accept- |
7647 |
headers}" header. This means that the response may be returned in reply |
7648 |
to a subsequent request with Accept-* headers identical to those in the |
7649 |
current request. |
7650 |
|
7651 |
Note that section 13.14.1 prevents caching of 300 (Multiple |
7652 |
choices) responses unless this is explicitly allowed by an |
7653 |
Expires or Cache-control header. |
7654 |
|
7655 |
|
7656 |
13.8.3 Use of Variant-IDs |
7657 |
A cache stores copies of specific entity instances, not copies of |
7658 |
varying resources per se. Therefore, the URI of a varying resource is |
7659 |
not sufficient for use as a cache key. In certain interactions between a |
7660 |
cache and an origin server, it is convenient to encode the cache key |
7661 |
using a more compact representation than the full set of selecting |
7662 |
request headers. Or, if the selection criteria are not known to the |
7663 |
cache, it may be impossible to express the actual cache key to the |
7664 |
cache. For these reasons, the HTTP protocol provides two different |
7665 |
optional mechanisms to encode a cache key: |
7666 |
|
7667 |
. Variant-IDs: an opaque identifier for a specific variant of a |
7668 |
varying resource. |
7669 |
. Selecting opaque validators: a special kind of opaque validator |
7670 |
that is defined to be unique across all variants of a varying |
7671 |
resource. |
7672 |
Variant-IDs are the preferred mechanism, since they generally allow more |
7673 |
efficient management of caches. |
7674 |
|
7675 |
If an origin server chooses to use the variant-ID mechanism, it assigns |
7676 |
a variant-ID (see section 3.14) to each distinct variant. This |
7677 |
assignment can only be done by the origin server. It then returns the |
7678 |
appropriate variant-ID with each response that applies to a specific |
7679 |
variant, using the CVal header (see 10.47). |
7680 |
|
7681 |
If an origin server provides a variant-ID for any variant of a resource, |
7682 |
it SHOULD provide a variant-ID for all variants of that resource. |
7683 |
|
7684 |
|
7685 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 128] |
7686 |
|
7687 |
|
7688 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7689 |
|
7690 |
|
7691 |
When a cache receives a successful response with a variant-ID, it SHOULD |
7692 |
use this information to replace any existing cache entries for the same |
7693 |
variant of the corresponding URI. That is, it forms a cache key using |
7694 |
the URI of the request and the variant-ID of the response. If this key |
7695 |
matches the key of an existing cache entry, it SHOULD replace the |
7696 |
existing entry with the new response (subject to all of the other rules |
7697 |
on caching). See section 13.12 for more details on update. |
7698 |
|
7699 |
When a cache performs a conditional request on a varying resource, and |
7700 |
it has one or more cache entries for the resource that include variant- |
7701 |
IDs, the cache MUST transmit the (cache-validator, variant-ID) tuples in |
7702 |
the conditional request, using the variant-set mechanism (see section |
7703 |
3.16). This tells the server which variants are currently in the |
7704 |
requester's cache. |
7705 |
|
7706 |
The client MAY choose to transmit only a subset of the (cache- |
7707 |
validator, variant-ID) tuples corresponding to its cache entries |
7708 |
for this resource. |
7709 |
|
7710 |
When a server receives a conditional request that includes a variant- |
7711 |
set, and the server is able to reply with an appropriate variant (either |
7712 |
because it is the origin server, or because it is an intermediate cache |
7713 |
that can properly implement the variant selection algorithm), once it |
7714 |
has selected the variant it should examine the elements of the supplied |
7715 |
variant-set. If one of these matches the variant-ID of the selected |
7716 |
variant, and if the cache validators match, the server SHOULD reply with |
7717 |
a 304 (Not Modified) response, including the variant-ID of the selected |
7718 |
variant. Otherwise, the server should reply as if the request were |
7719 |
unconditional. |
7720 |
|
7721 |
The server may optionally use the variant-set information in its |
7722 |
selection algorithm. For example, if the selection algorithm yields |
7723 |
several variants with equal preference, and one of these is already in |
7724 |
the requester's cache, the server could select that variant and avoid an |
7725 |
extra data transfer. This is a performance optimization; otherwise, the |
7726 |
variant-selection mechanism is orthogonal to the variant-ID mechanism. |
7727 |
|
7728 |
|
7729 |
13.8.4 Use of Selecting Opaque Validators |
7730 |
If the origin server prefers not to provide variant-IDs, it MAY at its |
7731 |
option use the _selecting opaque validator_ mechanism. A selecting |
7732 |
opaque validator is an opaque validator whose value is unique across all |
7733 |
variants of a resource. |
7734 |
|
7735 |
If the origin server cannot generate opaque validators that are |
7736 |
guaranteed to be unique across all variants of a varying resource, it |
7737 |
MUST NOT send any opaque validators for that resource. |
7738 |
|
7739 |
When a cache receives a successful response with an opaque validator and |
7740 |
no variant-ID, it MAY either replace any cache entries for the resource |
7741 |
with the new response, or it may keep multiple such entries. See |
7742 |
section 13.12 for more details on update. |
7743 |
|
7744 |
|
7745 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 129] |
7746 |
|
7747 |
|
7748 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7749 |
|
7750 |
|
7751 |
When a cache performs a conditional request on a varying resource, and |
7752 |
it has one or more cache entries for the resource that include opaque |
7753 |
validators, the cache SHOULD transmit the set of opaque validators in |
7754 |
the conditional request, using the validator-set mechanism (see section |
7755 |
3.15). This tells the server which variants are currently in the |
7756 |
requester's cache. |
7757 |
|
7758 |
The client MAY chose to transmit only a subset of the opaque validators |
7759 |
from its cache entries for this resource. |
7760 |
|
7761 |
When a server receives a conditional request that includes a validator- |
7762 |
set, and the server is able to reply with an appropriate variant (either |
7763 |
because it is the origin server, or because it is an intermediate cache |
7764 |
that can properly implement the variant selection algorithm), once it |
7765 |
has selected the variant it should examine the elements of the supplied |
7766 |
validator-set. If one of these matches the cache validator of the |
7767 |
selected variant, the server SHOULD reply with a 304 (Not Modified) |
7768 |
response, including that cache validator. Otherwise, the server should |
7769 |
reply as if the request were unconditional. |
7770 |
|
7771 |
|
7772 |
13.10 Shared and Non-Shared Caches |
7773 |
For reasons of security and privacy, it is necessary to make a |
7774 |
distinction between _shared_ and _non-shared_ caches. A non-shared cache |
7775 |
is one that is accessible only to a single user. Accessibility in this |
7776 |
case SHOULD be enforced by appropriate security mechanisms. All other |
7777 |
caches are considered to be _shared._ Other sections of this |
7778 |
specification place certain constraints on the operation of shared |
7779 |
caches in order to prevent loss of privacy or failure of access |
7780 |
controls. |
7781 |
|
7782 |
|
7783 |
13.11 SLUSHY: Miscellaneous Considerations |
7784 |
This section is somewhat miscellaneous, and its contents might be |
7785 |
shifted to other locations in the document. |
7786 |
|
7787 |
|
7788 |
13.11.1 Detecting Firsthand Responses |
7789 |
Note that a client can usually tell if a response is firsthand by |
7790 |
comparing the Date to its local request-time, and hoping that the clocks |
7791 |
are not badly skewed. |
7792 |
|
7793 |
|
7794 |
13.11.2 Disambiguating Expiration values |
7795 |
Because expiration values are assigned optimistically, it is possible |
7796 |
that two caches may contain fresh values for the same resource that are |
7797 |
different. |
7798 |
|
7799 |
If a client performing a retrieval receives a non-firsthand response for |
7800 |
a resource that was already fresh in its own cache, and the Date header |
7801 |
in its existing cache entry is newer than the Date on the new response, |
7802 |
then the client MAY ignore the response. If so, it MAY retry the request |
7803 |
with a _Cache-Control: max-age=0_ directive (see section 10.8), to force |
7804 |
a check with the origin server. |
7805 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 130] |
7806 |
|
7807 |
|
7808 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7809 |
|
7810 |
|
7811 |
If a cache that is pooling cached responses from other caches sees two |
7812 |
fresh responses for the same resource with different validators, it |
7813 |
SHOULD use the one with the newer Date header. |
7814 |
|
7815 |
|
7816 |
13.11.3 Disambiguating Multiple Responses |
7817 |
Because a client may be receiving responses via multiple paths, so that |
7818 |
some responses flow through one set of caches and other responses flow |
7819 |
through a different set of caches, a client may receive responses in an |
7820 |
order different from that in which the origin server generated them. We |
7821 |
would like the client to use the most recently generated response, even |
7822 |
if older responses are still apparently fresh. |
7823 |
|
7824 |
Neither the opaque validator nor the expiration value can impose an |
7825 |
ordering on responses, since it is possible that a later response |
7826 |
intentionally carries an earlier expiration time. However, the HTTP/1.1 |
7827 |
specification requires the transmission of Date headers on every |
7828 |
response, and the Date values are ordered to a granularity of one |
7829 |
second. |
7830 |
|
7831 |
If a client performs a request for a resource that it already has in its |
7832 |
cache, and the response it receives contains a Date header that appears |
7833 |
to be older than the one it already has in its cache, then the client |
7834 |
SHOULD repeat the request unconditionally, and include |
7835 |
|
7836 |
Cache-Control: max-age=0 |
7837 |
|
7838 |
|
7839 |
|
7840 |
to force any intermediate caches to validate their copies directly with |
7841 |
the origin server, or |
7842 |
|
7843 |
Cache-Control: no-cache |
7844 |
|
7845 |
|
7846 |
|
7847 |
to force any intermediate caches to obtain a new copy from the origin |
7848 |
server. This prevents certain paradoxes arising from the use of multiple |
7849 |
caches. |
7850 |
|
7851 |
If the Date values are equal, then the client may use either response |
7852 |
(or may, if it is being extremely prudent, request a new response). |
7853 |
Servers MUST NOT depend on clients being able to choose |
7854 |
deterministically between responses generated during the same second, if |
7855 |
their expiration times overlap. |
7856 |
|
7857 |
|
7858 |
13.12 SLUSHY: Cache Keys |
7859 |
A _cache key_ is a value used to identify a cache entry. HTTP caches |
7860 |
three different kinds of cache keys, for use in different contexts: |
7861 |
|
7862 |
. Some subset of the fields stored with a cache entry constitute the |
7863 |
_entry key_ for that entry. These may include the Request-URI, |
7864 |
some request-header fields, and some response-header fields. |
7865 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 131] |
7866 |
|
7867 |
|
7868 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7869 |
|
7870 |
|
7871 |
. Some subset of the fields of a response, together with perhaps the |
7872 |
Request-URI, constitute the _update key_ of a response. |
7873 |
. Some subset of the fields of a request, together with the Request- |
7874 |
URI, constitute the _lookup key_ of a request. |
7875 |
When a cache receives a request, it builds a lookup key from that |
7876 |
request, then tries to find (lookup) a cache entry with a matching entry |
7877 |
key according to the key matching procedure in section 13.12.3. If such |
7878 |
a match exists, then the cache can decide (based on the other caching |
7879 |
rules) whether to return that entry in reply to the request. |
7880 |
|
7881 |
When a cache receives a response, it builds a update key from that |
7882 |
response, and from the request that elicited it. It uses this key to |
7883 |
find any previously stored entry with a matching entry key. If such an |
7884 |
entry exists, the cache replaces the old entry with the new one. |
7885 |
|
7886 |
The term _update_ means to remove the old entry from the cache, |
7887 |
and then to insert the new entry. It does not imply a |
7888 |
modification of an existing entry. |
7889 |
|
7890 |
This section describes specifically how the three kinds of keys are |
7891 |
constructed, and how a cache determines if keys match. |
7892 |
|
7893 |
|
7894 |
13.12.1 Non-varying Resources |
7895 |
When a response is received for a non-varying resource (that is, the |
7896 |
response includes no Vary, Alternates, or Content-Location headers), the |
7897 |
update key for the response is simply the Request-URI of the request |
7898 |
that elicited it: (Request-URI, null). The entry key for the response |
7899 |
is (Request-URI, null, null). |
7900 |
|
7901 |
|
7902 |
13.12.2 SLUSHY: Varying Resources |
7903 |
If a response includes a Vary header, then we use the notation _sel-hdr- |
7904 |
values_ to denote the canonical form of the headers in the corresponding |
7905 |
request whose field-names are given in the Vary header. If the response |
7906 |
does not include a Vary header, then sel-hdr-values is assigned the null |
7907 |
value. Section 10.52 on Vary defines the canonical form for selecting |
7908 |
headers. |
7909 |
|
7910 |
The canonical form of the headers is defined to be a set whose elements |
7911 |
are sequences of request headers with identical field-names. For a |
7912 |
given field-name, the corresponding element is the concatenation of the |
7913 |
request headers with that field-name, in exactly the order that these |
7914 |
fields appear in the request |
7915 |
|
7916 |
If the response contains "Vary: {other}", then sel-hdr-values is |
7917 |
assigned a non-null value that is defined as never matching a set of |
7918 |
request headers. |
7919 |
|
7920 |
When a response is received that includes a variant-ID in a CVal header |
7921 |
(see section 10.102), but no Content-Location header, then the update |
7922 |
key is (Request-URI, variant-ID), and the entry key for the response is |
7923 |
(Request-URI, variant-ID, sel-hdr-values). |
7924 |
|
7925 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 132] |
7926 |
|
7927 |
|
7928 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7929 |
|
7930 |
|
7931 |
When a response is received that includes a Vary header and an opaque |
7932 |
validator, but no variant-ID or Content-Location header, then the update |
7933 |
key is (Request-URI, opaque-validator), and the entry key for the |
7934 |
response is (Request-URI, opaque-validator, sel-hdr-values). |
7935 |
|
7936 |
This rule supports the _selecting opaque validators_ mechanism described |
7937 |
in section 13.8.4. The cache should distinguish between actual variant- |
7938 |
IDs and opaque-validators in the variant-ID element of the entry key; a |
7939 |
non-null opaque-validator in an entry key DOES match a null variant-ID |
7940 |
in a lookup key. |
7941 |
|
7942 |
When a response is received that includes both a variant-ID in a CVal |
7943 |
header, and a Content-Location header, then the update key is (content- |
7944 |
location-URI, variant-ID), and the entry key for the response is |
7945 |
(content-location-URI, variant-ID, sel-hdr-values). |
7946 |
|
7947 |
When a response is received that includes a Content-Location header but |
7948 |
no variant-ID, then the update key is (content-location-URI, null), and |
7949 |
the entry key for the response is (content-location-URI, null, sel-hdr- |
7950 |
values). |
7951 |
|
7952 |
|
7953 |
13.12.3 SLUSHY: Key-Matching Procedure |
7954 |
We express entry keys as the tuple (URI, variant-ID, sel-hdr-values), in |
7955 |
which the variant-ID may be null, and the sel-hdr-values may either be |
7956 |
null, or may be a set of request headers. |
7957 |
|
7958 |
We express update keys as a tuple (URI, variant-ID), in which the |
7959 |
variant-ID may be null. A update key matches an entry key if both their |
7960 |
URI elements match and their variant-ID elements match. (A null |
7961 |
variant-ID does not match a non-null variant-ID.) |
7962 |
|
7963 |
We express lookup keys as a tuple (URI, variant-ID, all-request- |
7964 |
headers), in which the variant-ID may be null. The all-request-headers |
7965 |
element of the tuple is not always used, but is included here as a |
7966 |
notational convenience. A lookup key matches an entry key if both their |
7967 |
URI elements match and their variant-ID elements match, and either |
7968 |
|
7969 |
. the sel-hdr-values element of the entry key is null |
7970 |
or |
7971 |
|
7972 |
. the sel-hdr-values element of the entry key matches the appropriate |
7973 |
headers in the all-request-headers element of the lookup key, |
7974 |
according to the matching rules in section on Vary, section 10.52. |
7975 |
This description matching algorithm is clearly not the most efficient |
7976 |
implementation of an equivalent algorithm. A cache may use any |
7977 |
algorithm that yields equivalent results. For example, it may use a |
7978 |
hierarchical approach where cache entries are grouped into sets by the |
7979 |
URI and variant-ID, and only if a set includes non-null sel-hdr-values |
7980 |
elements does the cache need to consider the other request headers. |
7981 |
|
7982 |
If on a cache lookup there are two or more fresh entries that appear to |
7983 |
match the request, then the one with the most recent Date value MUST be |
7984 |
used. |
7985 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 133] |
7986 |
|
7987 |
|
7988 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
7989 |
|
7990 |
|
7991 |
13.12.4 Canonicalization of URIs |
7992 |
A cache, when comparing two URIs to decide if they match or not, a cache |
7993 |
MUST use a case-sensitive octet-by-octet comparison of the entire URIs, |
7994 |
with these exceptions: |
7995 |
|
7996 |
Following the rules from section 3.2.2: |
7997 |
|
7998 |
. A port that is empty or not given is equivalent to port 80. |
7999 |
. Comparisons of host names MUST be case-insensitive. |
8000 |
. Comparisons of scheme names MUST be case-insensitive. |
8001 |
. An empty abs_path is equivalent to an abs_path of _/_ |
8002 |
Characters except those in the reserved set and the unsafe set (see |
8003 |
section 3.2) are equivalent to their _"%" HEX HEX_ encodings. |
8004 |
|
8005 |
For example, the following three URIs are equivalent: |
8006 |
|
8007 |
http://abc.com:80/~smith/home.html |
8008 |
http://ABC.com/%7Esmith/home.html |
8009 |
http://ABC.com:/%7esmith/home.html |
8010 |
|
8011 |
|
8012 |
|
8013 |
|
8014 |
13.13 FLUID: Cache-Related Problems Not Addressed in HTTP/1.1 |
8015 |
TBS |
8016 |
|
8017 |
This section will list a few problems that are NOT addressed in |
8018 |
HTTP/1.1, with the intention of encouraging implementers not to adopt |
8019 |
proprietary solutions inconsistent with possible future protocol |
8020 |
revisions.. |
8021 |
|
8022 |
. Server-driven invalidation |
8023 |
. Demographics |
8024 |
|
8025 |
13.14 Cache Operation When Receiving Errors or Incomplete Responses |
8026 |
A cache that receives an incomplete response (for example, with fewer |
8027 |
bytes of data than specified in a Content-length: header) may store the |
8028 |
response. However, the cache MUST treat this as a partial response. |
8029 |
Partial responses may be combined as described in section 13.7.4; the |
8030 |
result might be a full response or might still be partial. A cache MUST |
8031 |
NOT return a partial response to a client without explicitly marking it |
8032 |
as such, using the 206 (Partial Content) status code. A cache MUST NOT |
8033 |
return a partial response using a status code of 200 (OK). |
8034 |
|
8035 |
A cache that receives a response with a zero-length Entity-body and no |
8036 |
explicit indication that the correct length is zero (such as _Content- |
8037 |
Length: 0_) MUST NOT not store the response. The same rule applies to a |
8038 |
response of any length received without an explicit length indication if |
8039 |
the transport connection was terminated in any unusual way. |
8040 |
|
8041 |
If a cache receives a response carrying Retry-After header (see section |
8042 |
10.36), it may either forward this response to the requesting client, or |
8043 |
act as if the server failed to respond. In the latter case, it MAY |
8044 |
return a previously received response, although it MUST follow all of |
8045 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 134] |
8046 |
|
8047 |
|
8048 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8049 |
|
8050 |
|
8051 |
the rules applying to stale responses. In particular, it MUST NOT |
8052 |
override the _must-revalidate_ Cache-Control directive (see section |
8053 |
10.7). |
8054 |
|
8055 |
|
8056 |
13.14.1 Caching and Status Codes |
8057 |
A response received with a status code of 200 or 206 may be stored by a |
8058 |
cache and used in reply to a subsequent request, subject to the |
8059 |
expiration mechanism, unless a Cache-control directive prohibits |
8060 |
caching. |
8061 |
|
8062 |
A response received with any other status code MUST not be returned in a |
8063 |
reply to a subsequent request unless it carries at least one of the |
8064 |
following: |
8065 |
|
8066 |
. an Expires header |
8067 |
. a max-age Cache-control directive |
8068 |
. a must-revalidate Cache-control directive |
8069 |
. a public Cache-control directive |
8070 |
|
8071 |
13.14.2 Handling of Retry-After |
8072 |
If a cache receives a response carrying a Retry-After header (see |
8073 |
section 10.36), it may either forward this response to the requesting |
8074 |
client, or act as if the server failed to respond. In the latter case, |
8075 |
it MAY return a previously received response, although it MUST follow |
8076 |
all of the rules applying to stale responses. In particular, it MUST |
8077 |
not override the _must-revalidate_ Cache-control directive (see section |
8078 |
10.7). |
8079 |
|
8080 |
|
8081 |
13.15 FLUID: Compatibility With Earlier Versions of HTTP |
8082 |
TBS |
8083 |
|
8084 |
If anything should be here, it should be a collection of warnings about |
8085 |
what HTTP/1.1 systems should not assume about HTTP/1.0 systems. |
8086 |
|
8087 |
|
8088 |
13.16 SLUSHY: Side Effects of GET and HEAD |
8089 |
Unless the origin server explicitly prohibits the caching of their |
8090 |
responses, the application of GET and HEAD methods to any resources |
8091 |
SHOULD NOT have side effects that would lead to erroneous behavior if |
8092 |
these responses are taken from a cache. They may still have side |
8093 |
effects, but a cache is not required to consider such side effects in |
8094 |
its caching decisions. Caches are always expected to observe an origin |
8095 |
server's explicit restrictions on caching. |
8096 |
|
8097 |
We note one exception to this rule: since some applications have |
8098 |
traditionally used GETs and HEADs with query URLs (those containing a |
8099 |
_?_ in the rel_path part) to perform operations with significant side |
8100 |
effects, caches MUST NOT treat responses to such URLs as fresh unless |
8101 |
the server provides an explicit expiration time. |
8102 |
|
8103 |
This specifically means that responses from HTTP/1.0 servers for such |
8104 |
URIs should not be taken from a cache. |
8105 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 135] |
8106 |
|
8107 |
|
8108 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8109 |
|
8110 |
|
8111 |
See section 15.2 for related information. |
8112 |
|
8113 |
|
8114 |
13.17 SLUSHY: Invalidation After Updates or Deletions |
8115 |
The effect of certain methods at the origin server may cause one or more |
8116 |
existing cache entries to become non-transparently invalid. That is, |
8117 |
although they may continue to be _fresh,_ they do not accurately reflect |
8118 |
what the origin server would return for a new request. |
8119 |
|
8120 |
There is no way for the HTTP protocol to guarantee that all such cache |
8121 |
entries are marked invalid. For example, the request that caused the |
8122 |
change at the origin server may not have gone through the proxy where a |
8123 |
cache entry is stored. However, several rules help reduce the |
8124 |
likelihood of erroneous behavior. |
8125 |
|
8126 |
In this section, the phrase _invalidate an entity_ means that the cache |
8127 |
should either remove all instances of that entity from its storage, or |
8128 |
should mark these as _invalid_ and in need of a mandatory revalidation |
8129 |
before they can be returned in response to a subsequent request. |
8130 |
|
8131 |
Some HTTP methods invalidate a single entity. This is either the entity |
8132 |
referred to by the Request-URI, or by the Location or Content-Location |
8133 |
response headers (if present). These methods are: |
8134 |
|
8135 |
. PUT |
8136 |
. DELETE |
8137 |
. POST |
8138 |
In order to prevent denial of service attacks, an invalidation based on |
8139 |
the URI in a Location or Content-Location header MUST only be performed |
8140 |
if the host part is the same as in the Request-URI. |
8141 |
|
8142 |
|
8143 |
13.18 Write-Through Mandatory |
8144 |
All methods that may be expected to cause modifications to the origin |
8145 |
server's resources MUST be written through to the origin server. This |
8146 |
currently includes all methods except for GET and HEAD. A cache MUST NOT |
8147 |
reply to such a request from a client before having transmitted the |
8148 |
request to the inbound server, and having received a corresponding |
8149 |
response from the inbound server. |
8150 |
|
8151 |
The alternative (known as _write-back_ or _copy-back_ caching) is not |
8152 |
allowed in HTTP/1.1, due to the difficulty of providing consistent |
8153 |
updates and the problems arising from server, cache, or network failure |
8154 |
prior to write-back. |
8155 |
|
8156 |
|
8157 |
13.19 Interoperability of Varying Resources with HTTP/1.0 Proxy Caches |
8158 |
If the correct handling of responses from a varying resource (Section |
8159 |
10.xxx) by HTTP/1.0 proxy caches in the response chain is important, |
8160 |
HTTP/1.1 origin servers can include the following Expires (Section |
8161 |
10.exp) response header in all responses from the varying resource: |
8162 |
|
8163 |
Expires: Thu, 01 Jan 1980 00:00:00 GMT |
8164 |
|
8165 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 136] |
8166 |
|
8167 |
|
8168 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8169 |
|
8170 |
|
8171 |
If this Expires header is included, the server should usually also |
8172 |
include a Cache-Control header for the benefit of HTTP/1.1 caches, for |
8173 |
example |
8174 |
|
8175 |
|
8176 |
|
8177 |
which overrides the freshness lifetime of zero seconds specified by the |
8178 |
included Cache-Control: max-age=604800 Expires header. |
8179 |
|
8180 |
|
8181 |
13.20 Cache Replacement for Varying Resources |
8182 |
If a new 200 (OK) response is received from a non-varying resource while |
8183 |
an old 200 (OK) response is cached, caches can delete this old response |
8184 |
from cache memory and insert the new response. For 200 (OK) responses |
8185 |
from varying resources (Section 13.12.3), cache replacement is more |
8186 |
complex. |
8187 |
|
8188 |
HTTP/1.1 allows the authors of varying resources to guide cache update |
8189 |
by the inclusion of elements of so-called update keys in the responses |
8190 |
of these resources. The update key of a varying response consists of |
8191 |
two elements, both of which may be empty strings, separated by a |
8192 |
semicolon: |
8193 |
|
8194 |
update-key = variant-id ";" absoluteURI |
8195 |
|
8196 |
The variant-id element of the update key is the variant-id value in the |
8197 |
CVal header of the response, if a CVal header which such a value is |
8198 |
present, and an empty string otherwise. The absoluteURI element of the |
8199 |
update key is the absolute URI given in, or derived from, the Content- |
8200 |
Location header of the response if present, and an empty string if no |
8201 |
Content-Location header is present. |
8202 |
|
8203 |
If a cache has stored in memory a 200 (OK) response with a certain |
8204 |
update key, and receives, from the same resource, a new 200 (OK) |
8205 |
response which has the same update key, this should be interpreted as a |
8206 |
signal from the resource author that the old response can be deleted |
8207 |
from cache memory and replaced by the new response. |
8208 |
|
8209 |
The update key mechanism cannot cause deletion from cache memory of old |
8210 |
responses with update keys that will no longer be used. It is expected |
8211 |
that the normal _least recently used_ update heuristics employed by |
8212 |
caches will eventually cause such old responses to be deleted. |
8213 |
|
8214 |
All 200 (OK) responses from varying resources should include update key |
8215 |
elements. Resource authors may not assume that caches will be able to |
8216 |
cache responses not including update key elements. If a Vary header is |
8217 |
used to signal variance, the response should include a variant-id value |
8218 |
as the update key element. The Content-Location header should only be |
8219 |
used to supply a update key element if an Alternates header is present |
8220 |
in the response. |
8221 |
|
8222 |
|
8223 |
13.22 FLUID: Network Partitions |
8224 |
TBS |
8225 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 137] |
8226 |
|
8227 |
|
8228 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8229 |
|
8230 |
|
8231 |
There may be enough said elsewhere already, but we haven't checked. |
8232 |
|
8233 |
|
8234 |
13.23 FLUID: Caching of Negative Responses |
8235 |
TBS |
8236 |
|
8237 |
|
8238 |
13.24 History Lists |
8239 |
History lists as implemented in many user agents and caches are |
8240 |
different. In particular history lists SHOULD NOT try to show a |
8241 |
semantically transparent view of the current state of a resource. |
8242 |
Rather, a history list is meant to show exactly what the user saw at the |
8243 |
time when the resource was retrieved . |
8244 |
|
8245 |
This should not be construed to prohibit the history mechanism from |
8246 |
telling the user that a view may be stale. |
8247 |
|
8248 |
|
8249 |
14 Persistent Connections |
8250 |
|
8251 |
14.1 Purpose |
8252 |
HTTP's greatest strength and its greatest weakness has been its |
8253 |
simplicity. Prior to persistent connections, a separate TCP connection |
8254 |
was established to fetch each URL, increasing the load on HTTP servers, |
8255 |
and causing congestion on the Internet. The use of inline images and |
8256 |
other associated data often requires a client to make multiple requests |
8257 |
of the same server in a short amount of time. An excellent analysis of |
8258 |
these performance problems is available [2]; analysis and results from a |
8259 |
prototype implementation are in [32, 33]. |
8260 |
|
8261 |
Persistent HTTP connections have a number of advantages, including: |
8262 |
|
8263 |
. By opening and closing TCP fewer connections, CPU time is saved, |
8264 |
and memory used for TCP protocol control blocks is also saved |
8265 |
. HTTP requests and responses can be pipe-lined on a connection. |
8266 |
Pipe-lining allows a client to make multiple requests without |
8267 |
waiting for each response, allowing a single TCP connection to be |
8268 |
used much more efficiently, with much lower elapsed time. |
8269 |
. Network congestion is reduced by reducing the number of packets |
8270 |
caused by TCP opens, and by allowing TCP sufficient time to |
8271 |
determine the congestion state of the network. |
8272 |
. HTTP can evolve more gracefully; since errors can be reported |
8273 |
without the penalty of closing the TCP connection. Clients using |
8274 |
future versions of HTTP might optimistically try a new feature, but |
8275 |
if communicating with an older server, retry with old semantics |
8276 |
after an error were reported. |
8277 |
HTTP implementations SHOULD implement persistent connections. |
8278 |
|
8279 |
|
8280 |
14.2 Overall Operation |
8281 |
Persistent connections provides a mechanism by which a client and a |
8282 |
server can negotiate the use of a TCP connection for an extended |
8283 |
conversation.. This negotiation takes place using the Connection and |
8284 |
|
8285 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 138] |
8286 |
|
8287 |
|
8288 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8289 |
|
8290 |
|
8291 |
Persist header fields. Once this option has been negotiated the client |
8292 |
can make multiple HTTP requests over a single transport connection. |
8293 |
|
8294 |
|
8295 |
14.2.3 Negotiation |
8296 |
To request the use of persistent connections, a client sends a |
8297 |
Connection header with a connection-token _Persist_. If the server |
8298 |
wishes to accept persistent connections it will respond with the same |
8299 |
connection-token. Both the client and server MUST send this connection- |
8300 |
token with every request and response for the duration of the persistent |
8301 |
connection. If either the client or the server omits the Persist token |
8302 |
from the Connection header, that request becomes the last one for the |
8303 |
connection. |
8304 |
|
8305 |
A server MUST NOT establish a persistent connection with an HTTP/1.0 |
8306 |
client that uses the above form of the Persist header due to problems |
8307 |
with the interactions between 1.1 clients and 1.0 proxy servers (See |
8308 |
section E.2.5 for more information on backwards compatibility with HTTP |
8309 |
1.0 clients). |
8310 |
|
8311 |
|
8312 |
14.2.4 Pipe-lining |
8313 |
Clients and servers which support persistent connections MAY _pipe-line_ |
8314 |
their requests and responses. When pipe-lining, a client will send |
8315 |
multiple requests without waiting for the responses. The server MUST |
8316 |
then send all of the responses in the same order that the requests were |
8317 |
made. |
8318 |
|
8319 |
A client MAY pipeline multiple requests immediately if it has previous |
8320 |
knowledge that the server it is connecting to supports persistent |
8321 |
connections. A client MAY assume that a server supports persistent |
8322 |
connections if the same server has accepted persistent connections |
8323 |
within the past 24 hours. Clients which assume persistent connections |
8324 |
and pipeline immediately SHOULD be prepared to retry their connection if |
8325 |
the first pipe-lined attempt fails. If a client does such a retry, it |
8326 |
MUST NOT pipeline without first receiving an explicit Persist token from |
8327 |
the server. Clients MUST also be prepared to resend their requests if |
8328 |
the server closes the connection before sending all of the corresponding |
8329 |
responses. |
8330 |
|
8331 |
|
8332 |
14.2.5 Delimiting Entity-Bodies |
8333 |
When using persistent connections both the client and the server MUST |
8334 |
mark the exact endings of transmitted entity-bodies using one of the |
8335 |
following three techniques: |
8336 |
|
8337 |
1. Send a Content-length field in the header with the exact number of |
8338 |
bytes in the entity-body. |
8339 |
2. Send the message using Chunked transfer encoding as described in |
8340 |
section 3.6. Chunked transfer encoding allows the server to |
8341 |
transmit the data to the client a piece at a time while still |
8342 |
communicating an exact ending of the entity-body. |
8343 |
3. Close the transport connection after the entity body. |
8344 |
|
8345 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 139] |
8346 |
|
8347 |
|
8348 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8349 |
|
8350 |
|
8351 |
Sending the Content-length is the preferred technique. Chunked encoding |
8352 |
SHOULD be used when the size of the entity-body is not known before |
8353 |
beginning to transmit the entity-body. Finally, the connection MAY be |
8354 |
closed and fall back to non-persistent connections, if neither 1 or 2 |
8355 |
are possible. |
8356 |
|
8357 |
Clients and servers that support persistent connections MUST correctly |
8358 |
support receiving via all three techniques. |
8359 |
|
8360 |
|
8361 |
14.3 Proxy Servers |
8362 |
It is especially important that proxies correctly implement the |
8363 |
properties of the Connection header field as specified in 14.2.1. |
8364 |
|
8365 |
The proxy server MUST negotiate persistent connections separately with |
8366 |
its clients and the origin servers (or other proxy servers) that it |
8367 |
connects to. Each persistent connection applies to only one transport |
8368 |
link. |
8369 |
|
8370 |
A proxy server MUST NOT establish a persistent connection with an HTTP |
8371 |
1.0 client. |
8372 |
|
8373 |
|
8374 |
14.4 Interaction with Security Protocols |
8375 |
It is expected that the Session extension will operate with both SHTTP |
8376 |
[31] and SSL [32]. When used in conjunction with SHTTP, the SHTTP |
8377 |
request is prepared normally and the persist connection-token is placed |
8378 |
in the outermost request block (the one containing the _Secure_ method). |
8379 |
When used in conjunction with SSL, a SSL session is started as normal |
8380 |
and the first HTTP request made using SSL contains the persistent |
8381 |
connection header. |
8382 |
|
8383 |
|
8384 |
14.5 Practical Considerations |
8385 |
Servers will usually have some time-out value beyond which they will no |
8386 |
longer maintain an inactive connection. Proxy servers might make this a |
8387 |
higher value since it is likely that the client will be making more |
8388 |
connections through the same server. The use of persistent connections |
8389 |
places no requirements on the length of this time-out for either the |
8390 |
client or the server. |
8391 |
|
8392 |
When a client or server wishes to time-out it SHOULD issue a graceful |
8393 |
close on the transport connection. Clients and servers SHOULD both |
8394 |
constantly watch for the other side of the transport close, and respond |
8395 |
to it as appropriate. If a client or server does not detect the other |
8396 |
sides close promptly it could cause unnecessary resource drain on the |
8397 |
network. |
8398 |
|
8399 |
A client, server, or proxy MAY close the transport connection at any |
8400 |
time. For example, a client MAY have started to send a new request at |
8401 |
the same time that the server has decided to close the _idle_ |
8402 |
connection. From the server's point of view, the connection is being |
8403 |
closed while it was idle, but from the client's point of view, a request |
8404 |
is in progress. |
8405 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 140] |
8406 |
|
8407 |
|
8408 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8409 |
|
8410 |
|
8411 |
This means that clients, servers, and proxies MUST be able to recover |
8412 |
from asynchronous close events. Client software SHOULD reopen the |
8413 |
transport connection and retransmit the aborted request without user |
8414 |
interaction. However, this automatic retry SHOULD NOT be repeated if the |
8415 |
second request fails. |
8416 |
|
8417 |
Servers SHOULD always respond to at least one request per connection, if |
8418 |
at all possible. Servers SHOULD NOT close a connection in the middle of |
8419 |
transmitting a response, unless a network or client failure is |
8420 |
suspected. |
8421 |
|
8422 |
It is suggested that clients which use persistent connections SHOULD |
8423 |
limit the number of simultaneous connections that they maintain to a |
8424 |
given server. A single-user client SHOULD maintain AT MOST 2 connections |
8425 |
with any server of proxy. A proxy SHOULD use up to 2*N connections to |
8426 |
another server or proxy, where N is the number of simultaneously active |
8427 |
users. These guidelines are intended to improve HTTP response times and |
8428 |
avoid congestion of the Internet or other networks. |
8429 |
|
8430 |
|
8431 |
15. Security Considerations |
8432 |
This section is meant to inform application developers, information |
8433 |
providers, and users of the security limitations in HTTP/1.1 as |
8434 |
described by this document. The discussion does not include definitive |
8435 |
solutions to the problems revealed, though it does make some suggestions |
8436 |
for reducing security risks. |
8437 |
|
8438 |
|
8439 |
15.1 Authentication of Clients |
8440 |
As mentioned in Section 11.1, the Basic authentication scheme is not a |
8441 |
|
8442 |
secure method of user authentication, nor does it in any way protect the |
8443 |
Entity-Body, which is transmitted in clear text across the physical |
8444 |
network used as the carrier. HTTP does not prevent additional |
8445 |
authentication schemes and encryption mechanisms from being employed to |
8446 |
increase security or the addition of enhancements (such as schemes to |
8447 |
use one-time passwords) to Basic authentication. |
8448 |
|
8449 |
The most serious flaw in Basic authentication is that it results in the |
8450 |
essentially clear text transmission of the user's password over the |
8451 |
physical network. It is this problem which Digest Authentication |
8452 |
attempts to address. |
8453 |
|
8454 |
Because Basic authentication involves the clear text transmission of |
8455 |
passwords it SHOULD never be used (without enhancements) to protect |
8456 |
sensitive or valuable information. |
8457 |
|
8458 |
A common use of Basic authentication is for identification purposes -- |
8459 |
requiring the user to provide a user name and password as a means of |
8460 |
identification, for example, for purposes of gathering accurate usage |
8461 |
statistics on a server. When used in this way it is tempting to think |
8462 |
that there is no danger in its use if illicit access to the protected |
8463 |
documents is not a major concern. This is only correct if the server |
8464 |
issues both user name and password to the users and in particular does |
8465 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 141] |
8466 |
|
8467 |
|
8468 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8469 |
|
8470 |
|
8471 |
not allow the user to choose his or her own password. The danger arises |
8472 |
because naive users frequently reuse a single password to avoid the task |
8473 |
of maintaining multiple passwords. |
8474 |
|
8475 |
If a server permits users to select their own passwords, then the threat |
8476 |
is not only illicit access to documents on the server but also illicit |
8477 |
access to the accounts of all users who have chosen to use their account |
8478 |
password. If users are allowed to choose their own password that also |
8479 |
means the server must maintain files containing the (presumably |
8480 |
encrypted) passwords. Many of these may be the account passwords of |
8481 |
users perhaps at distant sites. The owner or administrator of such a |
8482 |
system could conceivably incur liability if this information is not |
8483 |
maintained in a secure fashion. |
8484 |
|
8485 |
Basic Authentication is also vulnerable to spoofing by counterfeit |
8486 |
servers. If a user can be led to believe that he is connecting to a |
8487 |
host containing information protected by basic authentication when in |
8488 |
fact he is connecting to a hostile server or gateway then the attacker |
8489 |
can request a password, store it for later use, and feign an error. |
8490 |
This type of attack is not possible with Digest Authentication[26]. |
8491 |
Server implementers SHOULD guard against the possibility of this sort of |
8492 |
counterfeiting by gateways or CGI scripts. In particular it is very |
8493 |
dangerous for a server to simply turn over a connection to a gateway |
8494 |
since that gateway can then use the persistent connection mechanism to |
8495 |
engage in multiple transactions with the client while impersonating the |
8496 |
original server in a way that is not detectable by the client. |
8497 |
|
8498 |
|
8499 |
|
8500 |
|
8501 |
15.2 Safe Methods |
8502 |
The writers of client software should be aware that the software |
8503 |
represents the user in their interactions over the Internet, and should |
8504 |
be careful to allow the user to be aware of any actions they may take |
8505 |
which may have an unexpected significance to themselves or others. |
8506 |
|
8507 |
In particular, the convention has been established that the GET and HEAD |
8508 |
methods should never have the significance of taking an action other |
8509 |
than retrieval. These methods should be considered _safe. _ This allows |
8510 |
user agents to represent other methods, such as POST, PUT and DELETE, in |
8511 |
a special way, so that the user is made aware of the fact that a |
8512 |
possibly unsafe action is being requested. |
8513 |
|
8514 |
Naturally, it is not possible to ensure that the server does not |
8515 |
generate side-effects as a result of performing a GET request; in fact, |
8516 |
some dynamic resources consider that a feature. The important |
8517 |
distinction here is that the user did not request the side-effects, so |
8518 |
therefore cannot be held accountable for them. |
8519 |
|
8520 |
|
8521 |
15.3 Abuse of Server Log Information |
8522 |
A server is in the position to save personal data about a user's |
8523 |
requests which may identify their reading patterns or subjects of |
8524 |
interest. This information is clearly confidential in nature and its |
8525 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 142] |
8526 |
|
8527 |
|
8528 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8529 |
|
8530 |
|
8531 |
handling may be constrained by law in certain countries. People using |
8532 |
the HTTP protocol to provide data are responsible for ensuring that such |
8533 |
material is not distributed without the permission of any individuals |
8534 |
that are identifiable by the published results. |
8535 |
|
8536 |
|
8537 |
15.4 Transfer of Sensitive Information |
8538 |
Like any generic data transfer protocol, HTTP cannot regulate the |
8539 |
content of the data that is transferred, nor is there any a priori |
8540 |
method of determining the sensitivity of any particular piece of |
8541 |
information within the context of any given request. Therefore, |
8542 |
applications SHOULD supply as much control over this information as |
8543 |
possible to the provider of that information. Four header fields are |
8544 |
worth special mention in this context: Server, Via, Referer and From. |
8545 |
|
8546 |
Revealing the specific software version of the server may allow the |
8547 |
server machine to become more vulnerable to attacks against software |
8548 |
that is known to contain security holes. Implementers SHOULD make the |
8549 |
Server header field a configurable option. |
8550 |
|
8551 |
Proxies which serve as a portal through a network firewall SHOULD take |
8552 |
special precautions regarding the transfer of header information that |
8553 |
identifies the hosts behind the firewall. In particular, they SHOULD |
8554 |
remove, or replace with sanitized versions, any Via fields generated |
8555 |
behind the firewall. |
8556 |
|
8557 |
The Referer field allows reading patterns to be studied and reverse |
8558 |
links drawn. Although it can be very useful, its power can be abused if |
8559 |
user details are not separated from the information contained in the |
8560 |
Referer. Even when the personal information has been removed, the |
8561 |
Referer field may indicate a private document's URI whose publication |
8562 |
would be inappropriate. |
8563 |
|
8564 |
The information sent in the From field might conflict with the user's |
8565 |
privacy interests or their site's security policy, and hence it SHOULD |
8566 |
not be transmitted without the user being able to disable, enable, and |
8567 |
modify the contents of the field. The user MUST be able to set the |
8568 |
contents of this field within a user preference or application defaults |
8569 |
configuration. |
8570 |
|
8571 |
We suggest, though do not require, that a convenient toggle interface be |
8572 |
provided for the user to enable or disable the sending of From and |
8573 |
Referer information. |
8574 |
|
8575 |
|
8576 |
15.5 Attacks Based On File and Path Names |
8577 |
Implementations of HTTP origin servers SHOULD be careful to restrict the |
8578 |
documents returned by HTTP requests to be only those that were intended |
8579 |
by the server administrators. If an HTTP server translates HTTP URIs |
8580 |
directly into file system calls, the server MUST take special care not |
8581 |
to serve files that were not intended to be delivered to HTTP clients. |
8582 |
For example, UNIX, Microsoft Windows, and other operating systems use |
8583 |
_.._ as a path component to indicate a directory level above the current |
8584 |
one. On such a system, an HTTP server MUST disallow any such construct |
8585 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 143] |
8586 |
|
8587 |
|
8588 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8589 |
|
8590 |
|
8591 |
in the Request-URI if it would otherwise allow access to a resource |
8592 |
outside those intended to be accessible via the HTTP server. Similarly, |
8593 |
files intended for reference only internally to the server (such as |
8594 |
access control files, configuration files, and script code) MUST be |
8595 |
protected from inappropriate retrieval, since they might contain |
8596 |
sensitive information. Experience has shown that minor bugs in such HTTP |
8597 |
server implementations have turned into security risks. |
8598 |
|
8599 |
|
8600 |
15.6 Personal Information |
8601 |
HTTP clients are often privy to large amounts of personal information |
8602 |
(e.g. the user's name, location, mail address, passwords, encryption |
8603 |
keys, etc.), and SHOULD be very careful to prevent unintentional leakage |
8604 |
of this information via the HTTP protocol to other sources. We very |
8605 |
strongly recommend that a convenient interface be provided for the user |
8606 |
to control dissemination of such information, and that designers and |
8607 |
implementers be particularly careful in this area. History shows that |
8608 |
errors in this area are often both serious security and/or privacy |
8609 |
problems, and often generate very adverse publicity for the |
8610 |
implementer's company. |
8611 |
|
8612 |
|
8613 |
15.7 Privacy issues connected to Accept headers |
8614 |
Accept request headers can reveal information about the user to all |
8615 |
servers which are accessed. The Accept-Language header in particular |
8616 |
can reveal information the user would consider to be of a private |
8617 |
nature, because the understanding of particular languages is often |
8618 |
strongly correlated to the membership of a particular ethnic group. |
8619 |
User agents which offer the option to configure the contents of an |
8620 |
Accept-Language header to be sent in every request are strongly |
8621 |
encouraged to let the configuration process include a message which |
8622 |
makes the user aware of the loss of privacy involved. |
8623 |
|
8624 |
An approach that limits the loss of privacy would be for a user agent to |
8625 |
omit the sending of Accept-Language headers by default, and to ask the |
8626 |
user whether it should start sending Accept-Language headers to a server |
8627 |
if it detects, by looking for any Vary or Alternates response headers |
8628 |
generated by the server, that such sending could improve the quality of |
8629 |
service. |
8630 |
|
8631 |
Elaborate user-customized accept header fields sent in every request, in |
8632 |
particular if these include quality values, can be used by servers as |
8633 |
relatively reliable and long-lived user identifiers. Such user |
8634 |
identifiers would allow content providers to do click-trail tracking, |
8635 |
and would allow collaborating content providers to match cross-server |
8636 |
click-trails or form submissions of individual users. Note that for |
8637 |
many users not behind a proxy, the network address of the host running |
8638 |
the user agent will also serve as a long-lived user identifier. In |
8639 |
environments where proxies are used to enhance privacy, user agents |
8640 |
should be conservative in offering accept header configuration options |
8641 |
to end users. As an extreme privacy measure, proxies could filter the |
8642 |
accept headers in relayed requests. General purpose user agents which |
8643 |
provide a high degree of header configurability should warn users about |
8644 |
the loss of privacy which can be involved. |
8645 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 144] |
8646 |
|
8647 |
|
8648 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8649 |
|
8650 |
|
8651 |
15.8 DNS Spoofing |
8652 |
Clients using HTTP rely heavily on the Domain Name Service, and are thus |
8653 |
generally prone to security attacks based on the deliberate miss- |
8654 |
association of IP addresses and DNS names. The deployment of DNSSEC[27] |
8655 |
|
8656 |
should help this situation. In advance of this deployment, however, |
8657 |
clients need to be cautious in assuming the continuing validity of an IP |
8658 |
number/DNS name association. |
8659 |
|
8660 |
In particular, HTTP clients SHOULD rely on their name resolver for |
8661 |
confirmation of an IP number/DNS name association, rather than caching |
8662 |
the result of previous host name lookups. Many platforms already can |
8663 |
cache host name lookups locally when appropriate, and they SHOULD be |
8664 |
configured to do so. These lookups should be cached, however, only when |
8665 |
the TTL (Time To Live) information reported by the name server makes it |
8666 |
likely that the cached information will remain useful. |
8667 |
|
8668 |
If HTTP clients cache the results of a host name lookups in order to |
8669 |
achieve a performance improvement, they MUST observe the TTL information |
8670 |
reported by DNS. |
8671 |
|
8672 |
If HTTP clients do not observe this rule, they could be spoofed when a |
8673 |
previously-accessed server's IP address changes. As renumbering is |
8674 |
expected to become increasingly common[24], the possibility of this form |
8675 |
|
8676 |
of attack will grow. Observing this requirement thus reduces this |
8677 |
potential security vulnerability. |
8678 |
|
8679 |
This requirement also improves the load-balancing behavior of clients |
8680 |
for replicated servers using the same DNS name and reduces the |
8681 |
likelihood of a user's experiencing failure in accessing sites which use |
8682 |
that strategy. |
8683 |
|
8684 |
|
8685 |
15.9 SLUSHY: Location Headers and Spoofing |
8686 |
If a single server supports multiple organizations that do not trust one |
8687 |
another, then it must check the values of Location and Content-Location |
8688 |
headers in responses that are generated under control of said |
8689 |
organizations to make sure that they do not attempt to invalidate |
8690 |
resources over which they have no authority. |
8691 |
|
8692 |
|
8693 |
16. Acknowledgments |
8694 |
This specification makes heavy use of the augmented BNF and generic |
8695 |
constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it |
8696 |
reuses many of the definitions provided by Nathaniel Borenstein and Ned |
8697 |
Freed for MIME [7]. We hope that their inclusion in this specification |
8698 |
will help reduce past confusion over the relationship between HTTP and |
8699 |
Internet mail message formats. |
8700 |
|
8701 |
The HTTP protocol has evolved considerably over the past four years. It |
8702 |
has benefited from a large and active developer community--the many |
8703 |
people who have participated on the www-talk mailing list--and it is |
8704 |
that community which has been most responsible for the success of HTTP |
8705 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 145] |
8706 |
|
8707 |
|
8708 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8709 |
|
8710 |
|
8711 |
and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, |
8712 |
Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip |
8713 |
M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, |
8714 |
Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special |
8715 |
recognition for their efforts in defining early aspects of the protocol. |
8716 |
|
8717 |
This document has benefited greatly from the comments of all those |
8718 |
participating in the HTTP-WG. In addition to those already mentioned, |
8719 |
the following individuals have contributed to this specification: |
8720 |
|
8721 |
Gary Adams Harald Tveit Alvestrand |
8722 |
Keith Ball Brian Behlendorf |
8723 |
Paul Burchard Maurizio Codogno |
8724 |
Mike Cowlishaw Roman Czyborra |
8725 |
Michael A. Dolan Jim Gettys |
8726 |
Marc Hedlund Koen Holtman |
8727 |
Alex Hopmann Bob Jernigan |
8728 |
Shel Kaphan Rohit Khare |
8729 |
Martijn Koster Alexei Kosut |
8730 |
David M. Kristol Daniel LaLiberte |
8731 |
Paul J. Leach Albert Lunde |
8732 |
John C. Mallery Jean-Philippe Martin-Flatin |
8733 |
Larry Masinter Mitra |
8734 |
Jeffrey Mogul Gavin Nicol |
8735 |
Bill Perry Jeffrey Perry |
8736 |
Owen Rees Luigi Rizzo |
8737 |
David Robinson Marc Salomon |
8738 |
Rich Salz Jim Seidman |
8739 |
Chuck Shotton Eric W. Sink |
8740 |
Simon E. Spero Richard N. Taylor |
8741 |
Robert S. Thau Francois Yergeau |
8742 |
Mary Ellen Zurko David Morris |
8743 |
Greg Herlihy Scott Powers |
8744 |
Allan M. Schiffman Alan Freier |
8745 |
Bill (BearHeart) Weinman |
8746 |
|
8747 |
|
8748 |
Much of the content and presentation of the caching design is due to |
8749 |
suggestions and comments from individuals including: Shel Kaphan, Paul |
8750 |
Leach, Koen Holtman, David Morris, Larry Masinter, and Roy Fielding. |
8751 |
|
8752 |
Most of the specification of ranges is based on work originally done by |
8753 |
Ari Luotonen and John Franks, with additional input from Steve Zilles |
8754 |
and Roy Fielding. |
8755 |
|
8756 |
XXX need acks for subgroup work. |
8757 |
|
8758 |
|
8759 |
|
8760 |
|
8761 |
|
8762 |
|
8763 |
|
8764 |
|
8765 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 146] |
8766 |
|
8767 |
|
8768 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8769 |
|
8770 |
|
8771 |
17. References |
8772 |
|
8773 |
[1] |
8774 |
H. Alvestrand. _Tags for the identification of languages._ RFC 1766, |
8775 |
|
8776 |
UNINETT, March 1995. |
8777 |
|
8778 |
[2] |
8779 |
F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. |
8780 |
Alberti. _The Internet Gopher Protocol: (a distributed document |
8781 |
|
8782 |
search and retrieval protocol)_, RFC 1436, University of Minnesota, |
8783 |
March 1993. |
8784 |
|
8785 |
[3] |
8786 |
T. Berners-Lee. _Universal Resource Identifiers in WWW A Unifying |
8787 |
|
8788 |
Syntax for the Expression of Names and Addresses of Objects on the |
8789 |
Network as used in the World-Wide Web._ RFC 1630, CERN, June 1994. |
8790 |
|
8791 |
[4] |
8792 |
T. Berners-Lee, L. Masinter, M. McCahill. |
8793 |
_Uniform Resource Locators (URL)._ RFC 1738, CERN, Xerox PARC, |
8794 |
|
8795 |
University of Minnesota, December 1994. |
8796 |
|
8797 |
[5] |
8798 |
T. Berners-Lee, D. Connolly. |
8799 |
_HyperText Markup Language Specification - 2.0._ RFC 1866, MIT/LCS, |
8800 |
|
8801 |
November 1995. |
8802 |
|
8803 |
[6] |
8804 |
T. Berners-Lee, R. Fielding, H. Frystyk. |
8805 |
"Hypertext Transfer Protocol - HTTP/1.0." Work in Progress (draft- |
8806 |
|
8807 |
ietf-http-v10-spec-04.txt), MIT/LCS, UC Irvine, September 1995. |
8808 |
|
8809 |
[7] |
8810 |
N. Borenstein, N. Freed. |
8811 |
_MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms |
8812 |
|
8813 |
for Specifying and Describing the Format of Internet Message Bodies." |
8814 |
RFC 1521, Bellcore, Innosoft, September 1993. |
8815 |
|
8816 |
[8] |
8817 |
R. Braden. |
8818 |
_Requirements for Internet hosts - application and support._ STD 3, |
8819 |
|
8820 |
RFC 1123, IETF, October 1989. |
8821 |
|
8822 |
[9] |
8823 |
D. H. Crocker. |
8824 |
|
8825 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 147] |
8826 |
|
8827 |
|
8828 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8829 |
|
8830 |
|
8831 |
_Standard for the Format of ARPA Internet Text Messages._ STD 11, RFC |
8832 |
|
8833 |
822, UDEL, August 1982. |
8834 |
|
8835 |
[10] |
8836 |
F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, M. |
8837 |
Grinbaum. _WAIS Interface Protocol Prototype Functional |
8838 |
Specification._ (v1.5), Thinking Machines Corporation, April 1990. |
8839 |
|
8840 |
[11] |
8841 |
R. Fielding. _Relative Uniform Resource Locators._ RFC 1808, UC |
8842 |
|
8843 |
Irvine, June 1995. |
8844 |
|
8845 |
[12] |
8846 |
M. Horton, R. Adams. _Standard for interchange of USENET messages._ |
8847 |
|
8848 |
RFC 1036 (Obsoletes RFC 850), AT&T Bell Laboratories, Center for |
8849 |
Seismic Studies, December 1987. |
8850 |
|
8851 |
[13] |
8852 |
B. Kantor, P. Lapsley. _Network News Transfer Protocol A Proposed |
8853 |
|
8854 |
Standard for the Stream-Based Transmission of News._ RFC 977, UC San |
8855 |
Diego, UC Berkeley, February 1986. |
8856 |
|
8857 |
[14] |
8858 |
K. Moore. _MIME (Multipurpose Internet Mail Extensions) Part Two : |
8859 |
|
8860 |
Message Header Extensions for Non-ASCII Text._ RFC 1522, University |
8861 |
of Tennessee, September 1993. |
8862 |
|
8863 |
[15] |
8864 |
E. Nebel, L. Masinter. _Form-based File Upload in HTML._ RFC 1867, |
8865 |
|
8866 |
Xerox Corporation, November 1995. |
8867 |
|
8868 |
[16] |
8869 |
J. Postel. _Simple Mail Transfer Protocol._ STD 10, RFC 821, USC/ISI, |
8870 |
|
8871 |
August 1982. |
8872 |
|
8873 |
[17] |
8874 |
J. Postel. _Media Type Registration Procedure._ RFC 1590, USC/ISI, |
8875 |
|
8876 |
March 1994. |
8877 |
|
8878 |
[18] |
8879 |
J. Postel, J. K. Reynolds. _File Transfer Protocol (FTP)_ STD 9, RFC |
8880 |
|
8881 |
959, USC/ISI, October 1985. |
8882 |
|
8883 |
|
8884 |
|
8885 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 148] |
8886 |
|
8887 |
|
8888 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8889 |
|
8890 |
|
8891 |
[19] |
8892 |
J. Reynolds, J. Postel. _Assigned Numbers._ STD 2, RFC 1700, USC/ISI, |
8893 |
|
8894 |
October 1994. |
8895 |
|
8896 |
[20] |
8897 |
K. Sollins, L. Masinter. |
8898 |
_Functional Requirements for Uniform Resource Names._ RFC 1737, |
8899 |
|
8900 |
MIT/LCS, Xerox Corporation, December 1994. |
8901 |
|
8902 |
[21] |
8903 |
US-ASCII. Coded Character Set - 7-Bit American Standard Code for |
8904 |
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. |
8905 |
|
8906 |
[22] |
8907 |
ISO-8859. International Standard -- Information Processing -- |
8908 |
8-bit Single-Byte Coded Graphic Character Sets -- |
8909 |
Part 1: Latin alphabet No. 1, ISO 8859-1:1987. |
8910 |
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. |
8911 |
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. |
8912 |
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. |
8913 |
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. |
8914 |
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. |
8915 |
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. |
8916 |
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. |
8917 |
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. |
8918 |
|
8919 |
[23] |
8920 |
Meyers, M. Rose _The Content-MD5 Header Field._ RFC 1864, Carnegie |
8921 |
|
8922 |
Mellon, Dover Beach Consulting, October, 1995. |
8923 |
|
8924 |
[24] |
8925 |
B. Carpenter, Y. Rekhter, _Renumbering Needs Work_. RFC 1900, IAB, |
8926 |
|
8927 |
February 1996. |
8928 |
|
8929 |
[25] |
8930 |
Gzip is available from the GNU project at |
8931 |
<URL:ftp://prep.ai.mit.edu/pub/gnu/>. A more formal specification is |
8932 |
|
8933 |
currently a work in progress. |
8934 |
|
8935 |
[26] |
8936 |
Work In Progress for Digest authentication of the IETF HTTP working |
8937 |
group. |
8938 |
|
8939 |
[27] |
8940 |
TBS, Work in progress (XXX should put RFC in here_ ) |
8941 |
|
8942 |
[28] |
8943 |
Mills, D, _Network Time Protocol, Version 3_, Specification, |
8944 |
|
8945 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 149] |
8946 |
|
8947 |
|
8948 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
8949 |
|
8950 |
|
8951 |
Implementation and Analysis RFC 1305, University of Delaware, March, |
8952 |
1992. |
8953 |
|
8954 |
[29] |
8955 |
Work in progress of the HTTP working group (XXX is this correct |
8956 |
reference for incomplete work?). |
8957 |
|
8958 |
[30] |
8959 |
S. Spero. _Analysis of HTTP Performance Problems_ |
8960 |
<URL:http://sunsite.unc.edu/mdma-release/http-prob.html> |
8961 |
|
8962 |
[31] |
8963 |
E. Rescorla, A. Schiffman _The Secure HyperText Transfer Protocol_ |
8964 |
Internet-Draft (work in progress). |
8965 |
|
8966 |
[32] |
8967 |
A. Freier, P Karlton, P. Kocher. _SSL Version 3.0" Internet-Draft_ |
8968 |
(work in progress). |
8969 |
|
8970 |
[33] |
8971 |
Jeffrey C. Mogul. _The Case for Persistent-Connection HTTP_. In |
8972 |
Proc.SIGCOMM '95 Symposium on Communications Architectures and |
8973 |
Protocols, pages 299-313. Cambridge, MA, August, 1995. |
8974 |
|
8975 |
[34] |
8976 |
Jeffrey C. Mogul. _The Case for Persistent-Connection HTTP_. |
8977 |
Research, Report 95/4, Digital Equipment Corporation Western Research |
8978 |
Laboratory, May, 1995., |
8979 |
<URL |
8980 |
:http://www.research.digital.com/wrl/techreports/abstracts/95.4.html> |
8981 |
|
8982 |
[35] |
8983 |
Work in progress of the HTTP working group on state management. |
8984 |
|
8985 |
|
8986 |
|
8987 |
|
8988 |
|
8989 |
18. Authors' Addresses |
8990 |
Roy T. Fielding |
8991 |
|
8992 |
Department of Information and Computer Science |
8993 |
University of California |
8994 |
Irvine, CA 92717-3425, USA |
8995 |
Fax: +1 (714) 824-4056 |
8996 |
Email: fielding@ics.uci.edu |
8997 |
|
8998 |
Henrik Frystyk Nielsen |
8999 |
|
9000 |
W3 Consortium |
9001 |
MIT Laboratory for Computer Science |
9002 |
545 Technology Square |
9003 |
Cambridge, MA 02139, USA |
9004 |
|
9005 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 150] |
9006 |
|
9007 |
|
9008 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9009 |
|
9010 |
|
9011 |
Fax: +1 (617) 258 8682 |
9012 |
Email: frystyk@w3.org |
9013 |
|
9014 |
Tim Berners-Lee |
9015 |
|
9016 |
Director, W3 Consortium |
9017 |
MIT Laboratory for Computer Science |
9018 |
545 Technology Square |
9019 |
Cambridge, MA 02139, USA |
9020 |
Fax: +1 (617) 258 8682 |
9021 |
Email: timbl@w3.org |
9022 |
|
9023 |
Jim Gettys |
9024 |
|
9025 |
MIT Laboratory for Computer Science |
9026 |
545 Technology Square |
9027 |
Cambridge, MA 02139, USA |
9028 |
Fax: +1 (617) 258 8682 |
9029 |
Email: jg@w3.org |
9030 |
|
9031 |
Jeffrey C. Mogul |
9032 |
|
9033 |
Western Research Laboratory |
9034 |
Digital Equipment Corporation |
9035 |
250 University Avenue |
9036 |
Palo Alto, California, 94305, U.S.A. |
9037 |
Email: mogul@wrl.dec.com |
9038 |
|
9039 |
|
9040 |
|
9041 |
|
9042 |
Appendices |
9043 |
These appendices are provided for informational reasons only -- they do |
9044 |
not form a part of the HTTP/1.1 specification. |
9045 |
|
9046 |
|
9047 |
A. Internet Media Type message/http |
9048 |
In addition to defining the HTTP/1.1 protocol, this document serves as |
9049 |
the specification for the Internet media type _message/http_. The |
9050 |
following is to be registered with IANA [17]. |
9051 |
|
9052 |
|
9053 |
|
9054 |
|
9055 |
|
9056 |
|
9057 |
|
9058 |
|
9059 |
|
9060 |
|
9061 |
|
9062 |
|
9063 |
|
9064 |
|
9065 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 151] |
9066 |
|
9067 |
|
9068 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9069 |
|
9070 |
|
9071 |
Media Type name: message |
9072 |
|
9073 |
Media subtype name: http |
9074 |
|
9075 |
Required parameters: none |
9076 |
|
9077 |
Optional parameters: version, msgtype |
9078 |
|
9079 |
version: The HTTP-Version number of the enclosed message |
9080 |
(e.g., "1.1"). If not present, the version can be |
9081 |
determined from the first line of the body. |
9082 |
|
9083 |
msgtype: The message type -- "request" or "response". If not |
9084 |
present, the type can be determined from the first |
9085 |
line of the body. |
9086 |
|
9087 |
Encoding considerations: only "7bit", "8bit", or "binary" are |
9088 |
permitted |
9089 |
|
9090 |
Security considerations: none |
9091 |
|
9092 |
|
9093 |
|
9094 |
|
9095 |
B. Tolerant Applications |
9096 |
Although this document specifies the requirements for the generation of |
9097 |
HTTP/1.1 messages, not all applications will be correct in their |
9098 |
implementation. We therefore recommend that operational applications be |
9099 |
tolerant of deviations whenever those deviations can be interpreted |
9100 |
|
9101 |
|
9102 |
Clients SHOULD be tolerant in parsing the Status-Line and servers |
9103 |
tolerant when parsing the Request-Line. In particular, they SHOULD |
9104 |
characters between fields, even though unambiguously. accept any amount of SP or HT |
9105 |
only a single SP is required. |
9106 |
|
9107 |
The line terminator for HTTP-header fields is the sequence CRLF. |
9108 |
However, we recommend that applications, when parsing such headers, |
9109 |
recognize a single LF as a line terminator and ignore the leading CR. |
9110 |
|
9111 |
|
9112 |
C. Differences Between HTTP Bodies and RFC 1521 Internet Message Bodies |
9113 |
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 |
9114 |
[9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow |
9115 |
|
9116 |
entities to be transmitted in an open variety of representations and |
9117 |
with extensible mechanisms. However, RFC 1521 discusses mail, and HTTP |
9118 |
has a few features that are different than those described in RFC 1521. |
9119 |
These differences were carefully chosen to optimize performance over |
9120 |
binary connections, to allow greater freedom in the use of new media |
9121 |
types, to make date comparisons easier, and to acknowledge the practice |
9122 |
of some early HTTP servers and clients. |
9123 |
|
9124 |
|
9125 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 152] |
9126 |
|
9127 |
|
9128 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9129 |
|
9130 |
|
9131 |
At the time of this writing, it is expected that RFC 1521 will be |
9132 |
revised. The revisions may include some of the practices found in |
9133 |
HTTP/1.1 but not in RFC 1521. |
9134 |
|
9135 |
This appendix describes specific areas where HTTP differs from RFC 1521. |
9136 |
Proxies and gateways to strict MIME environments SHOULD be aware of |
9137 |
these differences and provide the appropriate conversions where |
9138 |
necessary. Proxies and gateways from MIME environments to HTTP also need |
9139 |
to be aware of the differences because some conversions may be required. |
9140 |
|
9141 |
|
9142 |
C.1 Conversion to Canonical Form |
9143 |
RFC 1521 requires that an Internet mail entity be converted to canonical |
9144 |
form prior to being transferred, as described in Appendix G of RFC 1521 |
9145 |
[7]. Section 3.6.1 of this document describes the forms allowed for |
9146 |
|
9147 |
subtypes of the _text_ media type when transmitted over HTTP. RFC 1521 |
9148 |
requires that content with a typeof _text_ represent line breaks as |
9149 |
CRLF and forbids the use of CR or LF outside of line break sequences. |
9150 |
HTTP allows CRLF, bare CR, and bare LF to indicate a line break within |
9151 |
text content when a message is transmitted over HTTP. |
9152 |
|
9153 |
Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521 |
9154 |
environment SHOULD translate all line breaks within the text media types |
9155 |
described in Section 3.6.1 of this document to the RFC 1521 canonical |
9156 |
|
9157 |
form of CRLF. Note, however, that this may be complicated by the |
9158 |
presence of a Content-Encoding and by the fact that HTTP allows the use |
9159 |
of some character sets which do not use octets 13 and 10 to represent CR |
9160 |
and LF, as is the case for some multi-byte character sets. |
9161 |
|
9162 |
|
9163 |
C.2 Conversion of Date Formats |
9164 |
HTTP/1.1 uses a restricted set of date formats (Section 3.3) to simplify |
9165 |
|
9166 |
the process of date comparison. Proxies and gateways from other |
9167 |
protocols SHOULD ensure that any Date header field present in a message |
9168 |
conforms to one of the HTTP/1.1 formats and rewrite the date if |
9169 |
necessary. |
9170 |
|
9171 |
|
9172 |
C.3 Introduction of Content-Encoding |
9173 |
RFC 1521 does not include any concept equivalent to HTTP/1.1's Content- |
9174 |
Encoding header field. Since this acts as a modifier on the media type, |
9175 |
proxies and gateways from HTTP to MIME-compliant protocols MUST either |
9176 |
change the value of the Content-Type header field or decode the Entity- |
9177 |
Body before forwarding the message. (Some experimental applications of |
9178 |
Content-Type for Internet mail have used a media-type parameter of |
9179 |
_;conversions=<content-coding>_ to perform an equivalent function as |
9180 |
Content-Encoding. However, this parameter is not part of RFC 1521.) |
9181 |
|
9182 |
|
9183 |
|
9184 |
|
9185 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 153] |
9186 |
|
9187 |
|
9188 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9189 |
|
9190 |
|
9191 |
C.4 No Content-Transfer-Encoding |
9192 |
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 1521. |
9193 |
Proxies and gateways from MIME-compliant protocols to HTTP MUST remove |
9194 |
any non-identity CTE (_quoted-printable_ or _base64_) encoding prior to |
9195 |
delivering the response message to an HTTP client. |
9196 |
|
9197 |
Proxies and gateways from HTTP to MIME-compliant protocols are |
9198 |
responsible for ensuring that the message is in the correct format and |
9199 |
encoding for safe transport on that protocol, where _safe transport_ is |
9200 |
defined by the limitations of the protocol being used. Such a proxy or |
9201 |
gateway SHOULD label the data with an appropriate Content-Transfer- |
9202 |
Encoding if doing so will improve the likelihood of safe transport over |
9203 |
the destination protocol. |
9204 |
|
9205 |
|
9206 |
C.5 HTTP Header Fields in Multipart Body-Parts |
9207 |
In RFC 1521, most header fields in multipart body-parts are generally |
9208 |
ignored unless the field name begins with _Content-_. In HTTP/1.1, |
9209 |
multipart body-parts may contain any HTTP header fields which are |
9210 |
significant to the meaning of that part. |
9211 |
|
9212 |
|
9213 |
|
9214 |
|
9215 |
C.6 Introduction of Transfer-Encoding |
9216 |
HTTP/1.1 introduces the Transfer-Encoding header field (Section 10.39). |
9217 |
|
9218 |
Proxies/gateways MUST remove any transfer coding prior to forwarding a |
9219 |
message via a MIME-compliant protocol. The process for decoding the |
9220 |
_chunked_ transfer coding (Section 3.6) can be represented in pseudo- |
9221 |
|
9222 |
code as: |
9223 |
|
9224 |
length := 0 |
9225 |
read chunk-size and CRLF |
9226 |
while (chunk-size > 0) { |
9227 |
read chunk-data and CRLF |
9228 |
append chunk-data to Entity-Body |
9229 |
length := length + chunk-size |
9230 |
read chunk-size and CRLF |
9231 |
} |
9232 |
read entity-header |
9233 |
while (entity-header not empty) { |
9234 |
append entity-header to existing header fields |
9235 |
read entity-header |
9236 |
} |
9237 |
Content-Length := length |
9238 |
Remove "chunked" from Transfer-Encoding |
9239 |
|
9240 |
|
9241 |
|
9242 |
|
9243 |
|
9244 |
|
9245 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 154] |
9246 |
|
9247 |
|
9248 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9249 |
|
9250 |
|
9251 |
C.7 MIME-Version |
9252 |
HTTP is not a MIME-compliant protocol (see Appendix C). However, |
9253 |
|
9254 |
HTTP/1.1 messages may include a single MIME-Version general-header field |
9255 |
to indicate what version of the MIME protocol was used to construct the |
9256 |
message. Use of the MIME-Version header field indicates that the message |
9257 |
is in full compliance with the MIME protocol (as defined in [7]). |
9258 |
|
9259 |
Proxies/gateways are responsible for ensuring full compliance (where |
9260 |
possible) when exporting HTTP messages to strict MIME environments. |
9261 |
|
9262 |
|
9263 |
|
9264 |
|
9265 |
|
9266 |
MIME version _1.0_ is the default for use in HTTP/1.1. However, HTTP/1.1 |
9267 |
message parsing and semantics are defined by this document and not the |
9268 |
MIME specification. |
9269 |
|
9270 |
|
9271 |
D. Changes from HTTP/1.0 |
9272 |
This section will summarize major differences between versions 1.0 and MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT |
9273 |
1.1 of the Hypertext Transfer Protocol. |
9274 |
|
9275 |
|
9276 |
D.1 Changes to Simplify Multi-homed Web Servers and Conserve IP |
9277 |
Addresses |
9278 |
The requirements that clients and servers support the Host request- |
9279 |
header, report an error if the Host request-header is missing from an |
9280 |
HTTP/1.1 request (Section 10.22), and accept absolute URIs (Section |
9281 |
5.1.2) are among the most important changes from HTTP/1.0. |
9282 |
|
9283 |
In HTTP/1.0 there is a one-to-one relationship of IP addresses and |
9284 |
servers. There is no other way to distinguish the intended server of a |
9285 |
request than the IP address to which that request is directed. The |
9286 |
HTTP/1.1 change will allow the Internet, once HTTP/1.0 clients and |
9287 |
servers are no longer common, to support multiple Web sites from a |
9288 |
single IP address, greatly simplifying large operational Web servers, |
9289 |
where allocation of many IP addresses to a single host has created |
9290 |
serious problems. The Internet will also be able to recover the IP |
9291 |
addresses that have been used for the sole purpose of allowing root- |
9292 |
level domain names to be used in HTTP URLs. Given the rate of growth of |
9293 |
the Web, and the number of servers already deployed, it is extremely |
9294 |
important that implementations of HTTP/1.1 correctly implement these new |
9295 |
requirements: |
9296 |
|
9297 |
|
9298 |
. both clients and servers MUST support the Host request-header |
9299 |
|
9300 |
. Host request-headers are required in HTTP/1.1 requests. |
9301 |
|
9302 |
. servers MUST report an error if an HTTP/1.1 request does not |
9303 |
include a Host request-header |
9304 |
|
9305 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 155] |
9306 |
|
9307 |
|
9308 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9309 |
|
9310 |
|
9311 |
. servers MUST accept absolute URIs |
9312 |
|
9313 |
E. Additional Features |
9314 |
This appendix documents protocol elements used by some existing HTTP |
9315 |
implementations, but not consistently and correctly across most HTTP/1.1 |
9316 |
applications. Implementers should be aware of these features, but cannot |
9317 |
rely upon their presence in, or interoperability with, other HTTP/1.1 |
9318 |
applications. |
9319 |
|
9320 |
|
9321 |
E.1 Additional Request Methods |
9322 |
|
9323 |
E.1.1 PATCH |
9324 |
The PATCH method is similar to PUT except that the entity contains a |
9325 |
list of differences between the original version of the resource |
9326 |
identified by the Request-URI and the desired content of the resource |
9327 |
after the PATCH action has been applied. The list of differences is in a |
9328 |
format defined by the media type of the entity (e.g., |
9329 |
_application/diff_) and MUST include sufficient information to allow the |
9330 |
server to recreate the changes necessary to convert the original version |
9331 |
of the resource to the desired version. |
9332 |
|
9333 |
If the request passes through a cache and the Request-URI identifies a |
9334 |
currently cached entity, that entity MUST be removed from the cache. |
9335 |
Responses to this method are not cachable. |
9336 |
|
9337 |
For compatibility with HTTP/1.0 applications, all PATCH requests MUST |
9338 |
include a valid Content-Length header field unless the server is known |
9339 |
to be HTTP/1.1 compliant. When sending a PATCH request to an HTTP/1.1 |
9340 |
server, a client MUST use a valid Content-Length or the _chunked_ |
9341 |
Transfer-Encoding. The server SHOULD respond with a 400 (bad request) |
9342 |
message if it cannot determine the length of the request message's |
9343 |
content, or with 411 (length required) if it wishes to insist on |
9344 |
receiving a valid Content-Length. |
9345 |
|
9346 |
The actual method for determining how the patched resource is placed, |
9347 |
and what happens to its predecessor, is defined entirely by the origin |
9348 |
server. If the original version of the resource being patched included a |
9349 |
Content-Version header field, the request entity MUST include a Derived- |
9350 |
From header field corresponding to the value of the original Content- |
9351 |
Version header field. Applications are encouraged to use these fields |
9352 |
for constructing versioning relationships and resolving version |
9353 |
conflicts. |
9354 |
|
9355 |
PATCH requests must obey the entity transmission requirements set out in |
9356 |
section 8.4.1. |
9357 |
|
9358 |
Caches that implement PATCH should invalidate cached responses as |
9359 |
defined in section 13.17 for PUT. |
9360 |
|
9361 |
|
9362 |
|
9363 |
|
9364 |
|
9365 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 156] |
9366 |
|
9367 |
|
9368 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9369 |
|
9370 |
|
9371 |
E.1.2 LINK |
9372 |
The LINK method establishes one or more Link relationships between the |
9373 |
existing resource identified by the Request-URI and other existing |
9374 |
resources. The difference between LINK and other methods allowing links |
9375 |
to be established between resources is that the LINK method does not |
9376 |
allow any Entity-Body to be sent in the request and does not directly |
9377 |
result in the creation of new resources. |
9378 |
|
9379 |
If the request passes through a cache and the Request-URI identifies a |
9380 |
currently cached entity, that entity MUST be removed from the cache. |
9381 |
Responses to this method are not cachable. |
9382 |
|
9383 |
Caches that implement LINK should invalidate cached responses as defined |
9384 |
in section 13.17 for PUT. |
9385 |
|
9386 |
|
9387 |
E.1.3 UNLINK |
9388 |
The UNLINK method removes one or more Link relationships from the |
9389 |
existing resource identified by the Request-URI. These relationships may |
9390 |
have been established using the LINK method or by any other method |
9391 |
supporting the Link header. The removal of a link to a resource does not |
9392 |
imply that the resource ceases to exist or becomes inaccessible for |
9393 |
future references. |
9394 |
|
9395 |
If the request passes through a cache and the Request-URI identifies a |
9396 |
currently cached entity, that entity MUST be removed from the cache. |
9397 |
Responses to this method are not cachable. |
9398 |
|
9399 |
Caches that implement UNLINK should invalidate cached responses as |
9400 |
defined in section 13.17 for PUT. |
9401 |
|
9402 |
|
9403 |
E.2 Additional Header Field Definitions |
9404 |
|
9405 |
E.2.1 Content-Version |
9406 |
The Content-Version entity-header field defines the version tag |
9407 |
associated with a rendition of an evolving entity. Together with the |
9408 |
Derived-From field described in Section 10.18, it allows a group of |
9409 |
|
9410 |
people to work simultaneously on the creation of a work as an iterative |
9411 |
process. The field SHOULD be used to allow evolution of a particular |
9412 |
work along a single path. It SHOULD NOT be used to indicate derived |
9413 |
works or renditions in different representations. It MAY also me used as |
9414 |
an opaque value for comparing a cached entity's version with that of the |
9415 |
current resource. |
9416 |
|
9417 |
Content-Version = "Content-Version" ":" quoted-string |
9418 |
|
9419 |
|
9420 |
|
9421 |
Examples of the Content-Version field include: |
9422 |
|
9423 |
|
9424 |
|
9425 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 157] |
9426 |
|
9427 |
|
9428 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9429 |
|
9430 |
|
9431 |
Content-Version: "2.1.2" |
9432 |
|
9433 |
Content-Version: "Fred 19950116-12:26:48" |
9434 |
|
9435 |
Content-Version: "2.5a4-omega7" |
9436 |
|
9437 |
|
9438 |
|
9439 |
The value of the Content-Version field SHOULD be considered opaque to |
9440 |
all parties but the origin server. A user agent MAY suggest a value for |
9441 |
the version of an entity transferred via a PUT request; however, only |
9442 |
the origin server can reliably assign that value. |
9443 |
|
9444 |
|
9445 |
E.2.2 Derived-From |
9446 |
The Derived-From entity-header field can be used to indicate the version |
9447 |
tag of the resource from which the enclosed entity was derived before |
9448 |
modifications were made by the sender. This field is used to help manage |
9449 |
the process of merging successive changes to a resource, particularly |
9450 |
when such changes are being made in parallel and from multiple sources. |
9451 |
|
9452 |
Derived-From = "Derived-From" ":" quoted-string |
9453 |
|
9454 |
An example use of the field is: |
9455 |
|
9456 |
Derived-From: "2.1.1" |
9457 |
|
9458 |
The Derived-From field is required for PUT and PATCH requests if the |
9459 |
entity being sent was previously retrieved from the same URI and a |
9460 |
Content-Version header was included with the entity when it was last |
9461 |
retrieved. |
9462 |
|
9463 |
|
9464 |
E.2.3 Link |
9465 |
The Link entity-header field provides a means for describing a |
9466 |
relationship between two resources, generally between the requested |
9467 |
resource and some other resource. An entity MAY include multiple Link |
9468 |
values. Links at the metainformation level typically indicate |
9469 |
relationships like hierarchical structure and navigation paths. The Link |
9470 |
field is semantically equivalent to the <LINK> element in HTML [5]. |
9471 |
|
9472 |
|
9473 |
|
9474 |
|
9475 |
|
9476 |
|
9477 |
|
9478 |
|
9479 |
|
9480 |
|
9481 |
|
9482 |
|
9483 |
|
9484 |
|
9485 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 158] |
9486 |
|
9487 |
|
9488 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9489 |
|
9490 |
|
9491 |
Link = "Link" ":" #("<" URI ">" *( ";" link-param ) |
9492 |
|
9493 |
link-param = ( ( "rel" "=" relationship ) |
9494 |
| ( "rev" "=" relationship ) |
9495 |
| ( "title" "=" quoted-string ) |
9496 |
| ( "anchor" "=" <"> URI <"> ) |
9497 |
|
9498 |
| ( link-extension ) ) |
9499 |
|
9500 |
link-extension = token [ "=" ( token | quoted-string ) ] |
9501 |
|
9502 |
|
9503 |
relationship = sgml-name |
9504 |
| ( <"> sgml-name *( SP sgml-name) <"> ) |
9505 |
|
9506 |
|
9507 |
sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) |
9508 |
|
9509 |
|
9510 |
|
9511 |
Relationship values are case-insensitive and MAY be extended within the |
9512 |
constraints of the sgml-name syntax. The title parameter MAY be used to |
9513 |
label the destination of a link such that it can be used as |
9514 |
identification within a human-readable menu. The anchor parameter MAY be |
9515 |
used to indicate a source anchor other than the entire current resource, |
9516 |
such as a fragment of this resource or a third resource. |
9517 |
|
9518 |
Examples of usage include: |
9519 |
|
9520 |
Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" |
9521 |
|
9522 |
Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee" |
9523 |
|
9524 |
|
9525 |
|
9526 |
The first example indicates that chapter2 is previous to this resource |
9527 |
in a logical navigation path. The second indicates that the person |
9528 |
responsible for making the resource available is identified by the given |
9529 |
e-mail address. |
9530 |
|
9531 |
|
9532 |
E.2.4 URI |
9533 |
The URI header field has, in past versions of this specification, been |
9534 |
used as a combination of the existing Location, Content-Location, and |
9535 |
Alternates header fields. Its primary purpose has been to include a list |
9536 |
of additional URIs for the resource, including names and mirror |
9537 |
locations. However, it has become clear that the combination of many |
9538 |
different functions within this single field has been a barrier to |
9539 |
consistently and correctly implementing any of those functions. |
9540 |
Furthermore, we believe that the identification of names and mirror |
9541 |
locations would be better performed via the Link header field. The URI |
9542 |
header field is therefore deprecated in favor of those other fields. |
9543 |
|
9544 |
|
9545 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 159] |
9546 |
|
9547 |
|
9548 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9549 |
|
9550 |
|
9551 |
URI-header = "URI" ":" 1#( "<" URI ">" ) |
9552 |
|
9553 |
|
9554 |
E.2.5 Compatibility with HTTP/1.0 Persistent Connections |
9555 |
Some clients and servers may wish to be compatible with some previous |
9556 |
implementations of persistent connections in HTTP version 1.0 clients |
9557 |
and servers. |
9558 |
|
9559 |
When connecting to an origin server an HTTP client MAY send the Keep- |
9560 |
Alive connection-token in addition to the Persist connection-token: |
9561 |
|
9562 |
Connection: Keep-Alive,Persist |
9563 |
|
9564 |
An HTTP/1.0 server would then respond with the Keep-Alive connection |
9565 |
token and the client may proceed with an HTTP/1.0 (or Keep-Alive) |
9566 |
persistent connection. |
9567 |
|
9568 |
An HTTP/1.1 server may also establish persistent connections with |
9569 |
HTTP/1.0 clients upon receipt of a Keep-Alive connection token. |
9570 |
|
9571 |
A persistent connection based on the Keep-Alive connection token MUST |
9572 |
only use the _Content-Length_ technique for marking the ending |
9573 |
boundaries of entity-bodies. It MAY use pipe-lining. |
9574 |
|
9575 |
A client MUST NOT send the Keep-Alive connection token to a proxy server |
9576 |
as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing |
9577 |
the Connection header field. |
9578 |
|
9579 |
|
9580 |
E.2.5.1 The Keep-Alive Header |
9581 |
When the Keep-Alive connection-token has been transmitted with a request |
9582 |
or a response a Keep-Alive header field MAY also be included. The Keep- |
9583 |
Alive header field takes the following form: |
9584 |
|
9585 |
Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param |
9586 |
|
9587 |
keepalive-param = param-name "=" value |
9588 |
|
9589 |
The Keep-Alive header itself is optional, and is used only if a |
9590 |
parameter is being sent. HTTP/1.1 does not define any parameters. |
9591 |
|
9592 |
If the Keep-Alive header is sent, the corresponding connection token |
9593 |
MUST be transmitted. The Keep-Alive header MUST be ignored if received |
9594 |
without the connection token. |
9595 |
|
9596 |
|
9597 |
F.1 Compatibility with Previous Versions |
9598 |
It is beyond the scope of a protocol specification to mandate compliance |
9599 |
with previous versions. HTTP /1.1 was deliberately designed, however, |
9600 |
to make supporting previous versions easy. While we are contemplating a |
9601 |
separate document containing advice to implementers, we feel it worth |
9602 |
noting that at the time of composing this specification, we would expect |
9603 |
commercial HTTP/1.1 servers to:: |
9604 |
|
9605 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 160] |
9606 |
|
9607 |
|
9608 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9609 |
|
9610 |
|
9611 |
. recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 |
9612 |
requests; |
9613 |
|
9614 |
. understand any valid request in the format of HTTP/0.9, 1.0, or |
9615 |
1.1; |
9616 |
|
9617 |
. respond appropriately with a message in the same major version used |
9618 |
by the client. |
9619 |
And we would expect HTTP/1.1 clients to: |
9620 |
|
9621 |
|
9622 |
. recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
9623 |
responses; |
9624 |
|
9625 |
. understand any valid response in the format of HTTP/0.9, 1.0, or |
9626 |
1.1. |
9627 |
For most implementations of HTTP/1.0, each connection is established by |
9628 |
the client prior to the request and closed by the server after sending |
9629 |
the response. A few implementations implement the Keep-Alive version of |
9630 |
persistent connections described in Section E.2.5.1. |
9631 |
|
9632 |
|
9633 |
G. Proxy Cache Implementation Guidelines |
9634 |
|
9635 |
G.1 Support for Content Negotiation by Proxy Caches |
9636 |
The material in appendix G should go into a separate implementation |
9637 |
guide as an informational RFC, rather than in this specification. (since |
9638 |
it mostly describes 3 possible cache implementation strategies possible |
9639 |
within the protocol, rather than just the two protocol facilities |
9640 |
(transparent and opaque)). For the purposes of this (02) draft, we will |
9641 |
leave it in as an appendix as it clarifies some points of how caching |
9642 |
might work in the context of the HTTP/1.1 protocol. |
9643 |
|
9644 |
If a resource is varying, this has an important effect on cache |
9645 |
management, particularly for caching proxies which service a diverse set |
9646 |
of user agents. Such proxy caches must correctly handle requests on |
9647 |
varying resources in order not to disturb the negotiation process. |
9648 |
|
9649 |
This specification distinguishes six levels of correct support for |
9650 |
content negotiation by proxy caches. The text below describes these |
9651 |
levels, but does not exhaustively list all mechanisms associated with |
9652 |
support on these levels. In particular, mechanisms for handling partial |
9653 |
requests on varying resources are not discussed. |
9654 |
|
9655 |
1. A proxy cache providing level 1 support will never store in cache |
9656 |
memory responses from varying resources (such responses always |
9657 |
include at least one Vary header or Alternates header). When |
9658 |
receiving a request on a varying resource, the proxy will thus |
9659 |
always forward the request towards an upstream server. A level 1 |
9660 |
proxy cache never makes selection decisions itself. |
9661 |
2. A proxy cache providing level 2 support is able to maintain in |
9662 |
cache memory a mapping from the varying resource URI to a set of |
9663 |
200 (OK) response messages. When receiving a request on the |
9664 |
varying resource, the proxy will forward this request to an |
9665 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 161] |
9666 |
|
9667 |
|
9668 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9669 |
|
9670 |
|
9671 |
upstream server after including an If-Invalid request header field |
9672 |
listing the CVal header values of the associated cached 200 |
9673 |
responses, as described in Section 10.52. If a 304 (Not Modified) |
9674 |
response is received from the upstream server, the proxy updates, |
9675 |
with the 304 response headers, the stored 200 response which has |
9676 |
the same CVal header field as the 304 response. It then passes |
9677 |
either the updated 200 response or the 304 response on to its |
9678 |
client, the choice depending on the presence and contents of an If- |
9679 |
Invalid header in the original request. If a 200 response is |
9680 |
received from the upstream server, the proxy will update the set of |
9681 |
responses it has for the varying resource by using the cache update |
9682 |
algorithm described in Section 13.20, and pass on the 200 response |
9683 |
to its client. |
9684 |
3. A proxy cache providing level 3 support is able to maintain in |
9685 |
cache memory a mapping from the varying resource URI to a set of |
9686 |
200 (OK) response messages. In addition, it is able to maintain, |
9687 |
for each cached 200 response belonging to the varying resource, a |
9688 |
list of selecting request header sequences. This list of selecting |
9689 |
request header sequences starts with the sequence taken from the |
9690 |
request which initially caused an upstream server to return the |
9691 |
cached 200 response, and continues with any additional sequences |
9692 |
taken from subsequent requests which caused an upstream server to |
9693 |
return a 304 response with a CVal header identical to the CVal |
9694 |
header of that cached 200 response. When receiving a request on |
9695 |
the varying resource, the proxy will iterate over all cached, fresh |
9696 |
200 responses associated with the resource. For each fresh 200 |
9697 |
response, it will search the associated list of selecting request |
9698 |
header sequences to see if a match to the headers of the current |
9699 |
request can be found. If a match is found, the proxy will return |
9700 |
the fresh 200 response in question. If no match is found, the |
9701 |
proxy will switch to level 1 behavior and pass on the request to an |
9702 |
upstream server. The response received from the upstream server |
9703 |
may refresh a stale 200 response that was cached for the varying |
9704 |
resource a side effect. XXX previous sentence doesn't make sense_ |
9705 |
4. A proxy cache providing level 4 support provides transparent |
9706 |
negotiation services for transparently negotiated resources, and |
9707 |
provides level 1 support for opaquely negotiated resources. |
9708 |
5. A proxy cache providing level 5 support provides transparent |
9709 |
negotiation services for transparently negotiated resources, and |
9710 |
provides level 2 support for opaquely negotiated resources. |
9711 |
6. A proxy cache providing level 6 support provides transparent |
9712 |
negotiation services for transparently negotiated resources, and |
9713 |
provides level 3 support for opaquely negotiated resources. |
9714 |
Note: Implementation of support levels 4 to 6 is only possible |
9715 |
when the planned content negotiation specification [29] is |
9716 |
completed. The level numbers above were assigned to reflect |
9717 |
expected caching efficiency in an environment where the proxy |
9718 |
cache is serving a diverse set of clients. It is expected that |
9719 |
level 4 proxies will be easier to implement than level 3 |
9720 |
proxies. |
9721 |
|
9722 |
|
9723 |
|
9724 |
|
9725 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 162] |
9726 |
|
9727 |
|
9728 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9729 |
|
9730 |
|
9731 |
G.2 Propagation of Changes in Opaque Selection |
9732 |
Level 3 and level 6 proxy caches not only cache the responses from an |
9733 |
opaquely varying resource, they also cache the mappings from request |
9734 |
headers to particular entities computed by the opaque selection |
9735 |
algorithm located at the origin server. If this selection algorithm is |
9736 |
changed by the resource author, for example because a Spanish text |
9737 |
entity is added to a resource which previously only had English and |
9738 |
French entities available, it is important to make the level 3 and 6 |
9739 |
caches refresh their cached mappings. This can be done by changing the |
9740 |
CVal header fields sent along with the original English and French |
9741 |
responses. This change will eventually cause the proxies to replace the |
9742 |
old English and French responses in cache memory, along with their |
9743 |
associated lists of selecting request header sequences, by `new' English |
9744 |
and French responses with fresh lists of selecting request header |
9745 |
sequences. In order to guarantee an upper time bound for this update |
9746 |
process, the resource author can include an appropriate Cache-control: |
9747 |
max-age=... directive in the responses from the varying resource. |
9748 |
|
9749 |
|
9750 |
G.3 SLUSHY: State |
9751 |
This should probably be in the cookie ID, and not in this document at |
9752 |
all. |
9753 |
|
9754 |
HTTP implementations often support facilities for state management, |
9755 |
often called _cookies_[35]. Cookies can not be cached by public |
9756 |
(shared) caches, but since public documents may make up part of a |
9757 |
_stateful dialog,_ and in particular the first document in a stateful |
9758 |
dialog may be (for example) a public and cachable home page, servers |
9759 |
that wish to receive the client's cookie on each request, or to issue a |
9760 |
new cookie on requests for a document, must set the document up to |
9761 |
require validation on each request (Cache-Control: must-revalidate) |
9762 |
|
9763 |
In general, the cache control headers for responses control what a proxy |
9764 |
has to do. If a document is fresh in a cache, a request containing a |
9765 |
cookie does not have to be forwarded to the origin server, since (by |
9766 |
definition) if the document can be served from a cache the origin server |
9767 |
must have said there are no important side effects at the origin |
9768 |
relating to requests for that document, and so, no changes to the |
9769 |
cookie. |
9770 |
|
9771 |
One important state issue bearing on caching is that for conditional |
9772 |
requests that go through to the origin server, for which the origin |
9773 |
server responds with 304 and also with a set-cookie header, caches must |
9774 |
splice the set-cookie sent by the origin server into their own response. |
9775 |
For example, this allows a home page to be cached, but stale, so that |
9776 |
the only traffic to the origin server is to validate the home page, |
9777 |
receiving a 304 and potentially a new cookie. |
9778 |
|
9779 |
|
9780 |
G.4 FLUID: Cache Replacement Algorithms |
9781 |
TBS |
9782 |
|
9783 |
Should go into an implementers Informational RFC. |
9784 |
|
9785 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 163] |
9786 |
|
9787 |
|
9788 |
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 |
9789 |
|
9790 |
|
9791 |
G.5 FLUID: Bypassing in Caching Hierarchies |
9792 |
This should also go into an implementers Informational RFC, and become |
9793 |
grist for HTML's mill. |
9794 |
|
9795 |
Many HTTP caching configurations involve hierarchies of caches, often |
9796 |
designed to reduce bandwidth requirements rather than improving latency. |
9797 |
However, if a cache at a low level in the hierarchy is sure that the |
9798 |
cache(s) above it do not contain a cache entry to match a given request, |
9799 |
that low-level cache can transmit the request directly to the origin |
9800 |
server. This improves retrieval latency without increasing total |
9801 |
bandwidth requirements (it even eliminates some packet transmissions) |
9802 |
and is entirely appropriate for resources whose values are explicitly |
9803 |
not cached. |
9804 |
|
9805 |
We call this technique _request bypassing._ Note that although the |
9806 |
bypassing decision might be done by the ultimate client, in many cases |
9807 |
the use of firewalls or unsophisticated clients means that the decision |
9808 |
must be made by an intermediate-level cache. |
9809 |
|
9810 |
In order for request bypassing to work in the most efficient possible |
9811 |
way, the caches must be able to determine from the request whether the |
9812 |
response is likely to be cachable. (It is important to err on the side |
9813 |
of assuming cachability, since the assuming converse could seriously |
9814 |
reduce the effectiveness of the higher-level caches.) |
9815 |
|
9816 |
The current HTTP/1.1 draft specification does not include a foolproof |
9817 |
mechanism to mark requests in this way. While we generally do not allow |
9818 |
caching of responses to GET requests for URLs with a _?_ in the rel_path |
9819 |
part (see section 13.16), we also allow the origin server to mark |
9820 |
responses to such queries as cachable. Therefore, any bypassing done |
9821 |
using this heuristic runs the risk of giving up perfectly good |
9822 |
opportunities to cache some resources. |
9823 |
|
9824 |
XXX we have discussed various approaches for marking requests, all of |
9825 |
which apparently require some kind of change to HTML to allow the origin |
9826 |
server to pass the marks to the ultimate client. Some people suggest |
9827 |
using special methods that are explicitly always cachable |
9828 |
(_POST_WITH_NO_SIDE_EFFECTS_, or more concisely _POSTC_) or never |
9829 |
cachable (_GET_QUERY_, or more concisely _GETQ_). Others have suggested |
9830 |
adding tags to HTML that would cause subsequent requests to carry some |
9831 |
special sort of header. Neither solution has resulted in a consensus. |
9832 |
|
9833 |
An origin server would be able to use POSTC only withHTTP/1.1 clients |
9834 |
and proxies, and so would have to return different HTML forms depending |
9835 |
on the protocol version in the request header. This would also imply |
9836 |
using the proposed Vary: header with some token that indicates _varies |
9837 |
based on request HTTP version,_ since we don't want a cache returning |
9838 |
one of these HTML responses to an HTTP/1.0 client |
9839 |
|
9840 |
|
9841 |
|
9842 |
|
9843 |
|
9844 |
|
9845 |
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 164] |