Mercurial > gftp.yaz
comparison docs/rfcs/rfc2068.txt @ 497:e60a6ec4aa85
2004-7-12 Brian Masney <masneyb@gftp.org>
* docs/rfcs/* - added RFCs that are used by this program
author | masneyb |
---|---|
date | Tue, 13 Jul 2004 01:35:15 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
496:937f2b75bbee | 497:e60a6ec4aa85 |
---|---|
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 Network Working Group R. Fielding | |
8 Request for Comments: 2068 UC Irvine | |
9 Category: Standards Track J. Gettys | |
10 J. Mogul | |
11 DEC | |
12 H. Frystyk | |
13 T. Berners-Lee | |
14 MIT/LCS | |
15 January 1997 | |
16 | |
17 | |
18 Hypertext Transfer Protocol -- HTTP/1.1 | |
19 | |
20 Status of this Memo | |
21 | |
22 This document specifies an Internet standards track protocol for the | |
23 Internet community, and requests discussion and suggestions for | |
24 improvements. Please refer to the current edition of the "Internet | |
25 Official Protocol Standards" (STD 1) for the standardization state | |
26 and status of this protocol. Distribution of this memo is unlimited. | |
27 | |
28 Abstract | |
29 | |
30 The Hypertext Transfer Protocol (HTTP) is an application-level | |
31 protocol for distributed, collaborative, hypermedia information | |
32 systems. It is a generic, stateless, object-oriented protocol which | |
33 can be used for many tasks, such as name servers and distributed | |
34 object management systems, through extension of its request methods. | |
35 A feature of HTTP is the typing and negotiation of data | |
36 representation, allowing systems to be built independently of the | |
37 data being transferred. | |
38 | |
39 HTTP has been in use by the World-Wide Web global information | |
40 initiative since 1990. This specification defines the protocol | |
41 referred to as "HTTP/1.1". | |
42 | |
43 Table of Contents | |
44 | |
45 1 Introduction.............................................7 | |
46 1.1 Purpose ..............................................7 | |
47 1.2 Requirements .........................................7 | |
48 1.3 Terminology ..........................................8 | |
49 1.4 Overall Operation ...................................11 | |
50 2 Notational Conventions and Generic Grammar..............13 | |
51 2.1 Augmented BNF .......................................13 | |
52 2.2 Basic Rules .........................................15 | |
53 3 Protocol Parameters.....................................17 | |
54 3.1 HTTP Version ........................................17 | |
55 | |
56 | |
57 | |
58 Fielding, et. al. Standards Track [Page 1] | |
59 | |
60 RFC 2068 HTTP/1.1 January 1997 | |
61 | |
62 | |
63 3.2 Uniform Resource Identifiers ........................18 | |
64 3.2.1 General Syntax ...................................18 | |
65 3.2.2 http URL .........................................19 | |
66 3.2.3 URI Comparison ...................................20 | |
67 3.3 Date/Time Formats ...................................21 | |
68 3.3.1 Full Date ........................................21 | |
69 3.3.2 Delta Seconds ....................................22 | |
70 3.4 Character Sets ......................................22 | |
71 3.5 Content Codings .....................................23 | |
72 3.6 Transfer Codings ....................................24 | |
73 3.7 Media Types .........................................25 | |
74 3.7.1 Canonicalization and Text Defaults ...............26 | |
75 3.7.2 Multipart Types ..................................27 | |
76 3.8 Product Tokens ......................................28 | |
77 3.9 Quality Values ......................................28 | |
78 3.10 Language Tags ......................................28 | |
79 3.11 Entity Tags ........................................29 | |
80 3.12 Range Units ........................................30 | |
81 4 HTTP Message............................................30 | |
82 4.1 Message Types .......................................30 | |
83 4.2 Message Headers .....................................31 | |
84 4.3 Message Body ........................................32 | |
85 4.4 Message Length ......................................32 | |
86 4.5 General Header Fields ...............................34 | |
87 5 Request.................................................34 | |
88 5.1 Request-Line ........................................34 | |
89 5.1.1 Method ...........................................35 | |
90 5.1.2 Request-URI ......................................35 | |
91 5.2 The Resource Identified by a Request ................37 | |
92 5.3 Request Header Fields ...............................37 | |
93 6 Response................................................38 | |
94 6.1 Status-Line .........................................38 | |
95 6.1.1 Status Code and Reason Phrase ....................39 | |
96 6.2 Response Header Fields ..............................41 | |
97 7 Entity..................................................41 | |
98 7.1 Entity Header Fields ................................41 | |
99 7.2 Entity Body .........................................42 | |
100 7.2.1 Type .............................................42 | |
101 7.2.2 Length ...........................................43 | |
102 8 Connections.............................................43 | |
103 8.1 Persistent Connections ..............................43 | |
104 8.1.1 Purpose ..........................................43 | |
105 8.1.2 Overall Operation ................................44 | |
106 8.1.3 Proxy Servers ....................................45 | |
107 8.1.4 Practical Considerations .........................45 | |
108 8.2 Message Transmission Requirements ...................46 | |
109 9 Method Definitions......................................48 | |
110 9.1 Safe and Idempotent Methods .........................48 | |
111 | |
112 | |
113 | |
114 Fielding, et. al. Standards Track [Page 2] | |
115 | |
116 RFC 2068 HTTP/1.1 January 1997 | |
117 | |
118 | |
119 9.1.1 Safe Methods .....................................48 | |
120 9.1.2 Idempotent Methods ...............................49 | |
121 9.2 OPTIONS .............................................49 | |
122 9.3 GET .................................................50 | |
123 9.4 HEAD ................................................50 | |
124 9.5 POST ................................................51 | |
125 9.6 PUT .................................................52 | |
126 9.7 DELETE ..............................................53 | |
127 9.8 TRACE ...............................................53 | |
128 10 Status Code Definitions................................53 | |
129 10.1 Informational 1xx ..................................54 | |
130 10.1.1 100 Continue ....................................54 | |
131 10.1.2 101 Switching Protocols .........................54 | |
132 10.2 Successful 2xx .....................................54 | |
133 10.2.1 200 OK ..........................................54 | |
134 10.2.2 201 Created .....................................55 | |
135 10.2.3 202 Accepted ....................................55 | |
136 10.2.4 203 Non-Authoritative Information ...............55 | |
137 10.2.5 204 No Content ..................................55 | |
138 10.2.6 205 Reset Content ...............................56 | |
139 10.2.7 206 Partial Content .............................56 | |
140 10.3 Redirection 3xx ....................................56 | |
141 10.3.1 300 Multiple Choices ............................57 | |
142 10.3.2 301 Moved Permanently ...........................57 | |
143 10.3.3 302 Moved Temporarily ...........................58 | |
144 10.3.4 303 See Other ...................................58 | |
145 10.3.5 304 Not Modified ................................58 | |
146 10.3.6 305 Use Proxy ...................................59 | |
147 10.4 Client Error 4xx ...................................59 | |
148 10.4.1 400 Bad Request .................................60 | |
149 10.4.2 401 Unauthorized ................................60 | |
150 10.4.3 402 Payment Required ............................60 | |
151 10.4.4 403 Forbidden ...................................60 | |
152 10.4.5 404 Not Found ...................................60 | |
153 10.4.6 405 Method Not Allowed ..........................61 | |
154 10.4.7 406 Not Acceptable ..............................61 | |
155 10.4.8 407 Proxy Authentication Required ...............61 | |
156 10.4.9 408 Request Timeout .............................62 | |
157 10.4.10 409 Conflict ...................................62 | |
158 10.4.11 410 Gone .......................................62 | |
159 10.4.12 411 Length Required ............................63 | |
160 10.4.13 412 Precondition Failed ........................63 | |
161 10.4.14 413 Request Entity Too Large ...................63 | |
162 10.4.15 414 Request-URI Too Long .......................63 | |
163 10.4.16 415 Unsupported Media Type .....................63 | |
164 10.5 Server Error 5xx ...................................64 | |
165 10.5.1 500 Internal Server Error .......................64 | |
166 10.5.2 501 Not Implemented .............................64 | |
167 | |
168 | |
169 | |
170 Fielding, et. al. Standards Track [Page 3] | |
171 | |
172 RFC 2068 HTTP/1.1 January 1997 | |
173 | |
174 | |
175 10.5.3 502 Bad Gateway .................................64 | |
176 10.5.4 503 Service Unavailable .........................64 | |
177 10.5.5 504 Gateway Timeout .............................64 | |
178 10.5.6 505 HTTP Version Not Supported ..................65 | |
179 11 Access Authentication..................................65 | |
180 11.1 Basic Authentication Scheme ........................66 | |
181 11.2 Digest Authentication Scheme .......................67 | |
182 12 Content Negotiation....................................67 | |
183 12.1 Server-driven Negotiation ..........................68 | |
184 12.2 Agent-driven Negotiation ...........................69 | |
185 12.3 Transparent Negotiation ............................70 | |
186 13 Caching in HTTP........................................70 | |
187 13.1.1 Cache Correctness ...............................72 | |
188 13.1.2 Warnings ........................................73 | |
189 13.1.3 Cache-control Mechanisms ........................74 | |
190 13.1.4 Explicit User Agent Warnings ....................74 | |
191 13.1.5 Exceptions to the Rules and Warnings ............75 | |
192 13.1.6 Client-controlled Behavior ......................75 | |
193 13.2 Expiration Model ...................................75 | |
194 13.2.1 Server-Specified Expiration .....................75 | |
195 13.2.2 Heuristic Expiration ............................76 | |
196 13.2.3 Age Calculations ................................77 | |
197 13.2.4 Expiration Calculations .........................79 | |
198 13.2.5 Disambiguating Expiration Values ................80 | |
199 13.2.6 Disambiguating Multiple Responses ...............80 | |
200 13.3 Validation Model ...................................81 | |
201 13.3.1 Last-modified Dates .............................82 | |
202 13.3.2 Entity Tag Cache Validators .....................82 | |
203 13.3.3 Weak and Strong Validators ......................82 | |
204 13.3.4 Rules for When to Use Entity Tags and Last- | |
205 modified Dates..........................................85 | |
206 13.3.5 Non-validating Conditionals .....................86 | |
207 13.4 Response Cachability ...............................86 | |
208 13.5 Constructing Responses From Caches .................87 | |
209 13.5.1 End-to-end and Hop-by-hop Headers ...............88 | |
210 13.5.2 Non-modifiable Headers ..........................88 | |
211 13.5.3 Combining Headers ...............................89 | |
212 13.5.4 Combining Byte Ranges ...........................90 | |
213 13.6 Caching Negotiated Responses .......................90 | |
214 13.7 Shared and Non-Shared Caches .......................91 | |
215 13.8 Errors or Incomplete Response Cache Behavior .......91 | |
216 13.9 Side Effects of GET and HEAD .......................92 | |
217 13.10 Invalidation After Updates or Deletions ...........92 | |
218 13.11 Write-Through Mandatory ...........................93 | |
219 13.12 Cache Replacement .................................93 | |
220 13.13 History Lists .....................................93 | |
221 14 Header Field Definitions...............................94 | |
222 14.1 Accept .............................................95 | |
223 | |
224 | |
225 | |
226 Fielding, et. al. Standards Track [Page 4] | |
227 | |
228 RFC 2068 HTTP/1.1 January 1997 | |
229 | |
230 | |
231 14.2 Accept-Charset .....................................97 | |
232 14.3 Accept-Encoding ....................................97 | |
233 14.4 Accept-Language ....................................98 | |
234 14.5 Accept-Ranges ......................................99 | |
235 14.6 Age ................................................99 | |
236 14.7 Allow .............................................100 | |
237 14.8 Authorization .....................................100 | |
238 14.9 Cache-Control .....................................101 | |
239 14.9.1 What is Cachable ...............................103 | |
240 14.9.2 What May be Stored by Caches ...................103 | |
241 14.9.3 Modifications of the Basic Expiration Mechanism 104 | |
242 14.9.4 Cache Revalidation and Reload Controls .........105 | |
243 14.9.5 No-Transform Directive .........................107 | |
244 14.9.6 Cache Control Extensions .......................108 | |
245 14.10 Connection .......................................109 | |
246 14.11 Content-Base .....................................109 | |
247 14.12 Content-Encoding .................................110 | |
248 14.13 Content-Language .................................110 | |
249 14.14 Content-Length ...................................111 | |
250 14.15 Content-Location .................................112 | |
251 14.16 Content-MD5 ......................................113 | |
252 14.17 Content-Range ....................................114 | |
253 14.18 Content-Type .....................................116 | |
254 14.19 Date .............................................116 | |
255 14.20 ETag .............................................117 | |
256 14.21 Expires ..........................................117 | |
257 14.22 From .............................................118 | |
258 14.23 Host .............................................119 | |
259 14.24 If-Modified-Since ................................119 | |
260 14.25 If-Match .........................................121 | |
261 14.26 If-None-Match ....................................122 | |
262 14.27 If-Range .........................................123 | |
263 14.28 If-Unmodified-Since ..............................124 | |
264 14.29 Last-Modified ....................................124 | |
265 14.30 Location .........................................125 | |
266 14.31 Max-Forwards .....................................125 | |
267 14.32 Pragma ...........................................126 | |
268 14.33 Proxy-Authenticate ...............................127 | |
269 14.34 Proxy-Authorization ..............................127 | |
270 14.35 Public ...........................................127 | |
271 14.36 Range ............................................128 | |
272 14.36.1 Byte Ranges ...................................128 | |
273 14.36.2 Range Retrieval Requests ......................130 | |
274 14.37 Referer ..........................................131 | |
275 14.38 Retry-After ......................................131 | |
276 14.39 Server ...........................................132 | |
277 14.40 Transfer-Encoding ................................132 | |
278 14.41 Upgrade ..........................................132 | |
279 | |
280 | |
281 | |
282 Fielding, et. al. Standards Track [Page 5] | |
283 | |
284 RFC 2068 HTTP/1.1 January 1997 | |
285 | |
286 | |
287 14.42 User-Agent .......................................134 | |
288 14.43 Vary .............................................134 | |
289 14.44 Via ..............................................135 | |
290 14.45 Warning ..........................................137 | |
291 14.46 WWW-Authenticate .................................139 | |
292 15 Security Considerations...............................139 | |
293 15.1 Authentication of Clients .........................139 | |
294 15.2 Offering a Choice of Authentication Schemes .......140 | |
295 15.3 Abuse of Server Log Information ...................141 | |
296 15.4 Transfer of Sensitive Information .................141 | |
297 15.5 Attacks Based On File and Path Names ..............142 | |
298 15.6 Personal Information ..............................143 | |
299 15.7 Privacy Issues Connected to Accept Headers ........143 | |
300 15.8 DNS Spoofing ......................................144 | |
301 15.9 Location Headers and Spoofing .....................144 | |
302 16 Acknowledgments.......................................144 | |
303 17 References............................................146 | |
304 18 Authors' Addresses....................................149 | |
305 19 Appendices............................................150 | |
306 19.1 Internet Media Type message/http ..................150 | |
307 19.2 Internet Media Type multipart/byteranges ..........150 | |
308 19.3 Tolerant Applications .............................151 | |
309 19.4 Differences Between HTTP Entities and | |
310 MIME Entities...........................................152 | |
311 19.4.1 Conversion to Canonical Form ...................152 | |
312 19.4.2 Conversion of Date Formats .....................153 | |
313 19.4.3 Introduction of Content-Encoding ...............153 | |
314 19.4.4 No Content-Transfer-Encoding ...................153 | |
315 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153 | |
316 19.4.6 Introduction of Transfer-Encoding ..............154 | |
317 19.4.7 MIME-Version ...................................154 | |
318 19.5 Changes from HTTP/1.0 .............................154 | |
319 19.5.1 Changes to Simplify Multi-homed Web Servers and | |
320 Conserve IP Addresses .................................155 | |
321 19.6 Additional Features ...............................156 | |
322 19.6.1 Additional Request Methods .....................156 | |
323 19.6.2 Additional Header Field Definitions ............156 | |
324 19.7 Compatibility with Previous Versions ..............160 | |
325 19.7.1 Compatibility with HTTP/1.0 Persistent | |
326 Connections............................................161 | |
327 | |
328 | |
329 | |
330 | |
331 | |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 Fielding, et. al. Standards Track [Page 6] | |
339 | |
340 RFC 2068 HTTP/1.1 January 1997 | |
341 | |
342 | |
343 1 Introduction | |
344 | |
345 1.1 Purpose | |
346 | |
347 The Hypertext Transfer Protocol (HTTP) is an application-level | |
348 protocol for distributed, collaborative, hypermedia information | |
349 systems. HTTP has been in use by the World-Wide Web global | |
350 information initiative since 1990. The first version of HTTP, | |
351 referred to as HTTP/0.9, was a simple protocol for raw data transfer | |
352 across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved | |
353 the protocol by allowing messages to be in the format of MIME-like | |
354 messages, containing metainformation about the data transferred and | |
355 modifiers on the request/response semantics. However, HTTP/1.0 does | |
356 not sufficiently take into consideration the effects of hierarchical | |
357 proxies, caching, the need for persistent connections, and virtual | |
358 hosts. In addition, the proliferation of incompletely-implemented | |
359 applications calling themselves "HTTP/1.0" has necessitated a | |
360 protocol version change in order for two communicating applications | |
361 to determine each other's true capabilities. | |
362 | |
363 This specification defines the protocol referred to as "HTTP/1.1". | |
364 This protocol includes more stringent requirements than HTTP/1.0 in | |
365 order to ensure reliable implementation of its features. | |
366 | |
367 Practical information systems require more functionality than simple | |
368 retrieval, including search, front-end update, and annotation. HTTP | |
369 allows an open-ended set of methods that indicate the purpose of a | |
370 request. It builds on the discipline of reference provided by the | |
371 Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or | |
372 name (URN) , for indicating the resource to which a method is to be | |
373 applied. Messages are passed in a format similar to that used by | |
374 Internet mail as defined by the Multipurpose Internet Mail Extensions | |
375 (MIME). | |
376 | |
377 HTTP is also used as a generic protocol for communication between | |
378 user agents and proxies/gateways to other Internet systems, including | |
379 those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], | |
380 and WAIS [10] protocols. In this way, HTTP allows basic hypermedia | |
381 access to resources available from diverse applications. | |
382 | |
383 1.2 Requirements | |
384 | |
385 This specification uses the same words as RFC 1123 [8] for defining | |
386 the significance of each particular requirement. These words are: | |
387 | |
388 MUST | |
389 This word or the adjective "required" means that the item is an | |
390 absolute requirement of the specification. | |
391 | |
392 | |
393 | |
394 Fielding, et. al. Standards Track [Page 7] | |
395 | |
396 RFC 2068 HTTP/1.1 January 1997 | |
397 | |
398 | |
399 SHOULD | |
400 This word or the adjective "recommended" means that there may | |
401 exist valid reasons in particular circumstances to ignore this | |
402 item, but the full implications should be understood and the case | |
403 carefully weighed before choosing a different course. | |
404 | |
405 MAY | |
406 This word or the adjective "optional" means that this item is | |
407 truly optional. One vendor may choose to include the item because | |
408 a particular marketplace requires it or because it enhances the | |
409 product, for example; another vendor may omit the same item. | |
410 | |
411 An implementation is not compliant if it fails to satisfy one or more | |
412 of the MUST requirements for the protocols it implements. An | |
413 implementation that satisfies all the MUST and all the SHOULD | |
414 requirements for its protocols is said to be "unconditionally | |
415 compliant"; one that satisfies all the MUST requirements but not all | |
416 the SHOULD requirements for its protocols is said to be | |
417 "conditionally compliant." | |
418 | |
419 1.3 Terminology | |
420 | |
421 This specification uses a number of terms to refer to the roles | |
422 played by participants in, and objects of, the HTTP communication. | |
423 | |
424 connection | |
425 A transport layer virtual circuit established between two programs | |
426 for the purpose of communication. | |
427 | |
428 message | |
429 The basic unit of HTTP communication, consisting of a structured | |
430 sequence of octets matching the syntax defined in section 4 and | |
431 transmitted via the connection. | |
432 | |
433 request | |
434 An HTTP request message, as defined in section 5. | |
435 | |
436 response | |
437 An HTTP response message, as defined in section 6. | |
438 | |
439 resource | |
440 A network data object or service that can be identified by a URI, | |
441 as defined in section 3.2. Resources may be available in multiple | |
442 representations (e.g. multiple languages, data formats, size, | |
443 resolutions) or vary in other ways. | |
444 | |
445 | |
446 | |
447 | |
448 | |
449 | |
450 Fielding, et. al. Standards Track [Page 8] | |
451 | |
452 RFC 2068 HTTP/1.1 January 1997 | |
453 | |
454 | |
455 entity | |
456 The information transferred as the payload of a request or | |
457 response. An entity consists of metainformation in the form of | |
458 entity-header fields and content in the form of an entity-body, as | |
459 described in section 7. | |
460 | |
461 representation | |
462 An entity included with a response that is subject to content | |
463 negotiation, as described in section 12. There may exist multiple | |
464 representations associated with a particular response status. | |
465 | |
466 content negotiation | |
467 The mechanism for selecting the appropriate representation when | |
468 servicing a request, as described in section 12. The | |
469 representation of entities in any response can be negotiated | |
470 (including error responses). | |
471 | |
472 variant | |
473 A resource may have one, or more than one, representation(s) | |
474 associated with it at any given instant. Each of these | |
475 representations is termed a `variant.' Use of the term `variant' | |
476 does not necessarily imply that the resource is subject to content | |
477 negotiation. | |
478 | |
479 client | |
480 A program that establishes connections for the purpose of sending | |
481 requests. | |
482 | |
483 user agent | |
484 The client which initiates a request. These are often browsers, | |
485 editors, spiders (web-traversing robots), or other end user tools. | |
486 | |
487 server | |
488 An application program that accepts connections in order to | |
489 service requests by sending back responses. Any given program may | |
490 be capable of being both a client and a server; our use of these | |
491 terms refers only to the role being performed by the program for a | |
492 particular connection, rather than to the program's capabilities | |
493 in general. Likewise, any server may act as an origin server, | |
494 proxy, gateway, or tunnel, switching behavior based on the nature | |
495 of each request. | |
496 | |
497 origin server | |
498 The server on which a given resource resides or is to be created. | |
499 | |
500 | |
501 | |
502 | |
503 | |
504 | |
505 | |
506 Fielding, et. al. Standards Track [Page 9] | |
507 | |
508 RFC 2068 HTTP/1.1 January 1997 | |
509 | |
510 | |
511 proxy | |
512 An intermediary program which acts as both a server and a client | |
513 for the purpose of making requests on behalf of other clients. | |
514 Requests are serviced internally or by passing them on, with | |
515 possible translation, to other servers. A proxy must implement | |
516 both the client and server requirements of this specification. | |
517 | |
518 gateway | |
519 A server which acts as an intermediary for some other server. | |
520 Unlike a proxy, a gateway receives requests as if it were the | |
521 origin server for the requested resource; the requesting client | |
522 may not be aware that it is communicating with a gateway. | |
523 | |
524 tunnel | |
525 An intermediary program which is acting as a blind relay between | |
526 two connections. Once active, a tunnel is not considered a party | |
527 to the HTTP communication, though the tunnel may have been | |
528 initiated by an HTTP request. The tunnel ceases to exist when both | |
529 ends of the relayed connections are closed. | |
530 | |
531 cache | |
532 A program's local store of response messages and the subsystem | |
533 that controls its message storage, retrieval, and deletion. A | |
534 cache stores cachable responses in order to reduce the response | |
535 time and network bandwidth consumption on future, equivalent | |
536 requests. Any client or server may include a cache, though a cache | |
537 cannot be used by a server that is acting as a tunnel. | |
538 | |
539 cachable | |
540 A response is cachable if a cache is allowed to store a copy of | |
541 the response message for use in answering subsequent requests. The | |
542 rules for determining the cachability of HTTP responses are | |
543 defined in section 13. Even if a resource is cachable, there may | |
544 be additional constraints on whether a cache can use the cached | |
545 copy for a particular request. | |
546 | |
547 first-hand | |
548 A response is first-hand if it comes directly and without | |
549 unnecessary delay from the origin server, perhaps via one or more | |
550 proxies. A response is also first-hand if its validity has just | |
551 been checked directly with the origin server. | |
552 | |
553 explicit expiration time | |
554 The time at which the origin server intends that an entity should | |
555 no longer be returned by a cache without further validation. | |
556 | |
557 | |
558 | |
559 | |
560 | |
561 | |
562 Fielding, et. al. Standards Track [Page 10] | |
563 | |
564 RFC 2068 HTTP/1.1 January 1997 | |
565 | |
566 | |
567 heuristic expiration time | |
568 An expiration time assigned by a cache when no explicit expiration | |
569 time is available. | |
570 | |
571 age | |
572 The age of a response is the time since it was sent by, or | |
573 successfully validated with, the origin server. | |
574 | |
575 freshness lifetime | |
576 The length of time between the generation of a response and its | |
577 expiration time. | |
578 | |
579 fresh | |
580 A response is fresh if its age has not yet exceeded its freshness | |
581 lifetime. | |
582 | |
583 stale | |
584 A response is stale if its age has passed its freshness lifetime. | |
585 | |
586 semantically transparent | |
587 A cache behaves in a "semantically transparent" manner, with | |
588 respect to a particular response, when its use affects neither the | |
589 requesting client nor the origin server, except to improve | |
590 performance. When a cache is semantically transparent, the client | |
591 receives exactly the same response (except for hop-by-hop headers) | |
592 that it would have received had its request been handled directly | |
593 by the origin server. | |
594 | |
595 validator | |
596 A protocol element (e.g., an entity tag or a Last-Modified time) | |
597 that is used to find out whether a cache entry is an equivalent | |
598 copy of an entity. | |
599 | |
600 1.4 Overall Operation | |
601 | |
602 The HTTP protocol is a request/response protocol. A client sends a | |
603 request to the server in the form of a request method, URI, and | |
604 protocol version, followed by a MIME-like message containing request | |
605 modifiers, client information, and possible body content over a | |
606 connection with a server. The server responds with a status line, | |
607 including the message's protocol version and a success or error code, | |
608 followed by a MIME-like message containing server information, entity | |
609 metainformation, and possible entity-body content. The relationship | |
610 between HTTP and MIME is described in appendix 19.4. | |
611 | |
612 | |
613 | |
614 | |
615 | |
616 | |
617 | |
618 Fielding, et. al. Standards Track [Page 11] | |
619 | |
620 RFC 2068 HTTP/1.1 January 1997 | |
621 | |
622 | |
623 Most HTTP communication is initiated by a user agent and consists of | |
624 a request to be applied to a resource on some origin server. In the | |
625 simplest case, this may be accomplished via a single connection (v) | |
626 between the user agent (UA) and the origin server (O). | |
627 | |
628 request chain ------------------------> | |
629 UA -------------------v------------------- O | |
630 <----------------------- response chain | |
631 | |
632 A more complicated situation occurs when one or more intermediaries | |
633 are present in the request/response chain. There are three common | |
634 forms of intermediary: proxy, gateway, and tunnel. A proxy is a | |
635 forwarding agent, receiving requests for a URI in its absolute form, | |
636 rewriting all or part of the message, and forwarding the reformatted | |
637 request toward the server identified by the URI. A gateway is a | |
638 receiving agent, acting as a layer above some other server(s) and, if | |
639 necessary, translating the requests to the underlying server's | |
640 protocol. A tunnel acts as a relay point between two connections | |
641 without changing the messages; tunnels are used when the | |
642 communication needs to pass through an intermediary (such as a | |
643 firewall) even when the intermediary cannot understand the contents | |
644 of the messages. | |
645 | |
646 request chain --------------------------------------> | |
647 UA -----v----- A -----v----- B -----v----- C -----v----- O | |
648 <------------------------------------- response chain | |
649 | |
650 The figure above shows three intermediaries (A, B, and C) between the | |
651 user agent and origin server. A request or response message that | |
652 travels the whole chain will pass through four separate connections. | |
653 This distinction is important because some HTTP communication options | |
654 may apply only to the connection with the nearest, non-tunnel | |
655 neighbor, only to the end-points of the chain, or to all connections | |
656 along the chain. Although the diagram is linear, each participant | |
657 may be engaged in multiple, simultaneous communications. For example, | |
658 B may be receiving requests from many clients other than A, and/or | |
659 forwarding requests to servers other than C, at the same time that it | |
660 is handling A's request. | |
661 | |
662 Any party to the communication which is not acting as a tunnel may | |
663 employ an internal cache for handling requests. The effect of a cache | |
664 is that the request/response chain is shortened if one of the | |
665 participants along the chain has a cached response applicable to that | |
666 request. The following illustrates the resulting chain if B has a | |
667 cached copy of an earlier response from O (via C) for a request which | |
668 has not been cached by UA or A. | |
669 | |
670 | |
671 | |
672 | |
673 | |
674 Fielding, et. al. Standards Track [Page 12] | |
675 | |
676 RFC 2068 HTTP/1.1 January 1997 | |
677 | |
678 | |
679 request chain ----------> | |
680 UA -----v----- A -----v----- B - - - - - - C - - - - - - O | |
681 <--------- response chain | |
682 | |
683 Not all responses are usefully cachable, and some requests may | |
684 contain modifiers which place special requirements on cache behavior. | |
685 HTTP requirements for cache behavior and cachable responses are | |
686 defined in section 13. | |
687 | |
688 In fact, there are a wide variety of architectures and configurations | |
689 of caches and proxies currently being experimented with or deployed | |
690 across the World Wide Web; these systems include national hierarchies | |
691 of proxy caches to save transoceanic bandwidth, systems that | |
692 broadcast or multicast cache entries, organizations that distribute | |
693 subsets of cached data via CD-ROM, and so on. HTTP systems are used | |
694 in corporate intranets over high-bandwidth links, and for access via | |
695 PDAs with low-power radio links and intermittent connectivity. The | |
696 goal of HTTP/1.1 is to support the wide diversity of configurations | |
697 already deployed while introducing protocol constructs that meet the | |
698 needs of those who build web applications that require high | |
699 reliability and, failing that, at least reliable indications of | |
700 failure. | |
701 | |
702 HTTP communication usually takes place over TCP/IP connections. The | |
703 default port is TCP 80, but other ports can be used. This does not | |
704 preclude HTTP from being implemented on top of any other protocol on | |
705 the Internet, or on other networks. HTTP only presumes a reliable | |
706 transport; any protocol that provides such guarantees can be used; | |
707 the mapping of the HTTP/1.1 request and response structures onto the | |
708 transport data units of the protocol in question is outside the scope | |
709 of this specification. | |
710 | |
711 In HTTP/1.0, most implementations used a new connection for each | |
712 request/response exchange. In HTTP/1.1, a connection may be used for | |
713 one or more request/response exchanges, although connections may be | |
714 closed for a variety of reasons (see section 8.1). | |
715 | |
716 2 Notational Conventions and Generic Grammar | |
717 | |
718 2.1 Augmented BNF | |
719 | |
720 All of the mechanisms specified in this document are described in | |
721 both prose and an augmented Backus-Naur Form (BNF) similar to that | |
722 used by RFC 822 [9]. Implementers will need to be familiar with the | |
723 notation in order to understand this specification. The augmented BNF | |
724 includes the following constructs: | |
725 | |
726 | |
727 | |
728 | |
729 | |
730 Fielding, et. al. Standards Track [Page 13] | |
731 | |
732 RFC 2068 HTTP/1.1 January 1997 | |
733 | |
734 | |
735 name = definition | |
736 The name of a rule is simply the name itself (without any enclosing | |
737 "<" and ">") and is separated from its definition by the equal "=" | |
738 character. Whitespace is only significant in that indentation of | |
739 continuation lines is used to indicate a rule definition that spans | |
740 more than one line. Certain basic rules are in uppercase, such as | |
741 SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used | |
742 within definitions whenever their presence will facilitate | |
743 discerning the use of rule names. | |
744 | |
745 "literal" | |
746 Quotation marks surround literal text. Unless stated otherwise, the | |
747 text is case-insensitive. | |
748 | |
749 rule1 | rule2 | |
750 Elements separated by a bar ("|") are alternatives, e.g., "yes | | |
751 no" will accept yes or no. | |
752 | |
753 (rule1 rule2) | |
754 Elements enclosed in parentheses are treated as a single element. | |
755 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem | |
756 foo elem" and "elem bar elem". | |
757 | |
758 *rule | |
759 The character "*" preceding an element indicates repetition. The | |
760 full form is "<n>*<m>element" indicating at least <n> and at most | |
761 <m> occurrences of element. Default values are 0 and infinity so | |
762 that "*(element)" allows any number, including zero; "1*element" | |
763 requires at least one; and "1*2element" allows one or two. | |
764 | |
765 [rule] | |
766 Square brackets enclose optional elements; "[foo bar]" is | |
767 equivalent to "*1(foo bar)". | |
768 | |
769 N rule | |
770 Specific repetition: "<n>(element)" is equivalent to | |
771 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). | |
772 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three | |
773 alphabetic characters. | |
774 | |
775 #rule | |
776 A construct "#" is defined, similar to "*", for defining lists of | |
777 elements. The full form is "<n>#<m>element " indicating at least | |
778 <n> and at most <m> elements, each separated by one or more commas | |
779 (",") and optional linear whitespace (LWS). This makes the usual | |
780 form of lists very easy; a rule such as "( *LWS element *( *LWS "," | |
781 *LWS element )) " can be shown as "1#element". Wherever this | |
782 construct is used, null elements are allowed, but do not contribute | |
783 | |
784 | |
785 | |
786 Fielding, et. al. Standards Track [Page 14] | |
787 | |
788 RFC 2068 HTTP/1.1 January 1997 | |
789 | |
790 | |
791 to the count of elements present. That is, "(element), , (element) | |
792 " is permitted, but counts as only two elements. Therefore, where | |
793 at least one element is required, at least one non-null element | |
794 must be present. Default values are 0 and infinity so that | |
795 "#element" allows any number, including zero; "1#element" requires | |
796 at least one; and "1#2element" allows one or two. | |
797 | |
798 ; comment | |
799 A semi-colon, set off some distance to the right of rule text, | |
800 starts a comment that continues to the end of line. This is a | |
801 simple way of including useful notes in parallel with the | |
802 specifications. | |
803 | |
804 implied *LWS | |
805 The grammar described by this specification is word-based. Except | |
806 where noted otherwise, linear whitespace (LWS) can be included | |
807 between any two adjacent words (token or quoted-string), and | |
808 between adjacent tokens and delimiters (tspecials), without | |
809 changing the interpretation of a field. At least one delimiter | |
810 (tspecials) must exist between any two tokens, since they would | |
811 otherwise be interpreted as a single token. | |
812 | |
813 2.2 Basic Rules | |
814 | |
815 The following rules are used throughout this specification to | |
816 describe basic parsing constructs. The US-ASCII coded character set | |
817 is defined by ANSI X3.4-1986 [21]. | |
818 | |
819 OCTET = <any 8-bit sequence of data> | |
820 CHAR = <any US-ASCII character (octets 0 - 127)> | |
821 UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |
822 LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |
823 ALPHA = UPALPHA | LOALPHA | |
824 DIGIT = <any US-ASCII digit "0".."9"> | |
825 CTL = <any US-ASCII control character | |
826 (octets 0 - 31) and DEL (127)> | |
827 CR = <US-ASCII CR, carriage return (13)> | |
828 LF = <US-ASCII LF, linefeed (10)> | |
829 SP = <US-ASCII SP, space (32)> | |
830 HT = <US-ASCII HT, horizontal-tab (9)> | |
831 <"> = <US-ASCII double-quote mark (34)> | |
832 | |
833 | |
834 | |
835 | |
836 | |
837 | |
838 | |
839 | |
840 | |
841 | |
842 Fielding, et. al. Standards Track [Page 15] | |
843 | |
844 RFC 2068 HTTP/1.1 January 1997 | |
845 | |
846 | |
847 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |
848 protocol elements except the entity-body (see appendix 19.3 for | |
849 tolerant applications). The end-of-line marker within an entity-body | |
850 is defined by its associated media type, as described in section 3.7. | |
851 | |
852 CRLF = CR LF | |
853 | |
854 HTTP/1.1 headers can be folded onto multiple lines if the | |
855 continuation line begins with a space or horizontal tab. All linear | |
856 white space, including folding, has the same semantics as SP. | |
857 | |
858 LWS = [CRLF] 1*( SP | HT ) | |
859 | |
860 The TEXT rule is only used for descriptive field contents and values | |
861 that are not intended to be interpreted by the message parser. Words | |
862 of *TEXT may contain characters from character sets other than ISO | |
863 8859-1 [22] only when encoded according to the rules of RFC 1522 | |
864 [14]. | |
865 | |
866 TEXT = <any OCTET except CTLs, | |
867 but including LWS> | |
868 | |
869 Hexadecimal numeric characters are used in several protocol elements. | |
870 | |
871 HEX = "A" | "B" | "C" | "D" | "E" | "F" | |
872 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |
873 | |
874 Many HTTP/1.1 header field values consist of words separated by LWS | |
875 or special characters. These special characters MUST be in a quoted | |
876 string to be used within a parameter value. | |
877 | |
878 token = 1*<any CHAR except CTLs or tspecials> | |
879 | |
880 tspecials = "(" | ")" | "<" | ">" | "@" | |
881 | "," | ";" | ":" | "\" | <"> | |
882 | "/" | "[" | "]" | "?" | "=" | |
883 | "{" | "}" | SP | HT | |
884 | |
885 Comments can be included in some HTTP header fields by surrounding | |
886 the comment text with parentheses. Comments are only allowed in | |
887 fields containing "comment" as part of their field value definition. | |
888 In all other fields, parentheses are considered part of the field | |
889 value. | |
890 | |
891 comment = "(" *( ctext | comment ) ")" | |
892 ctext = <any TEXT excluding "(" and ")"> | |
893 | |
894 | |
895 | |
896 | |
897 | |
898 Fielding, et. al. Standards Track [Page 16] | |
899 | |
900 RFC 2068 HTTP/1.1 January 1997 | |
901 | |
902 | |
903 A string of text is parsed as a single word if it is quoted using | |
904 double-quote marks. | |
905 | |
906 quoted-string = ( <"> *(qdtext) <"> ) | |
907 | |
908 qdtext = <any TEXT except <">> | |
909 | |
910 The backslash character ("\") may be used as a single-character quoting | |
911 mechanism only within quoted-string and comment constructs. | |
912 | |
913 quoted-pair = "\" CHAR | |
914 | |
915 3 Protocol Parameters | |
916 | |
917 3.1 HTTP Version | |
918 | |
919 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | |
920 of the protocol. The protocol versioning policy is intended to allow | |
921 the sender to indicate the format of a message and its capacity for | |
922 understanding further HTTP communication, rather than the features | |
923 obtained via that communication. No change is made to the version | |
924 number for the addition of message components which do not affect | |
925 communication behavior or which only add to extensible field values. | |
926 The <minor> number is incremented when the changes made to the | |
927 protocol add features which do not change the general message parsing | |
928 algorithm, but which may add to the message semantics and imply | |
929 additional capabilities of the sender. The <major> number is | |
930 incremented when the format of a message within the protocol is | |
931 changed. | |
932 | |
933 The version of an HTTP message is indicated by an HTTP-Version field | |
934 in the first line of the message. | |
935 | |
936 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |
937 | |
938 Note that the major and minor numbers MUST be treated as separate | |
939 integers and that each may be incremented higher than a single digit. | |
940 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |
941 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and | |
942 MUST NOT be sent. | |
943 | |
944 Applications sending Request or Response messages, as defined by this | |
945 specification, MUST include an HTTP-Version of "HTTP/1.1". Use of | |
946 this version number indicates that the sending application is at | |
947 least conditionally compliant with this specification. | |
948 | |
949 The HTTP version of an application is the highest HTTP version for | |
950 which the application is at least conditionally compliant. | |
951 | |
952 | |
953 | |
954 Fielding, et. al. Standards Track [Page 17] | |
955 | |
956 RFC 2068 HTTP/1.1 January 1997 | |
957 | |
958 | |
959 Proxy and gateway applications must be careful when forwarding | |
960 messages in protocol versions different from that of the application. | |
961 Since the protocol version indicates the protocol capability of the | |
962 sender, a proxy/gateway MUST never send a message with a version | |
963 indicator which is greater than its actual version; if a higher | |
964 version request is received, the proxy/gateway MUST either downgrade | |
965 the request version, respond with an error, or switch to tunnel | |
966 behavior. Requests with a version lower than that of the | |
967 proxy/gateway's version MAY be upgraded before being forwarded; the | |
968 proxy/gateway's response to that request MUST be in the same major | |
969 version as the request. | |
970 | |
971 Note: Converting between versions of HTTP may involve modification | |
972 of header fields required or forbidden by the versions involved. | |
973 | |
974 3.2 Uniform Resource Identifiers | |
975 | |
976 URIs have been known by many names: WWW addresses, Universal Document | |
977 Identifiers, Universal Resource Identifiers , and finally the | |
978 combination of Uniform Resource Locators (URL) and Names (URN). As | |
979 far as HTTP is concerned, Uniform Resource Identifiers are simply | |
980 formatted strings which identify--via name, location, or any other | |
981 characteristic--a resource. | |
982 | |
983 3.2.1 General Syntax | |
984 | |
985 URIs in HTTP can be represented in absolute form or relative to some | |
986 known base URI, depending upon the context of their use. The two | |
987 forms are differentiated by the fact that absolute URIs always begin | |
988 with a scheme name followed by a colon. | |
989 | |
990 URI = ( absoluteURI | relativeURI ) [ "#" fragment ] | |
991 | |
992 absoluteURI = scheme ":" *( uchar | reserved ) | |
993 | |
994 relativeURI = net_path | abs_path | rel_path | |
995 | |
996 net_path = "//" net_loc [ abs_path ] | |
997 abs_path = "/" rel_path | |
998 rel_path = [ path ] [ ";" params ] [ "?" query ] | |
999 | |
1000 path = fsegment *( "/" segment ) | |
1001 fsegment = 1*pchar | |
1002 segment = *pchar | |
1003 | |
1004 params = param *( ";" param ) | |
1005 param = *( pchar | "/" ) | |
1006 | |
1007 | |
1008 | |
1009 | |
1010 Fielding, et. al. Standards Track [Page 18] | |
1011 | |
1012 RFC 2068 HTTP/1.1 January 1997 | |
1013 | |
1014 | |
1015 scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) | |
1016 net_loc = *( pchar | ";" | "?" ) | |
1017 | |
1018 query = *( uchar | reserved ) | |
1019 fragment = *( uchar | reserved ) | |
1020 | |
1021 pchar = uchar | ":" | "@" | "&" | "=" | "+" | |
1022 uchar = unreserved | escape | |
1023 unreserved = ALPHA | DIGIT | safe | extra | national | |
1024 | |
1025 escape = "%" HEX HEX | |
1026 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | |
1027 extra = "!" | "*" | "'" | "(" | ")" | "," | |
1028 safe = "$" | "-" | "_" | "." | |
1029 unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" | |
1030 national = <any OCTET excluding ALPHA, DIGIT, | |
1031 reserved, extra, safe, and unsafe> | |
1032 | |
1033 For definitive information on URL syntax and semantics, see RFC 1738 | |
1034 [4] and RFC 1808 [11]. The BNF above includes national characters not | |
1035 allowed in valid URLs as specified by RFC 1738, since HTTP servers | |
1036 are not restricted in the set of unreserved characters allowed to | |
1037 represent the rel_path part of addresses, and HTTP proxies may | |
1038 receive requests for URIs not defined by RFC 1738. | |
1039 | |
1040 The HTTP protocol does not place any a priori limit on the length of | |
1041 a URI. Servers MUST be able to handle the URI of any resource they | |
1042 serve, and SHOULD be able to handle URIs of unbounded length if they | |
1043 provide GET-based forms that could generate such URIs. A server | |
1044 SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |
1045 than the server can handle (see section 10.4.15). | |
1046 | |
1047 Note: Servers should be cautious about depending on URI lengths | |
1048 above 255 bytes, because some older client or proxy implementations | |
1049 may not properly support these lengths. | |
1050 | |
1051 3.2.2 http URL | |
1052 | |
1053 The "http" scheme is used to locate network resources via the HTTP | |
1054 protocol. This section defines the scheme-specific syntax and | |
1055 semantics for http URLs. | |
1056 | |
1057 | |
1058 | |
1059 | |
1060 | |
1061 | |
1062 | |
1063 | |
1064 | |
1065 | |
1066 Fielding, et. al. Standards Track [Page 19] | |
1067 | |
1068 RFC 2068 HTTP/1.1 January 1997 | |
1069 | |
1070 | |
1071 http_URL = "http:" "//" host [ ":" port ] [ abs_path ] | |
1072 | |
1073 host = <A legal Internet host domain name | |
1074 or IP address (in dotted-decimal form), | |
1075 as defined by Section 2.1 of RFC 1123> | |
1076 | |
1077 port = *DIGIT | |
1078 | |
1079 If the port is empty or not given, port 80 is assumed. The semantics | |
1080 are that the identified resource is located at the server listening | |
1081 for TCP connections on that port of that host, and the Request-URI | |
1082 for the resource is abs_path. The use of IP addresses in URL's SHOULD | |
1083 be avoided whenever possible (see RFC 1900 [24]). If the abs_path is | |
1084 not present in the URL, it MUST be given as "/" when used as a | |
1085 Request-URI for a resource (section 5.1.2). | |
1086 | |
1087 3.2.3 URI Comparison | |
1088 | |
1089 When comparing two URIs to decide if they match or not, a client | |
1090 SHOULD use a case-sensitive octet-by-octet comparison of the entire | |
1091 URIs, with these exceptions: | |
1092 | |
1093 o A port that is empty or not given is equivalent to the default | |
1094 port for that URI; | |
1095 | |
1096 o Comparisons of host names MUST be case-insensitive; | |
1097 | |
1098 o Comparisons of scheme names MUST be case-insensitive; | |
1099 | |
1100 o An empty abs_path is equivalent to an abs_path of "/". | |
1101 | |
1102 Characters other than those in the "reserved" and "unsafe" sets (see | |
1103 section 3.2) are equivalent to their ""%" HEX HEX" encodings. | |
1104 | |
1105 For example, the following three URIs are equivalent: | |
1106 | |
1107 http://abc.com:80/~smith/home.html | |
1108 http://ABC.com/%7Esmith/home.html | |
1109 http://ABC.com:/%7esmith/home.html | |
1110 | |
1111 | |
1112 | |
1113 | |
1114 | |
1115 | |
1116 | |
1117 | |
1118 | |
1119 | |
1120 | |
1121 | |
1122 Fielding, et. al. Standards Track [Page 20] | |
1123 | |
1124 RFC 2068 HTTP/1.1 January 1997 | |
1125 | |
1126 | |
1127 3.3 Date/Time Formats | |
1128 | |
1129 3.3.1 Full Date | |
1130 | |
1131 HTTP applications have historically allowed three different formats | |
1132 for the representation of date/time stamps: | |
1133 | |
1134 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 | |
1135 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | |
1136 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |
1137 | |
1138 The first format is preferred as an Internet standard and represents | |
1139 a fixed-length subset of that defined by RFC 1123 (an update to RFC | |
1140 822). The second format is in common use, but is based on the | |
1141 obsolete RFC 850 [12] date format and lacks a four-digit year. | |
1142 HTTP/1.1 clients and servers that parse the date value MUST accept | |
1143 all three formats (for compatibility with HTTP/1.0), though they MUST | |
1144 only generate the RFC 1123 format for representing HTTP-date values | |
1145 in header fields. | |
1146 | |
1147 Note: Recipients of date values are encouraged to be robust in | |
1148 accepting date values that may have been sent by non-HTTP | |
1149 applications, as is sometimes the case when retrieving or posting | |
1150 messages via proxies/gateways to SMTP or NNTP. | |
1151 | |
1152 All HTTP date/time stamps MUST be represented in Greenwich Mean Time | |
1153 (GMT), without exception. This is indicated in the first two formats | |
1154 by the inclusion of "GMT" as the three-letter abbreviation for time | |
1155 zone, and MUST be assumed when reading the asctime format. | |
1156 | |
1157 HTTP-date = rfc1123-date | rfc850-date | asctime-date | |
1158 | |
1159 rfc1123-date = wkday "," SP date1 SP time SP "GMT" | |
1160 rfc850-date = weekday "," SP date2 SP time SP "GMT" | |
1161 asctime-date = wkday SP date3 SP time SP 4DIGIT | |
1162 | |
1163 date1 = 2DIGIT SP month SP 4DIGIT | |
1164 ; day month year (e.g., 02 Jun 1982) | |
1165 date2 = 2DIGIT "-" month "-" 2DIGIT | |
1166 ; day-month-year (e.g., 02-Jun-82) | |
1167 date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | |
1168 ; month day (e.g., Jun 2) | |
1169 | |
1170 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |
1171 ; 00:00:00 - 23:59:59 | |
1172 | |
1173 wkday = "Mon" | "Tue" | "Wed" | |
1174 | "Thu" | "Fri" | "Sat" | "Sun" | |
1175 | |
1176 | |
1177 | |
1178 Fielding, et. al. Standards Track [Page 21] | |
1179 | |
1180 RFC 2068 HTTP/1.1 January 1997 | |
1181 | |
1182 | |
1183 weekday = "Monday" | "Tuesday" | "Wednesday" | |
1184 | "Thursday" | "Friday" | "Saturday" | "Sunday" | |
1185 | |
1186 month = "Jan" | "Feb" | "Mar" | "Apr" | |
1187 | "May" | "Jun" | "Jul" | "Aug" | |
1188 | "Sep" | "Oct" | "Nov" | "Dec" | |
1189 | |
1190 Note: HTTP requirements for the date/time stamp format apply only | |
1191 to their usage within the protocol stream. Clients and servers are | |
1192 not required to use these formats for user presentation, request | |
1193 logging, etc. | |
1194 | |
1195 3.3.2 Delta Seconds | |
1196 | |
1197 Some HTTP header fields allow a time value to be specified as an | |
1198 integer number of seconds, represented in decimal, after the time | |
1199 that the message was received. | |
1200 | |
1201 delta-seconds = 1*DIGIT | |
1202 | |
1203 3.4 Character Sets | |
1204 | |
1205 HTTP uses the same definition of the term "character set" as that | |
1206 described for MIME: | |
1207 | |
1208 The term "character set" is used in this document to refer to a | |
1209 method used with one or more tables to convert a sequence of octets | |
1210 into a sequence of characters. Note that unconditional conversion | |
1211 in the other direction is not required, in that not all characters | |
1212 may be available in a given character set and a character set may | |
1213 provide more than one sequence of octets to represent a particular | |
1214 character. This definition is intended to allow various kinds of | |
1215 character encodings, from simple single-table mappings such as US- | |
1216 ASCII to complex table switching methods such as those that use ISO | |
1217 2022's techniques. However, the definition associated with a MIME | |
1218 character set name MUST fully specify the mapping to be performed | |
1219 from octets to characters. In particular, use of external profiling | |
1220 information to determine the exact mapping is not permitted. | |
1221 | |
1222 Note: This use of the term "character set" is more commonly | |
1223 referred to as a "character encoding." However, since HTTP and MIME | |
1224 share the same registry, it is important that the terminology also | |
1225 be shared. | |
1226 | |
1227 | |
1228 | |
1229 | |
1230 | |
1231 | |
1232 | |
1233 | |
1234 Fielding, et. al. Standards Track [Page 22] | |
1235 | |
1236 RFC 2068 HTTP/1.1 January 1997 | |
1237 | |
1238 | |
1239 HTTP character sets are identified by case-insensitive tokens. The | |
1240 complete set of tokens is defined by the IANA Character Set registry | |
1241 [19]. | |
1242 | |
1243 charset = token | |
1244 | |
1245 Although HTTP allows an arbitrary token to be used as a charset | |
1246 value, any token that has a predefined value within the IANA | |
1247 Character Set registry MUST represent the character set defined by | |
1248 that registry. Applications SHOULD limit their use of character sets | |
1249 to those defined by the IANA registry. | |
1250 | |
1251 3.5 Content Codings | |
1252 | |
1253 Content coding values indicate an encoding transformation that has | |
1254 been or can be applied to an entity. Content codings are primarily | |
1255 used to allow a document to be compressed or otherwise usefully | |
1256 transformed without losing the identity of its underlying media type | |
1257 and without loss of information. Frequently, the entity is stored in | |
1258 coded form, transmitted directly, and only decoded by the recipient. | |
1259 | |
1260 content-coding = token | |
1261 | |
1262 All content-coding values are case-insensitive. HTTP/1.1 uses | |
1263 content-coding values in the Accept-Encoding (section 14.3) and | |
1264 Content-Encoding (section 14.12) header fields. Although the value | |
1265 describes the content-coding, what is more important is that it | |
1266 indicates what decoding mechanism will be required to remove the | |
1267 encoding. | |
1268 | |
1269 The Internet Assigned Numbers Authority (IANA) acts as a registry for | |
1270 content-coding value tokens. Initially, the registry contains the | |
1271 following tokens: | |
1272 | |
1273 gzip An encoding format produced by the file compression program "gzip" | |
1274 (GNU zip) as described in RFC 1952 [25]. This format is a Lempel- | |
1275 Ziv coding (LZ77) with a 32 bit CRC. | |
1276 | |
1277 compress | |
1278 The encoding format produced by the common UNIX file compression | |
1279 program "compress". This format is an adaptive Lempel-Ziv-Welch | |
1280 coding (LZW). | |
1281 | |
1282 | |
1283 | |
1284 | |
1285 | |
1286 | |
1287 | |
1288 | |
1289 | |
1290 Fielding, et. al. Standards Track [Page 23] | |
1291 | |
1292 RFC 2068 HTTP/1.1 January 1997 | |
1293 | |
1294 | |
1295 Note: Use of program names for the identification of encoding | |
1296 formats is not desirable and should be discouraged for future | |
1297 encodings. Their use here is representative of historical practice, | |
1298 not good design. For compatibility with previous implementations of | |
1299 HTTP, applications should consider "x-gzip" and "x-compress" to be | |
1300 equivalent to "gzip" and "compress" respectively. | |
1301 | |
1302 deflate The "zlib" format defined in RFC 1950[31] in combination with | |
1303 the "deflate" compression mechanism described in RFC 1951[29]. | |
1304 | |
1305 New content-coding value tokens should be registered; to allow | |
1306 interoperability between clients and servers, specifications of the | |
1307 content coding algorithms needed to implement a new value should be | |
1308 publicly available and adequate for independent implementation, and | |
1309 conform to the purpose of content coding defined in this section. | |
1310 | |
1311 3.6 Transfer Codings | |
1312 | |
1313 Transfer coding values are used to indicate an encoding | |
1314 transformation that has been, can be, or may need to be applied to an | |
1315 entity-body in order to ensure "safe transport" through the network. | |
1316 This differs from a content coding in that the transfer coding is a | |
1317 property of the message, not of the original entity. | |
1318 | |
1319 transfer-coding = "chunked" | transfer-extension | |
1320 | |
1321 transfer-extension = token | |
1322 | |
1323 All transfer-coding values are case-insensitive. HTTP/1.1 uses | |
1324 transfer coding values in the Transfer-Encoding header field (section | |
1325 14.40). | |
1326 | |
1327 Transfer codings are analogous to the Content-Transfer-Encoding | |
1328 values of MIME , which were designed to enable safe transport of | |
1329 binary data over a 7-bit transport service. However, safe transport | |
1330 has a different focus for an 8bit-clean transfer protocol. In HTTP, | |
1331 the only unsafe characteristic of message-bodies is the difficulty in | |
1332 determining the exact body length (section 7.2.2), or the desire to | |
1333 encrypt data over a shared transport. | |
1334 | |
1335 The chunked encoding modifies the body of a message in order to | |
1336 transfer it as a series of chunks, each with its own size indicator, | |
1337 followed by an optional footer containing entity-header fields. This | |
1338 allows dynamically-produced content to be transferred along with the | |
1339 information necessary for the recipient to verify that it has | |
1340 received the full message. | |
1341 | |
1342 | |
1343 | |
1344 | |
1345 | |
1346 Fielding, et. al. Standards Track [Page 24] | |
1347 | |
1348 RFC 2068 HTTP/1.1 January 1997 | |
1349 | |
1350 | |
1351 Chunked-Body = *chunk | |
1352 "0" CRLF | |
1353 footer | |
1354 CRLF | |
1355 | |
1356 chunk = chunk-size [ chunk-ext ] CRLF | |
1357 chunk-data CRLF | |
1358 | |
1359 hex-no-zero = <HEX excluding "0"> | |
1360 | |
1361 chunk-size = hex-no-zero *HEX | |
1362 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) | |
1363 chunk-ext-name = token | |
1364 chunk-ext-val = token | quoted-string | |
1365 chunk-data = chunk-size(OCTET) | |
1366 | |
1367 footer = *entity-header | |
1368 | |
1369 The chunked encoding is ended by a zero-sized chunk followed by the | |
1370 footer, which is terminated by an empty line. The purpose of the | |
1371 footer is to provide an efficient way to supply information about an | |
1372 entity that is generated dynamically; applications MUST NOT send | |
1373 header fields in the footer which are not explicitly defined as being | |
1374 appropriate for the footer, such as Content-MD5 or future extensions | |
1375 to HTTP for digital signatures or other facilities. | |
1376 | |
1377 An example process for decoding a Chunked-Body is presented in | |
1378 appendix 19.4.6. | |
1379 | |
1380 All HTTP/1.1 applications MUST be able to receive and decode the | |
1381 "chunked" transfer coding, and MUST ignore transfer coding extensions | |
1382 they do not understand. A server which receives an entity-body with a | |
1383 transfer-coding it does not understand SHOULD return 501 | |
1384 (Unimplemented), and close the connection. A server MUST NOT send | |
1385 transfer-codings to an HTTP/1.0 client. | |
1386 | |
1387 3.7 Media Types | |
1388 | |
1389 HTTP uses Internet Media Types in the Content-Type (section 14.18) | |
1390 and Accept (section 14.1) header fields in order to provide open and | |
1391 extensible data typing and type negotiation. | |
1392 | |
1393 media-type = type "/" subtype *( ";" parameter ) | |
1394 type = token | |
1395 subtype = token | |
1396 | |
1397 Parameters may follow the type/subtype in the form of attribute/value | |
1398 pairs. | |
1399 | |
1400 | |
1401 | |
1402 Fielding, et. al. Standards Track [Page 25] | |
1403 | |
1404 RFC 2068 HTTP/1.1 January 1997 | |
1405 | |
1406 | |
1407 parameter = attribute "=" value | |
1408 attribute = token | |
1409 value = token | quoted-string | |
1410 | |
1411 The type, subtype, and parameter attribute names are case- | |
1412 insensitive. Parameter values may or may not be case-sensitive, | |
1413 depending on the semantics of the parameter name. Linear white space | |
1414 (LWS) MUST NOT be used between the type and subtype, nor between an | |
1415 attribute and its value. User agents that recognize the media-type | |
1416 MUST process (or arrange to be processed by any external applications | |
1417 used to process that type/subtype by the user agent) the parameters | |
1418 for that MIME type as described by that type/subtype definition to | |
1419 the and inform the user of any problems discovered. | |
1420 | |
1421 Note: some older HTTP applications do not recognize media type | |
1422 parameters. When sending data to older HTTP applications, | |
1423 implementations should only use media type parameters when they are | |
1424 required by that type/subtype definition. | |
1425 | |
1426 Media-type values are registered with the Internet Assigned Number | |
1427 Authority (IANA). The media type registration process is outlined in | |
1428 RFC 2048 [17]. Use of non-registered media types is discouraged. | |
1429 | |
1430 3.7.1 Canonicalization and Text Defaults | |
1431 | |
1432 Internet media types are registered with a canonical form. In | |
1433 general, an entity-body transferred via HTTP messages MUST be | |
1434 represented in the appropriate canonical form prior to its | |
1435 transmission; the exception is "text" types, as defined in the next | |
1436 paragraph. | |
1437 | |
1438 When in canonical form, media subtypes of the "text" type use CRLF as | |
1439 the text line break. HTTP relaxes this requirement and allows the | |
1440 transport of text media with plain CR or LF alone representing a line | |
1441 break when it is done consistently for an entire entity-body. HTTP | |
1442 applications MUST accept CRLF, bare CR, and bare LF as being | |
1443 representative of a line break in text media received via HTTP. In | |
1444 addition, if the text is represented in a character set that does not | |
1445 use octets 13 and 10 for CR and LF respectively, as is the case for | |
1446 some multi-byte character sets, HTTP allows the use of whatever octet | |
1447 sequences are defined by that character set to represent the | |
1448 equivalent of CR and LF for line breaks. This flexibility regarding | |
1449 line breaks applies only to text media in the entity-body; a bare CR | |
1450 or LF MUST NOT be substituted for CRLF within any of the HTTP control | |
1451 structures (such as header fields and multipart boundaries). | |
1452 | |
1453 If an entity-body is encoded with a Content-Encoding, the underlying | |
1454 data MUST be in a form defined above prior to being encoded. | |
1455 | |
1456 | |
1457 | |
1458 Fielding, et. al. Standards Track [Page 26] | |
1459 | |
1460 RFC 2068 HTTP/1.1 January 1997 | |
1461 | |
1462 | |
1463 The "charset" parameter is used with some media types to define the | |
1464 character set (section 3.4) of the data. When no explicit charset | |
1465 parameter is provided by the sender, media subtypes of the "text" | |
1466 type are defined to have a default charset value of "ISO-8859-1" when | |
1467 received via HTTP. Data in character sets other than "ISO-8859-1" or | |
1468 its subsets MUST be labeled with an appropriate charset value. | |
1469 | |
1470 Some HTTP/1.0 software has interpreted a Content-Type header without | |
1471 charset parameter incorrectly to mean "recipient should guess." | |
1472 Senders wishing to defeat this behavior MAY include a charset | |
1473 parameter even when the charset is ISO-8859-1 and SHOULD do so when | |
1474 it is known that it will not confuse the recipient. | |
1475 | |
1476 Unfortunately, some older HTTP/1.0 clients did not deal properly with | |
1477 an explicit charset parameter. HTTP/1.1 recipients MUST respect the | |
1478 charset label provided by the sender; and those user agents that have | |
1479 a provision to "guess" a charset MUST use the charset from the | |
1480 content-type field if they support that charset, rather than the | |
1481 recipient's preference, when initially displaying a document. | |
1482 | |
1483 3.7.2 Multipart Types | |
1484 | |
1485 MIME provides for a number of "multipart" types -- encapsulations of | |
1486 one or more entities within a single message-body. All multipart | |
1487 types share a common syntax, as defined in MIME [7], and MUST | |
1488 include a boundary parameter as part of the media type value. The | |
1489 message body is itself a protocol element and MUST therefore use only | |
1490 CRLF to represent line breaks between body-parts. Unlike in MIME, the | |
1491 epilogue of any multipart message MUST be empty; HTTP applications | |
1492 MUST NOT transmit the epilogue (even if the original multipart | |
1493 contains an epilogue). | |
1494 | |
1495 In HTTP, multipart body-parts MAY contain header fields which are | |
1496 significant to the meaning of that part. A Content-Location header | |
1497 field (section 14.15) SHOULD be included in the body-part of each | |
1498 enclosed entity that can be identified by a URL. | |
1499 | |
1500 In general, an HTTP user agent SHOULD follow the same or similar | |
1501 behavior as a MIME user agent would upon receipt of a multipart type. | |
1502 If an application receives an unrecognized multipart subtype, the | |
1503 application MUST treat it as being equivalent to "multipart/mixed". | |
1504 | |
1505 Note: The "multipart/form-data" type has been specifically defined | |
1506 for carrying form data suitable for processing via the POST request | |
1507 method, as described in RFC 1867 [15]. | |
1508 | |
1509 | |
1510 | |
1511 | |
1512 | |
1513 | |
1514 Fielding, et. al. Standards Track [Page 27] | |
1515 | |
1516 RFC 2068 HTTP/1.1 January 1997 | |
1517 | |
1518 | |
1519 3.8 Product Tokens | |
1520 | |
1521 Product tokens are used to allow communicating applications to | |
1522 identify themselves by software name and version. Most fields using | |
1523 product tokens also allow sub-products which form a significant part | |
1524 of the application to be listed, separated by whitespace. By | |
1525 convention, the products are listed in order of their significance | |
1526 for identifying the application. | |
1527 | |
1528 product = token ["/" product-version] | |
1529 product-version = token | |
1530 | |
1531 Examples: | |
1532 | |
1533 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |
1534 Server: Apache/0.8.4 | |
1535 | |
1536 Product tokens should be short and to the point -- use of them for | |
1537 advertising or other non-essential information is explicitly | |
1538 forbidden. Although any token character may appear in a product- | |
1539 version, this token SHOULD only be used for a version identifier | |
1540 (i.e., successive versions of the same product SHOULD only differ in | |
1541 the product-version portion of the product value). | |
1542 | |
1543 3.9 Quality Values | |
1544 | |
1545 HTTP content negotiation (section 12) uses short "floating point" | |
1546 numbers to indicate the relative importance ("weight") of various | |
1547 negotiable parameters. A weight is normalized to a real number in the | |
1548 range 0 through 1, where 0 is the minimum and 1 the maximum value. | |
1549 HTTP/1.1 applications MUST NOT generate more than three digits after | |
1550 the decimal point. User configuration of these values SHOULD also be | |
1551 limited in this fashion. | |
1552 | |
1553 qvalue = ( "0" [ "." 0*3DIGIT ] ) | |
1554 | ( "1" [ "." 0*3("0") ] ) | |
1555 | |
1556 "Quality values" is a misnomer, since these values merely represent | |
1557 relative degradation in desired quality. | |
1558 | |
1559 3.10 Language Tags | |
1560 | |
1561 A language tag identifies a natural language spoken, written, or | |
1562 otherwise conveyed by human beings for communication of information | |
1563 to other human beings. Computer languages are explicitly excluded. | |
1564 HTTP uses language tags within the Accept-Language and Content- | |
1565 Language fields. | |
1566 | |
1567 | |
1568 | |
1569 | |
1570 Fielding, et. al. Standards Track [Page 28] | |
1571 | |
1572 RFC 2068 HTTP/1.1 January 1997 | |
1573 | |
1574 | |
1575 The syntax and registry of HTTP language tags is the same as that | |
1576 defined by RFC 1766 [1]. In summary, a language tag is composed of 1 | |
1577 or more parts: A primary language tag and a possibly empty series of | |
1578 subtags: | |
1579 | |
1580 language-tag = primary-tag *( "-" subtag ) | |
1581 | |
1582 primary-tag = 1*8ALPHA | |
1583 subtag = 1*8ALPHA | |
1584 | |
1585 Whitespace is not allowed within the tag and all tags are case- | |
1586 insensitive. The name space of language tags is administered by the | |
1587 IANA. Example tags include: | |
1588 | |
1589 en, en-US, en-cockney, i-cherokee, x-pig-latin | |
1590 | |
1591 where any two-letter primary-tag is an ISO 639 language abbreviation | |
1592 and any two-letter initial subtag is an ISO 3166 country code. (The | |
1593 last three tags above are not registered tags; all but the last are | |
1594 examples of tags which could be registered in future.) | |
1595 | |
1596 3.11 Entity Tags | |
1597 | |
1598 Entity tags are used for comparing two or more entities from the same | |
1599 requested resource. HTTP/1.1 uses entity tags in the ETag (section | |
1600 14.20), If-Match (section 14.25), If-None-Match (section 14.26), and | |
1601 If-Range (section 14.27) header fields. The definition of how they | |
1602 are used and compared as cache validators is in section 13.3.3. An | |
1603 entity tag consists of an opaque quoted string, possibly prefixed by | |
1604 a weakness indicator. | |
1605 | |
1606 entity-tag = [ weak ] opaque-tag | |
1607 | |
1608 weak = "W/" | |
1609 opaque-tag = quoted-string | |
1610 | |
1611 A "strong entity tag" may be shared by two entities of a resource | |
1612 only if they are equivalent by octet equality. | |
1613 | |
1614 A "weak entity tag," indicated by the "W/" prefix, may be shared by | |
1615 two entities of a resource only if the entities are equivalent and | |
1616 could be substituted for each other with no significant change in | |
1617 semantics. A weak entity tag can only be used for weak comparison. | |
1618 | |
1619 An entity tag MUST be unique across all versions of all entities | |
1620 associated with a particular resource. A given entity tag value may | |
1621 be used for entities obtained by requests on different URIs without | |
1622 implying anything about the equivalence of those entities. | |
1623 | |
1624 | |
1625 | |
1626 Fielding, et. al. Standards Track [Page 29] | |
1627 | |
1628 RFC 2068 HTTP/1.1 January 1997 | |
1629 | |
1630 | |
1631 3.12 Range Units | |
1632 | |
1633 HTTP/1.1 allows a client to request that only part (a range of) the | |
1634 response entity be included within the response. HTTP/1.1 uses range | |
1635 units in the Range (section 14.36) and Content-Range (section 14.17) | |
1636 header fields. An entity may be broken down into subranges according | |
1637 to various structural units. | |
1638 | |
1639 range-unit = bytes-unit | other-range-unit | |
1640 | |
1641 bytes-unit = "bytes" | |
1642 other-range-unit = token | |
1643 | |
1644 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | |
1645 implementations may ignore ranges specified using other units. | |
1646 HTTP/1.1 has been designed to allow implementations of applications | |
1647 that do not depend on knowledge of ranges. | |
1648 | |
1649 4 HTTP Message | |
1650 | |
1651 4.1 Message Types | |
1652 | |
1653 HTTP messages consist of requests from client to server and responses | |
1654 from server to client. | |
1655 | |
1656 HTTP-message = Request | Response ; HTTP/1.1 messages | |
1657 | |
1658 Request (section 5) and Response (section 6) messages use the generic | |
1659 message format of RFC 822 [9] for transferring entities (the payload | |
1660 of the message). Both types of message consist of a start-line, one | |
1661 or more header fields (also known as "headers"), an empty line (i.e., | |
1662 a line with nothing preceding the CRLF) indicating the end of the | |
1663 header fields, and an optional message-body. | |
1664 | |
1665 generic-message = start-line | |
1666 *message-header | |
1667 CRLF | |
1668 [ message-body ] | |
1669 | |
1670 start-line = Request-Line | Status-Line | |
1671 | |
1672 In the interest of robustness, servers SHOULD ignore any empty | |
1673 line(s) received where a Request-Line is expected. In other words, if | |
1674 the server is reading the protocol stream at the beginning of a | |
1675 message and receives a CRLF first, it should ignore the CRLF. | |
1676 | |
1677 | |
1678 | |
1679 | |
1680 | |
1681 | |
1682 Fielding, et. al. Standards Track [Page 30] | |
1683 | |
1684 RFC 2068 HTTP/1.1 January 1997 | |
1685 | |
1686 | |
1687 Note: certain buggy HTTP/1.0 client implementations generate an | |
1688 extra CRLF's after a POST request. To restate what is explicitly | |
1689 forbidden by the BNF, an HTTP/1.1 client must not preface or follow | |
1690 a request with an extra CRLF. | |
1691 | |
1692 4.2 Message Headers | |
1693 | |
1694 HTTP header fields, which include general-header (section 4.5), | |
1695 request-header (section 5.3), response-header (section 6.2), and | |
1696 entity-header (section 7.1) fields, follow the same generic format as | |
1697 that given in Section 3.1 of RFC 822 [9]. Each header field consists | |
1698 of a name followed by a colon (":") and the field value. Field names | |
1699 are case-insensitive. The field value may be preceded by any amount | |
1700 of LWS, though a single SP is preferred. Header fields can be | |
1701 extended over multiple lines by preceding each extra line with at | |
1702 least one SP or HT. Applications SHOULD follow "common form" when | |
1703 generating HTTP constructs, since there might exist some | |
1704 implementations that fail to accept anything beyond the common forms. | |
1705 | |
1706 message-header = field-name ":" [ field-value ] CRLF | |
1707 | |
1708 field-name = token | |
1709 field-value = *( field-content | LWS ) | |
1710 | |
1711 field-content = <the OCTETs making up the field-value | |
1712 and consisting of either *TEXT or combinations | |
1713 of token, tspecials, and quoted-string> | |
1714 | |
1715 The order in which header fields with differing field names are | |
1716 received is not significant. However, it is "good practice" to send | |
1717 general-header fields first, followed by request-header or response- | |
1718 header fields, and ending with the entity-header fields. | |
1719 | |
1720 Multiple message-header fields with the same field-name may be | |
1721 present in a message if and only if the entire field-value for that | |
1722 header field is defined as a comma-separated list [i.e., #(values)]. | |
1723 It MUST be possible to combine the multiple header fields into one | |
1724 "field-name: field-value" pair, without changing the semantics of the | |
1725 message, by appending each subsequent field-value to the first, each | |
1726 separated by a comma. The order in which header fields with the same | |
1727 field-name are received is therefore significant to the | |
1728 interpretation of the combined field value, and thus a proxy MUST NOT | |
1729 change the order of these field values when a message is forwarded. | |
1730 | |
1731 | |
1732 | |
1733 | |
1734 | |
1735 | |
1736 | |
1737 | |
1738 Fielding, et. al. Standards Track [Page 31] | |
1739 | |
1740 RFC 2068 HTTP/1.1 January 1997 | |
1741 | |
1742 | |
1743 4.3 Message Body | |
1744 | |
1745 The message-body (if any) of an HTTP message is used to carry the | |
1746 entity-body associated with the request or response. The message-body | |
1747 differs from the entity-body only when a transfer coding has been | |
1748 applied, as indicated by the Transfer-Encoding header field (section | |
1749 14.40). | |
1750 | |
1751 message-body = entity-body | |
1752 | <entity-body encoded as per Transfer-Encoding> | |
1753 | |
1754 Transfer-Encoding MUST be used to indicate any transfer codings | |
1755 applied by an application to ensure safe and proper transfer of the | |
1756 message. Transfer-Encoding is a property of the message, not of the | |
1757 entity, and thus can be added or removed by any application along the | |
1758 request/response chain. | |
1759 | |
1760 The rules for when a message-body is allowed in a message differ for | |
1761 requests and responses. | |
1762 | |
1763 The presence of a message-body in a request is signaled by the | |
1764 inclusion of a Content-Length or Transfer-Encoding header field in | |
1765 the request's message-headers. A message-body MAY be included in a | |
1766 request only when the request method (section 5.1.1) allows an | |
1767 entity-body. | |
1768 | |
1769 For response messages, whether or not a message-body is included with | |
1770 a message is dependent on both the request method and the response | |
1771 status code (section 6.1.1). All responses to the HEAD request method | |
1772 MUST NOT include a message-body, even though the presence of entity- | |
1773 header fields might lead one to believe they do. All 1xx | |
1774 (informational), 204 (no content), and 304 (not modified) responses | |
1775 MUST NOT include a message-body. All other responses do include a | |
1776 message-body, although it may be of zero length. | |
1777 | |
1778 4.4 Message Length | |
1779 | |
1780 When a message-body is included with a message, the length of that | |
1781 body is determined by one of the following (in order of precedence): | |
1782 | |
1783 1. Any response message which MUST NOT include a message-body | |
1784 (such as the 1xx, 204, and 304 responses and any response to a HEAD | |
1785 request) is always terminated by the first empty line after the | |
1786 header fields, regardless of the entity-header fields present in the | |
1787 message. | |
1788 | |
1789 2. If a Transfer-Encoding header field (section 14.40) is present and | |
1790 indicates that the "chunked" transfer coding has been applied, then | |
1791 | |
1792 | |
1793 | |
1794 Fielding, et. al. Standards Track [Page 32] | |
1795 | |
1796 RFC 2068 HTTP/1.1 January 1997 | |
1797 | |
1798 | |
1799 the length is defined by the chunked encoding (section 3.6). | |
1800 | |
1801 3. If a Content-Length header field (section 14.14) is present, its | |
1802 value in bytes represents the length of the message-body. | |
1803 | |
1804 4. If the message uses the media type "multipart/byteranges", which is | |
1805 self-delimiting, then that defines the length. This media type MUST | |
1806 NOT be used unless the sender knows that the recipient can parse it; | |
1807 the presence in a request of a Range header with multiple byte-range | |
1808 specifiers implies that the client can parse multipart/byteranges | |
1809 responses. | |
1810 | |
1811 5. By the server closing the connection. (Closing the connection | |
1812 cannot be used to indicate the end of a request body, since that | |
1813 would leave no possibility for the server to send back a response.) | |
1814 | |
1815 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | |
1816 containing a message-body MUST include a valid Content-Length header | |
1817 field unless the server is known to be HTTP/1.1 compliant. If a | |
1818 request contains a message-body and a Content-Length is not given, | |
1819 the server SHOULD respond with 400 (bad request) if it cannot | |
1820 determine the length of the message, or with 411 (length required) if | |
1821 it wishes to insist on receiving a valid Content-Length. | |
1822 | |
1823 All HTTP/1.1 applications that receive entities MUST accept the | |
1824 "chunked" transfer coding (section 3.6), thus allowing this mechanism | |
1825 to be used for messages when the message length cannot be determined | |
1826 in advance. | |
1827 | |
1828 Messages MUST NOT include both a Content-Length header field and the | |
1829 "chunked" transfer coding. If both are received, the Content-Length | |
1830 MUST be ignored. | |
1831 | |
1832 When a Content-Length is given in a message where a message-body is | |
1833 allowed, its field value MUST exactly match the number of OCTETs in | |
1834 the message-body. HTTP/1.1 user agents MUST notify the user when an | |
1835 invalid length is received and detected. | |
1836 | |
1837 | |
1838 | |
1839 | |
1840 | |
1841 | |
1842 | |
1843 | |
1844 | |
1845 | |
1846 | |
1847 | |
1848 | |
1849 | |
1850 Fielding, et. al. Standards Track [Page 33] | |
1851 | |
1852 RFC 2068 HTTP/1.1 January 1997 | |
1853 | |
1854 | |
1855 4.5 General Header Fields | |
1856 | |
1857 There are a few header fields which have general applicability for | |
1858 both request and response messages, but which do not apply to the | |
1859 entity being transferred. These header fields apply only to the | |
1860 message being transmitted. | |
1861 | |
1862 general-header = Cache-Control ; Section 14.9 | |
1863 | Connection ; Section 14.10 | |
1864 | Date ; Section 14.19 | |
1865 | Pragma ; Section 14.32 | |
1866 | Transfer-Encoding ; Section 14.40 | |
1867 | Upgrade ; Section 14.41 | |
1868 | Via ; Section 14.44 | |
1869 | |
1870 General-header field names can be extended reliably only in | |
1871 combination with a change in the protocol version. However, new or | |
1872 experimental header fields may be given the semantics of general | |
1873 header fields if all parties in the communication recognize them to | |
1874 be general-header fields. Unrecognized header fields are treated as | |
1875 entity-header fields. | |
1876 | |
1877 5 Request | |
1878 | |
1879 A request message from a client to a server includes, within the | |
1880 first line of that message, the method to be applied to the resource, | |
1881 the identifier of the resource, and the protocol version in use. | |
1882 | |
1883 Request = Request-Line ; Section 5.1 | |
1884 *( general-header ; Section 4.5 | |
1885 | request-header ; Section 5.3 | |
1886 | entity-header ) ; Section 7.1 | |
1887 CRLF | |
1888 [ message-body ] ; Section 7.2 | |
1889 | |
1890 5.1 Request-Line | |
1891 | |
1892 The Request-Line begins with a method token, followed by the | |
1893 Request-URI and the protocol version, and ending with CRLF. The | |
1894 elements are separated by SP characters. No CR or LF are allowed | |
1895 except in the final CRLF sequence. | |
1896 | |
1897 Request-Line = Method SP Request-URI SP HTTP-Version CRLF | |
1898 | |
1899 | |
1900 | |
1901 | |
1902 | |
1903 | |
1904 | |
1905 | |
1906 Fielding, et. al. Standards Track [Page 34] | |
1907 | |
1908 RFC 2068 HTTP/1.1 January 1997 | |
1909 | |
1910 | |
1911 5.1.1 Method | |
1912 | |
1913 The Method token indicates the method to be performed on the resource | |
1914 identified by the Request-URI. The method is case-sensitive. | |
1915 | |
1916 Method = "OPTIONS" ; Section 9.2 | |
1917 | "GET" ; Section 9.3 | |
1918 | "HEAD" ; Section 9.4 | |
1919 | "POST" ; Section 9.5 | |
1920 | "PUT" ; Section 9.6 | |
1921 | "DELETE" ; Section 9.7 | |
1922 | "TRACE" ; Section 9.8 | |
1923 | extension-method | |
1924 | |
1925 extension-method = token | |
1926 | |
1927 The list of methods allowed by a resource can be specified in an | |
1928 Allow header field (section 14.7). The return code of the response | |
1929 always notifies the client whether a method is currently allowed on a | |
1930 resource, since the set of allowed methods can change dynamically. | |
1931 Servers SHOULD return the status code 405 (Method Not Allowed) if the | |
1932 method is known by the server but not allowed for the requested | |
1933 resource, and 501 (Not Implemented) if the method is unrecognized or | |
1934 not implemented by the server. The list of methods known by a server | |
1935 can be listed in a Public response-header field (section 14.35). | |
1936 | |
1937 The methods GET and HEAD MUST be supported by all general-purpose | |
1938 servers. All other methods are optional; however, if the above | |
1939 methods are implemented, they MUST be implemented with the same | |
1940 semantics as those specified in section 9. | |
1941 | |
1942 5.1.2 Request-URI | |
1943 | |
1944 The Request-URI is a Uniform Resource Identifier (section 3.2) and | |
1945 identifies the resource upon which to apply the request. | |
1946 | |
1947 Request-URI = "*" | absoluteURI | abs_path | |
1948 | |
1949 The three options for Request-URI are dependent on the nature of the | |
1950 request. The asterisk "*" means that the request does not apply to a | |
1951 particular resource, but to the server itself, and is only allowed | |
1952 when the method used does not necessarily apply to a resource. One | |
1953 example would be | |
1954 | |
1955 OPTIONS * HTTP/1.1 | |
1956 | |
1957 The absoluteURI form is required when the request is being made to a | |
1958 proxy. The proxy is requested to forward the request or service it | |
1959 | |
1960 | |
1961 | |
1962 Fielding, et. al. Standards Track [Page 35] | |
1963 | |
1964 RFC 2068 HTTP/1.1 January 1997 | |
1965 | |
1966 | |
1967 from a valid cache, and return the response. Note that the proxy MAY | |
1968 forward the request on to another proxy or directly to the server | |
1969 specified by the absoluteURI. In order to avoid request loops, a | |
1970 proxy MUST be able to recognize all of its server names, including | |
1971 any aliases, local variations, and the numeric IP address. An example | |
1972 Request-Line would be: | |
1973 | |
1974 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 | |
1975 | |
1976 To allow for transition to absoluteURIs in all requests in future | |
1977 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI | |
1978 form in requests, even though HTTP/1.1 clients will only generate | |
1979 them in requests to proxies. | |
1980 | |
1981 The most common form of Request-URI is that used to identify a | |
1982 resource on an origin server or gateway. In this case the absolute | |
1983 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as | |
1984 the Request-URI, and the network location of the URI (net_loc) MUST | |
1985 be transmitted in a Host header field. For example, a client wishing | |
1986 to retrieve the resource above directly from the origin server would | |
1987 create a TCP connection to port 80 of the host "www.w3.org" and send | |
1988 the lines: | |
1989 | |
1990 GET /pub/WWW/TheProject.html HTTP/1.1 | |
1991 Host: www.w3.org | |
1992 | |
1993 followed by the remainder of the Request. Note that the absolute path | |
1994 cannot be empty; if none is present in the original URI, it MUST be | |
1995 given as "/" (the server root). | |
1996 | |
1997 If a proxy receives a request without any path in the Request-URI and | |
1998 the method specified is capable of supporting the asterisk form of | |
1999 request, then the last proxy on the request chain MUST forward the | |
2000 request with "*" as the final Request-URI. For example, the request | |
2001 | |
2002 OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1 | |
2003 | |
2004 would be forwarded by the proxy as | |
2005 | |
2006 OPTIONS * HTTP/1.1 | |
2007 Host: www.ics.uci.edu:8001 | |
2008 | |
2009 after connecting to port 8001 of host "www.ics.uci.edu". | |
2010 | |
2011 The Request-URI is transmitted in the format specified in section | |
2012 3.2.1. The origin server MUST decode the Request-URI in order to | |
2013 properly interpret the request. Servers SHOULD respond to invalid | |
2014 Request-URIs with an appropriate status code. | |
2015 | |
2016 | |
2017 | |
2018 Fielding, et. al. Standards Track [Page 36] | |
2019 | |
2020 RFC 2068 HTTP/1.1 January 1997 | |
2021 | |
2022 | |
2023 In requests that they forward, proxies MUST NOT rewrite the | |
2024 "abs_path" part of a Request-URI in any way except as noted above to | |
2025 replace a null abs_path with "*", no matter what the proxy does in | |
2026 its internal implementation. | |
2027 | |
2028 Note: The "no rewrite" rule prevents the proxy from changing the | |
2029 meaning of the request when the origin server is improperly using a | |
2030 non-reserved URL character for a reserved purpose. Implementers | |
2031 should be aware that some pre-HTTP/1.1 proxies have been known to | |
2032 rewrite the Request-URI. | |
2033 | |
2034 5.2 The Resource Identified by a Request | |
2035 | |
2036 HTTP/1.1 origin servers SHOULD be aware that the exact resource | |
2037 identified by an Internet request is determined by examining both the | |
2038 Request-URI and the Host header field. | |
2039 | |
2040 An origin server that does not allow resources to differ by the | |
2041 requested host MAY ignore the Host header field value. (But see | |
2042 section 19.5.1 for other requirements on Host support in HTTP/1.1.) | |
2043 | |
2044 An origin server that does differentiate resources based on the host | |
2045 requested (sometimes referred to as virtual hosts or vanity | |
2046 hostnames) MUST use the following rules for determining the requested | |
2047 resource on an HTTP/1.1 request: | |
2048 | |
2049 1. If Request-URI is an absoluteURI, the host is part of the | |
2050 Request-URI. Any Host header field value in the request MUST be | |
2051 ignored. | |
2052 | |
2053 2. If the Request-URI is not an absoluteURI, and the request | |
2054 includes a Host header field, the host is determined by the Host | |
2055 header field value. | |
2056 | |
2057 3. If the host as determined by rule 1 or 2 is not a valid host on | |
2058 the server, the response MUST be a 400 (Bad Request) error | |
2059 message. | |
2060 | |
2061 Recipients of an HTTP/1.0 request that lacks a Host header field MAY | |
2062 attempt to use heuristics (e.g., examination of the URI path for | |
2063 something unique to a particular host) in order to determine what | |
2064 exact resource is being requested. | |
2065 | |
2066 5.3 Request Header Fields | |
2067 | |
2068 The request-header fields allow the client to pass additional | |
2069 information about the request, and about the client itself, to the | |
2070 server. These fields act as request modifiers, with semantics | |
2071 | |
2072 | |
2073 | |
2074 Fielding, et. al. Standards Track [Page 37] | |
2075 | |
2076 RFC 2068 HTTP/1.1 January 1997 | |
2077 | |
2078 | |
2079 equivalent to the parameters on a programming language method | |
2080 invocation. | |
2081 | |
2082 request-header = Accept ; Section 14.1 | |
2083 | Accept-Charset ; Section 14.2 | |
2084 | Accept-Encoding ; Section 14.3 | |
2085 | Accept-Language ; Section 14.4 | |
2086 | Authorization ; Section 14.8 | |
2087 | From ; Section 14.22 | |
2088 | Host ; Section 14.23 | |
2089 | If-Modified-Since ; Section 14.24 | |
2090 | If-Match ; Section 14.25 | |
2091 | If-None-Match ; Section 14.26 | |
2092 | If-Range ; Section 14.27 | |
2093 | If-Unmodified-Since ; Section 14.28 | |
2094 | Max-Forwards ; Section 14.31 | |
2095 | Proxy-Authorization ; Section 14.34 | |
2096 | Range ; Section 14.36 | |
2097 | Referer ; Section 14.37 | |
2098 | User-Agent ; Section 14.42 | |
2099 | |
2100 Request-header field names can be extended reliably only in | |
2101 combination with a change in the protocol version. However, new or | |
2102 experimental header fields MAY be given the semantics of request- | |
2103 header fields if all parties in the communication recognize them to | |
2104 be request-header fields. Unrecognized header fields are treated as | |
2105 entity-header fields. | |
2106 | |
2107 6 Response | |
2108 | |
2109 After receiving and interpreting a request message, a server responds | |
2110 with an HTTP response message. | |
2111 | |
2112 Response = Status-Line ; Section 6.1 | |
2113 *( general-header ; Section 4.5 | |
2114 | response-header ; Section 6.2 | |
2115 | entity-header ) ; Section 7.1 | |
2116 CRLF | |
2117 [ message-body ] ; Section 7.2 | |
2118 | |
2119 6.1 Status-Line | |
2120 | |
2121 The first line of a Response message is the Status-Line, consisting | |
2122 of the protocol version followed by a numeric status code and its | |
2123 associated textual phrase, with each element separated by SP | |
2124 characters. No CR or LF is allowed except in the final CRLF | |
2125 sequence. | |
2126 | |
2127 | |
2128 | |
2129 | |
2130 Fielding, et. al. Standards Track [Page 38] | |
2131 | |
2132 RFC 2068 HTTP/1.1 January 1997 | |
2133 | |
2134 | |
2135 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | |
2136 | |
2137 6.1.1 Status Code and Reason Phrase | |
2138 | |
2139 The Status-Code element is a 3-digit integer result code of the | |
2140 attempt to understand and satisfy the request. These codes are fully | |
2141 defined in section 10. The Reason-Phrase is intended to give a short | |
2142 textual description of the Status-Code. The Status-Code is intended | |
2143 for use by automata and the Reason-Phrase is intended for the human | |
2144 user. The client is not required to examine or display the Reason- | |
2145 Phrase. | |
2146 | |
2147 The first digit of the Status-Code defines the class of response. The | |
2148 last two digits do not have any categorization role. There are 5 | |
2149 values for the first digit: | |
2150 | |
2151 o 1xx: Informational - Request received, continuing process | |
2152 | |
2153 o 2xx: Success - The action was successfully received, understood, | |
2154 and accepted | |
2155 | |
2156 o 3xx: Redirection - Further action must be taken in order to | |
2157 complete the request | |
2158 | |
2159 o 4xx: Client Error - The request contains bad syntax or cannot be | |
2160 fulfilled | |
2161 | |
2162 o 5xx: Server Error - The server failed to fulfill an apparently | |
2163 valid request | |
2164 | |
2165 The individual values of the numeric status codes defined for | |
2166 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | |
2167 presented below. The reason phrases listed here are only recommended | |
2168 -- they may be replaced by local equivalents without affecting the | |
2169 protocol. | |
2170 | |
2171 Status-Code = "100" ; Continue | |
2172 | "101" ; Switching Protocols | |
2173 | "200" ; OK | |
2174 | "201" ; Created | |
2175 | "202" ; Accepted | |
2176 | "203" ; Non-Authoritative Information | |
2177 | "204" ; No Content | |
2178 | "205" ; Reset Content | |
2179 | "206" ; Partial Content | |
2180 | "300" ; Multiple Choices | |
2181 | "301" ; Moved Permanently | |
2182 | "302" ; Moved Temporarily | |
2183 | |
2184 | |
2185 | |
2186 Fielding, et. al. Standards Track [Page 39] | |
2187 | |
2188 RFC 2068 HTTP/1.1 January 1997 | |
2189 | |
2190 | |
2191 | "303" ; See Other | |
2192 | "304" ; Not Modified | |
2193 | "305" ; Use Proxy | |
2194 | "400" ; Bad Request | |
2195 | "401" ; Unauthorized | |
2196 | "402" ; Payment Required | |
2197 | "403" ; Forbidden | |
2198 | "404" ; Not Found | |
2199 | "405" ; Method Not Allowed | |
2200 | "406" ; Not Acceptable | |
2201 | "407" ; Proxy Authentication Required | |
2202 | "408" ; Request Time-out | |
2203 | "409" ; Conflict | |
2204 | "410" ; Gone | |
2205 | "411" ; Length Required | |
2206 | "412" ; Precondition Failed | |
2207 | "413" ; Request Entity Too Large | |
2208 | "414" ; Request-URI Too Large | |
2209 | "415" ; Unsupported Media Type | |
2210 | "500" ; Internal Server Error | |
2211 | "501" ; Not Implemented | |
2212 | "502" ; Bad Gateway | |
2213 | "503" ; Service Unavailable | |
2214 | "504" ; Gateway Time-out | |
2215 | "505" ; HTTP Version not supported | |
2216 | extension-code | |
2217 | |
2218 extension-code = 3DIGIT | |
2219 | |
2220 Reason-Phrase = *<TEXT, excluding CR, LF> | |
2221 | |
2222 HTTP status codes are extensible. HTTP applications are not required | |
2223 to understand the meaning of all registered status codes, though such | |
2224 understanding is obviously desirable. However, applications MUST | |
2225 understand the class of any status code, as indicated by the first | |
2226 digit, and treat any unrecognized response as being equivalent to the | |
2227 x00 status code of that class, with the exception that an | |
2228 unrecognized response MUST NOT be cached. For example, if an | |
2229 unrecognized status code of 431 is received by the client, it can | |
2230 safely assume that there was something wrong with its request and | |
2231 treat the response as if it had received a 400 status code. In such | |
2232 cases, user agents SHOULD present to the user the entity returned | |
2233 with the response, since that entity is likely to include human- | |
2234 readable information which will explain the unusual status. | |
2235 | |
2236 | |
2237 | |
2238 | |
2239 | |
2240 | |
2241 | |
2242 Fielding, et. al. Standards Track [Page 40] | |
2243 | |
2244 RFC 2068 HTTP/1.1 January 1997 | |
2245 | |
2246 | |
2247 6.2 Response Header Fields | |
2248 | |
2249 The response-header fields allow the server to pass additional | |
2250 information about the response which cannot be placed in the Status- | |
2251 Line. These header fields give information about the server and about | |
2252 further access to the resource identified by the Request-URI. | |
2253 | |
2254 response-header = Age ; Section 14.6 | |
2255 | Location ; Section 14.30 | |
2256 | Proxy-Authenticate ; Section 14.33 | |
2257 | Public ; Section 14.35 | |
2258 | Retry-After ; Section 14.38 | |
2259 | Server ; Section 14.39 | |
2260 | Vary ; Section 14.43 | |
2261 | Warning ; Section 14.45 | |
2262 | WWW-Authenticate ; Section 14.46 | |
2263 | |
2264 Response-header field names can be extended reliably only in | |
2265 combination with a change in the protocol version. However, new or | |
2266 experimental header fields MAY be given the semantics of response- | |
2267 header fields if all parties in the communication recognize them to | |
2268 be response-header fields. Unrecognized header fields are treated as | |
2269 entity-header fields. | |
2270 | |
2271 7 Entity | |
2272 | |
2273 Request and Response messages MAY transfer an entity if not otherwise | |
2274 restricted by the request method or response status code. An entity | |
2275 consists of entity-header fields and an entity-body, although some | |
2276 responses will only include the entity-headers. | |
2277 | |
2278 In this section, both sender and recipient refer to either the client | |
2279 or the server, depending on who sends and who receives the entity. | |
2280 | |
2281 7.1 Entity Header Fields | |
2282 | |
2283 Entity-header fields define optional metainformation about the | |
2284 entity-body or, if no body is present, about the resource identified | |
2285 by the request. | |
2286 | |
2287 | |
2288 | |
2289 | |
2290 | |
2291 | |
2292 | |
2293 | |
2294 | |
2295 | |
2296 | |
2297 | |
2298 Fielding, et. al. Standards Track [Page 41] | |
2299 | |
2300 RFC 2068 HTTP/1.1 January 1997 | |
2301 | |
2302 | |
2303 entity-header = Allow ; Section 14.7 | |
2304 | Content-Base ; Section 14.11 | |
2305 | Content-Encoding ; Section 14.12 | |
2306 | Content-Language ; Section 14.13 | |
2307 | Content-Length ; Section 14.14 | |
2308 | Content-Location ; Section 14.15 | |
2309 | Content-MD5 ; Section 14.16 | |
2310 | Content-Range ; Section 14.17 | |
2311 | Content-Type ; Section 14.18 | |
2312 | ETag ; Section 14.20 | |
2313 | Expires ; Section 14.21 | |
2314 | Last-Modified ; Section 14.29 | |
2315 | extension-header | |
2316 | |
2317 extension-header = message-header | |
2318 | |
2319 The extension-header mechanism allows additional entity-header fields | |
2320 to be defined without changing the protocol, but these fields cannot | |
2321 be assumed to be recognizable by the recipient. Unrecognized header | |
2322 fields SHOULD be ignored by the recipient and forwarded by proxies. | |
2323 | |
2324 7.2 Entity Body | |
2325 | |
2326 The entity-body (if any) sent with an HTTP request or response is in | |
2327 a format and encoding defined by the entity-header fields. | |
2328 | |
2329 entity-body = *OCTET | |
2330 | |
2331 An entity-body is only present in a message when a message-body is | |
2332 present, as described in section 4.3. The entity-body is obtained | |
2333 from the message-body by decoding any Transfer-Encoding that may have | |
2334 been applied to ensure safe and proper transfer of the message. | |
2335 | |
2336 7.2.1 Type | |
2337 | |
2338 When an entity-body is included with a message, the data type of that | |
2339 body is determined via the header fields Content-Type and Content- | |
2340 Encoding. These define a two-layer, ordered encoding model: | |
2341 | |
2342 entity-body := Content-Encoding( Content-Type( data ) ) | |
2343 | |
2344 Content-Type specifies the media type of the underlying data. | |
2345 Content-Encoding may be used to indicate any additional content | |
2346 codings applied to the data, usually for the purpose of data | |
2347 compression, that are a property of the requested resource. There is | |
2348 no default encoding. | |
2349 | |
2350 | |
2351 | |
2352 | |
2353 | |
2354 Fielding, et. al. Standards Track [Page 42] | |
2355 | |
2356 RFC 2068 HTTP/1.1 January 1997 | |
2357 | |
2358 | |
2359 Any HTTP/1.1 message containing an entity-body SHOULD include a | |
2360 Content-Type header field defining the media type of that body. If | |
2361 and only if the media type is not given by a Content-Type field, the | |
2362 recipient MAY attempt to guess the media type via inspection of its | |
2363 content and/or the name extension(s) of the URL used to identify the | |
2364 resource. If the media type remains unknown, the recipient SHOULD | |
2365 treat it as type "application/octet-stream". | |
2366 | |
2367 7.2.2 Length | |
2368 | |
2369 The length of an entity-body is the length of the message-body after | |
2370 any transfer codings have been removed. Section 4.4 defines how the | |
2371 length of a message-body is determined. | |
2372 | |
2373 8 Connections | |
2374 | |
2375 8.1 Persistent Connections | |
2376 | |
2377 8.1.1 Purpose | |
2378 | |
2379 Prior to persistent connections, a separate TCP connection was | |
2380 established to fetch each URL, increasing the load on HTTP servers | |
2381 and causing congestion on the Internet. The use of inline images and | |
2382 other associated data often requires a client to make multiple | |
2383 requests of the same server in a short amount of time. Analyses of | |
2384 these performance problems are available [30][27]; analysis and | |
2385 results from a prototype implementation are in [26]. | |
2386 | |
2387 Persistent HTTP connections have a number of advantages: | |
2388 | |
2389 o By opening and closing fewer TCP connections, CPU time is saved, | |
2390 and memory used for TCP protocol control blocks is also saved. | |
2391 o HTTP requests and responses can be pipelined on a connection. | |
2392 Pipelining allows a client to make multiple requests without | |
2393 waiting for each response, allowing a single TCP connection to be | |
2394 used much more efficiently, with much lower elapsed time. | |
2395 o Network congestion is reduced by reducing the number of packets | |
2396 caused by TCP opens, and by allowing TCP sufficient time to | |
2397 determine the congestion state of the network. | |
2398 o HTTP can evolve more gracefully; since errors can be reported | |
2399 without the penalty of closing the TCP connection. Clients using | |
2400 future versions of HTTP might optimistically try a new feature, but | |
2401 if communicating with an older server, retry with old semantics | |
2402 after an error is reported. | |
2403 | |
2404 HTTP implementations SHOULD implement persistent connections. | |
2405 | |
2406 | |
2407 | |
2408 | |
2409 | |
2410 Fielding, et. al. Standards Track [Page 43] | |
2411 | |
2412 RFC 2068 HTTP/1.1 January 1997 | |
2413 | |
2414 | |
2415 8.1.2 Overall Operation | |
2416 | |
2417 A significant difference between HTTP/1.1 and earlier versions of | |
2418 HTTP is that persistent connections are the default behavior of any | |
2419 HTTP connection. That is, unless otherwise indicated, the client may | |
2420 assume that the server will maintain a persistent connection. | |
2421 | |
2422 Persistent connections provide a mechanism by which a client and a | |
2423 server can signal the close of a TCP connection. This signaling takes | |
2424 place using the Connection header field. Once a close has been | |
2425 signaled, the client MUST not send any more requests on that | |
2426 connection. | |
2427 | |
2428 8.1.2.1 Negotiation | |
2429 | |
2430 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | |
2431 maintain a persistent connection unless a Connection header including | |
2432 the connection-token "close" was sent in the request. If the server | |
2433 chooses to close the connection immediately after sending the | |
2434 response, it SHOULD send a Connection header including the | |
2435 connection-token close. | |
2436 | |
2437 An HTTP/1.1 client MAY expect a connection to remain open, but would | |
2438 decide to keep it open based on whether the response from a server | |
2439 contains a Connection header with the connection-token close. In case | |
2440 the client does not want to maintain a connection for more than that | |
2441 request, it SHOULD send a Connection header including the | |
2442 connection-token close. | |
2443 | |
2444 If either the client or the server sends the close token in the | |
2445 Connection header, that request becomes the last one for the | |
2446 connection. | |
2447 | |
2448 Clients and servers SHOULD NOT assume that a persistent connection is | |
2449 maintained for HTTP versions less than 1.1 unless it is explicitly | |
2450 signaled. See section 19.7.1 for more information on backwards | |
2451 compatibility with HTTP/1.0 clients. | |
2452 | |
2453 In order to remain persistent, all messages on the connection must | |
2454 have a self-defined message length (i.e., one not defined by closure | |
2455 of the connection), as described in section 4.4. | |
2456 | |
2457 8.1.2.2 Pipelining | |
2458 | |
2459 A client that supports persistent connections MAY "pipeline" its | |
2460 requests (i.e., send multiple requests without waiting for each | |
2461 response). A server MUST send its responses to those requests in the | |
2462 same order that the requests were received. | |
2463 | |
2464 | |
2465 | |
2466 Fielding, et. al. Standards Track [Page 44] | |
2467 | |
2468 RFC 2068 HTTP/1.1 January 1997 | |
2469 | |
2470 | |
2471 Clients which assume persistent connections and pipeline immediately | |
2472 after connection establishment SHOULD be prepared to retry their | |
2473 connection if the first pipelined attempt fails. If a client does | |
2474 such a retry, it MUST NOT pipeline before it knows the connection is | |
2475 persistent. Clients MUST also be prepared to resend their requests if | |
2476 the server closes the connection before sending all of the | |
2477 corresponding responses. | |
2478 | |
2479 8.1.3 Proxy Servers | |
2480 | |
2481 It is especially important that proxies correctly implement the | |
2482 properties of the Connection header field as specified in 14.2.1. | |
2483 | |
2484 The proxy server MUST signal persistent connections separately with | |
2485 its clients and the origin servers (or other proxy servers) that it | |
2486 connects to. Each persistent connection applies to only one transport | |
2487 link. | |
2488 | |
2489 A proxy server MUST NOT establish a persistent connection with an | |
2490 HTTP/1.0 client. | |
2491 | |
2492 8.1.4 Practical Considerations | |
2493 | |
2494 Servers will usually have some time-out value beyond which they will | |
2495 no longer maintain an inactive connection. Proxy servers might make | |
2496 this a higher value since it is likely that the client will be making | |
2497 more connections through the same server. The use of persistent | |
2498 connections places no requirements on the length of this time-out for | |
2499 either the client or the server. | |
2500 | |
2501 When a client or server wishes to time-out it SHOULD issue a graceful | |
2502 close on the transport connection. Clients and servers SHOULD both | |
2503 constantly watch for the other side of the transport close, and | |
2504 respond to it as appropriate. If a client or server does not detect | |
2505 the other side's close promptly it could cause unnecessary resource | |
2506 drain on the network. | |
2507 | |
2508 A client, server, or proxy MAY close the transport connection at any | |
2509 time. For example, a client MAY have started to send a new request at | |
2510 the same time that the server has decided to close the "idle" | |
2511 connection. From the server's point of view, the connection is being | |
2512 closed while it was idle, but from the client's point of view, a | |
2513 request is in progress. | |
2514 | |
2515 This means that clients, servers, and proxies MUST be able to recover | |
2516 from asynchronous close events. Client software SHOULD reopen the | |
2517 transport connection and retransmit the aborted request without user | |
2518 interaction so long as the request method is idempotent (see section | |
2519 | |
2520 | |
2521 | |
2522 Fielding, et. al. Standards Track [Page 45] | |
2523 | |
2524 RFC 2068 HTTP/1.1 January 1997 | |
2525 | |
2526 | |
2527 9.1.2); other methods MUST NOT be automatically retried, although | |
2528 user agents MAY offer a human operator the choice of retrying the | |
2529 request. | |
2530 | |
2531 However, this automatic retry SHOULD NOT be repeated if the second | |
2532 request fails. | |
2533 | |
2534 Servers SHOULD always respond to at least one request per connection, | |
2535 if at all possible. Servers SHOULD NOT close a connection in the | |
2536 middle of transmitting a response, unless a network or client failure | |
2537 is suspected. | |
2538 | |
2539 Clients that use persistent connections SHOULD limit the number of | |
2540 simultaneous connections that they maintain to a given server. A | |
2541 single-user client SHOULD maintain AT MOST 2 connections with any | |
2542 server or proxy. A proxy SHOULD use up to 2*N connections to another | |
2543 server or proxy, where N is the number of simultaneously active | |
2544 users. These guidelines are intended to improve HTTP response times | |
2545 and avoid congestion of the Internet or other networks. | |
2546 | |
2547 8.2 Message Transmission Requirements | |
2548 | |
2549 General requirements: | |
2550 | |
2551 o HTTP/1.1 servers SHOULD maintain persistent connections and use | |
2552 TCP's flow control mechanisms to resolve temporary overloads, | |
2553 rather than terminating connections with the expectation that | |
2554 clients will retry. The latter technique can exacerbate network | |
2555 congestion. | |
2556 | |
2557 o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor | |
2558 the network connection for an error status while it is transmitting | |
2559 the request. If the client sees an error status, it SHOULD | |
2560 immediately cease transmitting the body. If the body is being sent | |
2561 using a "chunked" encoding (section 3.6), a zero length chunk and | |
2562 empty footer MAY be used to prematurely mark the end of the | |
2563 message. If the body was preceded by a Content-Length header, the | |
2564 client MUST close the connection. | |
2565 | |
2566 o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 | |
2567 (Continue) status followed by a regular response. | |
2568 | |
2569 o An HTTP/1.1 (or later) server that receives a request from a | |
2570 HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue) | |
2571 response; it SHOULD either wait for the request to be completed | |
2572 normally (thus avoiding an interrupted request) or close the | |
2573 connection prematurely. | |
2574 | |
2575 | |
2576 | |
2577 | |
2578 Fielding, et. al. Standards Track [Page 46] | |
2579 | |
2580 RFC 2068 HTTP/1.1 January 1997 | |
2581 | |
2582 | |
2583 Upon receiving a method subject to these requirements from an | |
2584 HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either | |
2585 respond with 100 (Continue) status and continue to read from the | |
2586 input stream, or respond with an error status. If it responds with an | |
2587 error status, it MAY close the transport (TCP) connection or it MAY | |
2588 continue to read and discard the rest of the request. It MUST NOT | |
2589 perform the requested method if it returns an error status. | |
2590 | |
2591 Clients SHOULD remember the version number of at least the most | |
2592 recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or | |
2593 later response from the server, and it sees the connection close | |
2594 before receiving any status from the server, the client SHOULD retry | |
2595 the request without user interaction so long as the request method is | |
2596 idempotent (see section 9.1.2); other methods MUST NOT be | |
2597 automatically retried, although user agents MAY offer a human | |
2598 operator the choice of retrying the request.. If the client does | |
2599 retry the request, the client | |
2600 | |
2601 o MUST first send the request header fields, and then | |
2602 | |
2603 o MUST wait for the server to respond with either a 100 (Continue) | |
2604 response, in which case the client should continue, or with an | |
2605 error status. | |
2606 | |
2607 If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from | |
2608 the server, it should assume that the server implements HTTP/1.0 or | |
2609 older and will not use the 100 (Continue) response. If in this case | |
2610 the client sees the connection close before receiving any status from | |
2611 the server, the client SHOULD retry the request. If the client does | |
2612 retry the request to this HTTP/1.0 server, it should use the | |
2613 following "binary exponential backoff" algorithm to be assured of | |
2614 obtaining a reliable response: | |
2615 | |
2616 1. Initiate a new connection to the server | |
2617 | |
2618 2. Transmit the request-headers | |
2619 | |
2620 3. Initialize a variable R to the estimated round-trip time to the | |
2621 server (e.g., based on the time it took to establish the | |
2622 connection), or to a constant value of 5 seconds if the round-trip | |
2623 time is not available. | |
2624 | |
2625 4. Compute T = R * (2**N), where N is the number of previous retries | |
2626 of this request. | |
2627 | |
2628 5. Wait either for an error response from the server, or for T seconds | |
2629 (whichever comes first) | |
2630 | |
2631 | |
2632 | |
2633 | |
2634 Fielding, et. al. Standards Track [Page 47] | |
2635 | |
2636 RFC 2068 HTTP/1.1 January 1997 | |
2637 | |
2638 | |
2639 6. If no error response is received, after T seconds transmit the body | |
2640 of the request. | |
2641 | |
2642 7. If client sees that the connection is closed prematurely, repeat | |
2643 from step 1 until the request is accepted, an error response is | |
2644 received, or the user becomes impatient and terminates the retry | |
2645 process. | |
2646 | |
2647 No matter what the server version, if an error status is received, | |
2648 the client | |
2649 | |
2650 o MUST NOT continue and | |
2651 | |
2652 o MUST close the connection if it has not completed sending the | |
2653 message. | |
2654 | |
2655 An HTTP/1.1 (or later) client that sees the connection close after | |
2656 receiving a 100 (Continue) but before receiving any other status | |
2657 SHOULD retry the request, and need not wait for 100 (Continue) | |
2658 response (but MAY do so if this simplifies the implementation). | |
2659 | |
2660 9 Method Definitions | |
2661 | |
2662 The set of common methods for HTTP/1.1 is defined below. Although | |
2663 this set can be expanded, additional methods cannot be assumed to | |
2664 share the same semantics for separately extended clients and servers. | |
2665 | |
2666 The Host request-header field (section 14.23) MUST accompany all | |
2667 HTTP/1.1 requests. | |
2668 | |
2669 9.1 Safe and Idempotent Methods | |
2670 | |
2671 9.1.1 Safe Methods | |
2672 | |
2673 Implementers should be aware that the software represents the user in | |
2674 their interactions over the Internet, and should be careful to allow | |
2675 the user to be aware of any actions they may take which may have an | |
2676 unexpected significance to themselves or others. | |
2677 | |
2678 In particular, the convention has been established that the GET and | |
2679 HEAD methods should never have the significance of taking an action | |
2680 other than retrieval. These methods should be considered "safe." This | |
2681 allows user agents to represent other methods, such as POST, PUT and | |
2682 DELETE, in a special way, so that the user is made aware of the fact | |
2683 that a possibly unsafe action is being requested. | |
2684 | |
2685 Naturally, it is not possible to ensure that the server does not | |
2686 generate side-effects as a result of performing a GET request; in | |
2687 | |
2688 | |
2689 | |
2690 Fielding, et. al. Standards Track [Page 48] | |
2691 | |
2692 RFC 2068 HTTP/1.1 January 1997 | |
2693 | |
2694 | |
2695 fact, some dynamic resources consider that a feature. The important | |
2696 distinction here is that the user did not request the side-effects, | |
2697 so therefore cannot be held accountable for them. | |
2698 | |
2699 9.1.2 Idempotent Methods | |
2700 | |
2701 Methods may also have the property of "idempotence" in that (aside | |
2702 from error or expiration issues) the side-effects of N > 0 identical | |
2703 requests is the same as for a single request. The methods GET, HEAD, | |
2704 PUT and DELETE share this property. | |
2705 | |
2706 9.2 OPTIONS | |
2707 | |
2708 The OPTIONS method represents a request for information about the | |
2709 communication options available on the request/response chain | |
2710 identified by the Request-URI. This method allows the client to | |
2711 determine the options and/or requirements associated with a resource, | |
2712 or the capabilities of a server, without implying a resource action | |
2713 or initiating a resource retrieval. | |
2714 | |
2715 Unless the server's response is an error, the response MUST NOT | |
2716 include entity information other than what can be considered as | |
2717 communication options (e.g., Allow is appropriate, but Content-Type | |
2718 is not). Responses to this method are not cachable. | |
2719 | |
2720 If the Request-URI is an asterisk ("*"), the OPTIONS request is | |
2721 intended to apply to the server as a whole. A 200 response SHOULD | |
2722 include any header fields which indicate optional features | |
2723 implemented by the server (e.g., Public), including any extensions | |
2724 not defined by this specification, in addition to any applicable | |
2725 general or response-header fields. As described in section 5.1.2, an | |
2726 "OPTIONS *" request can be applied through a proxy by specifying the | |
2727 destination server in the Request-URI without any path information. | |
2728 | |
2729 If the Request-URI is not an asterisk, the OPTIONS request applies | |
2730 only to the options that are available when communicating with that | |
2731 resource. A 200 response SHOULD include any header fields which | |
2732 indicate optional features implemented by the server and applicable | |
2733 to that resource (e.g., Allow), including any extensions not defined | |
2734 by this specification, in addition to any applicable general or | |
2735 response-header fields. If the OPTIONS request passes through a | |
2736 proxy, the proxy MUST edit the response to exclude those options | |
2737 which apply to a proxy's capabilities and which are known to be | |
2738 unavailable through that proxy. | |
2739 | |
2740 | |
2741 | |
2742 | |
2743 | |
2744 | |
2745 | |
2746 Fielding, et. al. Standards Track [Page 49] | |
2747 | |
2748 RFC 2068 HTTP/1.1 January 1997 | |
2749 | |
2750 | |
2751 9.3 GET | |
2752 | |
2753 The GET method means retrieve whatever information (in the form of an | |
2754 entity) is identified by the Request-URI. If the Request-URI refers | |
2755 to a data-producing process, it is the produced data which shall be | |
2756 returned as the entity in the response and not the source text of the | |
2757 process, unless that text happens to be the output of the process. | |
2758 | |
2759 The semantics of the GET method change to a "conditional GET" if the | |
2760 request message includes an If-Modified-Since, If-Unmodified-Since, | |
2761 If-Match, If-None-Match, or If-Range header field. A conditional GET | |
2762 method requests that the entity be transferred only under the | |
2763 circumstances described by the conditional header field(s). The | |
2764 conditional GET method is intended to reduce unnecessary network | |
2765 usage by allowing cached entities to be refreshed without requiring | |
2766 multiple requests or transferring data already held by the client. | |
2767 | |
2768 The semantics of the GET method change to a "partial GET" if the | |
2769 request message includes a Range header field. A partial GET requests | |
2770 that only part of the entity be transferred, as described in section | |
2771 14.36. The partial GET method is intended to reduce unnecessary | |
2772 network usage by allowing partially-retrieved entities to be | |
2773 completed without transferring data already held by the client. | |
2774 | |
2775 The response to a GET request is cachable if and only if it meets the | |
2776 requirements for HTTP caching described in section 13. | |
2777 | |
2778 9.4 HEAD | |
2779 | |
2780 The HEAD method is identical to GET except that the server MUST NOT | |
2781 return a message-body in the response. The metainformation contained | |
2782 in the HTTP headers in response to a HEAD request SHOULD be identical | |
2783 to the information sent in response to a GET request. This method can | |
2784 be used for obtaining metainformation about the entity implied by the | |
2785 request without transferring the entity-body itself. This method is | |
2786 often used for testing hypertext links for validity, accessibility, | |
2787 and recent modification. | |
2788 | |
2789 The response to a HEAD request may be cachable in the sense that the | |
2790 information contained in the response may be used to update a | |
2791 previously cached entity from that resource. If the new field values | |
2792 indicate that the cached entity differs from the current entity (as | |
2793 would be indicated by a change in Content-Length, Content-MD5, ETag | |
2794 or Last-Modified), then the cache MUST treat the cache entry as | |
2795 stale. | |
2796 | |
2797 | |
2798 | |
2799 | |
2800 | |
2801 | |
2802 Fielding, et. al. Standards Track [Page 50] | |
2803 | |
2804 RFC 2068 HTTP/1.1 January 1997 | |
2805 | |
2806 | |
2807 9.5 POST | |
2808 | |
2809 The POST method is used to request that the destination server accept | |
2810 the entity enclosed in the request as a new subordinate of the | |
2811 resource identified by the Request-URI in the Request-Line. POST is | |
2812 designed to allow a uniform method to cover the following functions: | |
2813 | |
2814 o Annotation of existing resources; | |
2815 | |
2816 o Posting a message to a bulletin board, newsgroup, mailing list, | |
2817 or similar group of articles; | |
2818 | |
2819 o Providing a block of data, such as the result of submitting a | |
2820 form, to a data-handling process; | |
2821 | |
2822 o Extending a database through an append operation. | |
2823 | |
2824 The actual function performed by the POST method is determined by the | |
2825 server and is usually dependent on the Request-URI. The posted entity | |
2826 is subordinate to that URI in the same way that a file is subordinate | |
2827 to a directory containing it, a news article is subordinate to a | |
2828 newsgroup to which it is posted, or a record is subordinate to a | |
2829 database. | |
2830 | |
2831 The action performed by the POST method might not result in a | |
2832 resource that can be identified by a URI. In this case, either 200 | |
2833 (OK) or 204 (No Content) is the appropriate response status, | |
2834 depending on whether or not the response includes an entity that | |
2835 describes the result. | |
2836 | |
2837 If a resource has been created on the origin server, the response | |
2838 SHOULD be 201 (Created) and contain an entity which describes the | |
2839 status of the request and refers to the new resource, and a Location | |
2840 header (see section 14.30). | |
2841 | |
2842 Responses to this method are not cachable, unless the response | |
2843 includes appropriate Cache-Control or Expires header fields. However, | |
2844 the 303 (See Other) response can be used to direct the user agent to | |
2845 retrieve a cachable resource. | |
2846 | |
2847 POST requests must obey the message transmission requirements set out | |
2848 in section 8.2. | |
2849 | |
2850 | |
2851 | |
2852 | |
2853 | |
2854 | |
2855 | |
2856 | |
2857 | |
2858 Fielding, et. al. Standards Track [Page 51] | |
2859 | |
2860 RFC 2068 HTTP/1.1 January 1997 | |
2861 | |
2862 | |
2863 9.6 PUT | |
2864 | |
2865 The PUT method requests that the enclosed entity be stored under the | |
2866 supplied Request-URI. If the Request-URI refers to an already | |
2867 existing resource, the enclosed entity SHOULD be considered as a | |
2868 modified version of the one residing on the origin server. If the | |
2869 Request-URI does not point to an existing resource, and that URI is | |
2870 capable of being defined as a new resource by the requesting user | |
2871 agent, the origin server can create the resource with that URI. If a | |
2872 new resource is created, the origin server MUST inform the user agent | |
2873 via the 201 (Created) response. If an existing resource is modified, | |
2874 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent | |
2875 to indicate successful completion of the request. If the resource | |
2876 could not be created or modified with the Request-URI, an appropriate | |
2877 error response SHOULD be given that reflects the nature of the | |
2878 problem. The recipient of the entity MUST NOT ignore any Content-* | |
2879 (e.g. Content-Range) headers that it does not understand or implement | |
2880 and MUST return a 501 (Not Implemented) response in such cases. | |
2881 | |
2882 If the request passes through a cache and the Request-URI identifies | |
2883 one or more currently cached entities, those entries should be | |
2884 treated as stale. Responses to this method are not cachable. | |
2885 | |
2886 The fundamental difference between the POST and PUT requests is | |
2887 reflected in the different meaning of the Request-URI. The URI in a | |
2888 POST request identifies the resource that will handle the enclosed | |
2889 entity. That resource may be a data-accepting process, a gateway to | |
2890 some other protocol, or a separate entity that accepts annotations. | |
2891 In contrast, the URI in a PUT request identifies the entity enclosed | |
2892 with the request -- the user agent knows what URI is intended and the | |
2893 server MUST NOT attempt to apply the request to some other resource. | |
2894 If the server desires that the request be applied to a different URI, | |
2895 it MUST send a 301 (Moved Permanently) response; the user agent MAY | |
2896 then make its own decision regarding whether or not to redirect the | |
2897 request. | |
2898 | |
2899 A single resource MAY be identified by many different URIs. For | |
2900 example, an article may have a URI for identifying "the current | |
2901 version" which is separate from the URI identifying each particular | |
2902 version. In this case, a PUT request on a general URI may result in | |
2903 several other URIs being defined by the origin server. | |
2904 | |
2905 HTTP/1.1 does not define how a PUT method affects the state of an | |
2906 origin server. | |
2907 | |
2908 PUT requests must obey the message transmission requirements set out | |
2909 in section 8.2. | |
2910 | |
2911 | |
2912 | |
2913 | |
2914 Fielding, et. al. Standards Track [Page 52] | |
2915 | |
2916 RFC 2068 HTTP/1.1 January 1997 | |
2917 | |
2918 | |
2919 9.7 DELETE | |
2920 | |
2921 The DELETE method requests that the origin server delete the resource | |
2922 identified by the Request-URI. This method MAY be overridden by human | |
2923 intervention (or other means) on the origin server. The client cannot | |
2924 be guaranteed that the operation has been carried out, even if the | |
2925 status code returned from the origin server indicates that the action | |
2926 has been completed successfully. However, the server SHOULD not | |
2927 indicate success unless, at the time the response is given, it | |
2928 intends to delete the resource or move it to an inaccessible | |
2929 location. | |
2930 | |
2931 A successful response SHOULD be 200 (OK) if the response includes an | |
2932 entity describing the status, 202 (Accepted) if the action has not | |
2933 yet been enacted, or 204 (No Content) if the response is OK but does | |
2934 not include an entity. | |
2935 | |
2936 If the request passes through a cache and the Request-URI identifies | |
2937 one or more currently cached entities, those entries should be | |
2938 treated as stale. Responses to this method are not cachable. | |
2939 | |
2940 9.8 TRACE | |
2941 | |
2942 The TRACE method is used to invoke a remote, application-layer loop- | |
2943 back of the request message. The final recipient of the request | |
2944 SHOULD reflect the message received back to the client as the | |
2945 entity-body of a 200 (OK) response. The final recipient is either the | |
2946 origin server or the first proxy or gateway to receive a Max-Forwards | |
2947 value of zero (0) in the request (see section 14.31). A TRACE request | |
2948 MUST NOT include an entity. | |
2949 | |
2950 TRACE allows the client to see what is being received at the other | |
2951 end of the request chain and use that data for testing or diagnostic | |
2952 information. The value of the Via header field (section 14.44) is of | |
2953 particular interest, since it acts as a trace of the request chain. | |
2954 Use of the Max-Forwards header field allows the client to limit the | |
2955 length of the request chain, which is useful for testing a chain of | |
2956 proxies forwarding messages in an infinite loop. | |
2957 | |
2958 If successful, the response SHOULD contain the entire request message | |
2959 in the entity-body, with a Content-Type of "message/http". Responses | |
2960 to this method MUST NOT be cached. | |
2961 | |
2962 10 Status Code Definitions | |
2963 | |
2964 Each Status-Code is described below, including a description of which | |
2965 method(s) it can follow and any metainformation required in the | |
2966 response. | |
2967 | |
2968 | |
2969 | |
2970 Fielding, et. al. Standards Track [Page 53] | |
2971 | |
2972 RFC 2068 HTTP/1.1 January 1997 | |
2973 | |
2974 | |
2975 10.1 Informational 1xx | |
2976 | |
2977 This class of status code indicates a provisional response, | |
2978 consisting only of the Status-Line and optional headers, and is | |
2979 terminated by an empty line. Since HTTP/1.0 did not define any 1xx | |
2980 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 | |
2981 client except under experimental conditions. | |
2982 | |
2983 10.1.1 100 Continue | |
2984 | |
2985 The client may continue with its request. This interim response is | |
2986 used to inform the client that the initial part of the request has | |
2987 been received and has not yet been rejected by the server. The client | |
2988 SHOULD continue by sending the remainder of the request or, if the | |
2989 request has already been completed, ignore this response. The server | |
2990 MUST send a final response after the request has been completed. | |
2991 | |
2992 10.1.2 101 Switching Protocols | |
2993 | |
2994 The server understands and is willing to comply with the client's | |
2995 request, via the Upgrade message header field (section 14.41), for a | |
2996 change in the application protocol being used on this connection. The | |
2997 server will switch protocols to those defined by the response's | |
2998 Upgrade header field immediately after the empty line which | |
2999 terminates the 101 response. | |
3000 | |
3001 The protocol should only be switched when it is advantageous to do | |
3002 so. For example, switching to a newer version of HTTP is | |
3003 advantageous over older versions, and switching to a real-time, | |
3004 synchronous protocol may be advantageous when delivering resources | |
3005 that use such features. | |
3006 | |
3007 10.2 Successful 2xx | |
3008 | |
3009 This class of status code indicates that the client's request was | |
3010 successfully received, understood, and accepted. | |
3011 | |
3012 10.2.1 200 OK | |
3013 | |
3014 The request has succeeded. The information returned with the response | |
3015 is dependent on the method used in the request, for example: | |
3016 | |
3017 GET an entity corresponding to the requested resource is sent in the | |
3018 response; | |
3019 | |
3020 HEAD the entity-header fields corresponding to the requested resource | |
3021 are sent in the response without any message-body; | |
3022 | |
3023 | |
3024 | |
3025 | |
3026 Fielding, et. al. Standards Track [Page 54] | |
3027 | |
3028 RFC 2068 HTTP/1.1 January 1997 | |
3029 | |
3030 | |
3031 POST an entity describing or containing the result of the action; | |
3032 | |
3033 TRACE an entity containing the request message as received by the end | |
3034 server. | |
3035 | |
3036 10.2.2 201 Created | |
3037 | |
3038 The request has been fulfilled and resulted in a new resource being | |
3039 created. The newly created resource can be referenced by the URI(s) | |
3040 returned in the entity of the response, with the most specific URL | |
3041 for the resource given by a Location header field. The origin server | |
3042 MUST create the resource before returning the 201 status code. If the | |
3043 action cannot be carried out immediately, the server should respond | |
3044 with 202 (Accepted) response instead. | |
3045 | |
3046 10.2.3 202 Accepted | |
3047 | |
3048 The request has been accepted for processing, but the processing has | |
3049 not been completed. The request MAY or MAY NOT eventually be acted | |
3050 upon, as it MAY be disallowed when processing actually takes place. | |
3051 There is no facility for re-sending a status code from an | |
3052 asynchronous operation such as this. | |
3053 | |
3054 The 202 response is intentionally non-committal. Its purpose is to | |
3055 allow a server to accept a request for some other process (perhaps a | |
3056 batch-oriented process that is only run once per day) without | |
3057 requiring that the user agent's connection to the server persist | |
3058 until the process is completed. The entity returned with this | |
3059 response SHOULD include an indication of the request's current status | |
3060 and either a pointer to a status monitor or some estimate of when the | |
3061 user can expect the request to be fulfilled. | |
3062 | |
3063 10.2.4 203 Non-Authoritative Information | |
3064 | |
3065 The returned metainformation in the entity-header is not the | |
3066 definitive set as available from the origin server, but is gathered | |
3067 from a local or a third-party copy. The set presented MAY be a subset | |
3068 or superset of the original version. For example, including local | |
3069 annotation information about the resource MAY result in a superset of | |
3070 the metainformation known by the origin server. Use of this response | |
3071 code is not required and is only appropriate when the response would | |
3072 otherwise be 200 (OK). | |
3073 | |
3074 10.2.5 204 No Content | |
3075 | |
3076 The server has fulfilled the request but there is no new information | |
3077 to send back. If the client is a user agent, it SHOULD NOT change its | |
3078 document view from that which caused the request to be sent. This | |
3079 | |
3080 | |
3081 | |
3082 Fielding, et. al. Standards Track [Page 55] | |
3083 | |
3084 RFC 2068 HTTP/1.1 January 1997 | |
3085 | |
3086 | |
3087 response is primarily intended to allow input for actions to take | |
3088 place without causing a change to the user agent's active document | |
3089 view. The response MAY include new metainformation in the form of | |
3090 entity-headers, which SHOULD apply to the document currently in the | |
3091 user agent's active view. | |
3092 | |
3093 The 204 response MUST NOT include a message-body, and thus is always | |
3094 terminated by the first empty line after the header fields. | |
3095 | |
3096 10.2.6 205 Reset Content | |
3097 | |
3098 The server has fulfilled the request and the user agent SHOULD reset | |
3099 the document view which caused the request to be sent. This response | |
3100 is primarily intended to allow input for actions to take place via | |
3101 user input, followed by a clearing of the form in which the input is | |
3102 given so that the user can easily initiate another input action. The | |
3103 response MUST NOT include an entity. | |
3104 | |
3105 10.2.7 206 Partial Content | |
3106 | |
3107 The server has fulfilled the partial GET request for the resource. | |
3108 The request must have included a Range header field (section 14.36) | |
3109 indicating the desired range. The response MUST include either a | |
3110 Content-Range header field (section 14.17) indicating the range | |
3111 included with this response, or a multipart/byteranges Content-Type | |
3112 including Content-Range fields for each part. If multipart/byteranges | |
3113 is not used, the Content-Length header field in the response MUST | |
3114 match the actual number of OCTETs transmitted in the message-body. | |
3115 | |
3116 A cache that does not support the Range and Content-Range headers | |
3117 MUST NOT cache 206 (Partial) responses. | |
3118 | |
3119 10.3 Redirection 3xx | |
3120 | |
3121 This class of status code indicates that further action needs to be | |
3122 taken by the user agent in order to fulfill the request. The action | |
3123 required MAY be carried out by the user agent without interaction | |
3124 with the user if and only if the method used in the second request is | |
3125 GET or HEAD. A user agent SHOULD NOT automatically redirect a request | |
3126 more than 5 times, since such redirections usually indicate an | |
3127 infinite loop. | |
3128 | |
3129 | |
3130 | |
3131 | |
3132 | |
3133 | |
3134 | |
3135 | |
3136 | |
3137 | |
3138 Fielding, et. al. Standards Track [Page 56] | |
3139 | |
3140 RFC 2068 HTTP/1.1 January 1997 | |
3141 | |
3142 | |
3143 10.3.1 300 Multiple Choices | |
3144 | |
3145 The requested resource corresponds to any one of a set of | |
3146 representations, each with its own specific location, and agent- | |
3147 driven negotiation information (section 12) is being provided so that | |
3148 the user (or user agent) can select a preferred representation and | |
3149 redirect its request to that location. | |
3150 | |
3151 Unless it was a HEAD request, the response SHOULD include an entity | |
3152 containing a list of resource characteristics and location(s) from | |
3153 which the user or user agent can choose the one most appropriate. The | |
3154 entity format is specified by the media type given in the Content- | |
3155 Type header field. Depending upon the format and the capabilities of | |
3156 the user agent, selection of the most appropriate choice may be | |
3157 performed automatically. However, this specification does not define | |
3158 any standard for such automatic selection. | |
3159 | |
3160 If the server has a preferred choice of representation, it SHOULD | |
3161 include the specific URL for that representation in the Location | |
3162 field; user agents MAY use the Location field value for automatic | |
3163 redirection. This response is cachable unless indicated otherwise. | |
3164 | |
3165 10.3.2 301 Moved Permanently | |
3166 | |
3167 The requested resource has been assigned a new permanent URI and any | |
3168 future references to this resource SHOULD be done using one of the | |
3169 returned URIs. Clients with link editing capabilities SHOULD | |
3170 automatically re-link references to the Request-URI to one or more of | |
3171 the new references returned by the server, where possible. This | |
3172 response is cachable unless indicated otherwise. | |
3173 | |
3174 If the new URI is a location, its URL SHOULD be given by the Location | |
3175 field in the response. Unless the request method was HEAD, the entity | |
3176 of the response SHOULD contain a short hypertext note with a | |
3177 hyperlink to the new URI(s). | |
3178 | |
3179 If the 301 status code is received in response to a request other | |
3180 than GET or HEAD, the user agent MUST NOT automatically redirect the | |
3181 request unless it can be confirmed by the user, since this might | |
3182 change the conditions under which the request was issued. | |
3183 | |
3184 Note: When automatically redirecting a POST request after receiving | |
3185 a 301 status code, some existing HTTP/1.0 user agents will | |
3186 erroneously change it into a GET request. | |
3187 | |
3188 | |
3189 | |
3190 | |
3191 | |
3192 | |
3193 | |
3194 Fielding, et. al. Standards Track [Page 57] | |
3195 | |
3196 RFC 2068 HTTP/1.1 January 1997 | |
3197 | |
3198 | |
3199 10.3.3 302 Moved Temporarily | |
3200 | |
3201 The requested resource resides temporarily under a different URI. | |
3202 Since the redirection may be altered on occasion, the client SHOULD | |
3203 continue to use the Request-URI for future requests. This response is | |
3204 only cachable if indicated by a Cache-Control or Expires header | |
3205 field. | |
3206 | |
3207 If the new URI is a location, its URL SHOULD be given by the Location | |
3208 field in the response. Unless the request method was HEAD, the entity | |
3209 of the response SHOULD contain a short hypertext note with a | |
3210 hyperlink to the new URI(s). | |
3211 | |
3212 If the 302 status code is received in response to a request other | |
3213 than GET or HEAD, the user agent MUST NOT automatically redirect the | |
3214 request unless it can be confirmed by the user, since this might | |
3215 change the conditions under which the request was issued. | |
3216 | |
3217 Note: When automatically redirecting a POST request after receiving | |
3218 a 302 status code, some existing HTTP/1.0 user agents will | |
3219 erroneously change it into a GET request. | |
3220 | |
3221 10.3.4 303 See Other | |
3222 | |
3223 The response to the request can be found under a different URI and | |
3224 SHOULD be retrieved using a GET method on that resource. This method | |
3225 exists primarily to allow the output of a POST-activated script to | |
3226 redirect the user agent to a selected resource. The new URI is not a | |
3227 substitute reference for the originally requested resource. The 303 | |
3228 response is not cachable, but the response to the second (redirected) | |
3229 request MAY be cachable. | |
3230 | |
3231 If the new URI is a location, its URL SHOULD be given by the Location | |
3232 field in the response. Unless the request method was HEAD, the entity | |
3233 of the response SHOULD contain a short hypertext note with a | |
3234 hyperlink to the new URI(s). | |
3235 | |
3236 10.3.5 304 Not Modified | |
3237 | |
3238 If the client has performed a conditional GET request and access is | |
3239 allowed, but the document has not been modified, the server SHOULD | |
3240 respond with this status code. The response MUST NOT contain a | |
3241 message-body. | |
3242 | |
3243 | |
3244 | |
3245 | |
3246 | |
3247 | |
3248 | |
3249 | |
3250 Fielding, et. al. Standards Track [Page 58] | |
3251 | |
3252 RFC 2068 HTTP/1.1 January 1997 | |
3253 | |
3254 | |
3255 The response MUST include the following header fields: | |
3256 | |
3257 o Date | |
3258 | |
3259 o ETag and/or Content-Location, if the header would have been sent in | |
3260 a 200 response to the same request | |
3261 | |
3262 o Expires, Cache-Control, and/or Vary, if the field-value might | |
3263 differ from that sent in any previous response for the same variant | |
3264 | |
3265 If the conditional GET used a strong cache validator (see section | |
3266 13.3.3), the response SHOULD NOT include other entity-headers. | |
3267 Otherwise (i.e., the conditional GET used a weak validator), the | |
3268 response MUST NOT include other entity-headers; this prevents | |
3269 inconsistencies between cached entity-bodies and updated headers. | |
3270 | |
3271 If a 304 response indicates an entity not currently cached, then the | |
3272 cache MUST disregard the response and repeat the request without the | |
3273 conditional. | |
3274 | |
3275 If a cache uses a received 304 response to update a cache entry, the | |
3276 cache MUST update the entry to reflect any new field values given in | |
3277 the response. | |
3278 | |
3279 The 304 response MUST NOT include a message-body, and thus is always | |
3280 terminated by the first empty line after the header fields. | |
3281 | |
3282 10.3.6 305 Use Proxy | |
3283 | |
3284 The requested resource MUST be accessed through the proxy given by | |
3285 the Location field. The Location field gives the URL of the proxy. | |
3286 The recipient is expected to repeat the request via the proxy. | |
3287 | |
3288 10.4 Client Error 4xx | |
3289 | |
3290 The 4xx class of status code is intended for cases in which the | |
3291 client seems to have erred. Except when responding to a HEAD request, | |
3292 the server SHOULD include an entity containing an explanation of the | |
3293 error situation, and whether it is a temporary or permanent | |
3294 condition. These status codes are applicable to any request method. | |
3295 User agents SHOULD display any included entity to the user. | |
3296 | |
3297 Note: If the client is sending data, a server implementation using | |
3298 TCP should be careful to ensure that the client acknowledges | |
3299 receipt of the packet(s) containing the response, before the server | |
3300 closes the input connection. If the client continues sending data | |
3301 to the server after the close, the server's TCP stack will send a | |
3302 reset packet to the client, which may erase the client's | |
3303 | |
3304 | |
3305 | |
3306 Fielding, et. al. Standards Track [Page 59] | |
3307 | |
3308 RFC 2068 HTTP/1.1 January 1997 | |
3309 | |
3310 | |
3311 unacknowledged input buffers before they can be read and | |
3312 interpreted by the HTTP application. | |
3313 | |
3314 10.4.1 400 Bad Request | |
3315 | |
3316 The request could not be understood by the server due to malformed | |
3317 syntax. The client SHOULD NOT repeat the request without | |
3318 modifications. | |
3319 | |
3320 10.4.2 401 Unauthorized | |
3321 | |
3322 The request requires user authentication. The response MUST include a | |
3323 WWW-Authenticate header field (section 14.46) containing a challenge | |
3324 applicable to the requested resource. The client MAY repeat the | |
3325 request with a suitable Authorization header field (section 14.8). If | |
3326 the request already included Authorization credentials, then the 401 | |
3327 response indicates that authorization has been refused for those | |
3328 credentials. If the 401 response contains the same challenge as the | |
3329 prior response, and the user agent has already attempted | |
3330 authentication at least once, then the user SHOULD be presented the | |
3331 entity that was given in the response, since that entity MAY include | |
3332 relevant diagnostic information. HTTP access authentication is | |
3333 explained in section 11. | |
3334 | |
3335 10.4.3 402 Payment Required | |
3336 | |
3337 This code is reserved for future use. | |
3338 | |
3339 10.4.4 403 Forbidden | |
3340 | |
3341 The server understood the request, but is refusing to fulfill it. | |
3342 Authorization will not help and the request SHOULD NOT be repeated. | |
3343 If the request method was not HEAD and the server wishes to make | |
3344 public why the request has not been fulfilled, it SHOULD describe the | |
3345 reason for the refusal in the entity. This status code is commonly | |
3346 used when the server does not wish to reveal exactly why the request | |
3347 has been refused, or when no other response is applicable. | |
3348 | |
3349 10.4.5 404 Not Found | |
3350 | |
3351 The server has not found anything matching the Request-URI. No | |
3352 indication is given of whether the condition is temporary or | |
3353 permanent. | |
3354 | |
3355 | |
3356 | |
3357 | |
3358 | |
3359 | |
3360 | |
3361 | |
3362 Fielding, et. al. Standards Track [Page 60] | |
3363 | |
3364 RFC 2068 HTTP/1.1 January 1997 | |
3365 | |
3366 | |
3367 If the server does not wish to make this information available to the | |
3368 client, the status code 403 (Forbidden) can be used instead. The 410 | |
3369 (Gone) status code SHOULD be used if the server knows, through some | |
3370 internally configurable mechanism, that an old resource is | |
3371 permanently unavailable and has no forwarding address. | |
3372 | |
3373 10.4.6 405 Method Not Allowed | |
3374 | |
3375 The method specified in the Request-Line is not allowed for the | |
3376 resource identified by the Request-URI. The response MUST include an | |
3377 Allow header containing a list of valid methods for the requested | |
3378 resource. | |
3379 | |
3380 10.4.7 406 Not Acceptable | |
3381 | |
3382 The resource identified by the request is only capable of generating | |
3383 response entities which have content characteristics not acceptable | |
3384 according to the accept headers sent in the request. | |
3385 | |
3386 Unless it was a HEAD request, the response SHOULD include an entity | |
3387 containing a list of available entity characteristics and location(s) | |
3388 from which the user or user agent can choose the one most | |
3389 appropriate. The entity format is specified by the media type given | |
3390 in the Content-Type header field. Depending upon the format and the | |
3391 capabilities of the user agent, selection of the most appropriate | |
3392 choice may be performed automatically. However, this specification | |
3393 does not define any standard for such automatic selection. | |
3394 | |
3395 Note: HTTP/1.1 servers are allowed to return responses which are | |
3396 not acceptable according to the accept headers sent in the request. | |
3397 In some cases, this may even be preferable to sending a 406 | |
3398 response. User agents are encouraged to inspect the headers of an | |
3399 incoming response to determine if it is acceptable. If the response | |
3400 could be unacceptable, a user agent SHOULD temporarily stop receipt | |
3401 of more data and query the user for a decision on further actions. | |
3402 | |
3403 10.4.8 407 Proxy Authentication Required | |
3404 | |
3405 This code is similar to 401 (Unauthorized), but indicates that the | |
3406 client MUST first authenticate itself with the proxy. The proxy MUST | |
3407 return a Proxy-Authenticate header field (section 14.33) containing a | |
3408 challenge applicable to the proxy for the requested resource. The | |
3409 client MAY repeat the request with a suitable Proxy-Authorization | |
3410 header field (section 14.34). HTTP access authentication is explained | |
3411 in section 11. | |
3412 | |
3413 | |
3414 | |
3415 | |
3416 | |
3417 | |
3418 Fielding, et. al. Standards Track [Page 61] | |
3419 | |
3420 RFC 2068 HTTP/1.1 January 1997 | |
3421 | |
3422 | |
3423 10.4.9 408 Request Timeout | |
3424 | |
3425 The client did not produce a request within the time that the server | |
3426 was prepared to wait. The client MAY repeat the request without | |
3427 modifications at any later time. | |
3428 | |
3429 10.4.10 409 Conflict | |
3430 | |
3431 The request could not be completed due to a conflict with the current | |
3432 state of the resource. This code is only allowed in situations where | |
3433 it is expected that the user might be able to resolve the conflict | |
3434 and resubmit the request. The response body SHOULD include enough | |
3435 information for the user to recognize the source of the conflict. | |
3436 Ideally, the response entity would include enough information for the | |
3437 user or user agent to fix the problem; however, that may not be | |
3438 possible and is not required. | |
3439 | |
3440 Conflicts are most likely to occur in response to a PUT request. If | |
3441 versioning is being used and the entity being PUT includes changes to | |
3442 a resource which conflict with those made by an earlier (third-party) | |
3443 request, the server MAY use the 409 response to indicate that it | |
3444 can't complete the request. In this case, the response entity SHOULD | |
3445 contain a list of the differences between the two versions in a | |
3446 format defined by the response Content-Type. | |
3447 | |
3448 10.4.11 410 Gone | |
3449 | |
3450 The requested resource is no longer available at the server and no | |
3451 forwarding address is known. This condition SHOULD be considered | |
3452 permanent. Clients with link editing capabilities SHOULD delete | |
3453 references to the Request-URI after user approval. If the server does | |
3454 not know, or has no facility to determine, whether or not the | |
3455 condition is permanent, the status code 404 (Not Found) SHOULD be | |
3456 used instead. This response is cachable unless indicated otherwise. | |
3457 | |
3458 The 410 response is primarily intended to assist the task of web | |
3459 maintenance by notifying the recipient that the resource is | |
3460 intentionally unavailable and that the server owners desire that | |
3461 remote links to that resource be removed. Such an event is common for | |
3462 limited-time, promotional services and for resources belonging to | |
3463 individuals no longer working at the server's site. It is not | |
3464 necessary to mark all permanently unavailable resources as "gone" or | |
3465 to keep the mark for any length of time -- that is left to the | |
3466 discretion of the server owner. | |
3467 | |
3468 | |
3469 | |
3470 | |
3471 | |
3472 | |
3473 | |
3474 Fielding, et. al. Standards Track [Page 62] | |
3475 | |
3476 RFC 2068 HTTP/1.1 January 1997 | |
3477 | |
3478 | |
3479 10.4.12 411 Length Required | |
3480 | |
3481 The server refuses to accept the request without a defined Content- | |
3482 Length. The client MAY repeat the request if it adds a valid | |
3483 Content-Length header field containing the length of the message-body | |
3484 in the request message. | |
3485 | |
3486 10.4.13 412 Precondition Failed | |
3487 | |
3488 The precondition given in one or more of the request-header fields | |
3489 evaluated to false when it was tested on the server. This response | |
3490 code allows the client to place preconditions on the current resource | |
3491 metainformation (header field data) and thus prevent the requested | |
3492 method from being applied to a resource other than the one intended. | |
3493 | |
3494 10.4.14 413 Request Entity Too Large | |
3495 | |
3496 The server is refusing to process a request because the request | |
3497 entity is larger than the server is willing or able to process. The | |
3498 server may close the connection to prevent the client from continuing | |
3499 the request. | |
3500 | |
3501 If the condition is temporary, the server SHOULD include a Retry- | |
3502 After header field to indicate that it is temporary and after what | |
3503 time the client may try again. | |
3504 | |
3505 10.4.15 414 Request-URI Too Long | |
3506 | |
3507 The server is refusing to service the request because the Request-URI | |
3508 is longer than the server is willing to interpret. This rare | |
3509 condition is only likely to occur when a client has improperly | |
3510 converted a POST request to a GET request with long query | |
3511 information, when the client has descended into a URL "black hole" of | |
3512 redirection (e.g., a redirected URL prefix that points to a suffix of | |
3513 itself), or when the server is under attack by a client attempting to | |
3514 exploit security holes present in some servers using fixed-length | |
3515 buffers for reading or manipulating the Request-URI. | |
3516 | |
3517 10.4.16 415 Unsupported Media Type | |
3518 | |
3519 The server is refusing to service the request because the entity of | |
3520 the request is in a format not supported by the requested resource | |
3521 for the requested method. | |
3522 | |
3523 | |
3524 | |
3525 | |
3526 | |
3527 | |
3528 | |
3529 | |
3530 Fielding, et. al. Standards Track [Page 63] | |
3531 | |
3532 RFC 2068 HTTP/1.1 January 1997 | |
3533 | |
3534 | |
3535 10.5 Server Error 5xx | |
3536 | |
3537 Response status codes beginning with the digit "5" indicate cases in | |
3538 which the server is aware that it has erred or is incapable of | |
3539 performing the request. Except when responding to a HEAD request, the | |
3540 server SHOULD include an entity containing an explanation of the | |
3541 error situation, and whether it is a temporary or permanent | |
3542 condition. User agents SHOULD display any included entity to the | |
3543 user. These response codes are applicable to any request method. | |
3544 | |
3545 10.5.1 500 Internal Server Error | |
3546 | |
3547 The server encountered an unexpected condition which prevented it | |
3548 from fulfilling the request. | |
3549 | |
3550 10.5.2 501 Not Implemented | |
3551 | |
3552 The server does not support the functionality required to fulfill the | |
3553 request. This is the appropriate response when the server does not | |
3554 recognize the request method and is not capable of supporting it for | |
3555 any resource. | |
3556 | |
3557 10.5.3 502 Bad Gateway | |
3558 | |
3559 The server, while acting as a gateway or proxy, received an invalid | |
3560 response from the upstream server it accessed in attempting to | |
3561 fulfill the request. | |
3562 | |
3563 10.5.4 503 Service Unavailable | |
3564 | |
3565 The server is currently unable to handle the request due to a | |
3566 temporary overloading or maintenance of the server. The implication | |
3567 is that this is a temporary condition which will be alleviated after | |
3568 some delay. If known, the length of the delay may be indicated in a | |
3569 Retry-After header. If no Retry-After is given, the client SHOULD | |
3570 handle the response as it would for a 500 response. | |
3571 | |
3572 Note: The existence of the 503 status code does not imply that a | |
3573 server must use it when becoming overloaded. Some servers may wish | |
3574 to simply refuse the connection. | |
3575 | |
3576 10.5.5 504 Gateway Timeout | |
3577 | |
3578 The server, while acting as a gateway or proxy, did not receive a | |
3579 timely response from the upstream server it accessed in attempting to | |
3580 complete the request. | |
3581 | |
3582 | |
3583 | |
3584 | |
3585 | |
3586 Fielding, et. al. Standards Track [Page 64] | |
3587 | |
3588 RFC 2068 HTTP/1.1 January 1997 | |
3589 | |
3590 | |
3591 10.5.6 505 HTTP Version Not Supported | |
3592 | |
3593 The server does not support, or refuses to support, the HTTP protocol | |
3594 version that was used in the request message. The server is | |
3595 indicating that it is unable or unwilling to complete the request | |
3596 using the same major version as the client, as described in section | |
3597 3.1, other than with this error message. The response SHOULD contain | |
3598 an entity describing why that version is not supported and what other | |
3599 protocols are supported by that server. | |
3600 | |
3601 11 Access Authentication | |
3602 | |
3603 HTTP provides a simple challenge-response authentication mechanism | |
3604 which MAY be used by a server to challenge a client request and by a | |
3605 client to provide authentication information. It uses an extensible, | |
3606 case-insensitive token to identify the authentication scheme, | |
3607 followed by a comma-separated list of attribute-value pairs which | |
3608 carry the parameters necessary for achieving authentication via that | |
3609 scheme. | |
3610 | |
3611 auth-scheme = token | |
3612 | |
3613 auth-param = token "=" quoted-string | |
3614 | |
3615 The 401 (Unauthorized) response message is used by an origin server | |
3616 to challenge the authorization of a user agent. This response MUST | |
3617 include a WWW-Authenticate header field containing at least one | |
3618 challenge applicable to the requested resource. | |
3619 | |
3620 challenge = auth-scheme 1*SP realm *( "," auth-param ) | |
3621 | |
3622 realm = "realm" "=" realm-value | |
3623 realm-value = quoted-string | |
3624 | |
3625 The realm attribute (case-insensitive) is required for all | |
3626 authentication schemes which issue a challenge. The realm value | |
3627 (case-sensitive), in combination with the canonical root URL (see | |
3628 section 5.1.2) of the server being accessed, defines the protection | |
3629 space. These realms allow the protected resources on a server to be | |
3630 partitioned into a set of protection spaces, each with its own | |
3631 authentication scheme and/or authorization database. The realm value | |
3632 is a string, generally assigned by the origin server, which may have | |
3633 additional semantics specific to the authentication scheme. | |
3634 | |
3635 A user agent that wishes to authenticate itself with a server-- | |
3636 usually, but not necessarily, after receiving a 401 or 411 response- | |
3637 -MAY do so by including an Authorization header field with the | |
3638 request. The Authorization field value consists of credentials | |
3639 | |
3640 | |
3641 | |
3642 Fielding, et. al. Standards Track [Page 65] | |
3643 | |
3644 RFC 2068 HTTP/1.1 January 1997 | |
3645 | |
3646 | |
3647 containing the authentication information of the user agent for the | |
3648 realm of the resource being requested. | |
3649 | |
3650 credentials = basic-credentials | |
3651 | auth-scheme #auth-param | |
3652 | |
3653 The domain over which credentials can be automatically applied by a | |
3654 user agent is determined by the protection space. If a prior request | |
3655 has been authorized, the same credentials MAY be reused for all other | |
3656 requests within that protection space for a period of time determined | |
3657 by the authentication scheme, parameters, and/or user preference. | |
3658 Unless otherwise defined by the authentication scheme, a single | |
3659 protection space cannot extend outside the scope of its server. | |
3660 | |
3661 If the server does not wish to accept the credentials sent with a | |
3662 request, it SHOULD return a 401 (Unauthorized) response. The response | |
3663 MUST include a WWW-Authenticate header field containing the (possibly | |
3664 new) challenge applicable to the requested resource and an entity | |
3665 explaining the refusal. | |
3666 | |
3667 The HTTP protocol does not restrict applications to this simple | |
3668 challenge-response mechanism for access authentication. Additional | |
3669 mechanisms MAY be used, such as encryption at the transport level or | |
3670 via message encapsulation, and with additional header fields | |
3671 specifying authentication information. However, these additional | |
3672 mechanisms are not defined by this specification. | |
3673 | |
3674 Proxies MUST be completely transparent regarding user agent | |
3675 authentication. That is, they MUST forward the WWW-Authenticate and | |
3676 Authorization headers untouched, and follow the rules found in | |
3677 section 14.8. | |
3678 | |
3679 HTTP/1.1 allows a client to pass authentication information to and | |
3680 from a proxy via the Proxy-Authenticate and Proxy-Authorization | |
3681 headers. | |
3682 | |
3683 11.1 Basic Authentication Scheme | |
3684 | |
3685 The "basic" authentication scheme is based on the model that the user | |
3686 agent must authenticate itself with a user-ID and a password for each | |
3687 realm. The realm value should be considered an opaque string which | |
3688 can only be compared for equality with other realms on that server. | |
3689 The server will service the request only if it can validate the | |
3690 user-ID and password for the protection space of the Request-URI. | |
3691 There are no optional authentication parameters. | |
3692 | |
3693 | |
3694 | |
3695 | |
3696 | |
3697 | |
3698 Fielding, et. al. Standards Track [Page 66] | |
3699 | |
3700 RFC 2068 HTTP/1.1 January 1997 | |
3701 | |
3702 | |
3703 Upon receipt of an unauthorized request for a URI within the | |
3704 protection space, the server MAY respond with a challenge like the | |
3705 following: | |
3706 | |
3707 WWW-Authenticate: Basic realm="WallyWorld" | |
3708 | |
3709 where "WallyWorld" is the string assigned by the server to identify | |
3710 the protection space of the Request-URI. | |
3711 | |
3712 To receive authorization, the client sends the userid and password, | |
3713 separated by a single colon (":") character, within a base64 encoded | |
3714 string in the credentials. | |
3715 | |
3716 basic-credentials = "Basic" SP basic-cookie | |
3717 | |
3718 basic-cookie = <base64 [7] encoding of user-pass, | |
3719 except not limited to 76 char/line> | |
3720 | |
3721 user-pass = userid ":" password | |
3722 | |
3723 userid = *<TEXT excluding ":"> | |
3724 | |
3725 password = *TEXT | |
3726 | |
3727 Userids might be case sensitive. | |
3728 | |
3729 If the user agent wishes to send the userid "Aladdin" and password | |
3730 "open sesame", it would use the following header field: | |
3731 | |
3732 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== | |
3733 | |
3734 See section 15 for security considerations associated with Basic | |
3735 authentication. | |
3736 | |
3737 11.2 Digest Authentication Scheme | |
3738 | |
3739 A digest authentication for HTTP is specified in RFC 2069 [32]. | |
3740 | |
3741 12 Content Negotiation | |
3742 | |
3743 Most HTTP responses include an entity which contains information for | |
3744 interpretation by a human user. Naturally, it is desirable to supply | |
3745 the user with the "best available" entity corresponding to the | |
3746 request. Unfortunately for servers and caches, not all users have | |
3747 the same preferences for what is "best," and not all user agents are | |
3748 equally capable of rendering all entity types. For that reason, HTTP | |
3749 has provisions for several mechanisms for "content negotiation" -- | |
3750 the process of selecting the best representation for a given response | |
3751 | |
3752 | |
3753 | |
3754 Fielding, et. al. Standards Track [Page 67] | |
3755 | |
3756 RFC 2068 HTTP/1.1 January 1997 | |
3757 | |
3758 | |
3759 when there are multiple representations available. | |
3760 | |
3761 Note: This is not called "format negotiation" because the alternate | |
3762 representations may be of the same media type, but use different | |
3763 capabilities of that type, be in different languages, etc. | |
3764 | |
3765 Any response containing an entity-body MAY be subject to negotiation, | |
3766 including error responses. | |
3767 | |
3768 There are two kinds of content negotiation which are possible in | |
3769 HTTP: server-driven and agent-driven negotiation. These two kinds of | |
3770 negotiation are orthogonal and thus may be used separately or in | |
3771 combination. One method of combination, referred to as transparent | |
3772 negotiation, occurs when a cache uses the agent-driven negotiation | |
3773 information provided by the origin server in order to provide | |
3774 server-driven negotiation for subsequent requests. | |
3775 | |
3776 12.1 Server-driven Negotiation | |
3777 | |
3778 If the selection of the best representation for a response is made by | |
3779 an algorithm located at the server, it is called server-driven | |
3780 negotiation. Selection is based on the available representations of | |
3781 the response (the dimensions over which it can vary; e.g. language, | |
3782 content-coding, etc.) and the contents of particular header fields in | |
3783 the request message or on other information pertaining to the request | |
3784 (such as the network address of the client). | |
3785 | |
3786 Server-driven negotiation is advantageous when the algorithm for | |
3787 selecting from among the available representations is difficult to | |
3788 describe to the user agent, or when the server desires to send its | |
3789 "best guess" to the client along with the first response (hoping to | |
3790 avoid the round-trip delay of a subsequent request if the "best | |
3791 guess" is good enough for the user). In order to improve the server's | |
3792 guess, the user agent MAY include request header fields (Accept, | |
3793 Accept-Language, Accept-Encoding, etc.) which describe its | |
3794 preferences for such a response. | |
3795 | |
3796 Server-driven negotiation has disadvantages: | |
3797 | |
3798 1. It is impossible for the server to accurately determine what might be | |
3799 "best" for any given user, since that would require complete | |
3800 knowledge of both the capabilities of the user agent and the intended | |
3801 use for the response (e.g., does the user want to view it on screen | |
3802 or print it on paper?). | |
3803 | |
3804 2. Having the user agent describe its capabilities in every request can | |
3805 be both very inefficient (given that only a small percentage of | |
3806 responses have multiple representations) and a potential violation of | |
3807 | |
3808 | |
3809 | |
3810 Fielding, et. al. Standards Track [Page 68] | |
3811 | |
3812 RFC 2068 HTTP/1.1 January 1997 | |
3813 | |
3814 | |
3815 the user's privacy. | |
3816 | |
3817 3. It complicates the implementation of an origin server and the | |
3818 algorithms for generating responses to a request. | |
3819 | |
3820 4. It may limit a public cache's ability to use the same response for | |
3821 multiple user's requests. | |
3822 | |
3823 HTTP/1.1 includes the following request-header fields for enabling | |
3824 server-driven negotiation through description of user agent | |
3825 capabilities and user preferences: Accept (section 14.1), Accept- | |
3826 Charset (section 14.2), Accept-Encoding (section 14.3), Accept- | |
3827 Language (section 14.4), and User-Agent (section 14.42). However, an | |
3828 origin server is not limited to these dimensions and MAY vary the | |
3829 response based on any aspect of the request, including information | |
3830 outside the request-header fields or within extension header fields | |
3831 not defined by this specification. | |
3832 | |
3833 HTTP/1.1 origin servers MUST include an appropriate Vary header field | |
3834 (section 14.43) in any cachable response based on server-driven | |
3835 negotiation. The Vary header field describes the dimensions over | |
3836 which the response might vary (i.e. the dimensions over which the | |
3837 origin server picks its "best guess" response from multiple | |
3838 representations). | |
3839 | |
3840 HTTP/1.1 public caches MUST recognize the Vary header field when it | |
3841 is included in a response and obey the requirements described in | |
3842 section 13.6 that describes the interactions between caching and | |
3843 content negotiation. | |
3844 | |
3845 12.2 Agent-driven Negotiation | |
3846 | |
3847 With agent-driven negotiation, selection of the best representation | |
3848 for a response is performed by the user agent after receiving an | |
3849 initial response from the origin server. Selection is based on a list | |
3850 of the available representations of the response included within the | |
3851 header fields (this specification reserves the field-name Alternates, | |
3852 as described in appendix 19.6.2.1) or entity-body of the initial | |
3853 response, with each representation identified by its own URI. | |
3854 Selection from among the representations may be performed | |
3855 automatically (if the user agent is capable of doing so) or manually | |
3856 by the user selecting from a generated (possibly hypertext) menu. | |
3857 | |
3858 Agent-driven negotiation is advantageous when the response would vary | |
3859 over commonly-used dimensions (such as type, language, or encoding), | |
3860 when the origin server is unable to determine a user agent's | |
3861 capabilities from examining the request, and generally when public | |
3862 caches are used to distribute server load and reduce network usage. | |
3863 | |
3864 | |
3865 | |
3866 Fielding, et. al. Standards Track [Page 69] | |
3867 | |
3868 RFC 2068 HTTP/1.1 January 1997 | |
3869 | |
3870 | |
3871 Agent-driven negotiation suffers from the disadvantage of needing a | |
3872 second request to obtain the best alternate representation. This | |
3873 second request is only efficient when caching is used. In addition, | |
3874 this specification does not define any mechanism for supporting | |
3875 automatic selection, though it also does not prevent any such | |
3876 mechanism from being developed as an extension and used within | |
3877 HTTP/1.1. | |
3878 | |
3879 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | |
3880 status codes for enabling agent-driven negotiation when the server is | |
3881 unwilling or unable to provide a varying response using server-driven | |
3882 negotiation. | |
3883 | |
3884 12.3 Transparent Negotiation | |
3885 | |
3886 Transparent negotiation is a combination of both server-driven and | |
3887 agent-driven negotiation. When a cache is supplied with a form of the | |
3888 list of available representations of the response (as in agent-driven | |
3889 negotiation) and the dimensions of variance are completely understood | |
3890 by the cache, then the cache becomes capable of performing server- | |
3891 driven negotiation on behalf of the origin server for subsequent | |
3892 requests on that resource. | |
3893 | |
3894 Transparent negotiation has the advantage of distributing the | |
3895 negotiation work that would otherwise be required of the origin | |
3896 server and also removing the second request delay of agent-driven | |
3897 negotiation when the cache is able to correctly guess the right | |
3898 response. | |
3899 | |
3900 This specification does not define any mechanism for transparent | |
3901 negotiation, though it also does not prevent any such mechanism from | |
3902 being developed as an extension and used within HTTP/1.1. An HTTP/1.1 | |
3903 cache performing transparent negotiation MUST include a Vary header | |
3904 field in the response (defining the dimensions of its variance) if it | |
3905 is cachable to ensure correct interoperation with all HTTP/1.1 | |
3906 clients. The agent-driven negotiation information supplied by the | |
3907 origin server SHOULD be included with the transparently negotiated | |
3908 response. | |
3909 | |
3910 13 Caching in HTTP | |
3911 | |
3912 HTTP is typically used for distributed information systems, where | |
3913 performance can be improved by the use of response caches. The | |
3914 HTTP/1.1 protocol includes a number of elements intended to make | |
3915 caching work as well as possible. Because these elements are | |
3916 inextricable from other aspects of the protocol, and because they | |
3917 interact with each other, it is useful to describe the basic caching | |
3918 design of HTTP separately from the detailed descriptions of methods, | |
3919 | |
3920 | |
3921 | |
3922 Fielding, et. al. Standards Track [Page 70] | |
3923 | |
3924 RFC 2068 HTTP/1.1 January 1997 | |
3925 | |
3926 | |
3927 headers, response codes, etc. | |
3928 | |
3929 Caching would be useless if it did not significantly improve | |
3930 performance. The goal of caching in HTTP/1.1 is to eliminate the need | |
3931 to send requests in many cases, and to eliminate the need to send | |
3932 full responses in many other cases. The former reduces the number of | |
3933 network round-trips required for many operations; we use an | |
3934 "expiration" mechanism for this purpose (see section 13.2). The | |
3935 latter reduces network bandwidth requirements; we use a "validation" | |
3936 mechanism for this purpose (see section 13.3). | |
3937 | |
3938 Requirements for performance, availability, and disconnected | |
3939 operation require us to be able to relax the goal of semantic | |
3940 transparency. The HTTP/1.1 protocol allows origin servers, caches, | |
3941 and clients to explicitly reduce transparency when necessary. | |
3942 However, because non-transparent operation may confuse non-expert | |
3943 users, and may be incompatible with certain server applications (such | |
3944 as those for ordering merchandise), the protocol requires that | |
3945 transparency be relaxed | |
3946 | |
3947 o only by an explicit protocol-level request when relaxed by client | |
3948 or origin server | |
3949 | |
3950 o only with an explicit warning to the end user when relaxed by cache | |
3951 or client | |
3952 | |
3953 | |
3954 | |
3955 | |
3956 | |
3957 | |
3958 | |
3959 | |
3960 | |
3961 | |
3962 | |
3963 | |
3964 | |
3965 | |
3966 | |
3967 | |
3968 | |
3969 | |
3970 | |
3971 | |
3972 | |
3973 | |
3974 | |
3975 | |
3976 | |
3977 | |
3978 Fielding, et. al. Standards Track [Page 71] | |
3979 | |
3980 RFC 2068 HTTP/1.1 January 1997 | |
3981 | |
3982 | |
3983 Therefore, the HTTP/1.1 protocol provides these important elements: | |
3984 | |
3985 1. Protocol features that provide full semantic transparency when this | |
3986 is required by all parties. | |
3987 | |
3988 2. Protocol features that allow an origin server or user agent to | |
3989 explicitly request and control non-transparent operation. | |
3990 | |
3991 3. Protocol features that allow a cache to attach warnings to | |
3992 responses that do not preserve the requested approximation of | |
3993 semantic transparency. | |
3994 | |
3995 A basic principle is that it must be possible for the clients to | |
3996 detect any potential relaxation of semantic transparency. | |
3997 | |
3998 Note: The server, cache, or client implementer may be faced with | |
3999 design decisions not explicitly discussed in this specification. If | |
4000 a decision may affect semantic transparency, the implementer ought | |
4001 to err on the side of maintaining transparency unless a careful and | |
4002 complete analysis shows significant benefits in breaking | |
4003 transparency. | |
4004 | |
4005 13.1.1 Cache Correctness | |
4006 | |
4007 A correct cache MUST respond to a request with the most up-to-date | |
4008 response held by the cache that is appropriate to the request (see | |
4009 sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | |
4010 conditions: | |
4011 | |
4012 1. It has been checked for equivalence with what the origin server | |
4013 would have returned by revalidating the response with the origin | |
4014 server (section 13.3); | |
4015 | |
4016 2. It is "fresh enough" (see section 13.2). In the default case, this | |
4017 means it meets the least restrictive freshness requirement of the | |
4018 client, server, and cache (see section 14.9); if the origin server | |
4019 so specifies, it is the freshness requirement of the origin server | |
4020 alone. | |
4021 | |
4022 3. It includes a warning if the freshness demand of the client or the | |
4023 origin server is violated (see section 13.1.5 and 14.45). | |
4024 | |
4025 4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or | |
4026 error (4xx or 5xx) response message. | |
4027 | |
4028 If the cache can not communicate with the origin server, then a | |
4029 correct cache SHOULD respond as above if the response can be | |
4030 correctly served from the cache; if not it MUST return an error or | |
4031 | |
4032 | |
4033 | |
4034 Fielding, et. al. Standards Track [Page 72] | |
4035 | |
4036 RFC 2068 HTTP/1.1 January 1997 | |
4037 | |
4038 | |
4039 warning indicating that there was a communication failure. | |
4040 | |
4041 If a cache receives a response (either an entire response, or a 304 | |
4042 (Not Modified) response) that it would normally forward to the | |
4043 requesting client, and the received response is no longer fresh, the | |
4044 cache SHOULD forward it to the requesting client without adding a new | |
4045 Warning (but without removing any existing Warning headers). A cache | |
4046 SHOULD NOT attempt to revalidate a response simply because that | |
4047 response became stale in transit; this might lead to an infinite | |
4048 loop. An user agent that receives a stale response without a Warning | |
4049 MAY display a warning indication to the user. | |
4050 | |
4051 13.1.2 Warnings | |
4052 | |
4053 Whenever a cache returns a response that is neither first-hand nor | |
4054 "fresh enough" (in the sense of condition 2 in section 13.1.1), it | |
4055 must attach a warning to that effect, using a Warning response- | |
4056 header. This warning allows clients to take appropriate action. | |
4057 | |
4058 Warnings may be used for other purposes, both cache-related and | |
4059 otherwise. The use of a warning, rather than an error status code, | |
4060 distinguish these responses from true failures. | |
4061 | |
4062 Warnings are always cachable, because they never weaken the | |
4063 transparency of a response. This means that warnings can be passed to | |
4064 HTTP/1.0 caches without danger; such caches will simply pass the | |
4065 warning along as an entity-header in the response. | |
4066 | |
4067 Warnings are assigned numbers between 0 and 99. This specification | |
4068 defines the code numbers and meanings of each currently assigned | |
4069 warnings, allowing a client or cache to take automated action in some | |
4070 (but not all) cases. | |
4071 | |
4072 Warnings also carry a warning text. The text may be in any | |
4073 appropriate natural language (perhaps based on the client's Accept | |
4074 headers), and include an optional indication of what character set is | |
4075 used. | |
4076 | |
4077 Multiple warnings may be attached to a response (either by the origin | |
4078 server or by a cache), including multiple warnings with the same code | |
4079 number. For example, a server may provide the same warning with texts | |
4080 in both English and Basque. | |
4081 | |
4082 When multiple warnings are attached to a response, it may not be | |
4083 practical or reasonable to display all of them to the user. This | |
4084 version of HTTP does not specify strict priority rules for deciding | |
4085 which warnings to display and in what order, but does suggest some | |
4086 heuristics. | |
4087 | |
4088 | |
4089 | |
4090 Fielding, et. al. Standards Track [Page 73] | |
4091 | |
4092 RFC 2068 HTTP/1.1 January 1997 | |
4093 | |
4094 | |
4095 The Warning header and the currently defined warnings are described | |
4096 in section 14.45. | |
4097 | |
4098 13.1.3 Cache-control Mechanisms | |
4099 | |
4100 The basic cache mechanisms in HTTP/1.1 (server-specified expiration | |
4101 times and validators) are implicit directives to caches. In some | |
4102 cases, a server or client may need to provide explicit directives to | |
4103 the HTTP caches. We use the Cache-Control header for this purpose. | |
4104 | |
4105 The Cache-Control header allows a client or server to transmit a | |
4106 variety of directives in either requests or responses. These | |
4107 directives typically override the default caching algorithms. As a | |
4108 general rule, if there is any apparent conflict between header | |
4109 values, the most restrictive interpretation should be applied (that | |
4110 is, the one that is most likely to preserve semantic transparency). | |
4111 However, in some cases, Cache-Control directives are explicitly | |
4112 specified as weakening the approximation of semantic transparency | |
4113 (for example, "max-stale" or "public"). | |
4114 | |
4115 The Cache-Control directives are described in detail in section 14.9. | |
4116 | |
4117 13.1.4 Explicit User Agent Warnings | |
4118 | |
4119 Many user agents make it possible for users to override the basic | |
4120 caching mechanisms. For example, the user agent may allow the user to | |
4121 specify that cached entities (even explicitly stale ones) are never | |
4122 validated. Or the user agent might habitually add "Cache-Control: | |
4123 max-stale=3600" to every request. The user should have to explicitly | |
4124 request either non-transparent behavior, or behavior that results in | |
4125 abnormally ineffective caching. | |
4126 | |
4127 If the user has overridden the basic caching mechanisms, the user | |
4128 agent should explicitly indicate to the user whenever this results in | |
4129 the display of information that might not meet the server's | |
4130 transparency requirements (in particular, if the displayed entity is | |
4131 known to be stale). Since the protocol normally allows the user agent | |
4132 to determine if responses are stale or not, this indication need only | |
4133 be displayed when this actually happens. The indication need not be a | |
4134 dialog box; it could be an icon (for example, a picture of a rotting | |
4135 fish) or some other visual indicator. | |
4136 | |
4137 If the user has overridden the caching mechanisms in a way that would | |
4138 abnormally reduce the effectiveness of caches, the user agent should | |
4139 continually display an indication (for example, a picture of currency | |
4140 in flames) so that the user does not inadvertently consume excess | |
4141 resources or suffer from excessive latency. | |
4142 | |
4143 | |
4144 | |
4145 | |
4146 Fielding, et. al. Standards Track [Page 74] | |
4147 | |
4148 RFC 2068 HTTP/1.1 January 1997 | |
4149 | |
4150 | |
4151 13.1.5 Exceptions to the Rules and Warnings | |
4152 | |
4153 In some cases, the operator of a cache may choose to configure it to | |
4154 return stale responses even when not requested by clients. This | |
4155 decision should not be made lightly, but may be necessary for reasons | |
4156 of availability or performance, especially when the cache is poorly | |
4157 connected to the origin server. Whenever a cache returns a stale | |
4158 response, it MUST mark it as such (using a Warning header). This | |
4159 allows the client software to alert the user that there may be a | |
4160 potential problem. | |
4161 | |
4162 It also allows the user agent to take steps to obtain a first-hand or | |
4163 fresh response. For this reason, a cache SHOULD NOT return a stale | |
4164 response if the client explicitly requests a first-hand or fresh one, | |
4165 unless it is impossible to comply for technical or policy reasons. | |
4166 | |
4167 13.1.6 Client-controlled Behavior | |
4168 | |
4169 While the origin server (and to a lesser extent, intermediate caches, | |
4170 by their contribution to the age of a response) are the primary | |
4171 source of expiration information, in some cases the client may need | |
4172 to control a cache's decision about whether to return a cached | |
4173 response without validating it. Clients do this using several | |
4174 directives of the Cache-Control header. | |
4175 | |
4176 A client's request may specify the maximum age it is willing to | |
4177 accept of an unvalidated response; specifying a value of zero forces | |
4178 the cache(s) to revalidate all responses. A client may also specify | |
4179 the minimum time remaining before a response expires. Both of these | |
4180 options increase constraints on the behavior of caches, and so cannot | |
4181 further relax the cache's approximation of semantic transparency. | |
4182 | |
4183 A client may also specify that it will accept stale responses, up to | |
4184 some maximum amount of staleness. This loosens the constraints on the | |
4185 caches, and so may violate the origin server's specified constraints | |
4186 on semantic transparency, but may be necessary to support | |
4187 disconnected operation, or high availability in the face of poor | |
4188 connectivity. | |
4189 | |
4190 13.2 Expiration Model | |
4191 | |
4192 13.2.1 Server-Specified Expiration | |
4193 | |
4194 HTTP caching works best when caches can entirely avoid making | |
4195 requests to the origin server. The primary mechanism for avoiding | |
4196 requests is for an origin server to provide an explicit expiration | |
4197 time in the future, indicating that a response may be used to satisfy | |
4198 subsequent requests. In other words, a cache can return a fresh | |
4199 | |
4200 | |
4201 | |
4202 Fielding, et. al. Standards Track [Page 75] | |
4203 | |
4204 RFC 2068 HTTP/1.1 January 1997 | |
4205 | |
4206 | |
4207 response without first contacting the server. | |
4208 | |
4209 Our expectation is that servers will assign future explicit | |
4210 expiration times to responses in the belief that the entity is not | |
4211 likely to change, in a semantically significant way, before the | |
4212 expiration time is reached. This normally preserves semantic | |
4213 transparency, as long as the server's expiration times are carefully | |
4214 chosen. | |
4215 | |
4216 The expiration mechanism applies only to responses taken from a cache | |
4217 and not to first-hand responses forwarded immediately to the | |
4218 requesting client. | |
4219 | |
4220 If an origin server wishes to force a semantically transparent cache | |
4221 to validate every request, it may assign an explicit expiration time | |
4222 in the past. This means that the response is always stale, and so the | |
4223 cache SHOULD validate it before using it for subsequent requests. See | |
4224 section 14.9.4 for a more restrictive way to force revalidation. | |
4225 | |
4226 If an origin server wishes to force any HTTP/1.1 cache, no matter how | |
4227 it is configured, to validate every request, it should use the | |
4228 "must-revalidate" Cache-Control directive (see section 14.9). | |
4229 | |
4230 Servers specify explicit expiration times using either the Expires | |
4231 header, or the max-age directive of the Cache-Control header. | |
4232 | |
4233 An expiration time cannot be used to force a user agent to refresh | |
4234 its display or reload a resource; its semantics apply only to caching | |
4235 mechanisms, and such mechanisms need only check a resource's | |
4236 expiration status when a new request for that resource is initiated. | |
4237 See section 13.13 for explanation of the difference between caches | |
4238 and history mechanisms. | |
4239 | |
4240 13.2.2 Heuristic Expiration | |
4241 | |
4242 Since origin servers do not always provide explicit expiration times, | |
4243 HTTP caches typically assign heuristic expiration times, employing | |
4244 algorithms that use other header values (such as the Last-Modified | |
4245 time) to estimate a plausible expiration time. The HTTP/1.1 | |
4246 specification does not provide specific algorithms, but does impose | |
4247 worst-case constraints on their results. Since heuristic expiration | |
4248 times may compromise semantic transparency, they should be used | |
4249 cautiously, and we encourage origin servers to provide explicit | |
4250 expiration times as much as possible. | |
4251 | |
4252 | |
4253 | |
4254 | |
4255 | |
4256 | |
4257 | |
4258 Fielding, et. al. Standards Track [Page 76] | |
4259 | |
4260 RFC 2068 HTTP/1.1 January 1997 | |
4261 | |
4262 | |
4263 13.2.3 Age Calculations | |
4264 | |
4265 In order to know if a cached entry is fresh, a cache needs to know if | |
4266 its age exceeds its freshness lifetime. We discuss how to calculate | |
4267 the latter in section 13.2.4; this section describes how to calculate | |
4268 the age of a response or cache entry. | |
4269 | |
4270 In this discussion, we use the term "now" to mean "the current value | |
4271 of the clock at the host performing the calculation." Hosts that use | |
4272 HTTP, but especially hosts running origin servers and caches, should | |
4273 use NTP [28] or some similar protocol to synchronize their clocks to | |
4274 a globally accurate time standard. | |
4275 | |
4276 Also note that HTTP/1.1 requires origin servers to send a Date header | |
4277 with every response, giving the time at which the response was | |
4278 generated. We use the term "date_value" to denote the value of the | |
4279 Date header, in a form appropriate for arithmetic operations. | |
4280 | |
4281 HTTP/1.1 uses the Age response-header to help convey age information | |
4282 between caches. The Age header value is the sender's estimate of the | |
4283 amount of time since the response was generated at the origin server. | |
4284 In the case of a cached response that has been revalidated with the | |
4285 origin server, the Age value is based on the time of revalidation, | |
4286 not of the original response. | |
4287 | |
4288 In essence, the Age value is the sum of the time that the response | |
4289 has been resident in each of the caches along the path from the | |
4290 origin server, plus the amount of time it has been in transit along | |
4291 network paths. | |
4292 | |
4293 We use the term "age_value" to denote the value of the Age header, in | |
4294 a form appropriate for arithmetic operations. | |
4295 | |
4296 A response's age can be calculated in two entirely independent ways: | |
4297 | |
4298 1. now minus date_value, if the local clock is reasonably well | |
4299 synchronized to the origin server's clock. If the result is | |
4300 negative, the result is replaced by zero. | |
4301 | |
4302 2. age_value, if all of the caches along the response path | |
4303 implement HTTP/1.1. | |
4304 | |
4305 Given that we have two independent ways to compute the age of a | |
4306 response when it is received, we can combine these as | |
4307 | |
4308 corrected_received_age = max(now - date_value, age_value) | |
4309 | |
4310 and as long as we have either nearly synchronized clocks or all- | |
4311 | |
4312 | |
4313 | |
4314 Fielding, et. al. Standards Track [Page 77] | |
4315 | |
4316 RFC 2068 HTTP/1.1 January 1997 | |
4317 | |
4318 | |
4319 HTTP/1.1 paths, one gets a reliable (conservative) result. | |
4320 | |
4321 Note that this correction is applied at each HTTP/1.1 cache along the | |
4322 path, so that if there is an HTTP/1.0 cache in the path, the correct | |
4323 received age is computed as long as the receiving cache's clock is | |
4324 nearly in sync. We don't need end-to-end clock synchronization | |
4325 (although it is good to have), and there is no explicit clock | |
4326 synchronization step. | |
4327 | |
4328 Because of network-imposed delays, some significant interval may pass | |
4329 from the time that a server generates a response and the time it is | |
4330 received at the next outbound cache or client. If uncorrected, this | |
4331 delay could result in improperly low ages. | |
4332 | |
4333 Because the request that resulted in the returned Age value must have | |
4334 been initiated prior to that Age value's generation, we can correct | |
4335 for delays imposed by the network by recording the time at which the | |
4336 request was initiated. Then, when an Age value is received, it MUST | |
4337 be interpreted relative to the time the request was initiated, not | |
4338 the time that the response was received. This algorithm results in | |
4339 conservative behavior no matter how much delay is experienced. So, we | |
4340 compute: | |
4341 | |
4342 corrected_initial_age = corrected_received_age | |
4343 + (now - request_time) | |
4344 | |
4345 where "request_time" is the time (according to the local clock) when | |
4346 the request that elicited this response was sent. | |
4347 | |
4348 Summary of age calculation algorithm, when a cache receives a | |
4349 response: | |
4350 | |
4351 /* | |
4352 * age_value | |
4353 * is the value of Age: header received by the cache with | |
4354 * this response. | |
4355 * date_value | |
4356 * is the value of the origin server's Date: header | |
4357 * request_time | |
4358 * is the (local) time when the cache made the request | |
4359 * that resulted in this cached response | |
4360 * response_time | |
4361 * is the (local) time when the cache received the | |
4362 * response | |
4363 * now | |
4364 * is the current (local) time | |
4365 */ | |
4366 apparent_age = max(0, response_time - date_value); | |
4367 | |
4368 | |
4369 | |
4370 Fielding, et. al. Standards Track [Page 78] | |
4371 | |
4372 RFC 2068 HTTP/1.1 January 1997 | |
4373 | |
4374 | |
4375 corrected_received_age = max(apparent_age, age_value); | |
4376 response_delay = response_time - request_time; | |
4377 corrected_initial_age = corrected_received_age + response_delay; | |
4378 resident_time = now - response_time; | |
4379 current_age = corrected_initial_age + resident_time; | |
4380 | |
4381 When a cache sends a response, it must add to the | |
4382 corrected_initial_age the amount of time that the response was | |
4383 resident locally. It must then transmit this total age, using the Age | |
4384 header, to the next recipient cache. | |
4385 | |
4386 Note that a client cannot reliably tell that a response is first- | |
4387 hand, but the presence of an Age header indicates that a response | |
4388 is definitely not first-hand. Also, if the Date in a response is | |
4389 earlier than the client's local request time, the response is | |
4390 probably not first-hand (in the absence of serious clock skew). | |
4391 | |
4392 13.2.4 Expiration Calculations | |
4393 | |
4394 In order to decide whether a response is fresh or stale, we need to | |
4395 compare its freshness lifetime to its age. The age is calculated as | |
4396 described in section 13.2.3; this section describes how to calculate | |
4397 the freshness lifetime, and to determine if a response has expired. | |
4398 In the discussion below, the values can be represented in any form | |
4399 appropriate for arithmetic operations. | |
4400 | |
4401 We use the term "expires_value" to denote the value of the Expires | |
4402 header. We use the term "max_age_value" to denote an appropriate | |
4403 value of the number of seconds carried by the max-age directive of | |
4404 the Cache-Control header in a response (see section 14.10. | |
4405 | |
4406 The max-age directive takes priority over Expires, so if max-age is | |
4407 present in a response, the calculation is simply: | |
4408 | |
4409 freshness_lifetime = max_age_value | |
4410 | |
4411 Otherwise, if Expires is present in the response, the calculation is: | |
4412 | |
4413 freshness_lifetime = expires_value - date_value | |
4414 | |
4415 Note that neither of these calculations is vulnerable to clock skew, | |
4416 since all of the information comes from the origin server. | |
4417 | |
4418 If neither Expires nor Cache-Control: max-age appears in the | |
4419 response, and the response does not include other restrictions on | |
4420 caching, the cache MAY compute a freshness lifetime using a | |
4421 heuristic. If the value is greater than 24 hours, the cache must | |
4422 attach Warning 13 to any response whose age is more than 24 hours if | |
4423 | |
4424 | |
4425 | |
4426 Fielding, et. al. Standards Track [Page 79] | |
4427 | |
4428 RFC 2068 HTTP/1.1 January 1997 | |
4429 | |
4430 | |
4431 such warning has not already been added. | |
4432 | |
4433 Also, if the response does have a Last-Modified time, the heuristic | |
4434 expiration value SHOULD be no more than some fraction of the interval | |
4435 since that time. A typical setting of this fraction might be 10%. | |
4436 | |
4437 The calculation to determine if a response has expired is quite | |
4438 simple: | |
4439 | |
4440 response_is_fresh = (freshness_lifetime > current_age) | |
4441 | |
4442 13.2.5 Disambiguating Expiration Values | |
4443 | |
4444 Because expiration values are assigned optimistically, it is possible | |
4445 for two caches to contain fresh values for the same resource that are | |
4446 different. | |
4447 | |
4448 If a client performing a retrieval receives a non-first-hand response | |
4449 for a request that was already fresh in its own cache, and the Date | |
4450 header in its existing cache entry is newer than the Date on the new | |
4451 response, then the client MAY ignore the response. If so, it MAY | |
4452 retry the request with a "Cache-Control: max-age=0" directive (see | |
4453 section 14.9), to force a check with the origin server. | |
4454 | |
4455 If a cache has two fresh responses for the same representation with | |
4456 different validators, it MUST use the one with the more recent Date | |
4457 header. This situation may arise because the cache is pooling | |
4458 responses from other caches, or because a client has asked for a | |
4459 reload or a revalidation of an apparently fresh cache entry. | |
4460 | |
4461 13.2.6 Disambiguating Multiple Responses | |
4462 | |
4463 Because a client may be receiving responses via multiple paths, so | |
4464 that some responses flow through one set of caches and other | |
4465 responses flow through a different set of caches, a client may | |
4466 receive responses in an order different from that in which the origin | |
4467 server sent them. We would like the client to use the most recently | |
4468 generated response, even if older responses are still apparently | |
4469 fresh. | |
4470 | |
4471 Neither the entity tag nor the expiration value can impose an | |
4472 ordering on responses, since it is possible that a later response | |
4473 intentionally carries an earlier expiration time. However, the | |
4474 HTTP/1.1 specification requires the transmission of Date headers on | |
4475 every response, and the Date values are ordered to a granularity of | |
4476 one second. | |
4477 | |
4478 | |
4479 | |
4480 | |
4481 | |
4482 Fielding, et. al. Standards Track [Page 80] | |
4483 | |
4484 RFC 2068 HTTP/1.1 January 1997 | |
4485 | |
4486 | |
4487 When a client tries to revalidate a cache entry, and the response it | |
4488 receives contains a Date header that appears to be older than the one | |
4489 for the existing entry, then the client SHOULD repeat the request | |
4490 unconditionally, and include | |
4491 | |
4492 Cache-Control: max-age=0 | |
4493 | |
4494 to force any intermediate caches to validate their copies directly | |
4495 with the origin server, or | |
4496 | |
4497 Cache-Control: no-cache | |
4498 | |
4499 to force any intermediate caches to obtain a new copy from the origin | |
4500 server. | |
4501 | |
4502 If the Date values are equal, then the client may use either response | |
4503 (or may, if it is being extremely prudent, request a new response). | |
4504 Servers MUST NOT depend on clients being able to choose | |
4505 deterministically between responses generated during the same second, | |
4506 if their expiration times overlap. | |
4507 | |
4508 13.3 Validation Model | |
4509 | |
4510 When a cache has a stale entry that it would like to use as a | |
4511 response to a client's request, it first has to check with the origin | |
4512 server (or possibly an intermediate cache with a fresh response) to | |
4513 see if its cached entry is still usable. We call this "validating" | |
4514 the cache entry. Since we do not want to have to pay the overhead of | |
4515 retransmitting the full response if the cached entry is good, and we | |
4516 do not want to pay the overhead of an extra round trip if the cached | |
4517 entry is invalid, the HTTP/1.1 protocol supports the use of | |
4518 conditional methods. | |
4519 | |
4520 The key protocol features for supporting conditional methods are | |
4521 those concerned with "cache validators." When an origin server | |
4522 generates a full response, it attaches some sort of validator to it, | |
4523 which is kept with the cache entry. When a client (user agent or | |
4524 proxy cache) makes a conditional request for a resource for which it | |
4525 has a cache entry, it includes the associated validator in the | |
4526 request. | |
4527 | |
4528 The server then checks that validator against the current validator | |
4529 for the entity, and, if they match, it responds with a special status | |
4530 code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it | |
4531 returns a full response (including entity-body). Thus, we avoid | |
4532 transmitting the full response if the validator matches, and we avoid | |
4533 an extra round trip if it does not match. | |
4534 | |
4535 | |
4536 | |
4537 | |
4538 Fielding, et. al. Standards Track [Page 81] | |
4539 | |
4540 RFC 2068 HTTP/1.1 January 1997 | |
4541 | |
4542 | |
4543 Note: the comparison functions used to decide if validators match | |
4544 are defined in section 13.3.3. | |
4545 | |
4546 In HTTP/1.1, a conditional request looks exactly the same as a normal | |
4547 request for the same resource, except that it carries a special | |
4548 header (which includes the validator) that implicitly turns the | |
4549 method (usually, GET) into a conditional. | |
4550 | |
4551 The protocol includes both positive and negative senses of cache- | |
4552 validating conditions. That is, it is possible to request either that | |
4553 a method be performed if and only if a validator matches or if and | |
4554 only if no validators match. | |
4555 | |
4556 Note: a response that lacks a validator may still be cached, and | |
4557 served from cache until it expires, unless this is explicitly | |
4558 prohibited by a Cache-Control directive. However, a cache cannot do | |
4559 a conditional retrieval if it does not have a validator for the | |
4560 entity, which means it will not be refreshable after it expires. | |
4561 | |
4562 13.3.1 Last-modified Dates | |
4563 | |
4564 The Last-Modified entity-header field value is often used as a cache | |
4565 validator. In simple terms, a cache entry is considered to be valid | |
4566 if the entity has not been modified since the Last-Modified value. | |
4567 | |
4568 13.3.2 Entity Tag Cache Validators | |
4569 | |
4570 The ETag entity-header field value, an entity tag, provides for an | |
4571 "opaque" cache validator. This may allow more reliable validation in | |
4572 situations where it is inconvenient to store modification dates, | |
4573 where the one-second resolution of HTTP date values is not | |
4574 sufficient, or where the origin server wishes to avoid certain | |
4575 paradoxes that may arise from the use of modification dates. | |
4576 | |
4577 Entity Tags are described in section 3.11. The headers used with | |
4578 entity tags are described in sections 14.20, 14.25, 14.26 and 14.43. | |
4579 | |
4580 13.3.3 Weak and Strong Validators | |
4581 | |
4582 Since both origin servers and caches will compare two validators to | |
4583 decide if they represent the same or different entities, one normally | |
4584 would expect that if the entity (the entity-body or any entity- | |
4585 headers) changes in any way, then the associated validator would | |
4586 change as well. If this is true, then we call this validator a | |
4587 "strong validator." | |
4588 | |
4589 However, there may be cases when a server prefers to change the | |
4590 validator only on semantically significant changes, and not when | |
4591 | |
4592 | |
4593 | |
4594 Fielding, et. al. Standards Track [Page 82] | |
4595 | |
4596 RFC 2068 HTTP/1.1 January 1997 | |
4597 | |
4598 | |
4599 insignificant aspects of the entity change. A validator that does not | |
4600 always change when the resource changes is a "weak validator." | |
4601 | |
4602 Entity tags are normally "strong validators," but the protocol | |
4603 provides a mechanism to tag an entity tag as "weak." One can think of | |
4604 a strong validator as one that changes whenever the bits of an entity | |
4605 changes, while a weak value changes whenever the meaning of an entity | |
4606 changes. Alternatively, one can think of a strong validator as part | |
4607 of an identifier for a specific entity, while a weak validator is | |
4608 part of an identifier for a set of semantically equivalent entities. | |
4609 | |
4610 Note: One example of a strong validator is an integer that is | |
4611 incremented in stable storage every time an entity is changed. | |
4612 | |
4613 An entity's modification time, if represented with one-second | |
4614 resolution, could be a weak validator, since it is possible that | |
4615 the resource may be modified twice during a single second. | |
4616 | |
4617 Support for weak validators is optional; however, weak validators | |
4618 allow for more efficient caching of equivalent objects; for | |
4619 example, a hit counter on a site is probably good enough if it is | |
4620 updated every few days or weeks, and any value during that period | |
4621 is likely "good enough" to be equivalent. | |
4622 | |
4623 A "use" of a validator is either when a client generates a request | |
4624 and includes the validator in a validating header field, or when a | |
4625 server compares two validators. | |
4626 | |
4627 Strong validators are usable in any context. Weak validators are only | |
4628 usable in contexts that do not depend on exact equality of an entity. | |
4629 For example, either kind is usable for a conditional GET of a full | |
4630 entity. However, only a strong validator is usable for a sub-range | |
4631 retrieval, since otherwise the client may end up with an internally | |
4632 inconsistent entity. | |
4633 | |
4634 The only function that the HTTP/1.1 protocol defines on validators is | |
4635 comparison. There are two validator comparison functions, depending | |
4636 on whether the comparison context allows the use of weak validators | |
4637 or not: | |
4638 | |
4639 o The strong comparison function: in order to be considered equal, | |
4640 both validators must be identical in every way, and neither may be | |
4641 weak. | |
4642 o The weak comparison function: in order to be considered equal, both | |
4643 validators must be identical in every way, but either or both of | |
4644 them may be tagged as "weak" without affecting the result. | |
4645 | |
4646 The weak comparison function MAY be used for simple (non-subrange) | |
4647 | |
4648 | |
4649 | |
4650 Fielding, et. al. Standards Track [Page 83] | |
4651 | |
4652 RFC 2068 HTTP/1.1 January 1997 | |
4653 | |
4654 | |
4655 GET requests. The strong comparison function MUST be used in all | |
4656 other cases. | |
4657 | |
4658 An entity tag is strong unless it is explicitly tagged as weak. | |
4659 Section 3.11 gives the syntax for entity tags. | |
4660 | |
4661 A Last-Modified time, when used as a validator in a request, is | |
4662 implicitly weak unless it is possible to deduce that it is strong, | |
4663 using the following rules: | |
4664 | |
4665 o The validator is being compared by an origin server to the actual | |
4666 current validator for the entity and, | |
4667 o That origin server reliably knows that the associated entity did | |
4668 not change twice during the second covered by the presented | |
4669 validator. | |
4670 or | |
4671 | |
4672 o The validator is about to be used by a client in an If-Modified- | |
4673 Since or If-Unmodified-Since header, because the client has a cache | |
4674 entry for the associated entity, and | |
4675 o That cache entry includes a Date value, which gives the time when | |
4676 the origin server sent the original response, and | |
4677 o The presented Last-Modified time is at least 60 seconds before the | |
4678 Date value. | |
4679 or | |
4680 | |
4681 o The validator is being compared by an intermediate cache to the | |
4682 validator stored in its cache entry for the entity, and | |
4683 o That cache entry includes a Date value, which gives the time when | |
4684 the origin server sent the original response, and | |
4685 o The presented Last-Modified time is at least 60 seconds before the | |
4686 Date value. | |
4687 | |
4688 This method relies on the fact that if two different responses were | |
4689 sent by the origin server during the same second, but both had the | |
4690 same Last-Modified time, then at least one of those responses would | |
4691 have a Date value equal to its Last-Modified time. The arbitrary 60- | |
4692 second limit guards against the possibility that the Date and Last- | |
4693 Modified values are generated from different clocks, or at somewhat | |
4694 different times during the preparation of the response. An | |
4695 implementation may use a value larger than 60 seconds, if it is | |
4696 believed that 60 seconds is too short. | |
4697 | |
4698 If a client wishes to perform a sub-range retrieval on a value for | |
4699 which it has only a Last-Modified time and no opaque validator, it | |
4700 may do this only if the Last-Modified time is strong in the sense | |
4701 described here. | |
4702 | |
4703 | |
4704 | |
4705 | |
4706 Fielding, et. al. Standards Track [Page 84] | |
4707 | |
4708 RFC 2068 HTTP/1.1 January 1997 | |
4709 | |
4710 | |
4711 A cache or origin server receiving a cache-conditional request, other | |
4712 than a full-body GET request, MUST use the strong comparison function | |
4713 to evaluate the condition. | |
4714 | |
4715 These rules allow HTTP/1.1 caches and clients to safely perform sub- | |
4716 range retrievals on values that have been obtained from HTTP/1.0 | |
4717 servers. | |
4718 | |
4719 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates | |
4720 | |
4721 We adopt a set of rules and recommendations for origin servers, | |
4722 clients, and caches regarding when various validator types should be | |
4723 used, and for what purposes. | |
4724 | |
4725 HTTP/1.1 origin servers: | |
4726 | |
4727 o SHOULD send an entity tag validator unless it is not feasible to | |
4728 generate one. | |
4729 o MAY send a weak entity tag instead of a strong entity tag, if | |
4730 performance considerations support the use of weak entity tags, or | |
4731 if it is unfeasible to send a strong entity tag. | |
4732 o SHOULD send a Last-Modified value if it is feasible to send one, | |
4733 unless the risk of a breakdown in semantic transparency that could | |
4734 result from using this date in an If-Modified-Since header would | |
4735 lead to serious problems. | |
4736 | |
4737 In other words, the preferred behavior for an HTTP/1.1 origin server | |
4738 is to send both a strong entity tag and a Last-Modified value. | |
4739 | |
4740 In order to be legal, a strong entity tag MUST change whenever the | |
4741 associated entity value changes in any way. A weak entity tag SHOULD | |
4742 change whenever the associated entity changes in a semantically | |
4743 significant way. | |
4744 | |
4745 Note: in order to provide semantically transparent caching, an | |
4746 origin server must avoid reusing a specific strong entity tag value | |
4747 for two different entities, or reusing a specific weak entity tag | |
4748 value for two semantically different entities. Cache entries may | |
4749 persist for arbitrarily long periods, regardless of expiration | |
4750 times, so it may be inappropriate to expect that a cache will never | |
4751 again attempt to validate an entry using a validator that it | |
4752 obtained at some point in the past. | |
4753 | |
4754 HTTP/1.1 clients: | |
4755 | |
4756 o If an entity tag has been provided by the origin server, MUST | |
4757 use that entity tag in any cache-conditional request (using | |
4758 If-Match or If-None-Match). | |
4759 | |
4760 | |
4761 | |
4762 Fielding, et. al. Standards Track [Page 85] | |
4763 | |
4764 RFC 2068 HTTP/1.1 January 1997 | |
4765 | |
4766 | |
4767 o If only a Last-Modified value has been provided by the origin | |
4768 server, SHOULD use that value in non-subrange cache-conditional | |
4769 requests (using If-Modified-Since). | |
4770 o If only a Last-Modified value has been provided by an HTTP/1.0 | |
4771 origin server, MAY use that value in subrange cache-conditional | |
4772 requests (using If-Unmodified-Since:). The user agent should | |
4773 provide a way to disable this, in case of difficulty. | |
4774 o If both an entity tag and a Last-Modified value have been | |
4775 provided by the origin server, SHOULD use both validators in | |
4776 cache-conditional requests. This allows both HTTP/1.0 and | |
4777 HTTP/1.1 caches to respond appropriately. | |
4778 | |
4779 An HTTP/1.1 cache, upon receiving a request, MUST use the most | |
4780 restrictive validator when deciding whether the client's cache entry | |
4781 matches the cache's own cache entry. This is only an issue when the | |
4782 request contains both an entity tag and a last-modified-date | |
4783 validator (If-Modified-Since or If-Unmodified-Since). | |
4784 | |
4785 A note on rationale: The general principle behind these rules is | |
4786 that HTTP/1.1 servers and clients should transmit as much non- | |
4787 redundant information as is available in their responses and | |
4788 requests. HTTP/1.1 systems receiving this information will make the | |
4789 most conservative assumptions about the validators they receive. | |
4790 | |
4791 HTTP/1.0 clients and caches will ignore entity tags. Generally, | |
4792 last-modified values received or used by these systems will support | |
4793 transparent and efficient caching, and so HTTP/1.1 origin servers | |
4794 should provide Last-Modified values. In those rare cases where the | |
4795 use of a Last-Modified value as a validator by an HTTP/1.0 system | |
4796 could result in a serious problem, then HTTP/1.1 origin servers | |
4797 should not provide one. | |
4798 | |
4799 13.3.5 Non-validating Conditionals | |
4800 | |
4801 The principle behind entity tags is that only the service author | |
4802 knows the semantics of a resource well enough to select an | |
4803 appropriate cache validation mechanism, and the specification of any | |
4804 validator comparison function more complex than byte-equality would | |
4805 open up a can of worms. Thus, comparisons of any other headers | |
4806 (except Last-Modified, for compatibility with HTTP/1.0) are never | |
4807 used for purposes of validating a cache entry. | |
4808 | |
4809 13.4 Response Cachability | |
4810 | |
4811 Unless specifically constrained by a Cache-Control (section 14.9) | |
4812 directive, a caching system may always store a successful response | |
4813 (see section 13.8) as a cache entry, may return it without validation | |
4814 if it is fresh, and may return it after successful validation. If | |
4815 | |
4816 | |
4817 | |
4818 Fielding, et. al. Standards Track [Page 86] | |
4819 | |
4820 RFC 2068 HTTP/1.1 January 1997 | |
4821 | |
4822 | |
4823 there is neither a cache validator nor an explicit expiration time | |
4824 associated with a response, we do not expect it to be cached, but | |
4825 certain caches may violate this expectation (for example, when little | |
4826 or no network connectivity is available). A client can usually detect | |
4827 that such a response was taken from a cache by comparing the Date | |
4828 header to the current time. | |
4829 | |
4830 Note that some HTTP/1.0 caches are known to violate this | |
4831 expectation without providing any Warning. | |
4832 | |
4833 However, in some cases it may be inappropriate for a cache to retain | |
4834 an entity, or to return it in response to a subsequent request. This | |
4835 may be because absolute semantic transparency is deemed necessary by | |
4836 the service author, or because of security or privacy considerations. | |
4837 Certain Cache-Control directives are therefore provided so that the | |
4838 server can indicate that certain resource entities, or portions | |
4839 thereof, may not be cached regardless of other considerations. | |
4840 | |
4841 Note that section 14.8 normally prevents a shared cache from saving | |
4842 and returning a response to a previous request if that request | |
4843 included an Authorization header. | |
4844 | |
4845 A response received with a status code of 200, 203, 206, 300, 301 or | |
4846 410 may be stored by a cache and used in reply to a subsequent | |
4847 request, subject to the expiration mechanism, unless a Cache-Control | |
4848 directive prohibits caching. However, a cache that does not support | |
4849 the Range and Content-Range headers MUST NOT cache 206 (Partial | |
4850 Content) responses. | |
4851 | |
4852 A response received with any other status code MUST NOT be returned | |
4853 in a reply to a subsequent request unless there are Cache-Control | |
4854 directives or another header(s) that explicitly allow it. For | |
4855 example, these include the following: an Expires header (section | |
4856 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public" | |
4857 or "private" Cache-Control directive (section 14.9). | |
4858 | |
4859 13.5 Constructing Responses From Caches | |
4860 | |
4861 The purpose of an HTTP cache is to store information received in | |
4862 response to requests, for use in responding to future requests. In | |
4863 many cases, a cache simply returns the appropriate parts of a | |
4864 response to the requester. However, if the cache holds a cache entry | |
4865 based on a previous response, it may have to combine parts of a new | |
4866 response with what is held in the cache entry. | |
4867 | |
4868 | |
4869 | |
4870 | |
4871 | |
4872 | |
4873 | |
4874 Fielding, et. al. Standards Track [Page 87] | |
4875 | |
4876 RFC 2068 HTTP/1.1 January 1997 | |
4877 | |
4878 | |
4879 13.5.1 End-to-end and Hop-by-hop Headers | |
4880 | |
4881 For the purpose of defining the behavior of caches and non-caching | |
4882 proxies, we divide HTTP headers into two categories: | |
4883 | |
4884 o End-to-end headers, which must be transmitted to the | |
4885 ultimate recipient of a request or response. End-to-end | |
4886 headers in responses must be stored as part of a cache entry | |
4887 and transmitted in any response formed from a cache entry. | |
4888 o Hop-by-hop headers, which are meaningful only for a single | |
4889 transport-level connection, and are not stored by caches or | |
4890 forwarded by proxies. | |
4891 | |
4892 The following HTTP/1.1 headers are hop-by-hop headers: | |
4893 | |
4894 o Connection | |
4895 o Keep-Alive | |
4896 o Public | |
4897 o Proxy-Authenticate | |
4898 o Transfer-Encoding | |
4899 o Upgrade | |
4900 | |
4901 All other headers defined by HTTP/1.1 are end-to-end headers. | |
4902 | |
4903 Hop-by-hop headers introduced in future versions of HTTP MUST be | |
4904 listed in a Connection header, as described in section 14.10. | |
4905 | |
4906 13.5.2 Non-modifiable Headers | |
4907 | |
4908 Some features of the HTTP/1.1 protocol, such as Digest | |
4909 Authentication, depend on the value of certain end-to-end headers. A | |
4910 cache or non-caching proxy SHOULD NOT modify an end-to-end header | |
4911 unless the definition of that header requires or specifically allows | |
4912 that. | |
4913 | |
4914 A cache or non-caching proxy MUST NOT modify any of the following | |
4915 fields in a request or response, nor may it add any of these fields | |
4916 if not already present: | |
4917 | |
4918 o Content-Location | |
4919 o ETag | |
4920 o Expires | |
4921 o Last-Modified | |
4922 | |
4923 | |
4924 | |
4925 | |
4926 | |
4927 | |
4928 | |
4929 | |
4930 Fielding, et. al. Standards Track [Page 88] | |
4931 | |
4932 RFC 2068 HTTP/1.1 January 1997 | |
4933 | |
4934 | |
4935 A cache or non-caching proxy MUST NOT modify or add any of the | |
4936 following fields in a response that contains the no-transform Cache- | |
4937 Control directive, or in any request: | |
4938 | |
4939 o Content-Encoding | |
4940 o Content-Length | |
4941 o Content-Range | |
4942 o Content-Type | |
4943 | |
4944 A cache or non-caching proxy MAY modify or add these fields in a | |
4945 response that does not include no-transform, but if it does so, it | |
4946 MUST add a Warning 14 (Transformation applied) if one does not | |
4947 already appear in the response. | |
4948 | |
4949 Warning: unnecessary modification of end-to-end headers may cause | |
4950 authentication failures if stronger authentication mechanisms are | |
4951 introduced in later versions of HTTP. Such authentication | |
4952 mechanisms may rely on the values of header fields not listed here. | |
4953 | |
4954 13.5.3 Combining Headers | |
4955 | |
4956 When a cache makes a validating request to a server, and the server | |
4957 provides a 304 (Not Modified) response, the cache must construct a | |
4958 response to send to the requesting client. The cache uses the | |
4959 entity-body stored in the cache entry as the entity-body of this | |
4960 outgoing response. The end-to-end headers stored in the cache entry | |
4961 are used for the constructed response, except that any end-to-end | |
4962 headers provided in the 304 response MUST replace the corresponding | |
4963 headers from the cache entry. Unless the cache decides to remove the | |
4964 cache entry, it MUST also replace the end-to-end headers stored with | |
4965 the cache entry with corresponding headers received in the incoming | |
4966 response. | |
4967 | |
4968 In other words, the set of end-to-end headers received in the | |
4969 incoming response overrides all corresponding end-to-end headers | |
4970 stored with the cache entry. The cache may add Warning headers (see | |
4971 section 14.45) to this set. | |
4972 | |
4973 If a header field-name in the incoming response matches more than one | |
4974 header in the cache entry, all such old headers are replaced. | |
4975 | |
4976 Note: this rule allows an origin server to use a 304 (Not Modified) | |
4977 response to update any header associated with a previous response | |
4978 for the same entity, although it might not always be meaningful or | |
4979 correct to do so. This rule does not allow an origin server to use | |
4980 a 304 (not Modified) response to entirely delete a header that it | |
4981 had provided with a previous response. | |
4982 | |
4983 | |
4984 | |
4985 | |
4986 Fielding, et. al. Standards Track [Page 89] | |
4987 | |
4988 RFC 2068 HTTP/1.1 January 1997 | |
4989 | |
4990 | |
4991 13.5.4 Combining Byte Ranges | |
4992 | |
4993 A response may transfer only a subrange of the bytes of an entity- | |
4994 body, either because the request included one or more Range | |
4995 specifications, or because a connection was broken prematurely. After | |
4996 several such transfers, a cache may have received several ranges of | |
4997 the same entity-body. | |
4998 | |
4999 If a cache has a stored non-empty set of subranges for an entity, and | |
5000 an incoming response transfers another subrange, the cache MAY | |
5001 combine the new subrange with the existing set if both the following | |
5002 conditions are met: | |
5003 | |
5004 o Both the incoming response and the cache entry must have a cache | |
5005 validator. | |
5006 o The two cache validators must match using the strong comparison | |
5007 function (see section 13.3.3). | |
5008 | |
5009 If either requirement is not meant, the cache must use only the most | |
5010 recent partial response (based on the Date values transmitted with | |
5011 every response, and using the incoming response if these values are | |
5012 equal or missing), and must discard the other partial information. | |
5013 | |
5014 13.6 Caching Negotiated Responses | |
5015 | |
5016 Use of server-driven content negotiation (section 12), as indicated | |
5017 by the presence of a Vary header field in a response, alters the | |
5018 conditions and procedure by which a cache can use the response for | |
5019 subsequent requests. | |
5020 | |
5021 A server MUST use the Vary header field (section 14.43) to inform a | |
5022 cache of what header field dimensions are used to select among | |
5023 multiple representations of a cachable response. A cache may use the | |
5024 selected representation (the entity included with that particular | |
5025 response) for replying to subsequent requests on that resource only | |
5026 when the subsequent requests have the same or equivalent values for | |
5027 all header fields specified in the Vary response-header. Requests | |
5028 with a different value for one or more of those header fields would | |
5029 be forwarded toward the origin server. | |
5030 | |
5031 If an entity tag was assigned to the representation, the forwarded | |
5032 request SHOULD be conditional and include the entity tags in an If- | |
5033 None-Match header field from all its cache entries for the Request- | |
5034 URI. This conveys to the server the set of entities currently held by | |
5035 the cache, so that if any one of these entities matches the requested | |
5036 entity, the server can use the ETag header in its 304 (Not Modified) | |
5037 response to tell the cache which entry is appropriate. If the | |
5038 entity-tag of the new response matches that of an existing entry, the | |
5039 | |
5040 | |
5041 | |
5042 Fielding, et. al. Standards Track [Page 90] | |
5043 | |
5044 RFC 2068 HTTP/1.1 January 1997 | |
5045 | |
5046 | |
5047 new response SHOULD be used to update the header fields of the | |
5048 existing entry, and the result MUST be returned to the client. | |
5049 | |
5050 The Vary header field may also inform the cache that the | |
5051 representation was selected using criteria not limited to the | |
5052 request-headers; in this case, a cache MUST NOT use the response in a | |
5053 reply to a subsequent request unless the cache relays the new request | |
5054 to the origin server in a conditional request and the server responds | |
5055 with 304 (Not Modified), including an entity tag or Content-Location | |
5056 that indicates which entity should be used. | |
5057 | |
5058 If any of the existing cache entries contains only partial content | |
5059 for the associated entity, its entity-tag SHOULD NOT be included in | |
5060 the If-None-Match header unless the request is for a range that would | |
5061 be fully satisfied by that entry. | |
5062 | |
5063 If a cache receives a successful response whose Content-Location | |
5064 field matches that of an existing cache entry for the same Request- | |
5065 URI, whose entity-tag differs from that of the existing entry, and | |
5066 whose Date is more recent than that of the existing entry, the | |
5067 existing entry SHOULD NOT be returned in response to future requests, | |
5068 and should be deleted from the cache. | |
5069 | |
5070 13.7 Shared and Non-Shared Caches | |
5071 | |
5072 For reasons of security and privacy, it is necessary to make a | |
5073 distinction between "shared" and "non-shared" caches. A non-shared | |
5074 cache is one that is accessible only to a single user. Accessibility | |
5075 in this case SHOULD be enforced by appropriate security mechanisms. | |
5076 All other caches are considered to be "shared." Other sections of | |
5077 this specification place certain constraints on the operation of | |
5078 shared caches in order to prevent loss of privacy or failure of | |
5079 access controls. | |
5080 | |
5081 13.8 Errors or Incomplete Response Cache Behavior | |
5082 | |
5083 A cache that receives an incomplete response (for example, with fewer | |
5084 bytes of data than specified in a Content-Length header) may store | |
5085 the response. However, the cache MUST treat this as a partial | |
5086 response. Partial responses may be combined as described in section | |
5087 13.5.4; the result might be a full response or might still be | |
5088 partial. A cache MUST NOT return a partial response to a client | |
5089 without explicitly marking it as such, using the 206 (Partial | |
5090 Content) status code. A cache MUST NOT return a partial response | |
5091 using a status code of 200 (OK). | |
5092 | |
5093 If a cache receives a 5xx response while attempting to revalidate an | |
5094 entry, it may either forward this response to the requesting client, | |
5095 | |
5096 | |
5097 | |
5098 Fielding, et. al. Standards Track [Page 91] | |
5099 | |
5100 RFC 2068 HTTP/1.1 January 1997 | |
5101 | |
5102 | |
5103 or act as if the server failed to respond. In the latter case, it MAY | |
5104 return a previously received response unless the cached entry | |
5105 includes the "must-revalidate" Cache-Control directive (see section | |
5106 14.9). | |
5107 | |
5108 13.9 Side Effects of GET and HEAD | |
5109 | |
5110 Unless the origin server explicitly prohibits the caching of their | |
5111 responses, the application of GET and HEAD methods to any resources | |
5112 SHOULD NOT have side effects that would lead to erroneous behavior if | |
5113 these responses are taken from a cache. They may still have side | |
5114 effects, but a cache is not required to consider such side effects in | |
5115 its caching decisions. Caches are always expected to observe an | |
5116 origin server's explicit restrictions on caching. | |
5117 | |
5118 We note one exception to this rule: since some applications have | |
5119 traditionally used GETs and HEADs with query URLs (those containing a | |
5120 "?" in the rel_path part) to perform operations with significant side | |
5121 effects, caches MUST NOT treat responses to such URLs as fresh unless | |
5122 the server provides an explicit expiration time. This specifically | |
5123 means that responses from HTTP/1.0 servers for such URIs should not | |
5124 be taken from a cache. See section 9.1.1 for related information. | |
5125 | |
5126 13.10 Invalidation After Updates or Deletions | |
5127 | |
5128 The effect of certain methods at the origin server may cause one or | |
5129 more existing cache entries to become non-transparently invalid. That | |
5130 is, although they may continue to be "fresh," they do not accurately | |
5131 reflect what the origin server would return for a new request. | |
5132 | |
5133 There is no way for the HTTP protocol to guarantee that all such | |
5134 cache entries are marked invalid. For example, the request that | |
5135 caused the change at the origin server may not have gone through the | |
5136 proxy where a cache entry is stored. However, several rules help | |
5137 reduce the likelihood of erroneous behavior. | |
5138 | |
5139 In this section, the phrase "invalidate an entity" means that the | |
5140 cache should either remove all instances of that entity from its | |
5141 storage, or should mark these as "invalid" and in need of a mandatory | |
5142 revalidation before they can be returned in response to a subsequent | |
5143 request. | |
5144 | |
5145 | |
5146 | |
5147 | |
5148 | |
5149 | |
5150 | |
5151 | |
5152 | |
5153 | |
5154 Fielding, et. al. Standards Track [Page 92] | |
5155 | |
5156 RFC 2068 HTTP/1.1 January 1997 | |
5157 | |
5158 | |
5159 Some HTTP methods may invalidate an entity. This is either the entity | |
5160 referred to by the Request-URI, or by the Location or Content- | |
5161 Location response-headers (if present). These methods are: | |
5162 | |
5163 o PUT | |
5164 o DELETE | |
5165 o POST | |
5166 | |
5167 In order to prevent denial of service attacks, an invalidation based | |
5168 on the URI in a Location or Content-Location header MUST only be | |
5169 performed if the host part is the same as in the Request-URI. | |
5170 | |
5171 13.11 Write-Through Mandatory | |
5172 | |
5173 All methods that may be expected to cause modifications to the origin | |
5174 server's resources MUST be written through to the origin server. This | |
5175 currently includes all methods except for GET and HEAD. A cache MUST | |
5176 NOT reply to such a request from a client before having transmitted | |
5177 the request to the inbound server, and having received a | |
5178 corresponding response from the inbound server. This does not prevent | |
5179 a cache from sending a 100 (Continue) response before the inbound | |
5180 server has replied. | |
5181 | |
5182 The alternative (known as "write-back" or "copy-back" caching) is not | |
5183 allowed in HTTP/1.1, due to the difficulty of providing consistent | |
5184 updates and the problems arising from server, cache, or network | |
5185 failure prior to write-back. | |
5186 | |
5187 13.12 Cache Replacement | |
5188 | |
5189 If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) | |
5190 response is received from a resource while any existing responses for | |
5191 the same resource are cached, the cache SHOULD use the new response | |
5192 to reply to the current request. It may insert it into cache storage | |
5193 and may, if it meets all other requirements, use it to respond to any | |
5194 future requests that would previously have caused the old response to | |
5195 be returned. If it inserts the new response into cache storage it | |
5196 should follow the rules in section 13.5.3. | |
5197 | |
5198 Note: a new response that has an older Date header value than | |
5199 existing cached responses is not cachable. | |
5200 | |
5201 13.13 History Lists | |
5202 | |
5203 User agents often have history mechanisms, such as "Back" buttons and | |
5204 history lists, which can be used to redisplay an entity retrieved | |
5205 earlier in a session. | |
5206 | |
5207 | |
5208 | |
5209 | |
5210 Fielding, et. al. Standards Track [Page 93] | |
5211 | |
5212 RFC 2068 HTTP/1.1 January 1997 | |
5213 | |
5214 | |
5215 History mechanisms and caches are different. In particular history | |
5216 mechanisms SHOULD NOT try to show a semantically transparent view of | |
5217 the current state of a resource. Rather, a history mechanism is meant | |
5218 to show exactly what the user saw at the time when the resource was | |
5219 retrieved. | |
5220 | |
5221 By default, an expiration time does not apply to history mechanisms. | |
5222 If the entity is still in storage, a history mechanism should display | |
5223 it even if the entity has expired, unless the user has specifically | |
5224 configured the agent to refresh expired history documents. | |
5225 | |
5226 This should not be construed to prohibit the history mechanism from | |
5227 telling the user that a view may be stale. | |
5228 | |
5229 Note: if history list mechanisms unnecessarily prevent users from | |
5230 viewing stale resources, this will tend to force service authors to | |
5231 avoid using HTTP expiration controls and cache controls when they | |
5232 would otherwise like to. Service authors may consider it important | |
5233 that users not be presented with error messages or warning messages | |
5234 when they use navigation controls (such as BACK) to view previously | |
5235 fetched resources. Even though sometimes such resources ought not | |
5236 to cached, or ought to expire quickly, user interface | |
5237 considerations may force service authors to resort to other means | |
5238 of preventing caching (e.g. "once-only" URLs) in order not to | |
5239 suffer the effects of improperly functioning history mechanisms. | |
5240 | |
5241 14 Header Field Definitions | |
5242 | |
5243 This section defines the syntax and semantics of all standard | |
5244 HTTP/1.1 header fields. For entity-header fields, both sender and | |
5245 recipient refer to either the client or the server, depending on who | |
5246 sends and who receives the entity. | |
5247 | |
5248 | |
5249 | |
5250 | |
5251 | |
5252 | |
5253 | |
5254 | |
5255 | |
5256 | |
5257 | |
5258 | |
5259 | |
5260 | |
5261 | |
5262 | |
5263 | |
5264 | |
5265 | |
5266 Fielding, et. al. Standards Track [Page 94] | |
5267 | |
5268 RFC 2068 HTTP/1.1 January 1997 | |
5269 | |
5270 | |
5271 14.1 Accept | |
5272 | |
5273 The Accept request-header field can be used to specify certain media | |
5274 types which are acceptable for the response. Accept headers can be | |
5275 used to indicate that the request is specifically limited to a small | |
5276 set of desired types, as in the case of a request for an in-line | |
5277 image. | |
5278 | |
5279 Accept = "Accept" ":" | |
5280 #( media-range [ accept-params ] ) | |
5281 | |
5282 media-range = ( "*/*" | |
5283 | ( type "/" "*" ) | |
5284 | ( type "/" subtype ) | |
5285 ) *( ";" parameter ) | |
5286 | |
5287 accept-params = ";" "q" "=" qvalue *( accept-extension ) | |
5288 | |
5289 accept-extension = ";" token [ "=" ( token | quoted-string ) ] | |
5290 | |
5291 The asterisk "*" character is used to group media types into ranges, | |
5292 with "*/*" indicating all media types and "type/*" indicating all | |
5293 subtypes of that type. The media-range MAY include media type | |
5294 parameters that are applicable to that range. | |
5295 | |
5296 Each media-range MAY be followed by one or more accept-params, | |
5297 beginning with the "q" parameter for indicating a relative quality | |
5298 factor. The first "q" parameter (if any) separates the media-range | |
5299 parameter(s) from the accept-params. Quality factors allow the user | |
5300 or user agent to indicate the relative degree of preference for that | |
5301 media-range, using the qvalue scale from 0 to 1 (section 3.9). The | |
5302 default value is q=1. | |
5303 | |
5304 Note: Use of the "q" parameter name to separate media type | |
5305 parameters from Accept extension parameters is due to historical | |
5306 practice. Although this prevents any media type parameter named | |
5307 "q" from being used with a media range, such an event is believed | |
5308 to be unlikely given the lack of any "q" parameters in the IANA | |
5309 media type registry and the rare usage of any media type parameters | |
5310 in Accept. Future media types should be discouraged from | |
5311 registering any parameter named "q". | |
5312 | |
5313 The example | |
5314 | |
5315 Accept: audio/*; q=0.2, audio/basic | |
5316 | |
5317 SHOULD be interpreted as "I prefer audio/basic, but send me any audio | |
5318 type if it is the best available after an 80% mark-down in quality." | |
5319 | |
5320 | |
5321 | |
5322 Fielding, et. al. Standards Track [Page 95] | |
5323 | |
5324 RFC 2068 HTTP/1.1 January 1997 | |
5325 | |
5326 | |
5327 If no Accept header field is present, then it is assumed that the | |
5328 client accepts all media types. If an Accept header field is present, | |
5329 and if the server cannot send a response which is acceptable | |
5330 according to the combined Accept field value, then the server SHOULD | |
5331 send a 406 (not acceptable) response. | |
5332 | |
5333 A more elaborate example is | |
5334 | |
5335 Accept: text/plain; q=0.5, text/html, | |
5336 text/x-dvi; q=0.8, text/x-c | |
5337 | |
5338 Verbally, this would be interpreted as "text/html and text/x-c are | |
5339 the preferred media types, but if they do not exist, then send the | |
5340 text/x-dvi entity, and if that does not exist, send the text/plain | |
5341 entity." | |
5342 | |
5343 Media ranges can be overridden by more specific media ranges or | |
5344 specific media types. If more than one media range applies to a given | |
5345 type, the most specific reference has precedence. For example, | |
5346 | |
5347 Accept: text/*, text/html, text/html;level=1, */* | |
5348 | |
5349 have the following precedence: | |
5350 | |
5351 1) text/html;level=1 | |
5352 2) text/html | |
5353 3) text/* | |
5354 4) */* | |
5355 | |
5356 The media type quality factor associated with a given type is | |
5357 determined by finding the media range with the highest precedence | |
5358 which matches that type. For example, | |
5359 | |
5360 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, | |
5361 text/html;level=2;q=0.4, */*;q=0.5 | |
5362 | |
5363 would cause the following values to be associated: | |
5364 | |
5365 text/html;level=1 = 1 | |
5366 text/html = 0.7 | |
5367 text/plain = 0.3 | |
5368 image/jpeg = 0.5 | |
5369 text/html;level=2 = 0.4 | |
5370 text/html;level=3 = 0.7 | |
5371 | |
5372 Note: A user agent may be provided with a default set of quality | |
5373 values for certain media ranges. However, unless the user agent is | |
5374 a closed system which cannot interact with other rendering agents, | |
5375 | |
5376 | |
5377 | |
5378 Fielding, et. al. Standards Track [Page 96] | |
5379 | |
5380 RFC 2068 HTTP/1.1 January 1997 | |
5381 | |
5382 | |
5383 this default set should be configurable by the user. | |
5384 | |
5385 14.2 Accept-Charset | |
5386 | |
5387 The Accept-Charset request-header field can be used to indicate what | |
5388 character sets are acceptable for the response. This field allows | |
5389 clients capable of understanding more comprehensive or special- | |
5390 purpose character sets to signal that capability to a server which is | |
5391 capable of representing documents in those character sets. The ISO- | |
5392 8859-1 character set can be assumed to be acceptable to all user | |
5393 agents. | |
5394 | |
5395 Accept-Charset = "Accept-Charset" ":" | |
5396 1#( charset [ ";" "q" "=" qvalue ] ) | |
5397 | |
5398 Character set values are described in section 3.4. Each charset may | |
5399 be given an associated quality value which represents the user's | |
5400 preference for that charset. The default value is q=1. An example is | |
5401 | |
5402 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | |
5403 | |
5404 If no Accept-Charset header is present, the default is that any | |
5405 character set is acceptable. If an Accept-Charset header is present, | |
5406 and if the server cannot send a response which is acceptable | |
5407 according to the Accept-Charset header, then the server SHOULD send | |
5408 an error response with the 406 (not acceptable) status code, though | |
5409 the sending of an unacceptable response is also allowed. | |
5410 | |
5411 14.3 Accept-Encoding | |
5412 | |
5413 The Accept-Encoding request-header field is similar to Accept, but | |
5414 restricts the content-coding values (section 14.12) which are | |
5415 acceptable in the response. | |
5416 | |
5417 Accept-Encoding = "Accept-Encoding" ":" | |
5418 #( content-coding ) | |
5419 | |
5420 An example of its use is | |
5421 | |
5422 Accept-Encoding: compress, gzip | |
5423 | |
5424 If no Accept-Encoding header is present in a request, the server MAY | |
5425 assume that the client will accept any content coding. If an Accept- | |
5426 Encoding header is present, and if the server cannot send a response | |
5427 which is acceptable according to the Accept-Encoding header, then the | |
5428 server SHOULD send an error response with the 406 (Not Acceptable) | |
5429 status code. | |
5430 | |
5431 | |
5432 | |
5433 | |
5434 Fielding, et. al. Standards Track [Page 97] | |
5435 | |
5436 RFC 2068 HTTP/1.1 January 1997 | |
5437 | |
5438 | |
5439 An empty Accept-Encoding value indicates none are acceptable. | |
5440 | |
5441 14.4 Accept-Language | |
5442 | |
5443 The Accept-Language request-header field is similar to Accept, but | |
5444 restricts the set of natural languages that are preferred as a | |
5445 response to the request. | |
5446 | |
5447 Accept-Language = "Accept-Language" ":" | |
5448 1#( language-range [ ";" "q" "=" qvalue ] ) | |
5449 | |
5450 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |
5451 | |
5452 Each language-range MAY be given an associated quality value which | |
5453 represents an estimate of the user's preference for the languages | |
5454 specified by that range. The quality value defaults to "q=1". For | |
5455 example, | |
5456 | |
5457 Accept-Language: da, en-gb;q=0.8, en;q=0.7 | |
5458 | |
5459 would mean: "I prefer Danish, but will accept British English and | |
5460 other types of English." A language-range matches a language-tag if | |
5461 it exactly equals the tag, or if it exactly equals a prefix of the | |
5462 tag such that the first tag character following the prefix is "-". | |
5463 The special range "*", if present in the Accept-Language field, | |
5464 matches every tag not matched by any other range present in the | |
5465 Accept-Language field. | |
5466 | |
5467 Note: This use of a prefix matching rule does not imply that | |
5468 language tags are assigned to languages in such a way that it is | |
5469 always true that if a user understands a language with a certain | |
5470 tag, then this user will also understand all languages with tags | |
5471 for which this tag is a prefix. The prefix rule simply allows the | |
5472 use of prefix tags if this is the case. | |
5473 | |
5474 The language quality factor assigned to a language-tag by the | |
5475 Accept-Language field is the quality value of the longest language- | |
5476 range in the field that matches the language-tag. If no language- | |
5477 range in the field matches the tag, the language quality factor | |
5478 assigned is 0. If no Accept-Language header is present in the | |
5479 request, the server SHOULD assume that all languages are equally | |
5480 acceptable. If an Accept-Language header is present, then all | |
5481 languages which are assigned a quality factor greater than 0 are | |
5482 acceptable. | |
5483 | |
5484 It may be contrary to the privacy expectations of the user to send an | |
5485 Accept-Language header with the complete linguistic preferences of | |
5486 the user in every request. For a discussion of this issue, see | |
5487 | |
5488 | |
5489 | |
5490 Fielding, et. al. Standards Track [Page 98] | |
5491 | |
5492 RFC 2068 HTTP/1.1 January 1997 | |
5493 | |
5494 | |
5495 section 15.7. | |
5496 | |
5497 Note: As intelligibility is highly dependent on the individual | |
5498 user, it is recommended that client applications make the choice of | |
5499 linguistic preference available to the user. If the choice is not | |
5500 made available, then the Accept-Language header field must not be | |
5501 given in the request. | |
5502 | |
5503 14.5 Accept-Ranges | |
5504 | |
5505 The Accept-Ranges response-header field allows the server to indicate | |
5506 its acceptance of range requests for a resource: | |
5507 | |
5508 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | |
5509 | |
5510 acceptable-ranges = 1#range-unit | "none" | |
5511 | |
5512 Origin servers that accept byte-range requests MAY send | |
5513 | |
5514 Accept-Ranges: bytes | |
5515 | |
5516 but are not required to do so. Clients MAY generate byte-range | |
5517 requests without having received this header for the resource | |
5518 involved. | |
5519 | |
5520 Servers that do not accept any kind of range request for a resource | |
5521 MAY send | |
5522 | |
5523 Accept-Ranges: none | |
5524 | |
5525 to advise the client not to attempt a range request. | |
5526 | |
5527 14.6 Age | |
5528 | |
5529 The Age response-header field conveys the sender's estimate of the | |
5530 amount of time since the response (or its revalidation) was generated | |
5531 at the origin server. A cached response is "fresh" if its age does | |
5532 not exceed its freshness lifetime. Age values are calculated as | |
5533 specified in section 13.2.3. | |
5534 | |
5535 Age = "Age" ":" age-value | |
5536 | |
5537 age-value = delta-seconds | |
5538 | |
5539 Age values are non-negative decimal integers, representing time in | |
5540 seconds. | |
5541 | |
5542 | |
5543 | |
5544 | |
5545 | |
5546 Fielding, et. al. Standards Track [Page 99] | |
5547 | |
5548 RFC 2068 HTTP/1.1 January 1997 | |
5549 | |
5550 | |
5551 If a cache receives a value larger than the largest positive integer | |
5552 it can represent, or if any of its age calculations overflows, it | |
5553 MUST transmit an Age header with a value of 2147483648 (2^31). | |
5554 HTTP/1.1 caches MUST send an Age header in every response. Caches | |
5555 SHOULD use an arithmetic type of at least 31 bits of range. | |
5556 | |
5557 14.7 Allow | |
5558 | |
5559 The Allow entity-header field lists the set of methods supported by | |
5560 the resource identified by the Request-URI. The purpose of this field | |
5561 is strictly to inform the recipient of valid methods associated with | |
5562 the resource. An Allow header field MUST be present in a 405 (Method | |
5563 Not Allowed) response. | |
5564 | |
5565 Allow = "Allow" ":" 1#method | |
5566 | |
5567 Example of use: | |
5568 | |
5569 Allow: GET, HEAD, PUT | |
5570 | |
5571 This field cannot prevent a client from trying other methods. | |
5572 However, the indications given by the Allow header field value SHOULD | |
5573 be followed. The actual set of allowed methods is defined by the | |
5574 origin server at the time of each request. | |
5575 | |
5576 The Allow header field MAY be provided with a PUT request to | |
5577 recommend the methods to be supported by the new or modified | |
5578 resource. The server is not required to support these methods and | |
5579 SHOULD include an Allow header in the response giving the actual | |
5580 supported methods. | |
5581 | |
5582 A proxy MUST NOT modify the Allow header field even if it does not | |
5583 understand all the methods specified, since the user agent MAY have | |
5584 other means of communicating with the origin server. | |
5585 | |
5586 The Allow header field does not indicate what methods are implemented | |
5587 at the server level. Servers MAY use the Public response-header field | |
5588 (section 14.35) to describe what methods are implemented on the | |
5589 server as a whole. | |
5590 | |
5591 14.8 Authorization | |
5592 | |
5593 A user agent that wishes to authenticate itself with a server-- | |
5594 usually, but not necessarily, after receiving a 401 response--MAY do | |
5595 so by including an Authorization request-header field with the | |
5596 request. The Authorization field value consists of credentials | |
5597 containing the authentication information of the user agent for the | |
5598 realm of the resource being requested. | |
5599 | |
5600 | |
5601 | |
5602 Fielding, et. al. Standards Track [Page 100] | |
5603 | |
5604 RFC 2068 HTTP/1.1 January 1997 | |
5605 | |
5606 | |
5607 Authorization = "Authorization" ":" credentials | |
5608 | |
5609 HTTP access authentication is described in section 11. If a request | |
5610 is authenticated and a realm specified, the same credentials SHOULD | |
5611 be valid for all other requests within this realm. | |
5612 | |
5613 When a shared cache (see section 13.7) receives a request containing | |
5614 an Authorization field, it MUST NOT return the corresponding response | |
5615 as a reply to any other request, unless one of the following specific | |
5616 exceptions holds: | |
5617 | |
5618 1. If the response includes the "proxy-revalidate" Cache-Control | |
5619 directive, the cache MAY use that response in replying to a | |
5620 subsequent request, but a proxy cache MUST first revalidate it with | |
5621 the origin server, using the request-headers from the new request | |
5622 to allow the origin server to authenticate the new request. | |
5623 2. If the response includes the "must-revalidate" Cache-Control | |
5624 directive, the cache MAY use that response in replying to a | |
5625 subsequent request, but all caches MUST first revalidate it with | |
5626 the origin server, using the request-headers from the new request | |
5627 to allow the origin server to authenticate the new request. | |
5628 3. If the response includes the "public" Cache-Control directive, it | |
5629 may be returned in reply to any subsequent request. | |
5630 | |
5631 14.9 Cache-Control | |
5632 | |
5633 The Cache-Control general-header field is used to specify directives | |
5634 that MUST be obeyed by all caching mechanisms along the | |
5635 request/response chain. The directives specify behavior intended to | |
5636 prevent caches from adversely interfering with the request or | |
5637 response. These directives typically override the default caching | |
5638 algorithms. Cache directives are unidirectional in that the presence | |
5639 of a directive in a request does not imply that the same directive | |
5640 should be given in the response. | |
5641 | |
5642 Note that HTTP/1.0 caches may not implement Cache-Control and may | |
5643 only implement Pragma: no-cache (see section 14.32). | |
5644 | |
5645 Cache directives must be passed through by a proxy or gateway | |
5646 application, regardless of their significance to that application, | |
5647 since the directives may be applicable to all recipients along the | |
5648 request/response chain. It is not possible to specify a cache- | |
5649 directive for a specific cache. | |
5650 | |
5651 Cache-Control = "Cache-Control" ":" 1#cache-directive | |
5652 | |
5653 cache-directive = cache-request-directive | |
5654 | cache-response-directive | |
5655 | |
5656 | |
5657 | |
5658 Fielding, et. al. Standards Track [Page 101] | |
5659 | |
5660 RFC 2068 HTTP/1.1 January 1997 | |
5661 | |
5662 | |
5663 cache-request-directive = | |
5664 "no-cache" [ "=" <"> 1#field-name <"> ] | |
5665 | "no-store" | |
5666 | "max-age" "=" delta-seconds | |
5667 | "max-stale" [ "=" delta-seconds ] | |
5668 | "min-fresh" "=" delta-seconds | |
5669 | "only-if-cached" | |
5670 | cache-extension | |
5671 | |
5672 cache-response-directive = | |
5673 "public" | |
5674 | "private" [ "=" <"> 1#field-name <"> ] | |
5675 | "no-cache" [ "=" <"> 1#field-name <"> ] | |
5676 | "no-store" | |
5677 | "no-transform" | |
5678 | "must-revalidate" | |
5679 | "proxy-revalidate" | |
5680 | "max-age" "=" delta-seconds | |
5681 | cache-extension | |
5682 | |
5683 cache-extension = token [ "=" ( token | quoted-string ) ] | |
5684 | |
5685 When a directive appears without any 1#field-name parameter, the | |
5686 directive applies to the entire request or response. When such a | |
5687 directive appears with a 1#field-name parameter, it applies only to | |
5688 the named field or fields, and not to the rest of the request or | |
5689 response. This mechanism supports extensibility; implementations of | |
5690 future versions of the HTTP protocol may apply these directives to | |
5691 header fields not defined in HTTP/1.1. | |
5692 | |
5693 The cache-control directives can be broken down into these general | |
5694 categories: | |
5695 | |
5696 o Restrictions on what is cachable; these may only be imposed by the | |
5697 origin server. | |
5698 o Restrictions on what may be stored by a cache; these may be imposed | |
5699 by either the origin server or the user agent. | |
5700 o Modifications of the basic expiration mechanism; these may be | |
5701 imposed by either the origin server or the user agent. | |
5702 o Controls over cache revalidation and reload; these may only be | |
5703 imposed by a user agent. | |
5704 o Control over transformation of entities. | |
5705 o Extensions to the caching system. | |
5706 | |
5707 | |
5708 | |
5709 | |
5710 | |
5711 | |
5712 | |
5713 | |
5714 Fielding, et. al. Standards Track [Page 102] | |
5715 | |
5716 RFC 2068 HTTP/1.1 January 1997 | |
5717 | |
5718 | |
5719 14.9.1 What is Cachable | |
5720 | |
5721 By default, a response is cachable if the requirements of the request | |
5722 method, request header fields, and the response status indicate that | |
5723 it is cachable. Section 13.4 summarizes these defaults for | |
5724 cachability. The following Cache-Control response directives allow an | |
5725 origin server to override the default cachability of a response: | |
5726 | |
5727 public | |
5728 Indicates that the response is cachable by any cache, even if it | |
5729 would normally be non-cachable or cachable only within a non-shared | |
5730 cache. (See also Authorization, section 14.8, for additional | |
5731 details.) | |
5732 | |
5733 private | |
5734 Indicates that all or part of the response message is intended for a | |
5735 single user and MUST NOT be cached by a shared cache. This allows an | |
5736 origin server to state that the specified parts of the response are | |
5737 intended for only one user and are not a valid response for requests | |
5738 by other users. A private (non-shared) cache may cache the response. | |
5739 | |
5740 Note: This usage of the word private only controls where the | |
5741 response may be cached, and cannot ensure the privacy of the | |
5742 message content. | |
5743 | |
5744 no-cache | |
5745 Indicates that all or part of the response message MUST NOT be cached | |
5746 anywhere. This allows an origin server to prevent caching even by | |
5747 caches that have been configured to return stale responses to client | |
5748 requests. | |
5749 | |
5750 Note: Most HTTP/1.0 caches will not recognize or obey this | |
5751 directive. | |
5752 | |
5753 14.9.2 What May be Stored by Caches | |
5754 | |
5755 The purpose of the no-store directive is to prevent the inadvertent | |
5756 release or retention of sensitive information (for example, on backup | |
5757 tapes). The no-store directive applies to the entire message, and may | |
5758 be sent either in a response or in a request. If sent in a request, a | |
5759 cache MUST NOT store any part of either this request or any response | |
5760 to it. If sent in a response, a cache MUST NOT store any part of | |
5761 either this response or the request that elicited it. This directive | |
5762 applies to both non-shared and shared caches. "MUST NOT store" in | |
5763 this context means that the cache MUST NOT intentionally store the | |
5764 information in non-volatile storage, and MUST make a best-effort | |
5765 attempt to remove the information from volatile storage as promptly | |
5766 as possible after forwarding it. | |
5767 | |
5768 | |
5769 | |
5770 Fielding, et. al. Standards Track [Page 103] | |
5771 | |
5772 RFC 2068 HTTP/1.1 January 1997 | |
5773 | |
5774 | |
5775 Even when this directive is associated with a response, users may | |
5776 explicitly store such a response outside of the caching system (e.g., | |
5777 with a "Save As" dialog). History buffers may store such responses as | |
5778 part of their normal operation. | |
5779 | |
5780 The purpose of this directive is to meet the stated requirements of | |
5781 certain users and service authors who are concerned about accidental | |
5782 releases of information via unanticipated accesses to cache data | |
5783 structures. While the use of this directive may improve privacy in | |
5784 some cases, we caution that it is NOT in any way a reliable or | |
5785 sufficient mechanism for ensuring privacy. In particular, malicious | |
5786 or compromised caches may not recognize or obey this directive; and | |
5787 communications networks may be vulnerable to eavesdropping. | |
5788 | |
5789 14.9.3 Modifications of the Basic Expiration Mechanism | |
5790 | |
5791 The expiration time of an entity may be specified by the origin | |
5792 server using the Expires header (see section 14.21). Alternatively, | |
5793 it may be specified using the max-age directive in a response. | |
5794 | |
5795 If a response includes both an Expires header and a max-age | |
5796 directive, the max-age directive overrides the Expires header, even | |
5797 if the Expires header is more restrictive. This rule allows an origin | |
5798 server to provide, for a given response, a longer expiration time to | |
5799 an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be | |
5800 useful if certain HTTP/1.0 caches improperly calculate ages or | |
5801 expiration times, perhaps due to desynchronized clocks. | |
5802 | |
5803 Note: most older caches, not compliant with this specification, do | |
5804 not implement any Cache-Control directives. An origin server | |
5805 wishing to use a Cache-Control directive that restricts, but does | |
5806 not prevent, caching by an HTTP/1.1-compliant cache may exploit the | |
5807 requirement that the max-age directive overrides the Expires | |
5808 header, and the fact that non-HTTP/1.1-compliant caches do not | |
5809 observe the max-age directive. | |
5810 | |
5811 Other directives allow an user agent to modify the basic expiration | |
5812 mechanism. These directives may be specified on a request: | |
5813 | |
5814 max-age | |
5815 Indicates that the client is willing to accept a response whose age | |
5816 is no greater than the specified time in seconds. Unless max-stale | |
5817 directive is also included, the client is not willing to accept a | |
5818 stale response. | |
5819 | |
5820 min-fresh | |
5821 Indicates that the client is willing to accept a response whose | |
5822 freshness lifetime is no less than its current age plus the | |
5823 | |
5824 | |
5825 | |
5826 Fielding, et. al. Standards Track [Page 104] | |
5827 | |
5828 RFC 2068 HTTP/1.1 January 1997 | |
5829 | |
5830 | |
5831 specified time in seconds. That is, the client wants a response | |
5832 that will still be fresh for at least the specified number of | |
5833 seconds. | |
5834 | |
5835 max-stale | |
5836 Indicates that the client is willing to accept a response that has | |
5837 exceeded its expiration time. If max-stale is assigned a value, | |
5838 then the client is willing to accept a response that has exceeded | |
5839 its expiration time by no more than the specified number of | |
5840 seconds. If no value is assigned to max-stale, then the client is | |
5841 willing to accept a stale response of any age. | |
5842 | |
5843 If a cache returns a stale response, either because of a max-stale | |
5844 directive on a request, or because the cache is configured to | |
5845 override the expiration time of a response, the cache MUST attach a | |
5846 Warning header to the stale response, using Warning 10 (Response is | |
5847 stale). | |
5848 | |
5849 14.9.4 Cache Revalidation and Reload Controls | |
5850 | |
5851 Sometimes an user agent may want or need to insist that a cache | |
5852 revalidate its cache entry with the origin server (and not just with | |
5853 the next cache along the path to the origin server), or to reload its | |
5854 cache entry from the origin server. End-to-end revalidation may be | |
5855 necessary if either the cache or the origin server has overestimated | |
5856 the expiration time of the cached response. End-to-end reload may be | |
5857 necessary if the cache entry has become corrupted for some reason. | |
5858 | |
5859 End-to-end revalidation may be requested either when the client does | |
5860 not have its own local cached copy, in which case we call it | |
5861 "unspecified end-to-end revalidation", or when the client does have a | |
5862 local cached copy, in which case we call it "specific end-to-end | |
5863 revalidation." | |
5864 | |
5865 The client can specify these three kinds of action using Cache- | |
5866 Control request directives: | |
5867 | |
5868 End-to-end reload | |
5869 The request includes a "no-cache" Cache-Control directive or, for | |
5870 compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field | |
5871 names may be included with the no-cache directive in a request. The | |
5872 server MUST NOT use a cached copy when responding to such a | |
5873 request. | |
5874 | |
5875 Specific end-to-end revalidation | |
5876 The request includes a "max-age=0" Cache-Control directive, which | |
5877 forces each cache along the path to the origin server to revalidate | |
5878 its own entry, if any, with the next cache or server. The initial | |
5879 | |
5880 | |
5881 | |
5882 Fielding, et. al. Standards Track [Page 105] | |
5883 | |
5884 RFC 2068 HTTP/1.1 January 1997 | |
5885 | |
5886 | |
5887 request includes a cache-validating conditional with the client's | |
5888 current validator. | |
5889 | |
5890 Unspecified end-to-end revalidation | |
5891 The request includes "max-age=0" Cache-Control directive, which | |
5892 forces each cache along the path to the origin server to revalidate | |
5893 its own entry, if any, with the next cache or server. The initial | |
5894 request does not include a cache-validating conditional; the first | |
5895 cache along the path (if any) that holds a cache entry for this | |
5896 resource includes a cache-validating conditional with its current | |
5897 validator. | |
5898 | |
5899 When an intermediate cache is forced, by means of a max-age=0 | |
5900 directive, to revalidate its own cache entry, and the client has | |
5901 supplied its own validator in the request, the supplied validator may | |
5902 differ from the validator currently stored with the cache entry. In | |
5903 this case, the cache may use either validator in making its own | |
5904 request without affecting semantic transparency. | |
5905 | |
5906 However, the choice of validator may affect performance. The best | |
5907 approach is for the intermediate cache to use its own validator when | |
5908 making its request. If the server replies with 304 (Not Modified), | |
5909 then the cache should return its now validated copy to the client | |
5910 with a 200 (OK) response. If the server replies with a new entity and | |
5911 cache validator, however, the intermediate cache should compare the | |
5912 returned validator with the one provided in the client's request, | |
5913 using the strong comparison function. If the client's validator is | |
5914 equal to the origin server's, then the intermediate cache simply | |
5915 returns 304 (Not Modified). Otherwise, it returns the new entity with | |
5916 a 200 (OK) response. | |
5917 | |
5918 If a request includes the no-cache directive, it should not include | |
5919 min-fresh, max-stale, or max-age. | |
5920 | |
5921 In some cases, such as times of extremely poor network connectivity, | |
5922 a client may want a cache to return only those responses that it | |
5923 currently has stored, and not to reload or revalidate with the origin | |
5924 server. To do this, the client may include the only-if-cached | |
5925 directive in a request. If it receives this directive, a cache SHOULD | |
5926 either respond using a cached entry that is consistent with the other | |
5927 constraints of the request, or respond with a 504 (Gateway Timeout) | |
5928 status. However, if a group of caches is being operated as a unified | |
5929 system with good internal connectivity, such a request MAY be | |
5930 forwarded within that group of caches. | |
5931 | |
5932 Because a cache may be configured to ignore a server's specified | |
5933 expiration time, and because a client request may include a max-stale | |
5934 directive (which has a similar effect), the protocol also includes a | |
5935 | |
5936 | |
5937 | |
5938 Fielding, et. al. Standards Track [Page 106] | |
5939 | |
5940 RFC 2068 HTTP/1.1 January 1997 | |
5941 | |
5942 | |
5943 mechanism for the origin server to require revalidation of a cache | |
5944 entry on any subsequent use. When the must-revalidate directive is | |
5945 present in a response received by a cache, that cache MUST NOT use | |
5946 the entry after it becomes stale to respond to a subsequent request | |
5947 without first revalidating it with the origin server. (I.e., the | |
5948 cache must do an end-to-end revalidation every time, if, based solely | |
5949 on the origin server's Expires or max-age value, the cached response | |
5950 is stale.) | |
5951 | |
5952 The must-revalidate directive is necessary to support reliable | |
5953 operation for certain protocol features. In all circumstances an | |
5954 HTTP/1.1 cache MUST obey the must-revalidate directive; in | |
5955 particular, if the cache cannot reach the origin server for any | |
5956 reason, it MUST generate a 504 (Gateway Timeout) response. | |
5957 | |
5958 Servers should send the must-revalidate directive if and only if | |
5959 failure to revalidate a request on the entity could result in | |
5960 incorrect operation, such as a silently unexecuted financial | |
5961 transaction. Recipients MUST NOT take any automated action that | |
5962 violates this directive, and MUST NOT automatically provide an | |
5963 unvalidated copy of the entity if revalidation fails. | |
5964 | |
5965 Although this is not recommended, user agents operating under severe | |
5966 connectivity constraints may violate this directive but, if so, MUST | |
5967 explicitly warn the user that an unvalidated response has been | |
5968 provided. The warning MUST be provided on each unvalidated access, | |
5969 and SHOULD require explicit user confirmation. | |
5970 | |
5971 The proxy-revalidate directive has the same meaning as the must- | |
5972 revalidate directive, except that it does not apply to non-shared | |
5973 user agent caches. It can be used on a response to an authenticated | |
5974 request to permit the user's cache to store and later return the | |
5975 response without needing to revalidate it (since it has already been | |
5976 authenticated once by that user), while still requiring proxies that | |
5977 service many users to revalidate each time (in order to make sure | |
5978 that each user has been authenticated). Note that such authenticated | |
5979 responses also need the public cache control directive in order to | |
5980 allow them to be cached at all. | |
5981 | |
5982 14.9.5 No-Transform Directive | |
5983 | |
5984 Implementers of intermediate caches (proxies) have found it useful to | |
5985 convert the media type of certain entity bodies. A proxy might, for | |
5986 example, convert between image formats in order to save cache space | |
5987 or to reduce the amount of traffic on a slow link. HTTP has to date | |
5988 been silent on these transformations. | |
5989 | |
5990 | |
5991 | |
5992 | |
5993 | |
5994 Fielding, et. al. Standards Track [Page 107] | |
5995 | |
5996 RFC 2068 HTTP/1.1 January 1997 | |
5997 | |
5998 | |
5999 Serious operational problems have already occurred, however, when | |
6000 these transformations have been applied to entity bodies intended for | |
6001 certain kinds of applications. For example, applications for medical | |
6002 imaging, scientific data analysis and those using end-to-end | |
6003 authentication, all depend on receiving an entity body that is bit | |
6004 for bit identical to the original entity-body. | |
6005 | |
6006 Therefore, if a response includes the no-transform directive, an | |
6007 intermediate cache or proxy MUST NOT change those headers that are | |
6008 listed in section 13.5.2 as being subject to the no-transform | |
6009 directive. This implies that the cache or proxy must not change any | |
6010 aspect of the entity-body that is specified by these headers. | |
6011 | |
6012 14.9.6 Cache Control Extensions | |
6013 | |
6014 The Cache-Control header field can be extended through the use of one | |
6015 or more cache-extension tokens, each with an optional assigned value. | |
6016 Informational extensions (those which do not require a change in | |
6017 cache behavior) may be added without changing the semantics of other | |
6018 directives. Behavioral extensions are designed to work by acting as | |
6019 modifiers to the existing base of cache directives. Both the new | |
6020 directive and the standard directive are supplied, such that | |
6021 applications which do not understand the new directive will default | |
6022 to the behavior specified by the standard directive, and those that | |
6023 understand the new directive will recognize it as modifying the | |
6024 requirements associated with the standard directive. In this way, | |
6025 extensions to the Cache-Control directives can be made without | |
6026 requiring changes to the base protocol. | |
6027 | |
6028 This extension mechanism depends on a HTTP cache obeying all of the | |
6029 cache-control directives defined for its native HTTP-version, obeying | |
6030 certain extensions, and ignoring all directives that it does not | |
6031 understand. | |
6032 | |
6033 For example, consider a hypothetical new response directive called | |
6034 "community" which acts as a modifier to the "private" directive. We | |
6035 define this new directive to mean that, in addition to any non-shared | |
6036 cache, any cache which is shared only by members of the community | |
6037 named within its value may cache the response. An origin server | |
6038 wishing to allow the "UCI" community to use an otherwise private | |
6039 response in their shared cache(s) may do so by including | |
6040 | |
6041 Cache-Control: private, community="UCI" | |
6042 | |
6043 A cache seeing this header field will act correctly even if the cache | |
6044 does not understand the "community" cache-extension, since it will | |
6045 also see and understand the "private" directive and thus default to | |
6046 the safe behavior. | |
6047 | |
6048 | |
6049 | |
6050 Fielding, et. al. Standards Track [Page 108] | |
6051 | |
6052 RFC 2068 HTTP/1.1 January 1997 | |
6053 | |
6054 | |
6055 Unrecognized cache-directives MUST be ignored; it is assumed that any | |
6056 cache-directive likely to be unrecognized by an HTTP/1.1 cache will | |
6057 be combined with standard directives (or the response's default | |
6058 cachability) such that the cache behavior will remain minimally | |
6059 correct even if the cache does not understand the extension(s). | |
6060 | |
6061 14.10 Connection | |
6062 | |
6063 The Connection general-header field allows the sender to specify | |
6064 options that are desired for that particular connection and MUST NOT | |
6065 be communicated by proxies over further connections. | |
6066 | |
6067 The Connection header has the following grammar: | |
6068 | |
6069 Connection-header = "Connection" ":" 1#(connection-token) | |
6070 connection-token = token | |
6071 | |
6072 HTTP/1.1 proxies MUST parse the Connection header field before a | |
6073 message is forwarded and, for each connection-token in this field, | |
6074 remove any header field(s) from the message with the same name as the | |
6075 connection-token. Connection options are signaled by the presence of | |
6076 a connection-token in the Connection header field, not by any | |
6077 corresponding additional header field(s), since the additional header | |
6078 field may not be sent if there are no parameters associated with that | |
6079 connection option. HTTP/1.1 defines the "close" connection option | |
6080 for the sender to signal that the connection will be closed after | |
6081 completion of the response. For example, | |
6082 | |
6083 Connection: close | |
6084 | |
6085 in either the request or the response header fields indicates that | |
6086 the connection should not be considered `persistent' (section 8.1) | |
6087 after the current request/response is complete. | |
6088 | |
6089 HTTP/1.1 applications that do not support persistent connections MUST | |
6090 include the "close" connection option in every message. | |
6091 | |
6092 14.11 Content-Base | |
6093 | |
6094 The Content-Base entity-header field may be used to specify the base | |
6095 URI for resolving relative URLs within the entity. This header field | |
6096 is described as Base in RFC 1808, which is expected to be revised. | |
6097 | |
6098 Content-Base = "Content-Base" ":" absoluteURI | |
6099 | |
6100 If no Content-Base field is present, the base URI of an entity is | |
6101 defined either by its Content-Location (if that Content-Location URI | |
6102 is an absolute URI) or the URI used to initiate the request, in that | |
6103 | |
6104 | |
6105 | |
6106 Fielding, et. al. Standards Track [Page 109] | |
6107 | |
6108 RFC 2068 HTTP/1.1 January 1997 | |
6109 | |
6110 | |
6111 order of precedence. Note, however, that the base URI of the contents | |
6112 within the entity-body may be redefined within that entity-body. | |
6113 | |
6114 14.12 Content-Encoding | |
6115 | |
6116 The Content-Encoding entity-header field is used as a modifier to the | |
6117 media-type. When present, its value indicates what additional content | |
6118 codings have been applied to the entity-body, and thus what decoding | |
6119 mechanisms MUST be applied in order to obtain the media-type | |
6120 referenced by the Content-Type header field. Content-Encoding is | |
6121 primarily used to allow a document to be compressed without losing | |
6122 the identity of its underlying media type. | |
6123 | |
6124 Content-Encoding = "Content-Encoding" ":" 1#content-coding | |
6125 | |
6126 Content codings are defined in section 3.5. An example of its use is | |
6127 | |
6128 Content-Encoding: gzip | |
6129 | |
6130 The Content-Encoding is a characteristic of the entity identified by | |
6131 the Request-URI. Typically, the entity-body is stored with this | |
6132 encoding and is only decoded before rendering or analogous usage. | |
6133 | |
6134 If multiple encodings have been applied to an entity, the content | |
6135 codings MUST be listed in the order in which they were applied. | |
6136 | |
6137 Additional information about the encoding parameters MAY be provided | |
6138 by other entity-header fields not defined by this specification. | |
6139 | |
6140 14.13 Content-Language | |
6141 | |
6142 The Content-Language entity-header field describes the natural | |
6143 language(s) of the intended audience for the enclosed entity. Note | |
6144 that this may not be equivalent to all the languages used within the | |
6145 entity-body. | |
6146 | |
6147 Content-Language = "Content-Language" ":" 1#language-tag | |
6148 | |
6149 Language tags are defined in section 3.10. The primary purpose of | |
6150 Content-Language is to allow a user to identify and differentiate | |
6151 entities according to the user's own preferred language. Thus, if the | |
6152 body content is intended only for a Danish-literate audience, the | |
6153 appropriate field is | |
6154 | |
6155 Content-Language: da | |
6156 | |
6157 If no Content-Language is specified, the default is that the content | |
6158 is intended for all language audiences. This may mean that the sender | |
6159 | |
6160 | |
6161 | |
6162 Fielding, et. al. Standards Track [Page 110] | |
6163 | |
6164 RFC 2068 HTTP/1.1 January 1997 | |
6165 | |
6166 | |
6167 does not consider it to be specific to any natural language, or that | |
6168 the sender does not know for which language it is intended. | |
6169 | |
6170 Multiple languages MAY be listed for content that is intended for | |
6171 multiple audiences. For example, a rendition of the "Treaty of | |
6172 Waitangi," presented simultaneously in the original Maori and English | |
6173 versions, would call for | |
6174 | |
6175 Content-Language: mi, en | |
6176 | |
6177 However, just because multiple languages are present within an entity | |
6178 does not mean that it is intended for multiple linguistic audiences. | |
6179 An example would be a beginner's language primer, such as "A First | |
6180 Lesson in Latin," which is clearly intended to be used by an | |
6181 English-literate audience. In this case, the Content-Language should | |
6182 only include "en". | |
6183 | |
6184 Content-Language may be applied to any media type -- it is not | |
6185 limited to textual documents. | |
6186 | |
6187 14.14 Content-Length | |
6188 | |
6189 The Content-Length entity-header field indicates the size of the | |
6190 message-body, in decimal number of octets, sent to the recipient or, | |
6191 in the case of the HEAD method, the size of the entity-body that | |
6192 would have been sent had the request been a GET. | |
6193 | |
6194 Content-Length = "Content-Length" ":" 1*DIGIT | |
6195 | |
6196 An example is | |
6197 | |
6198 Content-Length: 3495 | |
6199 | |
6200 Applications SHOULD use this field to indicate the size of the | |
6201 message-body to be transferred, regardless of the media type of the | |
6202 entity. It must be possible for the recipient to reliably determine | |
6203 the end of HTTP/1.1 requests containing an entity-body, e.g., because | |
6204 the request has a valid Content-Length field, uses Transfer-Encoding: | |
6205 chunked or a multipart body. | |
6206 | |
6207 Any Content-Length greater than or equal to zero is a valid value. | |
6208 Section 4.4 describes how to determine the length of a message-body | |
6209 if a Content-Length is not given. | |
6210 | |
6211 | |
6212 | |
6213 | |
6214 | |
6215 | |
6216 | |
6217 | |
6218 Fielding, et. al. Standards Track [Page 111] | |
6219 | |
6220 RFC 2068 HTTP/1.1 January 1997 | |
6221 | |
6222 | |
6223 Note: The meaning of this field is significantly different from the | |
6224 corresponding definition in MIME, where it is an optional field | |
6225 used within the "message/external-body" content-type. In HTTP, it | |
6226 SHOULD be sent whenever the message's length can be determined | |
6227 prior to being transferred. | |
6228 | |
6229 14.15 Content-Location | |
6230 | |
6231 The Content-Location entity-header field may be used to supply the | |
6232 resource location for the entity enclosed in the message. In the case | |
6233 where a resource has multiple entities associated with it, and those | |
6234 entities actually have separate locations by which they might be | |
6235 individually accessed, the server should provide a Content-Location | |
6236 for the particular variant which is returned. In addition, a server | |
6237 SHOULD provide a Content-Location for the resource corresponding to | |
6238 the response entity. | |
6239 | |
6240 Content-Location = "Content-Location" ":" | |
6241 ( absoluteURI | relativeURI ) | |
6242 | |
6243 If no Content-Base header field is present, the value of Content- | |
6244 Location also defines the base URL for the entity (see section | |
6245 14.11). | |
6246 | |
6247 The Content-Location value is not a replacement for the original | |
6248 requested URI; it is only a statement of the location of the resource | |
6249 corresponding to this particular entity at the time of the request. | |
6250 Future requests MAY use the Content-Location URI if the desire is to | |
6251 identify the source of that particular entity. | |
6252 | |
6253 A cache cannot assume that an entity with a Content-Location | |
6254 different from the URI used to retrieve it can be used to respond to | |
6255 later requests on that Content-Location URI. However, the Content- | |
6256 Location can be used to differentiate between multiple entities | |
6257 retrieved from a single requested resource, as described in section | |
6258 13.6. | |
6259 | |
6260 If the Content-Location is a relative URI, the URI is interpreted | |
6261 relative to any Content-Base URI provided in the response. If no | |
6262 Content-Base is provided, the relative URI is interpreted relative to | |
6263 the Request-URI. | |
6264 | |
6265 | |
6266 | |
6267 | |
6268 | |
6269 | |
6270 | |
6271 | |
6272 | |
6273 | |
6274 Fielding, et. al. Standards Track [Page 112] | |
6275 | |
6276 RFC 2068 HTTP/1.1 January 1997 | |
6277 | |
6278 | |
6279 14.16 Content-MD5 | |
6280 | |
6281 The Content-MD5 entity-header field, as defined in RFC 1864 [23], is | |
6282 an MD5 digest of the entity-body for the purpose of providing an | |
6283 end-to-end message integrity check (MIC) of the entity-body. (Note: a | |
6284 MIC is good for detecting accidental modification of the entity-body | |
6285 in transit, but is not proof against malicious attacks.) | |
6286 | |
6287 Content-MD5 = "Content-MD5" ":" md5-digest | |
6288 | |
6289 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> | |
6290 | |
6291 The Content-MD5 header field may be generated by an origin server to | |
6292 function as an integrity check of the entity-body. Only origin | |
6293 servers may generate the Content-MD5 header field; proxies and | |
6294 gateways MUST NOT generate it, as this would defeat its value as an | |
6295 end-to-end integrity check. Any recipient of the entity-body, | |
6296 including gateways and proxies, MAY check that the digest value in | |
6297 this header field matches that of the entity-body as received. | |
6298 | |
6299 The MD5 digest is computed based on the content of the entity-body, | |
6300 including any Content-Encoding that has been applied, but not | |
6301 including any Transfer-Encoding that may have been applied to the | |
6302 message-body. If the message is received with a Transfer-Encoding, | |
6303 that encoding must be removed prior to checking the Content-MD5 value | |
6304 against the received entity. | |
6305 | |
6306 This has the result that the digest is computed on the octets of the | |
6307 entity-body exactly as, and in the order that, they would be sent if | |
6308 no Transfer-Encoding were being applied. | |
6309 | |
6310 HTTP extends RFC 1864 to permit the digest to be computed for MIME | |
6311 composite media-types (e.g., multipart/* and message/rfc822), but | |
6312 this does not change how the digest is computed as defined in the | |
6313 preceding paragraph. | |
6314 | |
6315 Note: There are several consequences of this. The entity-body for | |
6316 composite types may contain many body-parts, each with its own MIME | |
6317 and HTTP headers (including Content-MD5, Content-Transfer-Encoding, | |
6318 and Content-Encoding headers). If a body-part has a Content- | |
6319 Transfer-Encoding or Content-Encoding header, it is assumed that | |
6320 the content of the body-part has had the encoding applied, and the | |
6321 body-part is included in the Content-MD5 digest as is -- i.e., | |
6322 after the application. The Transfer-Encoding header field is not | |
6323 allowed within body-parts. | |
6324 | |
6325 Note: while the definition of Content-MD5 is exactly the same for | |
6326 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways | |
6327 | |
6328 | |
6329 | |
6330 Fielding, et. al. Standards Track [Page 113] | |
6331 | |
6332 RFC 2068 HTTP/1.1 January 1997 | |
6333 | |
6334 | |
6335 in which the application of Content-MD5 to HTTP entity-bodies | |
6336 differs from its application to MIME entity-bodies. One is that | |
6337 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does | |
6338 use Transfer-Encoding and Content-Encoding. Another is that HTTP | |
6339 more frequently uses binary content types than MIME, so it is worth | |
6340 noting that, in such cases, the byte order used to compute the | |
6341 digest is the transmission byte order defined for the type. Lastly, | |
6342 HTTP allows transmission of text types with any of several line | |
6343 break conventions and not just the canonical form using CRLF. | |
6344 Conversion of all line breaks to CRLF should not be done before | |
6345 computing or checking the digest: the line break convention used in | |
6346 the text actually transmitted should be left unaltered when | |
6347 computing the digest. | |
6348 | |
6349 14.17 Content-Range | |
6350 | |
6351 The Content-Range entity-header is sent with a partial entity-body to | |
6352 specify where in the full entity-body the partial body should be | |
6353 inserted. It also indicates the total size of the full entity-body. | |
6354 When a server returns a partial response to a client, it must | |
6355 describe both the extent of the range covered by the response, and | |
6356 the length of the entire entity-body. | |
6357 | |
6358 Content-Range = "Content-Range" ":" content-range-spec | |
6359 | |
6360 content-range-spec = byte-content-range-spec | |
6361 | |
6362 byte-content-range-spec = bytes-unit SP first-byte-pos "-" | |
6363 last-byte-pos "/" entity-length | |
6364 | |
6365 entity-length = 1*DIGIT | |
6366 | |
6367 Unlike byte-ranges-specifier values, a byte-content-range-spec may | |
6368 only specify one range, and must contain absolute byte positions for | |
6369 both the first and last byte of the range. | |
6370 | |
6371 A byte-content-range-spec whose last-byte-pos value is less than its | |
6372 first-byte-pos value, or whose entity-length value is less than or | |
6373 equal to its last-byte-pos value, is invalid. The recipient of an | |
6374 invalid byte-content-range-spec MUST ignore it and any content | |
6375 transferred along with it. | |
6376 | |
6377 | |
6378 | |
6379 | |
6380 | |
6381 | |
6382 | |
6383 | |
6384 | |
6385 | |
6386 Fielding, et. al. Standards Track [Page 114] | |
6387 | |
6388 RFC 2068 HTTP/1.1 January 1997 | |
6389 | |
6390 | |
6391 Examples of byte-content-range-spec values, assuming that the entity | |
6392 contains a total of 1234 bytes: | |
6393 | |
6394 o The first 500 bytes: | |
6395 | |
6396 bytes 0-499/1234 | |
6397 | |
6398 o The second 500 bytes: | |
6399 | |
6400 bytes 500-999/1234 | |
6401 | |
6402 o All except for the first 500 bytes: | |
6403 | |
6404 bytes 500-1233/1234 | |
6405 | |
6406 o The last 500 bytes: | |
6407 | |
6408 bytes 734-1233/1234 | |
6409 | |
6410 When an HTTP message includes the content of a single range (for | |
6411 example, a response to a request for a single range, or to a request | |
6412 for a set of ranges that overlap without any holes), this content is | |
6413 transmitted with a Content-Range header, and a Content-Length header | |
6414 showing the number of bytes actually transferred. For example, | |
6415 | |
6416 HTTP/1.1 206 Partial content | |
6417 Date: Wed, 15 Nov 1995 06:25:24 GMT | |
6418 Last-modified: Wed, 15 Nov 1995 04:58:08 GMT | |
6419 Content-Range: bytes 21010-47021/47022 | |
6420 Content-Length: 26012 | |
6421 Content-Type: image/gif | |
6422 | |
6423 When an HTTP message includes the content of multiple ranges (for | |
6424 example, a response to a request for multiple non-overlapping | |
6425 ranges), these are transmitted as a multipart MIME message. The | |
6426 multipart MIME content-type used for this purpose is defined in this | |
6427 specification to be "multipart/byteranges". See appendix 19.2 for its | |
6428 definition. | |
6429 | |
6430 A client that cannot decode a MIME multipart/byteranges message | |
6431 should not ask for multiple byte-ranges in a single request. | |
6432 | |
6433 When a client requests multiple byte-ranges in one request, the | |
6434 server SHOULD return them in the order that they appeared in the | |
6435 request. | |
6436 | |
6437 If the server ignores a byte-range-spec because it is invalid, the | |
6438 server should treat the request as if the invalid Range header field | |
6439 | |
6440 | |
6441 | |
6442 Fielding, et. al. Standards Track [Page 115] | |
6443 | |
6444 RFC 2068 HTTP/1.1 January 1997 | |
6445 | |
6446 | |
6447 did not exist. (Normally, this means return a 200 response containing | |
6448 the full entity). The reason is that the only time a client will make | |
6449 such an invalid request is when the entity is smaller than the entity | |
6450 retrieved by a prior request. | |
6451 | |
6452 14.18 Content-Type | |
6453 | |
6454 The Content-Type entity-header field indicates the media type of the | |
6455 entity-body sent to the recipient or, in the case of the HEAD method, | |
6456 the media type that would have been sent had the request been a GET. | |
6457 | |
6458 Content-Type = "Content-Type" ":" media-type | |
6459 Media types are defined in section 3.7. An example of the field is | |
6460 | |
6461 Content-Type: text/html; charset=ISO-8859-4 | |
6462 | |
6463 Further discussion of methods for identifying the media type of an | |
6464 entity is provided in section 7.2.1. | |
6465 | |
6466 14.19 Date | |
6467 | |
6468 The Date general-header field represents the date and time at which | |
6469 the message was originated, having the same semantics as orig-date in | |
6470 RFC 822. The field value is an HTTP-date, as described in section | |
6471 3.3.1. | |
6472 | |
6473 Date = "Date" ":" HTTP-date | |
6474 | |
6475 An example is | |
6476 | |
6477 Date: Tue, 15 Nov 1994 08:12:31 GMT | |
6478 | |
6479 If a message is received via direct connection with the user agent | |
6480 (in the case of requests) or the origin server (in the case of | |
6481 responses), then the date can be assumed to be the current date at | |
6482 the receiving end. However, since the date--as it is believed by the | |
6483 origin--is important for evaluating cached responses, origin servers | |
6484 MUST include a Date header field in all responses. Clients SHOULD | |
6485 only send a Date header field in messages that include an entity- | |
6486 body, as in the case of the PUT and POST requests, and even then it | |
6487 is optional. A received message which does not have a Date header | |
6488 field SHOULD be assigned one by the recipient if the message will be | |
6489 cached by that recipient or gatewayed via a protocol which requires a | |
6490 Date. | |
6491 | |
6492 | |
6493 | |
6494 | |
6495 | |
6496 | |
6497 | |
6498 Fielding, et. al. Standards Track [Page 116] | |
6499 | |
6500 RFC 2068 HTTP/1.1 January 1997 | |
6501 | |
6502 | |
6503 In theory, the date SHOULD represent the moment just before the | |
6504 entity is generated. In practice, the date can be generated at any | |
6505 time during the message origination without affecting its semantic | |
6506 value. | |
6507 | |
6508 The format of the Date is an absolute date and time as defined by | |
6509 HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format. | |
6510 | |
6511 14.20 ETag | |
6512 | |
6513 The ETag entity-header field defines the entity tag for the | |
6514 associated entity. The headers used with entity tags are described in | |
6515 sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used | |
6516 for comparison with other entities from the same resource (see | |
6517 section 13.3.2). | |
6518 | |
6519 ETag = "ETag" ":" entity-tag | |
6520 | |
6521 Examples: | |
6522 | |
6523 ETag: "xyzzy" | |
6524 ETag: W/"xyzzy" | |
6525 ETag: "" | |
6526 | |
6527 14.21 Expires | |
6528 | |
6529 The Expires entity-header field gives the date/time after which the | |
6530 response should be considered stale. A stale cache entry may not | |
6531 normally be returned by a cache (either a proxy cache or an user | |
6532 agent cache) unless it is first validated with the origin server (or | |
6533 with an intermediate cache that has a fresh copy of the entity). See | |
6534 section 13.2 for further discussion of the expiration model. | |
6535 | |
6536 The presence of an Expires field does not imply that the original | |
6537 resource will change or cease to exist at, before, or after that | |
6538 time. | |
6539 | |
6540 The format is an absolute date and time as defined by HTTP-date in | |
6541 section 3.3; it MUST be in RFC1123-date format: | |
6542 | |
6543 Expires = "Expires" ":" HTTP-date | |
6544 | |
6545 | |
6546 | |
6547 | |
6548 | |
6549 | |
6550 | |
6551 | |
6552 | |
6553 | |
6554 Fielding, et. al. Standards Track [Page 117] | |
6555 | |
6556 RFC 2068 HTTP/1.1 January 1997 | |
6557 | |
6558 | |
6559 An example of its use is | |
6560 | |
6561 Expires: Thu, 01 Dec 1994 16:00:00 GMT | |
6562 | |
6563 Note: if a response includes a Cache-Control field with the max-age | |
6564 directive, that directive overrides the Expires field. | |
6565 | |
6566 HTTP/1.1 clients and caches MUST treat other invalid date formats, | |
6567 especially including the value "0", as in the past (i.e., "already | |
6568 expired"). | |
6569 | |
6570 To mark a response as "already expired," an origin server should use | |
6571 an Expires date that is equal to the Date header value. (See the | |
6572 rules for expiration calculations in section 13.2.4.) | |
6573 | |
6574 To mark a response as "never expires," an origin server should use an | |
6575 Expires date approximately one year from the time the response is | |
6576 sent. HTTP/1.1 servers should not send Expires dates more than one | |
6577 year in the future. | |
6578 | |
6579 The presence of an Expires header field with a date value of some | |
6580 time in the future on an response that otherwise would by default be | |
6581 non-cacheable indicates that the response is cachable, unless | |
6582 indicated otherwise by a Cache-Control header field (section 14.9). | |
6583 | |
6584 14.22 From | |
6585 | |
6586 The From request-header field, if given, SHOULD contain an Internet | |
6587 e-mail address for the human user who controls the requesting user | |
6588 agent. The address SHOULD be machine-usable, as defined by mailbox | |
6589 in RFC 822 (as updated by RFC 1123 ): | |
6590 | |
6591 From = "From" ":" mailbox | |
6592 | |
6593 An example is: | |
6594 | |
6595 From: webmaster@w3.org | |
6596 | |
6597 This header field MAY be used for logging purposes and as a means for | |
6598 identifying the source of invalid or unwanted requests. It SHOULD NOT | |
6599 be used as an insecure form of access protection. The interpretation | |
6600 of this field is that the request is being performed on behalf of the | |
6601 person given, who accepts responsibility for the method performed. In | |
6602 particular, robot agents SHOULD include this header so that the | |
6603 person responsible for running the robot can be contacted if problems | |
6604 occur on the receiving end. | |
6605 | |
6606 | |
6607 | |
6608 | |
6609 | |
6610 Fielding, et. al. Standards Track [Page 118] | |
6611 | |
6612 RFC 2068 HTTP/1.1 January 1997 | |
6613 | |
6614 | |
6615 The Internet e-mail address in this field MAY be separate from the | |
6616 Internet host which issued the request. For example, when a request | |
6617 is passed through a proxy the original issuer's address SHOULD be | |
6618 used. | |
6619 | |
6620 Note: The client SHOULD not send the From header field without the | |
6621 user's approval, as it may conflict with the user's privacy | |
6622 interests or their site's security policy. It is strongly | |
6623 recommended that the user be able to disable, enable, and modify | |
6624 the value of this field at any time prior to a request. | |
6625 | |
6626 14.23 Host | |
6627 | |
6628 The Host request-header field specifies the Internet host and port | |
6629 number of the resource being requested, as obtained from the original | |
6630 URL given by the user or referring resource (generally an HTTP URL, | |
6631 as described in section 3.2.2). The Host field value MUST represent | |
6632 the network location of the origin server or gateway given by the | |
6633 original URL. This allows the origin server or gateway to | |
6634 differentiate between internally-ambiguous URLs, such as the root "/" | |
6635 URL of a server for multiple host names on a single IP address. | |
6636 | |
6637 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | |
6638 | |
6639 A "host" without any trailing port information implies the default | |
6640 port for the service requested (e.g., "80" for an HTTP URL). For | |
6641 example, a request on the origin server for | |
6642 <http://www.w3.org/pub/WWW/> MUST include: | |
6643 | |
6644 GET /pub/WWW/ HTTP/1.1 | |
6645 Host: www.w3.org | |
6646 | |
6647 A client MUST include a Host header field in all HTTP/1.1 request | |
6648 messages on the Internet (i.e., on any message corresponding to a | |
6649 request for a URL which includes an Internet host address for the | |
6650 service being requested). If the Host field is not already present, | |
6651 an HTTP/1.1 proxy MUST add a Host field to the request message prior | |
6652 to forwarding it on the Internet. All Internet-based HTTP/1.1 servers | |
6653 MUST respond with a 400 status code to any HTTP/1.1 request message | |
6654 which lacks a Host header field. | |
6655 | |
6656 See sections 5.2 and 19.5.1 for other requirements relating to Host. | |
6657 | |
6658 14.24 If-Modified-Since | |
6659 | |
6660 The If-Modified-Since request-header field is used with the GET | |
6661 method to make it conditional: if the requested variant has not been | |
6662 modified since the time specified in this field, an entity will not | |
6663 | |
6664 | |
6665 | |
6666 Fielding, et. al. Standards Track [Page 119] | |
6667 | |
6668 RFC 2068 HTTP/1.1 January 1997 | |
6669 | |
6670 | |
6671 be returned from the server; instead, a 304 (not modified) response | |
6672 will be returned without any message-body. | |
6673 | |
6674 If-Modified-Since = "If-Modified-Since" ":" HTTP-date | |
6675 | |
6676 An example of the field is: | |
6677 | |
6678 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |
6679 | |
6680 A GET method with an If-Modified-Since header and no Range header | |
6681 requests that the identified entity be transferred only if it has | |
6682 been modified since the date given by the If-Modified-Since header. | |
6683 The algorithm for determining this includes the following cases: | |
6684 | |
6685 a)If the request would normally result in anything other than a 200 | |
6686 (OK) status, or if the passed If-Modified-Since date is invalid, the | |
6687 response is exactly the same as for a normal GET. A date which is | |
6688 later than the server's current time is invalid. | |
6689 | |
6690 b)If the variant has been modified since the If-Modified-Since date, | |
6691 the response is exactly the same as for a normal GET. | |
6692 | |
6693 c)If the variant has not been modified since a valid If-Modified-Since | |
6694 date, the server MUST return a 304 (Not Modified) response. | |
6695 | |
6696 The purpose of this feature is to allow efficient updates of cached | |
6697 information with a minimum amount of transaction overhead. | |
6698 | |
6699 Note that the Range request-header field modifies the meaning of | |
6700 If-Modified-Since; see section 14.36 for full details. | |
6701 | |
6702 Note that If-Modified-Since times are interpreted by the server, | |
6703 whose clock may not be synchronized with the client. | |
6704 | |
6705 Note that if a client uses an arbitrary date in the If-Modified-Since | |
6706 header instead of a date taken from the Last-Modified header for the | |
6707 same request, the client should be aware of the fact that this date | |
6708 is interpreted in the server's understanding of time. The client | |
6709 should consider unsynchronized clocks and rounding problems due to | |
6710 the different encodings of time between the client and server. This | |
6711 includes the possibility of race conditions if the document has | |
6712 changed between the time it was first requested and the If-Modified- | |
6713 Since date of a subsequent request, and the possibility of clock- | |
6714 skew-related problems if the If-Modified-Since date is derived from | |
6715 the client's clock without correction to the server's clock. | |
6716 Corrections for different time bases between client and server are at | |
6717 best approximate due to network latency. | |
6718 | |
6719 | |
6720 | |
6721 | |
6722 Fielding, et. al. Standards Track [Page 120] | |
6723 | |
6724 RFC 2068 HTTP/1.1 January 1997 | |
6725 | |
6726 | |
6727 14.25 If-Match | |
6728 | |
6729 The If-Match request-header field is used with a method to make it | |
6730 conditional. A client that has one or more entities previously | |
6731 obtained from the resource can verify that one of those entities is | |
6732 current by including a list of their associated entity tags in the | |
6733 If-Match header field. The purpose of this feature is to allow | |
6734 efficient updates of cached information with a minimum amount of | |
6735 transaction overhead. It is also used, on updating requests, to | |
6736 prevent inadvertent modification of the wrong version of a resource. | |
6737 As a special case, the value "*" matches any current entity of the | |
6738 resource. | |
6739 | |
6740 If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | |
6741 | |
6742 If any of the entity tags match the entity tag of the entity that | |
6743 would have been returned in the response to a similar GET request | |
6744 (without the If-Match header) on that resource, or if "*" is given | |
6745 and any current entity exists for that resource, then the server MAY | |
6746 perform the requested method as if the If-Match header field did not | |
6747 exist. | |
6748 | |
6749 A server MUST use the strong comparison function (see section 3.11) | |
6750 to compare the entity tags in If-Match. | |
6751 | |
6752 If none of the entity tags match, or if "*" is given and no current | |
6753 entity exists, the server MUST NOT perform the requested method, and | |
6754 MUST return a 412 (Precondition Failed) response. This behavior is | |
6755 most useful when the client wants to prevent an updating method, such | |
6756 as PUT, from modifying a resource that has changed since the client | |
6757 last retrieved it. | |
6758 | |
6759 If the request would, without the If-Match header field, result in | |
6760 anything other than a 2xx status, then the If-Match header MUST be | |
6761 ignored. | |
6762 | |
6763 The meaning of "If-Match: *" is that the method SHOULD be performed | |
6764 if the representation selected by the origin server (or by a cache, | |
6765 possibly using the Vary mechanism, see section 14.43) exists, and | |
6766 MUST NOT be performed if the representation does not exist. | |
6767 | |
6768 | |
6769 | |
6770 | |
6771 | |
6772 | |
6773 | |
6774 | |
6775 | |
6776 | |
6777 | |
6778 Fielding, et. al. Standards Track [Page 121] | |
6779 | |
6780 RFC 2068 HTTP/1.1 January 1997 | |
6781 | |
6782 | |
6783 A request intended to update a resource (e.g., a PUT) MAY include an | |
6784 If-Match header field to signal that the request method MUST NOT be | |
6785 applied if the entity corresponding to the If-Match value (a single | |
6786 entity tag) is no longer a representation of that resource. This | |
6787 allows the user to indicate that they do not wish the request to be | |
6788 successful if the resource has been changed without their knowledge. | |
6789 Examples: | |
6790 | |
6791 If-Match: "xyzzy" | |
6792 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |
6793 If-Match: * | |
6794 | |
6795 14.26 If-None-Match | |
6796 | |
6797 The If-None-Match request-header field is used with a method to make | |
6798 it conditional. A client that has one or more entities previously | |
6799 obtained from the resource can verify that none of those entities is | |
6800 current by including a list of their associated entity tags in the | |
6801 If-None-Match header field. The purpose of this feature is to allow | |
6802 efficient updates of cached information with a minimum amount of | |
6803 transaction overhead. It is also used, on updating requests, to | |
6804 prevent inadvertent modification of a resource which was not known to | |
6805 exist. | |
6806 | |
6807 As a special case, the value "*" matches any current entity of the | |
6808 resource. | |
6809 | |
6810 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | |
6811 | |
6812 If any of the entity tags match the entity tag of the entity that | |
6813 would have been returned in the response to a similar GET request | |
6814 (without the If-None-Match header) on that resource, or if "*" is | |
6815 given and any current entity exists for that resource, then the | |
6816 server MUST NOT perform the requested method. Instead, if the request | |
6817 method was GET or HEAD, the server SHOULD respond with a 304 (Not | |
6818 Modified) response, including the cache-related entity-header fields | |
6819 (particularly ETag) of one of the entities that matched. For all | |
6820 other request methods, the server MUST respond with a status of 412 | |
6821 (Precondition Failed). | |
6822 | |
6823 See section 13.3.3 for rules on how to determine if two entity tags | |
6824 match. The weak comparison function can only be used with GET or HEAD | |
6825 requests. | |
6826 | |
6827 If none of the entity tags match, or if "*" is given and no current | |
6828 entity exists, then the server MAY perform the requested method as if | |
6829 the If-None-Match header field did not exist. | |
6830 | |
6831 | |
6832 | |
6833 | |
6834 Fielding, et. al. Standards Track [Page 122] | |
6835 | |
6836 RFC 2068 HTTP/1.1 January 1997 | |
6837 | |
6838 | |
6839 If the request would, without the If-None-Match header field, result | |
6840 in anything other than a 2xx status, then the If-None-Match header | |
6841 MUST be ignored. | |
6842 | |
6843 The meaning of "If-None-Match: *" is that the method MUST NOT be | |
6844 performed if the representation selected by the origin server (or by | |
6845 a cache, possibly using the Vary mechanism, see section 14.43) | |
6846 exists, and SHOULD be performed if the representation does not exist. | |
6847 This feature may be useful in preventing races between PUT | |
6848 operations. | |
6849 | |
6850 Examples: | |
6851 | |
6852 If-None-Match: "xyzzy" | |
6853 If-None-Match: W/"xyzzy" | |
6854 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |
6855 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | |
6856 If-None-Match: * | |
6857 | |
6858 14.27 If-Range | |
6859 | |
6860 If a client has a partial copy of an entity in its cache, and wishes | |
6861 to have an up-to-date copy of the entire entity in its cache, it | |
6862 could use the Range request-header with a conditional GET (using | |
6863 either or both of If-Unmodified-Since and If-Match.) However, if the | |
6864 condition fails because the entity has been modified, the client | |
6865 would then have to make a second request to obtain the entire current | |
6866 entity-body. | |
6867 | |
6868 The If-Range header allows a client to "short-circuit" the second | |
6869 request. Informally, its meaning is `if the entity is unchanged, send | |
6870 me the part(s) that I am missing; otherwise, send me the entire new | |
6871 entity.' | |
6872 | |
6873 If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | |
6874 | |
6875 If the client has no entity tag for an entity, but does have a Last- | |
6876 Modified date, it may use that date in a If-Range header. (The server | |
6877 can distinguish between a valid HTTP-date and any form of entity-tag | |
6878 by examining no more than two characters.) The If-Range header should | |
6879 only be used together with a Range header, and must be ignored if the | |
6880 request does not include a Range header, or if the server does not | |
6881 support the sub-range operation. | |
6882 | |
6883 | |
6884 | |
6885 | |
6886 | |
6887 | |
6888 | |
6889 | |
6890 Fielding, et. al. Standards Track [Page 123] | |
6891 | |
6892 RFC 2068 HTTP/1.1 January 1997 | |
6893 | |
6894 | |
6895 If the entity tag given in the If-Range header matches the current | |
6896 entity tag for the entity, then the server should provide the | |
6897 specified sub-range of the entity using a 206 (Partial content) | |
6898 response. If the entity tag does not match, then the server should | |
6899 return the entire entity using a 200 (OK) response. | |
6900 | |
6901 14.28 If-Unmodified-Since | |
6902 | |
6903 The If-Unmodified-Since request-header field is used with a method to | |
6904 make it conditional. If the requested resource has not been modified | |
6905 since the time specified in this field, the server should perform the | |
6906 requested operation as if the If-Unmodified-Since header were not | |
6907 present. | |
6908 | |
6909 If the requested variant has been modified since the specified time, | |
6910 the server MUST NOT perform the requested operation, and MUST return | |
6911 a 412 (Precondition Failed). | |
6912 | |
6913 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | |
6914 | |
6915 An example of the field is: | |
6916 | |
6917 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |
6918 | |
6919 If the request normally (i.e., without the If-Unmodified-Since | |
6920 header) would result in anything other than a 2xx status, the If- | |
6921 Unmodified-Since header should be ignored. | |
6922 | |
6923 If the specified date is invalid, the header is ignored. | |
6924 | |
6925 14.29 Last-Modified | |
6926 | |
6927 The Last-Modified entity-header field indicates the date and time at | |
6928 which the origin server believes the variant was last modified. | |
6929 | |
6930 Last-Modified = "Last-Modified" ":" HTTP-date | |
6931 | |
6932 An example of its use is | |
6933 | |
6934 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |
6935 | |
6936 The exact meaning of this header field depends on the implementation | |
6937 of the origin server and the nature of the original resource. For | |
6938 files, it may be just the file system last-modified time. For | |
6939 entities with dynamically included parts, it may be the most recent | |
6940 of the set of last-modify times for its component parts. For database | |
6941 gateways, it may be the last-update time stamp of the record. For | |
6942 virtual objects, it may be the last time the internal state changed. | |
6943 | |
6944 | |
6945 | |
6946 Fielding, et. al. Standards Track [Page 124] | |
6947 | |
6948 RFC 2068 HTTP/1.1 January 1997 | |
6949 | |
6950 | |
6951 An origin server MUST NOT send a Last-Modified date which is later | |
6952 than the server's time of message origination. In such cases, where | |
6953 the resource's last modification would indicate some time in the | |
6954 future, the server MUST replace that date with the message | |
6955 origination date. | |
6956 | |
6957 An origin server should obtain the Last-Modified value of the entity | |
6958 as close as possible to the time that it generates the Date value of | |
6959 its response. This allows a recipient to make an accurate assessment | |
6960 of the entity's modification time, especially if the entity changes | |
6961 near the time that the response is generated. | |
6962 | |
6963 HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. | |
6964 | |
6965 14.30 Location | |
6966 | |
6967 The Location response-header field is used to redirect the recipient | |
6968 to a location other than the Request-URI for completion of the | |
6969 request or identification of a new resource. For 201 (Created) | |
6970 responses, the Location is that of the new resource which was created | |
6971 by the request. For 3xx responses, the location SHOULD indicate the | |
6972 server's preferred URL for automatic redirection to the resource. The | |
6973 field value consists of a single absolute URL. | |
6974 | |
6975 Location = "Location" ":" absoluteURI | |
6976 | |
6977 An example is | |
6978 | |
6979 Location: http://www.w3.org/pub/WWW/People.html | |
6980 | |
6981 Note: The Content-Location header field (section 14.15) differs | |
6982 from Location in that the Content-Location identifies the original | |
6983 location of the entity enclosed in the request. It is therefore | |
6984 possible for a response to contain header fields for both Location | |
6985 and Content-Location. Also see section 13.10 for cache requirements | |
6986 of some methods. | |
6987 | |
6988 14.31 Max-Forwards | |
6989 | |
6990 The Max-Forwards request-header field may be used with the TRACE | |
6991 method (section 14.31) to limit the number of proxies or gateways | |
6992 that can forward the request to the next inbound server. This can be | |
6993 useful when the client is attempting to trace a request chain which | |
6994 appears to be failing or looping in mid-chain. | |
6995 | |
6996 Max-Forwards = "Max-Forwards" ":" 1*DIGIT | |
6997 | |
6998 | |
6999 | |
7000 | |
7001 | |
7002 Fielding, et. al. Standards Track [Page 125] | |
7003 | |
7004 RFC 2068 HTTP/1.1 January 1997 | |
7005 | |
7006 | |
7007 The Max-Forwards value is a decimal integer indicating the remaining | |
7008 number of times this request message may be forwarded. | |
7009 | |
7010 Each proxy or gateway recipient of a TRACE request containing a Max- | |
7011 Forwards header field SHOULD check and update its value prior to | |
7012 forwarding the request. If the received value is zero (0), the | |
7013 recipient SHOULD NOT forward the request; instead, it SHOULD respond | |
7014 as the final recipient with a 200 (OK) response containing the | |
7015 received request message as the response entity-body (as described in | |
7016 section 9.8). If the received Max-Forwards value is greater than | |
7017 zero, then the forwarded message SHOULD contain an updated Max- | |
7018 Forwards field with a value decremented by one (1). | |
7019 | |
7020 The Max-Forwards header field SHOULD be ignored for all other methods | |
7021 defined by this specification and for any extension methods for which | |
7022 it is not explicitly referred to as part of that method definition. | |
7023 | |
7024 14.32 Pragma | |
7025 | |
7026 The Pragma general-header field is used to include implementation- | |
7027 specific directives that may apply to any recipient along the | |
7028 request/response chain. All pragma directives specify optional | |
7029 behavior from the viewpoint of the protocol; however, some systems | |
7030 MAY require that behavior be consistent with the directives. | |
7031 | |
7032 Pragma = "Pragma" ":" 1#pragma-directive | |
7033 | |
7034 pragma-directive = "no-cache" | extension-pragma | |
7035 extension-pragma = token [ "=" ( token | quoted-string ) ] | |
7036 | |
7037 When the no-cache directive is present in a request message, an | |
7038 application SHOULD forward the request toward the origin server even | |
7039 if it has a cached copy of what is being requested. This pragma | |
7040 directive has the same semantics as the no-cache cache-directive (see | |
7041 section 14.9) and is defined here for backwards compatibility with | |
7042 HTTP/1.0. Clients SHOULD include both header fields when a no-cache | |
7043 request is sent to a server not known to be HTTP/1.1 compliant. | |
7044 | |
7045 Pragma directives MUST be passed through by a proxy or gateway | |
7046 application, regardless of their significance to that application, | |
7047 since the directives may be applicable to all recipients along the | |
7048 request/response chain. It is not possible to specify a pragma for a | |
7049 specific recipient; however, any pragma directive not relevant to a | |
7050 recipient SHOULD be ignored by that recipient. | |
7051 | |
7052 | |
7053 | |
7054 | |
7055 | |
7056 | |
7057 | |
7058 Fielding, et. al. Standards Track [Page 126] | |
7059 | |
7060 RFC 2068 HTTP/1.1 January 1997 | |
7061 | |
7062 | |
7063 HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1 | |
7064 caches SHOULD treat "Pragma: no-cache" as if the client had sent | |
7065 "Cache-Control: no-cache". No new Pragma directives will be defined | |
7066 in HTTP. | |
7067 | |
7068 14.33 Proxy-Authenticate | |
7069 | |
7070 The Proxy-Authenticate response-header field MUST be included as part | |
7071 of a 407 (Proxy Authentication Required) response. The field value | |
7072 consists of a challenge that indicates the authentication scheme and | |
7073 parameters applicable to the proxy for this Request-URI. | |
7074 | |
7075 Proxy-Authenticate = "Proxy-Authenticate" ":" challenge | |
7076 | |
7077 The HTTP access authentication process is described in section 11. | |
7078 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | |
7079 only to the current connection and SHOULD NOT be passed on to | |
7080 downstream clients. However, an intermediate proxy may need to obtain | |
7081 its own credentials by requesting them from the downstream client, | |
7082 which in some circumstances will appear as if the proxy is forwarding | |
7083 the Proxy-Authenticate header field. | |
7084 | |
7085 14.34 Proxy-Authorization | |
7086 | |
7087 The Proxy-Authorization request-header field allows the client to | |
7088 identify itself (or its user) to a proxy which requires | |
7089 authentication. The Proxy-Authorization field value consists of | |
7090 credentials containing the authentication information of the user | |
7091 agent for the proxy and/or realm of the resource being requested. | |
7092 | |
7093 Proxy-Authorization = "Proxy-Authorization" ":" credentials | |
7094 | |
7095 The HTTP access authentication process is described in section 11. | |
7096 Unlike Authorization, the Proxy-Authorization header field applies | |
7097 only to the next outbound proxy that demanded authentication using | |
7098 the Proxy-Authenticate field. When multiple proxies are used in a | |
7099 chain, the Proxy-Authorization header field is consumed by the first | |
7100 outbound proxy that was expecting to receive credentials. A proxy MAY | |
7101 relay the credentials from the client request to the next proxy if | |
7102 that is the mechanism by which the proxies cooperatively authenticate | |
7103 a given request. | |
7104 | |
7105 14.35 Public | |
7106 | |
7107 The Public response-header field lists the set of methods supported | |
7108 by the server. The purpose of this field is strictly to inform the | |
7109 recipient of the capabilities of the server regarding unusual | |
7110 methods. The methods listed may or may not be applicable to the | |
7111 | |
7112 | |
7113 | |
7114 Fielding, et. al. Standards Track [Page 127] | |
7115 | |
7116 RFC 2068 HTTP/1.1 January 1997 | |
7117 | |
7118 | |
7119 Request-URI; the Allow header field (section 14.7) MAY be used to | |
7120 indicate methods allowed for a particular URI. | |
7121 | |
7122 Public = "Public" ":" 1#method | |
7123 | |
7124 Example of use: | |
7125 | |
7126 Public: OPTIONS, MGET, MHEAD, GET, HEAD | |
7127 | |
7128 This header field applies only to the server directly connected to | |
7129 the client (i.e., the nearest neighbor in a chain of connections). If | |
7130 the response passes through a proxy, the proxy MUST either remove the | |
7131 Public header field or replace it with one applicable to its own | |
7132 capabilities. | |
7133 | |
7134 14.36 Range | |
7135 | |
7136 14.36.1 Byte Ranges | |
7137 | |
7138 Since all HTTP entities are represented in HTTP messages as sequences | |
7139 of bytes, the concept of a byte range is meaningful for any HTTP | |
7140 entity. (However, not all clients and servers need to support byte- | |
7141 range operations.) | |
7142 | |
7143 Byte range specifications in HTTP apply to the sequence of bytes in | |
7144 the entity-body (not necessarily the same as the message-body). | |
7145 | |
7146 A byte range operation may specify a single range of bytes, or a set | |
7147 of ranges within a single entity. | |
7148 | |
7149 ranges-specifier = byte-ranges-specifier | |
7150 | |
7151 byte-ranges-specifier = bytes-unit "=" byte-range-set | |
7152 | |
7153 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | |
7154 | |
7155 byte-range-spec = first-byte-pos "-" [last-byte-pos] | |
7156 | |
7157 first-byte-pos = 1*DIGIT | |
7158 | |
7159 last-byte-pos = 1*DIGIT | |
7160 | |
7161 The first-byte-pos value in a byte-range-spec gives the byte-offset | |
7162 of the first byte in a range. The last-byte-pos value gives the | |
7163 byte-offset of the last byte in the range; that is, the byte | |
7164 positions specified are inclusive. Byte offsets start at zero. | |
7165 | |
7166 | |
7167 | |
7168 | |
7169 | |
7170 Fielding, et. al. Standards Track [Page 128] | |
7171 | |
7172 RFC 2068 HTTP/1.1 January 1997 | |
7173 | |
7174 | |
7175 If the last-byte-pos value is present, it must be greater than or | |
7176 equal to the first-byte-pos in that byte-range-spec, or the byte- | |
7177 range-spec is invalid. The recipient of an invalid byte-range-spec | |
7178 must ignore it. | |
7179 | |
7180 If the last-byte-pos value is absent, or if the value is greater than | |
7181 or equal to the current length of the entity-body, last-byte-pos is | |
7182 taken to be equal to one less than the current length of the entity- | |
7183 body in bytes. | |
7184 | |
7185 By its choice of last-byte-pos, a client can limit the number of | |
7186 bytes retrieved without knowing the size of the entity. | |
7187 | |
7188 suffix-byte-range-spec = "-" suffix-length | |
7189 | |
7190 suffix-length = 1*DIGIT | |
7191 | |
7192 A suffix-byte-range-spec is used to specify the suffix of the | |
7193 entity-body, of a length given by the suffix-length value. (That is, | |
7194 this form specifies the last N bytes of an entity-body.) If the | |
7195 entity is shorter than the specified suffix-length, the entire | |
7196 entity-body is used. | |
7197 | |
7198 Examples of byte-ranges-specifier values (assuming an entity-body of | |
7199 length 10000): | |
7200 | |
7201 o The first 500 bytes (byte offsets 0-499, inclusive): | |
7202 | |
7203 bytes=0-499 | |
7204 | |
7205 o The second 500 bytes (byte offsets 500-999, inclusive): | |
7206 | |
7207 bytes=500-999 | |
7208 | |
7209 o The final 500 bytes (byte offsets 9500-9999, inclusive): | |
7210 | |
7211 bytes=-500 | |
7212 | |
7213 o Or | |
7214 | |
7215 bytes=9500- | |
7216 | |
7217 o The first and last bytes only (bytes 0 and 9999): | |
7218 | |
7219 bytes=0-0,-1 | |
7220 | |
7221 | |
7222 | |
7223 | |
7224 | |
7225 | |
7226 Fielding, et. al. Standards Track [Page 129] | |
7227 | |
7228 RFC 2068 HTTP/1.1 January 1997 | |
7229 | |
7230 | |
7231 o Several legal but not canonical specifications of the second | |
7232 500 bytes (byte offsets 500-999, inclusive): | |
7233 | |
7234 bytes=500-600,601-999 | |
7235 | |
7236 bytes=500-700,601-999 | |
7237 | |
7238 14.36.2 Range Retrieval Requests | |
7239 | |
7240 HTTP retrieval requests using conditional or unconditional GET | |
7241 methods may request one or more sub-ranges of the entity, instead of | |
7242 the entire entity, using the Range request header, which applies to | |
7243 the entity returned as the result of the request: | |
7244 | |
7245 Range = "Range" ":" ranges-specifier | |
7246 | |
7247 A server MAY ignore the Range header. However, HTTP/1.1 origin | |
7248 servers and intermediate caches SHOULD support byte ranges when | |
7249 possible, since Range supports efficient recovery from partially | |
7250 failed transfers, and supports efficient partial retrieval of large | |
7251 entities. | |
7252 | |
7253 If the server supports the Range header and the specified range or | |
7254 ranges are appropriate for the entity: | |
7255 | |
7256 o The presence of a Range header in an unconditional GET modifies | |
7257 what is returned if the GET is otherwise successful. In other | |
7258 words, the response carries a status code of 206 (Partial | |
7259 Content) instead of 200 (OK). | |
7260 | |
7261 o The presence of a Range header in a conditional GET (a request | |
7262 using one or both of If-Modified-Since and If-None-Match, or | |
7263 one or both of If-Unmodified-Since and If-Match) modifies what | |
7264 is returned if the GET is otherwise successful and the condition | |
7265 is true. It does not affect the 304 (Not Modified) response | |
7266 returned if the conditional is false. | |
7267 | |
7268 In some cases, it may be more appropriate to use the If-Range header | |
7269 (see section 14.27) in addition to the Range header. | |
7270 | |
7271 If a proxy that supports ranges receives a Range request, forwards | |
7272 the request to an inbound server, and receives an entire entity in | |
7273 reply, it SHOULD only return the requested range to its client. It | |
7274 SHOULD store the entire received response in its cache, if that is | |
7275 consistent with its cache allocation policies. | |
7276 | |
7277 | |
7278 | |
7279 | |
7280 | |
7281 | |
7282 Fielding, et. al. Standards Track [Page 130] | |
7283 | |
7284 RFC 2068 HTTP/1.1 January 1997 | |
7285 | |
7286 | |
7287 14.37 Referer | |
7288 | |
7289 The Referer[sic] request-header field allows the client to specify, | |
7290 for the server's benefit, the address (URI) of the resource from | |
7291 which the Request-URI was obtained (the "referrer", although the | |
7292 header field is misspelled.) The Referer request-header allows a | |
7293 server to generate lists of back-links to resources for interest, | |
7294 logging, optimized caching, etc. It also allows obsolete or mistyped | |
7295 links to be traced for maintenance. The Referer field MUST NOT be | |
7296 sent if the Request-URI was obtained from a source that does not have | |
7297 its own URI, such as input from the user keyboard. | |
7298 | |
7299 Referer = "Referer" ":" ( absoluteURI | relativeURI ) | |
7300 | |
7301 Example: | |
7302 | |
7303 Referer: http://www.w3.org/hypertext/DataSources/Overview.html | |
7304 | |
7305 If the field value is a partial URI, it SHOULD be interpreted | |
7306 relative to the Request-URI. The URI MUST NOT include a fragment. | |
7307 | |
7308 Note: Because the source of a link may be private information or | |
7309 may reveal an otherwise private information source, it is strongly | |
7310 recommended that the user be able to select whether or not the | |
7311 Referer field is sent. For example, a browser client could have a | |
7312 toggle switch for browsing openly/anonymously, which would | |
7313 respectively enable/disable the sending of Referer and From | |
7314 information. | |
7315 | |
7316 14.38 Retry-After | |
7317 | |
7318 The Retry-After response-header field can be used with a 503 (Service | |
7319 Unavailable) response to indicate how long the service is expected to | |
7320 be unavailable to the requesting client. The value of this field can | |
7321 be either an HTTP-date or an integer number of seconds (in decimal) | |
7322 after the time of the response. | |
7323 | |
7324 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | |
7325 | |
7326 Two examples of its use are | |
7327 | |
7328 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | |
7329 Retry-After: 120 | |
7330 | |
7331 In the latter example, the delay is 2 minutes. | |
7332 | |
7333 | |
7334 | |
7335 | |
7336 | |
7337 | |
7338 Fielding, et. al. Standards Track [Page 131] | |
7339 | |
7340 RFC 2068 HTTP/1.1 January 1997 | |
7341 | |
7342 | |
7343 14.39 Server | |
7344 | |
7345 The Server response-header field contains information about the | |
7346 software used by the origin server to handle the request. The field | |
7347 can contain multiple product tokens (section 3.8) and comments | |
7348 identifying the server and any significant subproducts. The product | |
7349 tokens are listed in order of their significance for identifying the | |
7350 application. | |
7351 | |
7352 Server = "Server" ":" 1*( product | comment ) | |
7353 | |
7354 Example: | |
7355 | |
7356 Server: CERN/3.0 libwww/2.17 | |
7357 | |
7358 If the response is being forwarded through a proxy, the proxy | |
7359 application MUST NOT modify the Server response-header. Instead, it | |
7360 SHOULD include a Via field (as described in section 14.44). | |
7361 | |
7362 Note: Revealing the specific software version of the server may | |
7363 allow the server machine to become more vulnerable to attacks | |
7364 against software that is known to contain security holes. Server | |
7365 implementers are encouraged to make this field a configurable | |
7366 option. | |
7367 | |
7368 14.40 Transfer-Encoding | |
7369 | |
7370 The Transfer-Encoding general-header field indicates what (if any) | |
7371 type of transformation has been applied to the message body in order | |
7372 to safely transfer it between the sender and the recipient. This | |
7373 differs from the Content-Encoding in that the transfer coding is a | |
7374 property of the message, not of the entity. | |
7375 | |
7376 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer- | |
7377 coding | |
7378 | |
7379 Transfer codings are defined in section 3.6. An example is: | |
7380 | |
7381 Transfer-Encoding: chunked | |
7382 | |
7383 Many older HTTP/1.0 applications do not understand the Transfer- | |
7384 Encoding header. | |
7385 | |
7386 14.41 Upgrade | |
7387 | |
7388 The Upgrade general-header allows the client to specify what | |
7389 additional communication protocols it supports and would like to use | |
7390 if the server finds it appropriate to switch protocols. The server | |
7391 | |
7392 | |
7393 | |
7394 Fielding, et. al. Standards Track [Page 132] | |
7395 | |
7396 RFC 2068 HTTP/1.1 January 1997 | |
7397 | |
7398 | |
7399 MUST use the Upgrade header field within a 101 (Switching Protocols) | |
7400 response to indicate which protocol(s) are being switched. | |
7401 | |
7402 Upgrade = "Upgrade" ":" 1#product | |
7403 | |
7404 For example, | |
7405 | |
7406 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | |
7407 | |
7408 The Upgrade header field is intended to provide a simple mechanism | |
7409 for transition from HTTP/1.1 to some other, incompatible protocol. It | |
7410 does so by allowing the client to advertise its desire to use another | |
7411 protocol, such as a later version of HTTP with a higher major version | |
7412 number, even though the current request has been made using HTTP/1.1. | |
7413 This eases the difficult transition between incompatible protocols by | |
7414 allowing the client to initiate a request in the more commonly | |
7415 supported protocol while indicating to the server that it would like | |
7416 to use a "better" protocol if available (where "better" is determined | |
7417 by the server, possibly according to the nature of the method and/or | |
7418 resource being requested). | |
7419 | |
7420 The Upgrade header field only applies to switching application-layer | |
7421 protocols upon the existing transport-layer connection. Upgrade | |
7422 cannot be used to insist on a protocol change; its acceptance and use | |
7423 by the server is optional. The capabilities and nature of the | |
7424 application-layer communication after the protocol change is entirely | |
7425 dependent upon the new protocol chosen, although the first action | |
7426 after changing the protocol MUST be a response to the initial HTTP | |
7427 request containing the Upgrade header field. | |
7428 | |
7429 The Upgrade header field only applies to the immediate connection. | |
7430 Therefore, the upgrade keyword MUST be supplied within a Connection | |
7431 header field (section 14.10) whenever Upgrade is present in an | |
7432 HTTP/1.1 message. | |
7433 | |
7434 The Upgrade header field cannot be used to indicate a switch to a | |
7435 protocol on a different connection. For that purpose, it is more | |
7436 appropriate to use a 301, 302, 303, or 305 redirection response. | |
7437 | |
7438 This specification only defines the protocol name "HTTP" for use by | |
7439 the family of Hypertext Transfer Protocols, as defined by the HTTP | |
7440 version rules of section 3.1 and future updates to this | |
7441 specification. Any token can be used as a protocol name; however, it | |
7442 will only be useful if both the client and server associate the name | |
7443 with the same protocol. | |
7444 | |
7445 | |
7446 | |
7447 | |
7448 | |
7449 | |
7450 Fielding, et. al. Standards Track [Page 133] | |
7451 | |
7452 RFC 2068 HTTP/1.1 January 1997 | |
7453 | |
7454 | |
7455 14.42 User-Agent | |
7456 | |
7457 The User-Agent request-header field contains information about the | |
7458 user agent originating the request. This is for statistical purposes, | |
7459 the tracing of protocol violations, and automated recognition of user | |
7460 agents for the sake of tailoring responses to avoid particular user | |
7461 agent limitations. User agents SHOULD include this field with | |
7462 requests. The field can contain multiple product tokens (section 3.8) | |
7463 and comments identifying the agent and any subproducts which form a | |
7464 significant part of the user agent. By convention, the product tokens | |
7465 are listed in order of their significance for identifying the | |
7466 application. | |
7467 | |
7468 User-Agent = "User-Agent" ":" 1*( product | comment ) | |
7469 | |
7470 Example: | |
7471 | |
7472 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |
7473 | |
7474 14.43 Vary | |
7475 | |
7476 The Vary response-header field is used by a server to signal that the | |
7477 response entity was selected from the available representations of | |
7478 the response using server-driven negotiation (section 12). Field- | |
7479 names listed in Vary headers are those of request-headers. The Vary | |
7480 field value indicates either that the given set of header fields | |
7481 encompass the dimensions over which the representation might vary, or | |
7482 that the dimensions of variance are unspecified ("*") and thus may | |
7483 vary over any aspect of future requests. | |
7484 | |
7485 Vary = "Vary" ":" ( "*" | 1#field-name ) | |
7486 | |
7487 An HTTP/1.1 server MUST include an appropriate Vary header field with | |
7488 any cachable response that is subject to server-driven negotiation. | |
7489 Doing so allows a cache to properly interpret future requests on that | |
7490 resource and informs the user agent about the presence of negotiation | |
7491 on that resource. A server SHOULD include an appropriate Vary header | |
7492 field with a non-cachable response that is subject to server-driven | |
7493 negotiation, since this might provide the user agent with useful | |
7494 information about the dimensions over which the response might vary. | |
7495 | |
7496 The set of header fields named by the Vary field value is known as | |
7497 the "selecting" request-headers. | |
7498 | |
7499 When the cache receives a subsequent request whose Request-URI | |
7500 specifies one or more cache entries including a Vary header, the | |
7501 cache MUST NOT use such a cache entry to construct a response to the | |
7502 new request unless all of the headers named in the cached Vary header | |
7503 | |
7504 | |
7505 | |
7506 Fielding, et. al. Standards Track [Page 134] | |
7507 | |
7508 RFC 2068 HTTP/1.1 January 1997 | |
7509 | |
7510 | |
7511 are present in the new request, and all of the stored selecting | |
7512 request-headers from the previous request match the corresponding | |
7513 headers in the new request. | |
7514 | |
7515 The selecting request-headers from two requests are defined to match | |
7516 if and only if the selecting request-headers in the first request can | |
7517 be transformed to the selecting request-headers in the second request | |
7518 by adding or removing linear whitespace (LWS) at places where this is | |
7519 allowed by the corresponding BNF, and/or combining multiple message- | |
7520 header fields with the same field name following the rules about | |
7521 message headers in section 4.2. | |
7522 | |
7523 A Vary field value of "*" signals that unspecified parameters, | |
7524 possibly other than the contents of request-header fields (e.g., the | |
7525 network address of the client), play a role in the selection of the | |
7526 response representation. Subsequent requests on that resource can | |
7527 only be properly interpreted by the origin server, and thus a cache | |
7528 MUST forward a (possibly conditional) request even when it has a | |
7529 fresh response cached for the resource. See section 13.6 for use of | |
7530 the Vary header by caches. | |
7531 | |
7532 A Vary field value consisting of a list of field-names signals that | |
7533 the representation selected for the response is based on a selection | |
7534 algorithm which considers ONLY the listed request-header field values | |
7535 in selecting the most appropriate representation. A cache MAY assume | |
7536 that the same selection will be made for future requests with the | |
7537 same values for the listed field names, for the duration of time in | |
7538 which the response is fresh. | |
7539 | |
7540 The field-names given are not limited to the set of standard | |
7541 request-header fields defined by this specification. Field names are | |
7542 case-insensitive. | |
7543 | |
7544 14.44 Via | |
7545 | |
7546 The Via general-header field MUST be used by gateways and proxies to | |
7547 indicate the intermediate protocols and recipients between the user | |
7548 agent and the server on requests, and between the origin server and | |
7549 the client on responses. It is analogous to the "Received" field of | |
7550 RFC 822 and is intended to be used for tracking message forwards, | |
7551 avoiding request loops, and identifying the protocol capabilities of | |
7552 all senders along the request/response chain. | |
7553 | |
7554 | |
7555 | |
7556 | |
7557 | |
7558 | |
7559 | |
7560 | |
7561 | |
7562 Fielding, et. al. Standards Track [Page 135] | |
7563 | |
7564 RFC 2068 HTTP/1.1 January 1997 | |
7565 | |
7566 | |
7567 Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |
7568 | |
7569 received-protocol = [ protocol-name "/" ] protocol-version | |
7570 protocol-name = token | |
7571 protocol-version = token | |
7572 received-by = ( host [ ":" port ] ) | pseudonym | |
7573 pseudonym = token | |
7574 | |
7575 The received-protocol indicates the protocol version of the message | |
7576 received by the server or client along each segment of the | |
7577 request/response chain. The received-protocol version is appended to | |
7578 the Via field value when the message is forwarded so that information | |
7579 about the protocol capabilities of upstream applications remains | |
7580 visible to all recipients. | |
7581 | |
7582 The protocol-name is optional if and only if it would be "HTTP". The | |
7583 received-by field is normally the host and optional port number of a | |
7584 recipient server or client that subsequently forwarded the message. | |
7585 However, if the real host is considered to be sensitive information, | |
7586 it MAY be replaced by a pseudonym. If the port is not given, it MAY | |
7587 be assumed to be the default port of the received-protocol. | |
7588 | |
7589 Multiple Via field values represent each proxy or gateway that has | |
7590 forwarded the message. Each recipient MUST append its information | |
7591 such that the end result is ordered according to the sequence of | |
7592 forwarding applications. | |
7593 | |
7594 Comments MAY be used in the Via header field to identify the software | |
7595 of the recipient proxy or gateway, analogous to the User-Agent and | |
7596 Server header fields. However, all comments in the Via field are | |
7597 optional and MAY be removed by any recipient prior to forwarding the | |
7598 message. | |
7599 | |
7600 For example, a request message could be sent from an HTTP/1.0 user | |
7601 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to | |
7602 forward the request to a public proxy at nowhere.com, which completes | |
7603 the request by forwarding it to the origin server at www.ics.uci.edu. | |
7604 The request received by www.ics.uci.edu would then have the following | |
7605 Via header field: | |
7606 | |
7607 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) | |
7608 | |
7609 Proxies and gateways used as a portal through a network firewall | |
7610 SHOULD NOT, by default, forward the names and ports of hosts within | |
7611 the firewall region. This information SHOULD only be propagated if | |
7612 explicitly enabled. If not enabled, the received-by host of any host | |
7613 behind the firewall SHOULD be replaced by an appropriate pseudonym | |
7614 for that host. | |
7615 | |
7616 | |
7617 | |
7618 Fielding, et. al. Standards Track [Page 136] | |
7619 | |
7620 RFC 2068 HTTP/1.1 January 1997 | |
7621 | |
7622 | |
7623 For organizations that have strong privacy requirements for hiding | |
7624 internal structures, a proxy MAY combine an ordered subsequence of | |
7625 Via header field entries with identical received-protocol values into | |
7626 a single such entry. For example, | |
7627 | |
7628 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy | |
7629 | |
7630 could be collapsed to | |
7631 | |
7632 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | |
7633 | |
7634 Applications SHOULD NOT combine multiple entries unless they are all | |
7635 under the same organizational control and the hosts have already been | |
7636 replaced by pseudonyms. Applications MUST NOT combine entries which | |
7637 have different received-protocol values. | |
7638 | |
7639 14.45 Warning | |
7640 | |
7641 The Warning response-header field is used to carry additional | |
7642 information about the status of a response which may not be reflected | |
7643 by the response status code. This information is typically, though | |
7644 not exclusively, used to warn about a possible lack of semantic | |
7645 transparency from caching operations. | |
7646 | |
7647 Warning headers are sent with responses using: | |
7648 | |
7649 Warning = "Warning" ":" 1#warning-value | |
7650 | |
7651 warning-value = warn-code SP warn-agent SP warn-text | |
7652 warn-code = 2DIGIT | |
7653 warn-agent = ( host [ ":" port ] ) | pseudonym | |
7654 ; the name or pseudonym of the server adding | |
7655 ; the Warning header, for use in debugging | |
7656 warn-text = quoted-string | |
7657 | |
7658 A response may carry more than one Warning header. | |
7659 | |
7660 The warn-text should be in a natural language and character set that | |
7661 is most likely to be intelligible to the human user receiving the | |
7662 response. This decision may be based on any available knowledge, | |
7663 such as the location of the cache or user, the Accept-Language field | |
7664 in a request, the Content-Language field in a response, etc. The | |
7665 default language is English and the default character set is ISO- | |
7666 8859-1. | |
7667 | |
7668 If a character set other than ISO-8859-1 is used, it MUST be encoded | |
7669 in the warn-text using the method described in RFC 1522 [14]. | |
7670 | |
7671 | |
7672 | |
7673 | |
7674 Fielding, et. al. Standards Track [Page 137] | |
7675 | |
7676 RFC 2068 HTTP/1.1 January 1997 | |
7677 | |
7678 | |
7679 Any server or cache may add Warning headers to a response. New | |
7680 Warning headers should be added after any existing Warning headers. A | |
7681 cache MUST NOT delete any Warning header that it received with a | |
7682 response. However, if a cache successfully validates a cache entry, | |
7683 it SHOULD remove any Warning headers previously attached to that | |
7684 entry except as specified for specific Warning codes. It MUST then | |
7685 add any Warning headers received in the validating response. In other | |
7686 words, Warning headers are those that would be attached to the most | |
7687 recent relevant response. | |
7688 | |
7689 When multiple Warning headers are attached to a response, the user | |
7690 agent SHOULD display as many of them as possible, in the order that | |
7691 they appear in the response. If it is not possible to display all of | |
7692 the warnings, the user agent should follow these heuristics: | |
7693 | |
7694 o Warnings that appear early in the response take priority over those | |
7695 appearing later in the response. | |
7696 o Warnings in the user's preferred character set take priority over | |
7697 warnings in other character sets but with identical warn-codes and | |
7698 warn-agents. | |
7699 | |
7700 Systems that generate multiple Warning headers should order them with | |
7701 this user agent behavior in mind. | |
7702 | |
7703 This is a list of the currently-defined warn-codes, each with a | |
7704 recommended warn-text in English, and a description of its meaning. | |
7705 | |
7706 10 Response is stale | |
7707 MUST be included whenever the returned response is stale. A cache may | |
7708 add this warning to any response, but may never remove it until the | |
7709 response is known to be fresh. | |
7710 | |
7711 11 Revalidation failed | |
7712 MUST be included if a cache returns a stale response because an | |
7713 attempt to revalidate the response failed, due to an inability to | |
7714 reach the server. A cache may add this warning to any response, but | |
7715 may never remove it until the response is successfully revalidated. | |
7716 | |
7717 12 Disconnected operation | |
7718 SHOULD be included if the cache is intentionally disconnected from | |
7719 the rest of the network for a period of time. | |
7720 | |
7721 13 Heuristic expiration | |
7722 MUST be included if the cache heuristically chose a freshness | |
7723 lifetime greater than 24 hours and the response's age is greater than | |
7724 24 hours. | |
7725 | |
7726 | |
7727 | |
7728 | |
7729 | |
7730 Fielding, et. al. Standards Track [Page 138] | |
7731 | |
7732 RFC 2068 HTTP/1.1 January 1997 | |
7733 | |
7734 | |
7735 14 Transformation applied | |
7736 MUST be added by an intermediate cache or proxy if it applies any | |
7737 transformation changing the content-coding (as specified in the | |
7738 Content-Encoding header) or media-type (as specified in the | |
7739 Content-Type header) of the response, unless this Warning code | |
7740 already appears in the response. MUST NOT be deleted from a response | |
7741 even after revalidation. | |
7742 | |
7743 99 Miscellaneous warning | |
7744 The warning text may include arbitrary information to be presented to | |
7745 a human user, or logged. A system receiving this warning MUST NOT | |
7746 take any automated action. | |
7747 | |
7748 14.46 WWW-Authenticate | |
7749 | |
7750 The WWW-Authenticate response-header field MUST be included in 401 | |
7751 (Unauthorized) response messages. The field value consists of at | |
7752 least one challenge that indicates the authentication scheme(s) and | |
7753 parameters applicable to the Request-URI. | |
7754 | |
7755 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | |
7756 | |
7757 The HTTP access authentication process is described in section 11. | |
7758 User agents MUST take special care in parsing the WWW-Authenticate | |
7759 field value if it contains more than one challenge, or if more than | |
7760 one WWW-Authenticate header field is provided, since the contents of | |
7761 a challenge may itself contain a comma-separated list of | |
7762 authentication parameters. | |
7763 | |
7764 15 Security Considerations | |
7765 | |
7766 This section is meant to inform application developers, information | |
7767 providers, and users of the security limitations in HTTP/1.1 as | |
7768 described by this document. The discussion does not include | |
7769 definitive solutions to the problems revealed, though it does make | |
7770 some suggestions for reducing security risks. | |
7771 | |
7772 15.1 Authentication of Clients | |
7773 | |
7774 The Basic authentication scheme is not a secure method of user | |
7775 authentication, nor does it in any way protect the entity, which is | |
7776 transmitted in clear text across the physical network used as the | |
7777 carrier. HTTP does not prevent additional authentication schemes and | |
7778 encryption mechanisms from being employed to increase security or the | |
7779 addition of enhancements (such as schemes to use one-time passwords) | |
7780 to Basic authentication. | |
7781 | |
7782 | |
7783 | |
7784 | |
7785 | |
7786 Fielding, et. al. Standards Track [Page 139] | |
7787 | |
7788 RFC 2068 HTTP/1.1 January 1997 | |
7789 | |
7790 | |
7791 The most serious flaw in Basic authentication is that it results in | |
7792 the essentially clear text transmission of the user's password over | |
7793 the physical network. It is this problem which Digest Authentication | |
7794 attempts to address. | |
7795 | |
7796 Because Basic authentication involves the clear text transmission of | |
7797 passwords it SHOULD never be used (without enhancements) to protect | |
7798 sensitive or valuable information. | |
7799 | |
7800 A common use of Basic authentication is for identification purposes | |
7801 -- requiring the user to provide a user name and password as a means | |
7802 of identification, for example, for purposes of gathering accurate | |
7803 usage statistics on a server. When used in this way it is tempting to | |
7804 think that there is no danger in its use if illicit access to the | |
7805 protected documents is not a major concern. This is only correct if | |
7806 the server issues both user name and password to the users and in | |
7807 particular does not allow the user to choose his or her own password. | |
7808 The danger arises because naive users frequently reuse a single | |
7809 password to avoid the task of maintaining multiple passwords. | |
7810 | |
7811 If a server permits users to select their own passwords, then the | |
7812 threat is not only illicit access to documents on the server but also | |
7813 illicit access to the accounts of all users who have chosen to use | |
7814 their account password. If users are allowed to choose their own | |
7815 password that also means the server must maintain files containing | |
7816 the (presumably encrypted) passwords. Many of these may be the | |
7817 account passwords of users perhaps at distant sites. The owner or | |
7818 administrator of such a system could conceivably incur liability if | |
7819 this information is not maintained in a secure fashion. | |
7820 | |
7821 Basic Authentication is also vulnerable to spoofing by counterfeit | |
7822 servers. If a user can be led to believe that he is connecting to a | |
7823 host containing information protected by basic authentication when in | |
7824 fact he is connecting to a hostile server or gateway then the | |
7825 attacker can request a password, store it for later use, and feign an | |
7826 error. This type of attack is not possible with Digest Authentication | |
7827 [32]. Server implementers SHOULD guard against the possibility of | |
7828 this sort of counterfeiting by gateways or CGI scripts. In particular | |
7829 it is very dangerous for a server to simply turn over a connection to | |
7830 a gateway since that gateway can then use the persistent connection | |
7831 mechanism to engage in multiple transactions with the client while | |
7832 impersonating the original server in a way that is not detectable by | |
7833 the client. | |
7834 | |
7835 15.2 Offering a Choice of Authentication Schemes | |
7836 | |
7837 An HTTP/1.1 server may return multiple challenges with a 401 | |
7838 (Authenticate) response, and each challenge may use a different | |
7839 | |
7840 | |
7841 | |
7842 Fielding, et. al. Standards Track [Page 140] | |
7843 | |
7844 RFC 2068 HTTP/1.1 January 1997 | |
7845 | |
7846 | |
7847 scheme. The order of the challenges returned to the user agent is in | |
7848 the order that the server would prefer they be chosen. The server | |
7849 should order its challenges with the "most secure" authentication | |
7850 scheme first. A user agent should choose as the challenge to be made | |
7851 to the user the first one that the user agent understands. | |
7852 | |
7853 When the server offers choices of authentication schemes using the | |
7854 WWW-Authenticate header, the "security" of the authentication is only | |
7855 as malicious user could capture the set of challenges and try to | |
7856 authenticate him/herself using the weakest of the authentication | |
7857 schemes. Thus, the ordering serves more to protect the user's | |
7858 credentials than the server's information. | |
7859 | |
7860 A possible man-in-the-middle (MITM) attack would be to add a weak | |
7861 authentication scheme to the set of choices, hoping that the client | |
7862 will use one that exposes the user's credentials (e.g. password). For | |
7863 this reason, the client should always use the strongest scheme that | |
7864 it understands from the choices accepted. | |
7865 | |
7866 An even better MITM attack would be to remove all offered choices, | |
7867 and to insert a challenge that requests Basic authentication. For | |
7868 this reason, user agents that are concerned about this kind of attack | |
7869 could remember the strongest authentication scheme ever requested by | |
7870 a server and produce a warning message that requires user | |
7871 confirmation before using a weaker one. A particularly insidious way | |
7872 to mount such a MITM attack would be to offer a "free" proxy caching | |
7873 service to gullible users. | |
7874 | |
7875 15.3 Abuse of Server Log Information | |
7876 | |
7877 A server is in the position to save personal data about a user's | |
7878 requests which may identify their reading patterns or subjects of | |
7879 interest. This information is clearly confidential in nature and its | |
7880 handling may be constrained by law in certain countries. People using | |
7881 the HTTP protocol to provide data are responsible for ensuring that | |
7882 such material is not distributed without the permission of any | |
7883 individuals that are identifiable by the published results. | |
7884 | |
7885 15.4 Transfer of Sensitive Information | |
7886 | |
7887 Like any generic data transfer protocol, HTTP cannot regulate the | |
7888 content of the data that is transferred, nor is there any a priori | |
7889 method of determining the sensitivity of any particular piece of | |
7890 information within the context of any given request. Therefore, | |
7891 applications SHOULD supply as much control over this information as | |
7892 possible to the provider of that information. Four header fields are | |
7893 worth special mention in this context: Server, Via, Referer and From. | |
7894 | |
7895 | |
7896 | |
7897 | |
7898 Fielding, et. al. Standards Track [Page 141] | |
7899 | |
7900 RFC 2068 HTTP/1.1 January 1997 | |
7901 | |
7902 | |
7903 Revealing the specific software version of the server may allow the | |
7904 server machine to become more vulnerable to attacks against software | |
7905 that is known to contain security holes. Implementers SHOULD make the | |
7906 Server header field a configurable option. | |
7907 | |
7908 Proxies which serve as a portal through a network firewall SHOULD | |
7909 take special precautions regarding the transfer of header information | |
7910 that identifies the hosts behind the firewall. In particular, they | |
7911 SHOULD remove, or replace with sanitized versions, any Via fields | |
7912 generated behind the firewall. | |
7913 | |
7914 The Referer field allows reading patterns to be studied and reverse | |
7915 links drawn. Although it can be very useful, its power can be abused | |
7916 if user details are not separated from the information contained in | |
7917 the Referer. Even when the personal information has been removed, the | |
7918 Referer field may indicate a private document's URI whose publication | |
7919 would be inappropriate. | |
7920 | |
7921 The information sent in the From field might conflict with the user's | |
7922 privacy interests or their site's security policy, and hence it | |
7923 SHOULD NOT be transmitted without the user being able to disable, | |
7924 enable, and modify the contents of the field. The user MUST be able | |
7925 to set the contents of this field within a user preference or | |
7926 application defaults configuration. | |
7927 | |
7928 We suggest, though do not require, that a convenient toggle interface | |
7929 be provided for the user to enable or disable the sending of From and | |
7930 Referer information. | |
7931 | |
7932 15.5 Attacks Based On File and Path Names | |
7933 | |
7934 Implementations of HTTP origin servers SHOULD be careful to restrict | |
7935 the documents returned by HTTP requests to be only those that were | |
7936 intended by the server administrators. If an HTTP server translates | |
7937 HTTP URIs directly into file system calls, the server MUST take | |
7938 special care not to serve files that were not intended to be | |
7939 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | |
7940 other operating systems use ".." as a path component to indicate a | |
7941 directory level above the current one. On such a system, an HTTP | |
7942 server MUST disallow any such construct in the Request-URI if it | |
7943 would otherwise allow access to a resource outside those intended to | |
7944 be accessible via the HTTP server. Similarly, files intended for | |
7945 reference only internally to the server (such as access control | |
7946 files, configuration files, and script code) MUST be protected from | |
7947 inappropriate retrieval, since they might contain sensitive | |
7948 information. Experience has shown that minor bugs in such HTTP server | |
7949 implementations have turned into security risks. | |
7950 | |
7951 | |
7952 | |
7953 | |
7954 Fielding, et. al. Standards Track [Page 142] | |
7955 | |
7956 RFC 2068 HTTP/1.1 January 1997 | |
7957 | |
7958 | |
7959 15.6 Personal Information | |
7960 | |
7961 HTTP clients are often privy to large amounts of personal information | |
7962 (e.g. the user's name, location, mail address, passwords, encryption | |
7963 keys, etc.), and SHOULD be very careful to prevent unintentional | |
7964 leakage of this information via the HTTP protocol to other sources. | |
7965 We very strongly recommend that a convenient interface be provided | |
7966 for the user to control dissemination of such information, and that | |
7967 designers and implementers be particularly careful in this area. | |
7968 History shows that errors in this area are often both serious | |
7969 security and/or privacy problems, and often generate highly adverse | |
7970 publicity for the implementer's company. | |
7971 | |
7972 15.7 Privacy Issues Connected to Accept Headers | |
7973 | |
7974 Accept request-headers can reveal information about the user to all | |
7975 servers which are accessed. The Accept-Language header in particular | |
7976 can reveal information the user would consider to be of a private | |
7977 nature, because the understanding of particular languages is often | |
7978 strongly correlated to the membership of a particular ethnic group. | |
7979 User agents which offer the option to configure the contents of an | |
7980 Accept-Language header to be sent in every request are strongly | |
7981 encouraged to let the configuration process include a message which | |
7982 makes the user aware of the loss of privacy involved. | |
7983 | |
7984 An approach that limits the loss of privacy would be for a user agent | |
7985 to omit the sending of Accept-Language headers by default, and to ask | |
7986 the user whether it should start sending Accept-Language headers to a | |
7987 server if it detects, by looking for any Vary response-header fields | |
7988 generated by the server, that such sending could improve the quality | |
7989 of service. | |
7990 | |
7991 Elaborate user-customized accept header fields sent in every request, | |
7992 in particular if these include quality values, can be used by servers | |
7993 as relatively reliable and long-lived user identifiers. Such user | |
7994 identifiers would allow content providers to do click-trail tracking, | |
7995 and would allow collaborating content providers to match cross-server | |
7996 click-trails or form submissions of individual users. Note that for | |
7997 many users not behind a proxy, the network address of the host | |
7998 running the user agent will also serve as a long-lived user | |
7999 identifier. In environments where proxies are used to enhance | |
8000 privacy, user agents should be conservative in offering accept header | |
8001 configuration options to end users. As an extreme privacy measure, | |
8002 proxies could filter the accept headers in relayed requests. General | |
8003 purpose user agents which provide a high degree of header | |
8004 configurability should warn users about the loss of privacy which can | |
8005 be involved. | |
8006 | |
8007 | |
8008 | |
8009 | |
8010 Fielding, et. al. Standards Track [Page 143] | |
8011 | |
8012 RFC 2068 HTTP/1.1 January 1997 | |
8013 | |
8014 | |
8015 15.8 DNS Spoofing | |
8016 | |
8017 Clients using HTTP rely heavily on the Domain Name Service, and are | |
8018 thus generally prone to security attacks based on the deliberate | |
8019 mis-association of IP addresses and DNS names. Clients need to be | |
8020 cautious in assuming the continuing validity of an IP number/DNS name | |
8021 association. | |
8022 | |
8023 In particular, HTTP clients SHOULD rely on their name resolver for | |
8024 confirmation of an IP number/DNS name association, rather than | |
8025 caching the result of previous host name lookups. Many platforms | |
8026 already can cache host name lookups locally when appropriate, and | |
8027 they SHOULD be configured to do so. These lookups should be cached, | |
8028 however, only when the TTL (Time To Live) information reported by the | |
8029 name server makes it likely that the cached information will remain | |
8030 useful. | |
8031 | |
8032 If HTTP clients cache the results of host name lookups in order to | |
8033 achieve a performance improvement, they MUST observe the TTL | |
8034 information reported by DNS. | |
8035 | |
8036 If HTTP clients do not observe this rule, they could be spoofed when | |
8037 a previously-accessed server's IP address changes. As network | |
8038 renumbering is expected to become increasingly common, the | |
8039 possibility of this form of attack will grow. Observing this | |
8040 requirement thus reduces this potential security vulnerability. | |
8041 | |
8042 This requirement also improves the load-balancing behavior of clients | |
8043 for replicated servers using the same DNS name and reduces the | |
8044 likelihood of a user's experiencing failure in accessing sites which | |
8045 use that strategy. | |
8046 | |
8047 15.9 Location Headers and Spoofing | |
8048 | |
8049 If a single server supports multiple organizations that do not trust | |
8050 one another, then it must check the values of Location and Content- | |
8051 Location headers in responses that are generated under control of | |
8052 said organizations to make sure that they do not attempt to | |
8053 invalidate resources over which they have no authority. | |
8054 | |
8055 16 Acknowledgments | |
8056 | |
8057 This specification makes heavy use of the augmented BNF and generic | |
8058 constructs defined by David H. Crocker for RFC 822. Similarly, it | |
8059 reuses many of the definitions provided by Nathaniel Borenstein and | |
8060 Ned Freed for MIME. We hope that their inclusion in this | |
8061 specification will help reduce past confusion over the relationship | |
8062 between HTTP and Internet mail message formats. | |
8063 | |
8064 | |
8065 | |
8066 Fielding, et. al. Standards Track [Page 144] | |
8067 | |
8068 RFC 2068 HTTP/1.1 January 1997 | |
8069 | |
8070 | |
8071 The HTTP protocol has evolved considerably over the past four years. | |
8072 It has benefited from a large and active developer community--the | |
8073 many people who have participated on the www-talk mailing list--and | |
8074 it is that community which has been most responsible for the success | |
8075 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | |
8076 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | |
8077 Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | |
8078 McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | |
8079 VanHeyningen deserve special recognition for their efforts in | |
8080 defining early aspects of the protocol. | |
8081 | |
8082 This document has benefited greatly from the comments of all those | |
8083 participating in the HTTP-WG. In addition to those already mentioned, | |
8084 the following individuals have contributed to this specification: | |
8085 | |
8086 Gary Adams Albert Lunde | |
8087 Harald Tveit Alvestrand John C. Mallery | |
8088 Keith Ball Jean-Philippe Martin-Flatin | |
8089 Brian Behlendorf Larry Masinter | |
8090 Paul Burchard Mitra | |
8091 Maurizio Codogno David Morris | |
8092 Mike Cowlishaw Gavin Nicol | |
8093 Roman Czyborra Bill Perry | |
8094 Michael A. Dolan Jeffrey Perry | |
8095 David J. Fiander Scott Powers | |
8096 Alan Freier Owen Rees | |
8097 Marc Hedlund Luigi Rizzo | |
8098 Greg Herlihy David Robinson | |
8099 Koen Holtman Marc Salomon | |
8100 Alex Hopmann Rich Salz | |
8101 Bob Jernigan Allan M. Schiffman | |
8102 Shel Kaphan Jim Seidman | |
8103 Rohit Khare Chuck Shotton | |
8104 John Klensin Eric W. Sink | |
8105 Martijn Koster Simon E. Spero | |
8106 Alexei Kosut Richard N. Taylor | |
8107 David M. Kristol Robert S. Thau | |
8108 Daniel LaLiberte Bill (BearHeart) Weinman | |
8109 Ben Laurie Francois Yergeau | |
8110 Paul J. Leach Mary Ellen Zurko | |
8111 Daniel DuBois | |
8112 | |
8113 Much of the content and presentation of the caching design is due to | |
8114 suggestions and comments from individuals including: Shel Kaphan, | |
8115 Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | |
8116 | |
8117 | |
8118 | |
8119 | |
8120 | |
8121 | |
8122 Fielding, et. al. Standards Track [Page 145] | |
8123 | |
8124 RFC 2068 HTTP/1.1 January 1997 | |
8125 | |
8126 | |
8127 Most of the specification of ranges is based on work originally done | |
8128 by Ari Luotonen and John Franks, with additional input from Steve | |
8129 Zilles. | |
8130 | |
8131 Thanks to the "cave men" of Palo Alto. You know who you are. | |
8132 | |
8133 Jim Gettys (the current editor of this document) wishes particularly | |
8134 to thank Roy Fielding, the previous editor of this document, along | |
8135 with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | |
8136 Holtman, John Franks, Alex Hopmann, and Larry Masinter for their | |
8137 help. | |
8138 | |
8139 17 References | |
8140 | |
8141 [1] Alvestrand, H., "Tags for the identification of languages", RFC | |
8142 1766, UNINETT, March 1995. | |
8143 | |
8144 [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | |
8145 D., and B. Alberti. "The Internet Gopher Protocol: (a distributed | |
8146 document search and retrieval protocol)", RFC 1436, University of | |
8147 Minnesota, March 1993. | |
8148 | |
8149 [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A | |
8150 Unifying Syntax for the Expression of Names and Addresses of Objects | |
8151 on the Network as used in the World-Wide Web", RFC 1630, CERN, June | |
8152 1994. | |
8153 | |
8154 [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource | |
8155 Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, | |
8156 December 1994. | |
8157 | |
8158 [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language | |
8159 Specification - 2.0", RFC 1866, MIT/LCS, November 1995. | |
8160 | |
8161 [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext | |
8162 Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May | |
8163 1996. | |
8164 | |
8165 [7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail | |
8166 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC | |
8167 2045, Innosoft, First Virtual, November 1996. | |
8168 | |
8169 [8] Braden, R., "Requirements for Internet hosts - application and | |
8170 support", STD 3, RFC 1123, IETF, October 1989. | |
8171 | |
8172 [9] Crocker, D., "Standard for the Format of ARPA Internet Text | |
8173 Messages", STD 11, RFC 822, UDEL, August 1982. | |
8174 | |
8175 | |
8176 | |
8177 | |
8178 Fielding, et. al. Standards Track [Page 146] | |
8179 | |
8180 RFC 2068 HTTP/1.1 January 1997 | |
8181 | |
8182 | |
8183 [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., | |
8184 Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype | |
8185 Functional Specification", (v1.5), Thinking Machines Corporation, | |
8186 April 1990. | |
8187 | |
8188 [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC | |
8189 Irvine, June 1995. | |
8190 | |
8191 [12] Horton, M., and R. Adams. "Standard for interchange of USENET | |
8192 messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic | |
8193 Studies, December 1987. | |
8194 | |
8195 [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A | |
8196 Proposed Standard for the Stream-Based Transmission of News", RFC | |
8197 977, UC San Diego, UC Berkeley, February 1986. | |
8198 | |
8199 [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | |
8200 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | |
8201 University of Tennessee, November 1996. | |
8202 | |
8203 [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML", | |
8204 RFC 1867, Xerox Corporation, November 1995. | |
8205 | |
8206 [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | |
8207 USC/ISI, August 1982. | |
8208 | |
8209 [17] Postel, J., "Media Type Registration Procedure", RFC 2048, | |
8210 USC/ISI, November 1996. | |
8211 | |
8212 [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD | |
8213 9, RFC 959, USC/ISI, October 1985. | |
8214 | |
8215 [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC | |
8216 1700, USC/ISI, October 1994. | |
8217 | |
8218 [20] Sollins, K., and L. Masinter, "Functional Requirements for | |
8219 Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, | |
8220 December 1994. | |
8221 | |
8222 [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for | |
8223 Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. | |
8224 | |
8225 [22] ISO-8859. International Standard -- Information Processing -- | |
8226 8-bit Single-Byte Coded Graphic Character Sets -- | |
8227 Part 1: Latin alphabet No. 1, ISO 8859-1:1987. | |
8228 Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. | |
8229 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. | |
8230 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. | |
8231 | |
8232 | |
8233 | |
8234 Fielding, et. al. Standards Track [Page 147] | |
8235 | |
8236 RFC 2068 HTTP/1.1 January 1997 | |
8237 | |
8238 | |
8239 Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. | |
8240 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. | |
8241 Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. | |
8242 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. | |
8243 Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. | |
8244 | |
8245 [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC | |
8246 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995. | |
8247 | |
8248 [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC | |
8249 1900, IAB, February 1996. | |
8250 | |
8251 [25] Deutsch, P., "GZIP file format specification version 4.3." RFC | |
8252 1952, Aladdin Enterprises, May 1996. | |
8253 | |
8254 [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP | |
8255 Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. | |
8256 1995. Slightly revised version of paper in Proc. 2nd International | |
8257 WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at | |
8258 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ | |
8259 HTTPLatency.html. | |
8260 | |
8261 [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP | |
8262 Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>, | |
8263 USC/Information Sciences Institute, June 1996 | |
8264 | |
8265 [28] Mills, D., "Network Time Protocol, Version 3, Specification, | |
8266 Implementation and Analysis", RFC 1305, University of Delaware, March | |
8267 1992. | |
8268 | |
8269 [29] Deutsch, P., "DEFLATE Compressed Data Format Specification | |
8270 version 1.3." RFC 1951, Aladdin Enterprises, May 1996. | |
8271 | |
8272 [30] Spero, S., "Analysis of HTTP Performance Problems" | |
8273 <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>. | |
8274 | |
8275 [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format | |
8276 Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, | |
8277 May 1996. | |
8278 | |
8279 [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |
8280 Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : | |
8281 Digest Access Authentication", RFC 2069, January 1997. | |
8282 | |
8283 | |
8284 | |
8285 | |
8286 | |
8287 | |
8288 | |
8289 | |
8290 Fielding, et. al. Standards Track [Page 148] | |
8291 | |
8292 RFC 2068 HTTP/1.1 January 1997 | |
8293 | |
8294 | |
8295 18 Authors' Addresses | |
8296 | |
8297 Roy T. Fielding | |
8298 Department of Information and Computer Science | |
8299 University of California | |
8300 Irvine, CA 92717-3425, USA | |
8301 | |
8302 Fax: +1 (714) 824-4056 | |
8303 EMail: fielding@ics.uci.edu | |
8304 | |
8305 | |
8306 Jim Gettys | |
8307 MIT Laboratory for Computer Science | |
8308 545 Technology Square | |
8309 Cambridge, MA 02139, USA | |
8310 | |
8311 Fax: +1 (617) 258 8682 | |
8312 EMail: jg@w3.org | |
8313 | |
8314 | |
8315 Jeffrey C. Mogul | |
8316 Western Research Laboratory | |
8317 Digital Equipment Corporation | |
8318 250 University Avenue | |
8319 Palo Alto, California, 94305, USA | |
8320 | |
8321 EMail: mogul@wrl.dec.com | |
8322 | |
8323 | |
8324 Henrik Frystyk Nielsen | |
8325 W3 Consortium | |
8326 MIT Laboratory for Computer Science | |
8327 545 Technology Square | |
8328 Cambridge, MA 02139, USA | |
8329 | |
8330 Fax: +1 (617) 258 8682 | |
8331 EMail: frystyk@w3.org | |
8332 | |
8333 | |
8334 Tim Berners-Lee | |
8335 Director, W3 Consortium | |
8336 MIT Laboratory for Computer Science | |
8337 545 Technology Square | |
8338 Cambridge, MA 02139, USA | |
8339 | |
8340 Fax: +1 (617) 258 8682 | |
8341 EMail: timbl@w3.org | |
8342 | |
8343 | |
8344 | |
8345 | |
8346 Fielding, et. al. Standards Track [Page 149] | |
8347 | |
8348 RFC 2068 HTTP/1.1 January 1997 | |
8349 | |
8350 | |
8351 19 Appendices | |
8352 | |
8353 19.1 Internet Media Type message/http | |
8354 | |
8355 In addition to defining the HTTP/1.1 protocol, this document serves | |
8356 as the specification for the Internet media type "message/http". The | |
8357 following is to be registered with IANA. | |
8358 | |
8359 Media Type name: message | |
8360 Media subtype name: http | |
8361 Required parameters: none | |
8362 Optional parameters: version, msgtype | |
8363 | |
8364 version: The HTTP-Version number of the enclosed message | |
8365 (e.g., "1.1"). If not present, the version can be | |
8366 determined from the first line of the body. | |
8367 | |
8368 msgtype: The message type -- "request" or "response". If not | |
8369 present, the type can be determined from the first | |
8370 line of the body. | |
8371 | |
8372 Encoding considerations: only "7bit", "8bit", or "binary" are | |
8373 permitted | |
8374 | |
8375 Security considerations: none | |
8376 | |
8377 19.2 Internet Media Type multipart/byteranges | |
8378 | |
8379 When an HTTP message includes the content of multiple ranges (for | |
8380 example, a response to a request for multiple non-overlapping | |
8381 ranges), these are transmitted as a multipart MIME message. The | |
8382 multipart media type for this purpose is called | |
8383 "multipart/byteranges". | |
8384 | |
8385 The multipart/byteranges media type includes two or more parts, each | |
8386 with its own Content-Type and Content-Range fields. The parts are | |
8387 separated using a MIME boundary parameter. | |
8388 | |
8389 Media Type name: multipart | |
8390 Media subtype name: byteranges | |
8391 Required parameters: boundary | |
8392 Optional parameters: none | |
8393 | |
8394 Encoding considerations: only "7bit", "8bit", or "binary" are | |
8395 permitted | |
8396 | |
8397 Security considerations: none | |
8398 | |
8399 | |
8400 | |
8401 | |
8402 Fielding, et. al. Standards Track [Page 150] | |
8403 | |
8404 RFC 2068 HTTP/1.1 January 1997 | |
8405 | |
8406 | |
8407 For example: | |
8408 | |
8409 HTTP/1.1 206 Partial content | |
8410 Date: Wed, 15 Nov 1995 06:25:24 GMT | |
8411 Last-modified: Wed, 15 Nov 1995 04:58:08 GMT | |
8412 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | |
8413 | |
8414 --THIS_STRING_SEPARATES | |
8415 Content-type: application/pdf | |
8416 Content-range: bytes 500-999/8000 | |
8417 | |
8418 ...the first range... | |
8419 --THIS_STRING_SEPARATES | |
8420 Content-type: application/pdf | |
8421 Content-range: bytes 7000-7999/8000 | |
8422 | |
8423 ...the second range | |
8424 --THIS_STRING_SEPARATES-- | |
8425 | |
8426 19.3 Tolerant Applications | |
8427 | |
8428 Although this document specifies the requirements for the generation | |
8429 of HTTP/1.1 messages, not all applications will be correct in their | |
8430 implementation. We therefore recommend that operational applications | |
8431 be tolerant of deviations whenever those deviations can be | |
8432 interpreted unambiguously. | |
8433 | |
8434 Clients SHOULD be tolerant in parsing the Status-Line and servers | |
8435 tolerant when parsing the Request-Line. In particular, they SHOULD | |
8436 accept any amount of SP or HT characters between fields, even though | |
8437 only a single SP is required. | |
8438 | |
8439 The line terminator for message-header fields is the sequence CRLF. | |
8440 However, we recommend that applications, when parsing such headers, | |
8441 recognize a single LF as a line terminator and ignore the leading CR. | |
8442 | |
8443 The character set of an entity-body should be labeled as the lowest | |
8444 common denominator of the character codes used within that body, with | |
8445 the exception that no label is preferred over the labels US-ASCII or | |
8446 ISO-8859-1. | |
8447 | |
8448 Additional rules for requirements on parsing and encoding of dates | |
8449 and other potential problems with date encodings include: | |
8450 | |
8451 o HTTP/1.1 clients and caches should assume that an RFC-850 date | |
8452 which appears to be more than 50 years in the future is in fact | |
8453 in the past (this helps solve the "year 2000" problem). | |
8454 | |
8455 | |
8456 | |
8457 | |
8458 Fielding, et. al. Standards Track [Page 151] | |
8459 | |
8460 RFC 2068 HTTP/1.1 January 1997 | |
8461 | |
8462 | |
8463 o An HTTP/1.1 implementation may internally represent a parsed | |
8464 Expires date as earlier than the proper value, but MUST NOT | |
8465 internally represent a parsed Expires date as later than the | |
8466 proper value. | |
8467 | |
8468 o All expiration-related calculations must be done in GMT. The | |
8469 local time zone MUST NOT influence the calculation or comparison | |
8470 of an age or expiration time. | |
8471 | |
8472 o If an HTTP header incorrectly carries a date value with a time | |
8473 zone other than GMT, it must be converted into GMT using the most | |
8474 conservative possible conversion. | |
8475 | |
8476 19.4 Differences Between HTTP Entities and MIME Entities | |
8477 | |
8478 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | |
8479 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow | |
8480 entities to be transmitted in an open variety of representations and | |
8481 with extensible mechanisms. However, MIME [7] discusses mail, and | |
8482 HTTP has a few features that are different from those described in | |
8483 MIME. These differences were carefully chosen to optimize | |
8484 performance over binary connections, to allow greater freedom in the | |
8485 use of new media types, to make date comparisons easier, and to | |
8486 acknowledge the practice of some early HTTP servers and clients. | |
8487 | |
8488 This appendix describes specific areas where HTTP differs from MIME. | |
8489 Proxies and gateways to strict MIME environments SHOULD be aware of | |
8490 these differences and provide the appropriate conversions where | |
8491 necessary. Proxies and gateways from MIME environments to HTTP also | |
8492 need to be aware of the differences because some conversions may be | |
8493 required. | |
8494 | |
8495 19.4.1 Conversion to Canonical Form | |
8496 | |
8497 MIME requires that an Internet mail entity be converted to canonical | |
8498 form prior to being transferred. Section 3.7.1 of this document | |
8499 describes the forms allowed for subtypes of the "text" media type | |
8500 when transmitted over HTTP. MIME requires that content with a type of | |
8501 "text" represent line breaks as CRLF and forbids the use of CR or LF | |
8502 outside of line break sequences. HTTP allows CRLF, bare CR, and bare | |
8503 LF to indicate a line break within text content when a message is | |
8504 transmitted over HTTP. | |
8505 | |
8506 Where it is possible, a proxy or gateway from HTTP to a strict MIME | |
8507 environment SHOULD translate all line breaks within the text media | |
8508 types described in section 3.7.1 of this document to the MIME | |
8509 canonical form of CRLF. Note, however, that this may be complicated | |
8510 by the presence of a Content-Encoding and by the fact that HTTP | |
8511 | |
8512 | |
8513 | |
8514 Fielding, et. al. Standards Track [Page 152] | |
8515 | |
8516 RFC 2068 HTTP/1.1 January 1997 | |
8517 | |
8518 | |
8519 allows the use of some character sets which do not use octets 13 and | |
8520 10 to represent CR and LF, as is the case for some multi-byte | |
8521 character sets. | |
8522 | |
8523 19.4.2 Conversion of Date Formats | |
8524 | |
8525 HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to | |
8526 simplify the process of date comparison. Proxies and gateways from | |
8527 other protocols SHOULD ensure that any Date header field present in a | |
8528 message conforms to one of the HTTP/1.1 formats and rewrite the date | |
8529 if necessary. | |
8530 | |
8531 19.4.3 Introduction of Content-Encoding | |
8532 | |
8533 MIME does not include any concept equivalent to HTTP/1.1's Content- | |
8534 Encoding header field. Since this acts as a modifier on the media | |
8535 type, proxies and gateways from HTTP to MIME-compliant protocols MUST | |
8536 either change the value of the Content-Type header field or decode | |
8537 the entity-body before forwarding the message. (Some experimental | |
8538 applications of Content-Type for Internet mail have used a media-type | |
8539 parameter of ";conversions=<content-coding>" to perform an equivalent | |
8540 function as Content-Encoding. However, this parameter is not part of | |
8541 MIME.) | |
8542 | |
8543 19.4.4 No Content-Transfer-Encoding | |
8544 | |
8545 HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME. | |
8546 Proxies and gateways from MIME-compliant protocols to HTTP MUST | |
8547 remove any non-identity CTE ("quoted-printable" or "base64") encoding | |
8548 prior to delivering the response message to an HTTP client. | |
8549 | |
8550 Proxies and gateways from HTTP to MIME-compliant protocols are | |
8551 responsible for ensuring that the message is in the correct format | |
8552 and encoding for safe transport on that protocol, where "safe | |
8553 transport" is defined by the limitations of the protocol being used. | |
8554 Such a proxy or gateway SHOULD label the data with an appropriate | |
8555 Content-Transfer-Encoding if doing so will improve the likelihood of | |
8556 safe transport over the destination protocol. | |
8557 | |
8558 19.4.5 HTTP Header Fields in Multipart Body-Parts | |
8559 | |
8560 In MIME, most header fields in multipart body-parts are generally | |
8561 ignored unless the field name begins with "Content-". In HTTP/1.1, | |
8562 multipart body-parts may contain any HTTP header fields which are | |
8563 significant to the meaning of that part. | |
8564 | |
8565 | |
8566 | |
8567 | |
8568 | |
8569 | |
8570 Fielding, et. al. Standards Track [Page 153] | |
8571 | |
8572 RFC 2068 HTTP/1.1 January 1997 | |
8573 | |
8574 | |
8575 19.4.6 Introduction of Transfer-Encoding | |
8576 | |
8577 HTTP/1.1 introduces the Transfer-Encoding header field (section | |
8578 14.40). Proxies/gateways MUST remove any transfer coding prior to | |
8579 forwarding a message via a MIME-compliant protocol. | |
8580 | |
8581 A process for decoding the "chunked" transfer coding (section 3.6) | |
8582 can be represented in pseudo-code as: | |
8583 | |
8584 length := 0 | |
8585 read chunk-size, chunk-ext (if any) and CRLF | |
8586 while (chunk-size > 0) { | |
8587 read chunk-data and CRLF | |
8588 append chunk-data to entity-body | |
8589 length := length + chunk-size | |
8590 read chunk-size and CRLF | |
8591 } | |
8592 read entity-header | |
8593 while (entity-header not empty) { | |
8594 append entity-header to existing header fields | |
8595 read entity-header | |
8596 } | |
8597 Content-Length := length | |
8598 Remove "chunked" from Transfer-Encoding | |
8599 | |
8600 19.4.7 MIME-Version | |
8601 | |
8602 HTTP is not a MIME-compliant protocol (see appendix 19.4). However, | |
8603 HTTP/1.1 messages may include a single MIME-Version general-header | |
8604 field to indicate what version of the MIME protocol was used to | |
8605 construct the message. Use of the MIME-Version header field indicates | |
8606 that the message is in full compliance with the MIME protocol. | |
8607 Proxies/gateways are responsible for ensuring full compliance (where | |
8608 possible) when exporting HTTP messages to strict MIME environments. | |
8609 | |
8610 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |
8611 | |
8612 MIME version "1.0" is the default for use in HTTP/1.1. However, | |
8613 HTTP/1.1 message parsing and semantics are defined by this document | |
8614 and not the MIME specification. | |
8615 | |
8616 19.5 Changes from HTTP/1.0 | |
8617 | |
8618 This section summarizes major differences between versions HTTP/1.0 | |
8619 and HTTP/1.1. | |
8620 | |
8621 | |
8622 | |
8623 | |
8624 | |
8625 | |
8626 Fielding, et. al. Standards Track [Page 154] | |
8627 | |
8628 RFC 2068 HTTP/1.1 January 1997 | |
8629 | |
8630 | |
8631 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP | |
8632 Addresses | |
8633 | |
8634 The requirements that clients and servers support the Host request- | |
8635 header, report an error if the Host request-header (section 14.23) is | |
8636 missing from an HTTP/1.1 request, and accept absolute URIs (section | |
8637 5.1.2) are among the most important changes defined by this | |
8638 specification. | |
8639 | |
8640 Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |
8641 addresses and servers; there was no other established mechanism for | |
8642 distinguishing the intended server of a request than the IP address | |
8643 to which that request was directed. The changes outlined above will | |
8644 allow the Internet, once older HTTP clients are no longer common, to | |
8645 support multiple Web sites from a single IP address, greatly | |
8646 simplifying large operational Web servers, where allocation of many | |
8647 IP addresses to a single host has created serious problems. The | |
8648 Internet will also be able to recover the IP addresses that have been | |
8649 allocated for the sole purpose of allowing special-purpose domain | |
8650 names to be used in root-level HTTP URLs. Given the rate of growth of | |
8651 the Web, and the number of servers already deployed, it is extremely | |
8652 important that all implementations of HTTP (including updates to | |
8653 existing HTTP/1.0 applications) correctly implement these | |
8654 requirements: | |
8655 | |
8656 o Both clients and servers MUST support the Host request-header. | |
8657 | |
8658 o Host request-headers are required in HTTP/1.1 requests. | |
8659 | |
8660 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | |
8661 request does not include a Host request-header. | |
8662 | |
8663 o Servers MUST accept absolute URIs. | |
8664 | |
8665 | |
8666 | |
8667 | |
8668 | |
8669 | |
8670 | |
8671 | |
8672 | |
8673 | |
8674 | |
8675 | |
8676 | |
8677 | |
8678 | |
8679 | |
8680 | |
8681 | |
8682 Fielding, et. al. Standards Track [Page 155] | |
8683 | |
8684 RFC 2068 HTTP/1.1 January 1997 | |
8685 | |
8686 | |
8687 19.6 Additional Features | |
8688 | |
8689 This appendix documents protocol elements used by some existing HTTP | |
8690 implementations, but not consistently and correctly across most | |
8691 HTTP/1.1 applications. Implementers should be aware of these | |
8692 features, but cannot rely upon their presence in, or interoperability | |
8693 with, other HTTP/1.1 applications. Some of these describe proposed | |
8694 experimental features, and some describe features that experimental | |
8695 deployment found lacking that are now addressed in the base HTTP/1.1 | |
8696 specification. | |
8697 | |
8698 19.6.1 Additional Request Methods | |
8699 | |
8700 19.6.1.1 PATCH | |
8701 | |
8702 The PATCH method is similar to PUT except that the entity contains a | |
8703 list of differences between the original version of the resource | |
8704 identified by the Request-URI and the desired content of the resource | |
8705 after the PATCH action has been applied. The list of differences is | |
8706 in a format defined by the media type of the entity (e.g., | |
8707 "application/diff") and MUST include sufficient information to allow | |
8708 the server to recreate the changes necessary to convert the original | |
8709 version of the resource to the desired version. | |
8710 | |
8711 If the request passes through a cache and the Request-URI identifies | |
8712 a currently cached entity, that entity MUST be removed from the | |
8713 cache. Responses to this method are not cachable. | |
8714 | |
8715 The actual method for determining how the patched resource is placed, | |
8716 and what happens to its predecessor, is defined entirely by the | |
8717 origin server. If the original version of the resource being patched | |
8718 included a Content-Version header field, the request entity MUST | |
8719 include a Derived-From header field corresponding to the value of the | |
8720 original Content-Version header field. Applications are encouraged to | |
8721 use these fields for constructing versioning relationships and | |
8722 resolving version conflicts. | |
8723 | |
8724 PATCH requests must obey the message transmission requirements set | |
8725 out in section 8.2. | |
8726 | |
8727 Caches that implement PATCH should invalidate cached responses as | |
8728 defined in section 13.10 for PUT. | |
8729 | |
8730 19.6.1.2 LINK | |
8731 | |
8732 The LINK method establishes one or more Link relationships between | |
8733 the existing resource identified by the Request-URI and other | |
8734 existing resources. The difference between LINK and other methods | |
8735 | |
8736 | |
8737 | |
8738 Fielding, et. al. Standards Track [Page 156] | |
8739 | |
8740 RFC 2068 HTTP/1.1 January 1997 | |
8741 | |
8742 | |
8743 allowing links to be established between resources is that the LINK | |
8744 method does not allow any message-body to be sent in the request and | |
8745 does not directly result in the creation of new resources. | |
8746 | |
8747 If the request passes through a cache and the Request-URI identifies | |
8748 a currently cached entity, that entity MUST be removed from the | |
8749 cache. Responses to this method are not cachable. | |
8750 | |
8751 Caches that implement LINK should invalidate cached responses as | |
8752 defined in section 13.10 for PUT. | |
8753 | |
8754 19.6.1.3 UNLINK | |
8755 | |
8756 The UNLINK method removes one or more Link relationships from the | |
8757 existing resource identified by the Request-URI. These relationships | |
8758 may have been established using the LINK method or by any other | |
8759 method supporting the Link header. The removal of a link to a | |
8760 resource does not imply that the resource ceases to exist or becomes | |
8761 inaccessible for future references. | |
8762 | |
8763 If the request passes through a cache and the Request-URI identifies | |
8764 a currently cached entity, that entity MUST be removed from the | |
8765 cache. Responses to this method are not cachable. | |
8766 | |
8767 Caches that implement UNLINK should invalidate cached responses as | |
8768 defined in section 13.10 for PUT. | |
8769 | |
8770 19.6.2 Additional Header Field Definitions | |
8771 | |
8772 19.6.2.1 Alternates | |
8773 | |
8774 The Alternates response-header field has been proposed as a means for | |
8775 the origin server to inform the client about other available | |
8776 representations of the requested resource, along with their | |
8777 distinguishing attributes, and thus providing a more reliable means | |
8778 for a user agent to perform subsequent selection of another | |
8779 representation which better fits the desires of its user (described | |
8780 as agent-driven negotiation in section 12). | |
8781 | |
8782 | |
8783 | |
8784 | |
8785 | |
8786 | |
8787 | |
8788 | |
8789 | |
8790 | |
8791 | |
8792 | |
8793 | |
8794 Fielding, et. al. Standards Track [Page 157] | |
8795 | |
8796 RFC 2068 HTTP/1.1 January 1997 | |
8797 | |
8798 | |
8799 The Alternates header field is orthogonal to the Vary header field in | |
8800 that both may coexist in a message without affecting the | |
8801 interpretation of the response or the available representations. It | |
8802 is expected that Alternates will provide a significant improvement | |
8803 over the server-driven negotiation provided by the Vary field for | |
8804 those resources that vary over common dimensions like type and | |
8805 language. | |
8806 | |
8807 The Alternates header field will be defined in a future | |
8808 specification. | |
8809 | |
8810 19.6.2.2 Content-Version | |
8811 | |
8812 The Content-Version entity-header field defines the version tag | |
8813 associated with a rendition of an evolving entity. Together with the | |
8814 Derived-From field described in section 19.6.2.3, it allows a group | |
8815 of people to work simultaneously on the creation of a work as an | |
8816 iterative process. The field should be used to allow evolution of a | |
8817 particular work along a single path rather than derived works or | |
8818 renditions in different representations. | |
8819 | |
8820 Content-Version = "Content-Version" ":" quoted-string | |
8821 | |
8822 Examples of the Content-Version field include: | |
8823 | |
8824 Content-Version: "2.1.2" | |
8825 Content-Version: "Fred 19950116-12:26:48" | |
8826 Content-Version: "2.5a4-omega7" | |
8827 | |
8828 19.6.2.3 Derived-From | |
8829 | |
8830 The Derived-From entity-header field can be used to indicate the | |
8831 version tag of the resource from which the enclosed entity was | |
8832 derived before modifications were made by the sender. This field is | |
8833 used to help manage the process of merging successive changes to a | |
8834 resource, particularly when such changes are being made in parallel | |
8835 and from multiple sources. | |
8836 | |
8837 Derived-From = "Derived-From" ":" quoted-string | |
8838 | |
8839 An example use of the field is: | |
8840 | |
8841 Derived-From: "2.1.1" | |
8842 | |
8843 The Derived-From field is required for PUT and PATCH requests if the | |
8844 entity being sent was previously retrieved from the same URI and a | |
8845 Content-Version header was included with the entity when it was last | |
8846 retrieved. | |
8847 | |
8848 | |
8849 | |
8850 Fielding, et. al. Standards Track [Page 158] | |
8851 | |
8852 RFC 2068 HTTP/1.1 January 1997 | |
8853 | |
8854 | |
8855 19.6.2.4 Link | |
8856 | |
8857 The Link entity-header field provides a means for describing a | |
8858 relationship between two resources, generally between the requested | |
8859 resource and some other resource. An entity MAY include multiple Link | |
8860 values. Links at the metainformation level typically indicate | |
8861 relationships like hierarchical structure and navigation paths. The | |
8862 Link field is semantically equivalent to the <LINK> element in | |
8863 HTML.[5] | |
8864 | |
8865 Link = "Link" ":" #("<" URI ">" *( ";" link-param ) | |
8866 | |
8867 link-param = ( ( "rel" "=" relationship ) | |
8868 | ( "rev" "=" relationship ) | |
8869 | ( "title" "=" quoted-string ) | |
8870 | ( "anchor" "=" <"> URI <"> ) | |
8871 | ( link-extension ) ) | |
8872 | |
8873 link-extension = token [ "=" ( token | quoted-string ) ] | |
8874 | |
8875 relationship = sgml-name | |
8876 | ( <"> sgml-name *( SP sgml-name) <"> ) | |
8877 | |
8878 sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) | |
8879 | |
8880 Relationship values are case-insensitive and MAY be extended within | |
8881 the constraints of the sgml-name syntax. The title parameter MAY be | |
8882 used to label the destination of a link such that it can be used as | |
8883 identification within a human-readable menu. The anchor parameter MAY | |
8884 be used to indicate a source anchor other than the entire current | |
8885 resource, such as a fragment of this resource or a third resource. | |
8886 | |
8887 Examples of usage include: | |
8888 | |
8889 Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous" | |
8890 | |
8891 Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee" | |
8892 | |
8893 The first example indicates that chapter2 is previous to this | |
8894 resource in a logical navigation path. The second indicates that the | |
8895 person responsible for making the resource available is identified by | |
8896 the given e-mail address. | |
8897 | |
8898 19.6.2.5 URI | |
8899 | |
8900 The URI header field has, in past versions of this specification, | |
8901 been used as a combination of the existing Location, Content- | |
8902 Location, and Vary header fields as well as the future Alternates | |
8903 | |
8904 | |
8905 | |
8906 Fielding, et. al. Standards Track [Page 159] | |
8907 | |
8908 RFC 2068 HTTP/1.1 January 1997 | |
8909 | |
8910 | |
8911 field (above). Its primary purpose has been to include a list of | |
8912 additional URIs for the resource, including names and mirror | |
8913 locations. However, it has become clear that the combination of many | |
8914 different functions within this single field has been a barrier to | |
8915 consistently and correctly implementing any of those functions. | |
8916 Furthermore, we believe that the identification of names and mirror | |
8917 locations would be better performed via the Link header field. The | |
8918 URI header field is therefore deprecated in favor of those other | |
8919 fields. | |
8920 | |
8921 URI-header = "URI" ":" 1#( "<" URI ">" ) | |
8922 | |
8923 19.7 Compatibility with Previous Versions | |
8924 | |
8925 It is beyond the scope of a protocol specification to mandate | |
8926 compliance with previous versions. HTTP/1.1 was deliberately | |
8927 designed, however, to make supporting previous versions easy. It is | |
8928 worth noting that at the time of composing this specification, we | |
8929 would expect commercial HTTP/1.1 servers to: | |
8930 | |
8931 o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 | |
8932 requests; | |
8933 | |
8934 o understand any valid request in the format of HTTP/0.9, 1.0, or | |
8935 1.1; | |
8936 | |
8937 o respond appropriately with a message in the same major version used | |
8938 by the client. | |
8939 | |
8940 And we would expect HTTP/1.1 clients to: | |
8941 | |
8942 o recognize the format of the Status-Line for HTTP/1.0 and 1.1 | |
8943 responses; | |
8944 | |
8945 o understand any valid response in the format of HTTP/0.9, 1.0, or | |
8946 1.1. | |
8947 | |
8948 For most implementations of HTTP/1.0, each connection is established | |
8949 by the client prior to the request and closed by the server after | |
8950 sending the response. A few implementations implement the Keep-Alive | |
8951 version of persistent connections described in section 19.7.1.1. | |
8952 | |
8953 | |
8954 | |
8955 | |
8956 | |
8957 | |
8958 | |
8959 | |
8960 | |
8961 | |
8962 Fielding, et. al. Standards Track [Page 160] | |
8963 | |
8964 RFC 2068 HTTP/1.1 January 1997 | |
8965 | |
8966 | |
8967 19.7.1 Compatibility with HTTP/1.0 Persistent Connections | |
8968 | |
8969 Some clients and servers may wish to be compatible with some previous | |
8970 implementations of persistent connections in HTTP/1.0 clients and | |
8971 servers. Persistent connections in HTTP/1.0 must be explicitly | |
8972 negotiated as they are not the default behavior. HTTP/1.0 | |
8973 experimental implementations of persistent connections are faulty, | |
8974 and the new facilities in HTTP/1.1 are designed to rectify these | |
8975 problems. The problem was that some existing 1.0 clients may be | |
8976 sending Keep-Alive to a proxy server that doesn't understand | |
8977 Connection, which would then erroneously forward it to the next | |
8978 inbound server, which would establish the Keep-Alive connection and | |
8979 result in a hung HTTP/1.0 proxy waiting for the close on the | |
8980 response. The result is that HTTP/1.0 clients must be prevented from | |
8981 using Keep-Alive when talking to proxies. | |
8982 | |
8983 However, talking to proxies is the most important use of persistent | |
8984 connections, so that prohibition is clearly unacceptable. Therefore, | |
8985 we need some other mechanism for indicating a persistent connection | |
8986 is desired, which is safe to use even when talking to an old proxy | |
8987 that ignores Connection. Persistent connections are the default for | |
8988 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | |
8989 declaring non-persistence. | |
8990 | |
8991 The following describes the original HTTP/1.0 form of persistent | |
8992 connections. | |
8993 | |
8994 When it connects to an origin server, an HTTP client MAY send the | |
8995 Keep-Alive connection-token in addition to the Persist connection- | |
8996 token: | |
8997 | |
8998 Connection: Keep-Alive | |
8999 | |
9000 An HTTP/1.0 server would then respond with the Keep-Alive connection | |
9001 token and the client may proceed with an HTTP/1.0 (or Keep-Alive) | |
9002 persistent connection. | |
9003 | |
9004 An HTTP/1.1 server may also establish persistent connections with | |
9005 HTTP/1.0 clients upon receipt of a Keep-Alive connection token. | |
9006 However, a persistent connection with an HTTP/1.0 client cannot make | |
9007 use of the chunked transfer-coding, and therefore MUST use a | |
9008 Content-Length for marking the ending boundary of each message. | |
9009 | |
9010 A client MUST NOT send the Keep-Alive connection token to a proxy | |
9011 server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 | |
9012 for parsing the Connection header field. | |
9013 | |
9014 | |
9015 | |
9016 | |
9017 | |
9018 Fielding, et. al. Standards Track [Page 161] | |
9019 | |
9020 RFC 2068 HTTP/1.1 January 1997 | |
9021 | |
9022 | |
9023 19.7.1.1 The Keep-Alive Header | |
9024 | |
9025 When the Keep-Alive connection-token has been transmitted with a | |
9026 request or a response, a Keep-Alive header field MAY also be | |
9027 included. The Keep-Alive header field takes the following form: | |
9028 | |
9029 Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param | |
9030 | |
9031 keepalive-param = param-name "=" value | |
9032 | |
9033 The Keep-Alive header itself is optional, and is used only if a | |
9034 parameter is being sent. HTTP/1.1 does not define any parameters. | |
9035 | |
9036 If the Keep-Alive header is sent, the corresponding connection token | |
9037 MUST be transmitted. The Keep-Alive header MUST be ignored if | |
9038 received without the connection token. | |
9039 | |
9040 | |
9041 | |
9042 | |
9043 | |
9044 | |
9045 | |
9046 | |
9047 | |
9048 | |
9049 | |
9050 | |
9051 | |
9052 | |
9053 | |
9054 | |
9055 | |
9056 | |
9057 | |
9058 | |
9059 | |
9060 | |
9061 | |
9062 | |
9063 | |
9064 | |
9065 | |
9066 | |
9067 | |
9068 | |
9069 | |
9070 | |
9071 | |
9072 | |
9073 | |
9074 Fielding, et. al. Standards Track [Page 162] | |
9075 |