Commit | Line | Data |
---|---|---|
d7ee16ed LM |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f |