]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group R. Fielding | |
8 | Request for Comments: 2616 UC Irvine | |
9 | Obsoletes: 2068 J. Gettys | |
10 | Category: Standards Track Compaq/W3C | |
11 | J. Mogul | |
12 | Compaq | |
13 | H. Frystyk | |
14 | W3C/MIT | |
15 | L. Masinter | |
16 | Xerox | |
17 | P. Leach | |
18 | Microsoft | |
19 | T. Berners-Lee | |
20 | W3C/MIT | |
21 | June 1999 | |
22 | ||
23 | ||
24 | Hypertext Transfer Protocol -- HTTP/1.1 | |
25 | ||
26 | Status of this Memo | |
27 | ||
28 | This document specifies an Internet standards track protocol for the | |
29 | Internet community, and requests discussion and suggestions for | |
30 | improvements. Please refer to the current edition of the "Internet | |
31 | Official Protocol Standards" (STD 1) for the standardization state | |
32 | and status of this protocol. Distribution of this memo is unlimited. | |
33 | ||
34 | Copyright Notice | |
35 | ||
36 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
37 | ||
38 | Abstract | |
39 | ||
40 | The Hypertext Transfer Protocol (HTTP) is an application-level | |
41 | protocol for distributed, collaborative, hypermedia information | |
42 | systems. It is a generic, stateless, protocol which can be used for | |
43 | many tasks beyond its use for hypertext, such as name servers and | |
44 | distributed object management systems, through extension of its | |
45 | request methods, error codes and headers [47]. A feature of HTTP is | |
46 | the typing and negotiation of data representation, allowing systems | |
47 | to be built independently of the data being transferred. | |
48 | ||
49 | HTTP has been in use by the World-Wide Web global information | |
50 | initiative since 1990. This specification defines the protocol | |
51 | referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. | |
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Fielding, et al. Standards Track [Page 1] | |
59 | \f | |
60 | RFC 2616 HTTP/1.1 June 1999 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1 Introduction ...................................................7 | |
66 | 1.1 Purpose......................................................7 | |
67 | 1.2 Requirements .................................................8 | |
68 | 1.3 Terminology ..................................................8 | |
69 | 1.4 Overall Operation ...........................................12 | |
70 | 2 Notational Conventions and Generic Grammar ....................14 | |
71 | 2.1 Augmented BNF ...............................................14 | |
72 | 2.2 Basic Rules .................................................15 | |
73 | 3 Protocol Parameters ...........................................17 | |
74 | 3.1 HTTP Version ................................................17 | |
75 | 3.2 Uniform Resource Identifiers ................................18 | |
76 | 3.2.1 General Syntax ...........................................19 | |
77 | 3.2.2 http URL .................................................19 | |
78 | 3.2.3 URI Comparison ...........................................20 | |
79 | 3.3 Date/Time Formats ...........................................20 | |
80 | 3.3.1 Full Date ................................................20 | |
81 | 3.3.2 Delta Seconds ............................................21 | |
82 | 3.4 Character Sets ..............................................21 | |
83 | 3.4.1 Missing Charset ..........................................22 | |
84 | 3.5 Content Codings .............................................23 | |
85 | 3.6 Transfer Codings ............................................24 | |
86 | 3.6.1 Chunked Transfer Coding ..................................25 | |
87 | 3.7 Media Types .................................................26 | |
88 | 3.7.1 Canonicalization and Text Defaults .......................27 | |
89 | 3.7.2 Multipart Types ..........................................27 | |
90 | 3.8 Product Tokens ..............................................28 | |
91 | 3.9 Quality Values ..............................................29 | |
92 | 3.10 Language Tags ...............................................29 | |
93 | 3.11 Entity Tags .................................................30 | |
94 | 3.12 Range Units .................................................30 | |
95 | 4 HTTP Message ..................................................31 | |
96 | 4.1 Message Types ...............................................31 | |
97 | 4.2 Message Headers .............................................31 | |
98 | 4.3 Message Body ................................................32 | |
99 | 4.4 Message Length ..............................................33 | |
100 | 4.5 General Header Fields .......................................34 | |
101 | 5 Request .......................................................35 | |
102 | 5.1 Request-Line ................................................35 | |
103 | 5.1.1 Method ...................................................36 | |
104 | 5.1.2 Request-URI ..............................................36 | |
105 | 5.2 The Resource Identified by a Request ........................38 | |
106 | 5.3 Request Header Fields .......................................38 | |
107 | 6 Response ......................................................39 | |
108 | 6.1 Status-Line .................................................39 | |
109 | 6.1.1 Status Code and Reason Phrase ............................39 | |
110 | 6.2 Response Header Fields ......................................41 | |
111 | ||
112 | ||
113 | ||
114 | Fielding, et al. Standards Track [Page 2] | |
115 | \f | |
116 | RFC 2616 HTTP/1.1 June 1999 | |
117 | ||
118 | ||
119 | 7 Entity ........................................................42 | |
120 | 7.1 Entity Header Fields ........................................42 | |
121 | 7.2 Entity Body .................................................43 | |
122 | 7.2.1 Type .....................................................43 | |
123 | 7.2.2 Entity Length ............................................43 | |
124 | 8 Connections ...................................................44 | |
125 | 8.1 Persistent Connections ......................................44 | |
126 | 8.1.1 Purpose ..................................................44 | |
127 | 8.1.2 Overall Operation ........................................45 | |
128 | 8.1.3 Proxy Servers ............................................46 | |
129 | 8.1.4 Practical Considerations .................................46 | |
130 | 8.2 Message Transmission Requirements ...........................47 | |
131 | 8.2.1 Persistent Connections and Flow Control ..................47 | |
132 | 8.2.2 Monitoring Connections for Error Status Messages .........48 | |
133 | 8.2.3 Use of the 100 (Continue) Status .........................48 | |
134 | 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50 | |
135 | 9 Method Definitions ............................................51 | |
136 | 9.1 Safe and Idempotent Methods .................................51 | |
137 | 9.1.1 Safe Methods .............................................51 | |
138 | 9.1.2 Idempotent Methods .......................................51 | |
139 | 9.2 OPTIONS .....................................................52 | |
140 | 9.3 GET .........................................................53 | |
141 | 9.4 HEAD ........................................................54 | |
142 | 9.5 POST ........................................................54 | |
143 | 9.6 PUT .........................................................55 | |
144 | 9.7 DELETE ......................................................56 | |
145 | 9.8 TRACE .......................................................56 | |
146 | 9.9 CONNECT .....................................................57 | |
147 | 10 Status Code Definitions ......................................57 | |
148 | 10.1 Informational 1xx ...........................................57 | |
149 | 10.1.1 100 Continue .............................................58 | |
150 | 10.1.2 101 Switching Protocols ..................................58 | |
151 | 10.2 Successful 2xx ..............................................58 | |
152 | 10.2.1 200 OK ...................................................58 | |
153 | 10.2.2 201 Created ..............................................59 | |
154 | 10.2.3 202 Accepted .............................................59 | |
155 | 10.2.4 203 Non-Authoritative Information ........................59 | |
156 | 10.2.5 204 No Content ...........................................60 | |
157 | 10.2.6 205 Reset Content ........................................60 | |
158 | 10.2.7 206 Partial Content ......................................60 | |
159 | 10.3 Redirection 3xx .............................................61 | |
160 | 10.3.1 300 Multiple Choices .....................................61 | |
161 | 10.3.2 301 Moved Permanently ....................................62 | |
162 | 10.3.3 302 Found ................................................62 | |
163 | 10.3.4 303 See Other ............................................63 | |
164 | 10.3.5 304 Not Modified .........................................63 | |
165 | 10.3.6 305 Use Proxy ............................................64 | |
166 | 10.3.7 306 (Unused) .............................................64 | |
167 | ||
168 | ||
169 | ||
170 | Fielding, et al. Standards Track [Page 3] | |
171 | \f | |
172 | RFC 2616 HTTP/1.1 June 1999 | |
173 | ||
174 | ||
175 | 10.3.8 307 Temporary Redirect ...................................65 | |
176 | 10.4 Client Error 4xx ............................................65 | |
177 | 10.4.1 400 Bad Request .........................................65 | |
178 | 10.4.2 401 Unauthorized ........................................66 | |
179 | 10.4.3 402 Payment Required ....................................66 | |
180 | 10.4.4 403 Forbidden ...........................................66 | |
181 | 10.4.5 404 Not Found ...........................................66 | |
182 | 10.4.6 405 Method Not Allowed ..................................66 | |
183 | 10.4.7 406 Not Acceptable ......................................67 | |
184 | 10.4.8 407 Proxy Authentication Required .......................67 | |
185 | 10.4.9 408 Request Timeout .....................................67 | |
186 | 10.4.10 409 Conflict ............................................67 | |
187 | 10.4.11 410 Gone ................................................68 | |
188 | 10.4.12 411 Length Required .....................................68 | |
189 | 10.4.13 412 Precondition Failed .................................68 | |
190 | 10.4.14 413 Request Entity Too Large ............................69 | |
191 | 10.4.15 414 Request-URI Too Long ................................69 | |
192 | 10.4.16 415 Unsupported Media Type ..............................69 | |
193 | 10.4.17 416 Requested Range Not Satisfiable .....................69 | |
194 | 10.4.18 417 Expectation Failed ..................................70 | |
195 | 10.5 Server Error 5xx ............................................70 | |
196 | 10.5.1 500 Internal Server Error ................................70 | |
197 | 10.5.2 501 Not Implemented ......................................70 | |
198 | 10.5.3 502 Bad Gateway ..........................................70 | |
199 | 10.5.4 503 Service Unavailable ..................................70 | |
200 | 10.5.5 504 Gateway Timeout ......................................71 | |
201 | 10.5.6 505 HTTP Version Not Supported ...........................71 | |
202 | 11 Access Authentication ........................................71 | |
203 | 12 Content Negotiation ..........................................71 | |
204 | 12.1 Server-driven Negotiation ...................................72 | |
205 | 12.2 Agent-driven Negotiation ....................................73 | |
206 | 12.3 Transparent Negotiation .....................................74 | |
207 | 13 Caching in HTTP ..............................................74 | |
208 | 13.1.1 Cache Correctness ........................................75 | |
209 | 13.1.2 Warnings .................................................76 | |
210 | 13.1.3 Cache-control Mechanisms .................................77 | |
211 | 13.1.4 Explicit User Agent Warnings .............................78 | |
212 | 13.1.5 Exceptions to the Rules and Warnings .....................78 | |
213 | 13.1.6 Client-controlled Behavior ...............................79 | |
214 | 13.2 Expiration Model ............................................79 | |
215 | 13.2.1 Server-Specified Expiration ..............................79 | |
216 | 13.2.2 Heuristic Expiration .....................................80 | |
217 | 13.2.3 Age Calculations .........................................80 | |
218 | 13.2.4 Expiration Calculations ..................................83 | |
219 | 13.2.5 Disambiguating Expiration Values .........................84 | |
220 | 13.2.6 Disambiguating Multiple Responses ........................84 | |
221 | 13.3 Validation Model ............................................85 | |
222 | 13.3.1 Last-Modified Dates ......................................86 | |
223 | ||
224 | ||
225 | ||
226 | Fielding, et al. Standards Track [Page 4] | |
227 | \f | |
228 | RFC 2616 HTTP/1.1 June 1999 | |
229 | ||
230 | ||
231 | 13.3.2 Entity Tag Cache Validators ..............................86 | |
232 | 13.3.3 Weak and Strong Validators ...............................86 | |
233 | 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89 | |
234 | 13.3.5 Non-validating Conditionals ..............................90 | |
235 | 13.4 Response Cacheability .......................................91 | |
236 | 13.5 Constructing Responses From Caches ..........................92 | |
237 | 13.5.1 End-to-end and Hop-by-hop Headers ........................92 | |
238 | 13.5.2 Non-modifiable Headers ...................................92 | |
239 | 13.5.3 Combining Headers ........................................94 | |
240 | 13.5.4 Combining Byte Ranges ....................................95 | |
241 | 13.6 Caching Negotiated Responses ................................95 | |
242 | 13.7 Shared and Non-Shared Caches ................................96 | |
243 | 13.8 Errors or Incomplete Response Cache Behavior ................97 | |
244 | 13.9 Side Effects of GET and HEAD ................................97 | |
245 | 13.10 Invalidation After Updates or Deletions ...................97 | |
246 | 13.11 Write-Through Mandatory ...................................98 | |
247 | 13.12 Cache Replacement .........................................99 | |
248 | 13.13 History Lists .............................................99 | |
249 | 14 Header Field Definitions ....................................100 | |
250 | 14.1 Accept .....................................................100 | |
251 | 14.2 Accept-Charset .............................................102 | |
252 | 14.3 Accept-Encoding ............................................102 | |
253 | 14.4 Accept-Language ............................................104 | |
254 | 14.5 Accept-Ranges ..............................................105 | |
255 | 14.6 Age ........................................................106 | |
256 | 14.7 Allow ......................................................106 | |
257 | 14.8 Authorization ..............................................107 | |
258 | 14.9 Cache-Control ..............................................108 | |
259 | 14.9.1 What is Cacheable .......................................109 | |
260 | 14.9.2 What May be Stored by Caches ............................110 | |
261 | 14.9.3 Modifications of the Basic Expiration Mechanism .........111 | |
262 | 14.9.4 Cache Revalidation and Reload Controls ..................113 | |
263 | 14.9.5 No-Transform Directive ..................................115 | |
264 | 14.9.6 Cache Control Extensions ................................116 | |
265 | 14.10 Connection ...............................................117 | |
266 | 14.11 Content-Encoding .........................................118 | |
267 | 14.12 Content-Language .........................................118 | |
268 | 14.13 Content-Length ...........................................119 | |
269 | 14.14 Content-Location .........................................120 | |
270 | 14.15 Content-MD5 ..............................................121 | |
271 | 14.16 Content-Range ............................................122 | |
272 | 14.17 Content-Type .............................................124 | |
273 | 14.18 Date .....................................................124 | |
274 | 14.18.1 Clockless Origin Server Operation ......................125 | |
275 | 14.19 ETag .....................................................126 | |
276 | 14.20 Expect ...................................................126 | |
277 | 14.21 Expires ..................................................127 | |
278 | 14.22 From .....................................................128 | |
279 | ||
280 | ||
281 | ||
282 | Fielding, et al. Standards Track [Page 5] | |
283 | \f | |
284 | RFC 2616 HTTP/1.1 June 1999 | |
285 | ||
286 | ||
287 | 14.23 Host .....................................................128 | |
288 | 14.24 If-Match .................................................129 | |
289 | 14.25 If-Modified-Since ........................................130 | |
290 | 14.26 If-None-Match ............................................132 | |
291 | 14.27 If-Range .................................................133 | |
292 | 14.28 If-Unmodified-Since ......................................134 | |
293 | 14.29 Last-Modified ............................................134 | |
294 | 14.30 Location .................................................135 | |
295 | 14.31 Max-Forwards .............................................136 | |
296 | 14.32 Pragma ...................................................136 | |
297 | 14.33 Proxy-Authenticate .......................................137 | |
298 | 14.34 Proxy-Authorization ......................................137 | |
299 | 14.35 Range ....................................................138 | |
300 | 14.35.1 Byte Ranges ...........................................138 | |
301 | 14.35.2 Range Retrieval Requests ..............................139 | |
302 | 14.36 Referer ..................................................140 | |
303 | 14.37 Retry-After ..............................................141 | |
304 | 14.38 Server ...................................................141 | |
305 | 14.39 TE .......................................................142 | |
306 | 14.40 Trailer ..................................................143 | |
307 | 14.41 Transfer-Encoding..........................................143 | |
308 | 14.42 Upgrade ..................................................144 | |
309 | 14.43 User-Agent ...............................................145 | |
310 | 14.44 Vary .....................................................145 | |
311 | 14.45 Via ......................................................146 | |
312 | 14.46 Warning ..................................................148 | |
313 | 14.47 WWW-Authenticate .........................................150 | |
314 | 15 Security Considerations .......................................150 | |
315 | 15.1 Personal Information....................................151 | |
316 | 15.1.1 Abuse of Server Log Information .........................151 | |
317 | 15.1.2 Transfer of Sensitive Information .......................151 | |
318 | 15.1.3 Encoding Sensitive Information in URI's .................152 | |
319 | 15.1.4 Privacy Issues Connected to Accept Headers ..............152 | |
320 | 15.2 Attacks Based On File and Path Names .......................153 | |
321 | 15.3 DNS Spoofing ...............................................154 | |
322 | 15.4 Location Headers and Spoofing ..............................154 | |
323 | 15.5 Content-Disposition Issues .................................154 | |
324 | 15.6 Authentication Credentials and Idle Clients ................155 | |
325 | 15.7 Proxies and Caching ........................................155 | |
326 | 15.7.1 Denial of Service Attacks on Proxies....................156 | |
327 | 16 Acknowledgments .............................................156 | |
328 | 17 References ..................................................158 | |
329 | 18 Authors' Addresses ..........................................162 | |
330 | 19 Appendices ..................................................164 | |
331 | 19.1 Internet Media Type message/http and application/http ......164 | |
332 | 19.2 Internet Media Type multipart/byteranges ...................165 | |
333 | 19.3 Tolerant Applications ......................................166 | |
334 | 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167 | |
335 | ||
336 | ||
337 | ||
338 | Fielding, et al. Standards Track [Page 6] | |
339 | \f | |
340 | RFC 2616 HTTP/1.1 June 1999 | |
341 | ||
342 | ||
343 | 19.4.1 MIME-Version ............................................167 | |
344 | 19.4.2 Conversion to Canonical Form ............................167 | |
345 | 19.4.3 Conversion of Date Formats ..............................168 | |
346 | 19.4.4 Introduction of Content-Encoding ........................168 | |
347 | 19.4.5 No Content-Transfer-Encoding ............................168 | |
348 | 19.4.6 Introduction of Transfer-Encoding .......................169 | |
349 | 19.4.7 MHTML and Line Length Limitations .......................169 | |
350 | 19.5 Additional Features ........................................169 | |
351 | 19.5.1 Content-Disposition .....................................170 | |
352 | 19.6 Compatibility with Previous Versions .......................170 | |
353 | 19.6.1 Changes from HTTP/1.0 ...................................171 | |
354 | 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172 | |
355 | 19.6.3 Changes from RFC 2068 ...................................172 | |
356 | 20 Index .......................................................175 | |
357 | 21 Full Copyright Statement ....................................176 | |
358 | ||
359 | 1 Introduction | |
360 | ||
361 | 1.1 Purpose | |
362 | ||
363 | The Hypertext Transfer Protocol (HTTP) is an application-level | |
364 | protocol for distributed, collaborative, hypermedia information | |
365 | systems. HTTP has been in use by the World-Wide Web global | |
366 | information initiative since 1990. The first version of HTTP, | |
367 | referred to as HTTP/0.9, was a simple protocol for raw data transfer | |
368 | across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved | |
369 | the protocol by allowing messages to be in the format of MIME-like | |
370 | messages, containing metainformation about the data transferred and | |
371 | modifiers on the request/response semantics. However, HTTP/1.0 does | |
372 | not sufficiently take into consideration the effects of hierarchical | |
373 | proxies, caching, the need for persistent connections, or virtual | |
374 | hosts. In addition, the proliferation of incompletely-implemented | |
375 | applications calling themselves "HTTP/1.0" has necessitated a | |
376 | protocol version change in order for two communicating applications | |
377 | to determine each other's true capabilities. | |
378 | ||
379 | This specification defines the protocol referred to as "HTTP/1.1". | |
380 | This protocol includes more stringent requirements than HTTP/1.0 in | |
381 | order to ensure reliable implementation of its features. | |
382 | ||
383 | Practical information systems require more functionality than simple | |
384 | retrieval, including search, front-end update, and annotation. HTTP | |
385 | allows an open-ended set of methods and headers that indicate the | |
386 | purpose of a request [47]. It builds on the discipline of reference | |
387 | provided by the Uniform Resource Identifier (URI) [3], as a location | |
388 | (URL) [4] or name (URN) [20], for indicating the resource to which a | |
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Fielding, et al. Standards Track [Page 7] | |
395 | \f | |
396 | RFC 2616 HTTP/1.1 June 1999 | |
397 | ||
398 | ||
399 | method is to be applied. Messages are passed in a format similar to | |
400 | that used by Internet mail [9] as defined by the Multipurpose | |
401 | Internet Mail Extensions (MIME) [7]. | |
402 | ||
403 | HTTP is also used as a generic protocol for communication between | |
404 | user agents and proxies/gateways to other Internet systems, including | |
405 | those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], | |
406 | and WAIS [10] protocols. In this way, HTTP allows basic hypermedia | |
407 | access to resources available from diverse applications. | |
408 | ||
409 | 1.2 Requirements | |
410 | ||
411 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
412 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
413 | document are to be interpreted as described in RFC 2119 [34]. | |
414 | ||
415 | An implementation is not compliant if it fails to satisfy one or more | |
416 | of the MUST or REQUIRED level requirements for the protocols it | |
417 | implements. An implementation that satisfies all the MUST or REQUIRED | |
418 | level and all the SHOULD level requirements for its protocols is said | |
419 | to be "unconditionally compliant"; one that satisfies all the MUST | |
420 | level requirements but not all the SHOULD level requirements for its | |
421 | protocols is said to be "conditionally compliant." | |
422 | ||
423 | 1.3 Terminology | |
424 | ||
425 | This specification uses a number of terms to refer to the roles | |
426 | played by participants in, and objects of, the HTTP communication. | |
427 | ||
428 | connection | |
429 | A transport layer virtual circuit established between two programs | |
430 | for the purpose of communication. | |
431 | ||
432 | message | |
433 | The basic unit of HTTP communication, consisting of a structured | |
434 | sequence of octets matching the syntax defined in section 4 and | |
435 | transmitted via the connection. | |
436 | ||
437 | request | |
438 | An HTTP request message, as defined in section 5. | |
439 | ||
440 | response | |
441 | An HTTP response message, as defined in section 6. | |
442 | ||
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | Fielding, et al. Standards Track [Page 8] | |
451 | \f | |
452 | RFC 2616 HTTP/1.1 June 1999 | |
453 | ||
454 | ||
455 | resource | |
456 | A network data object or service that can be identified by a URI, | |
457 | as defined in section 3.2. Resources may be available in multiple | |
458 | representations (e.g. multiple languages, data formats, size, and | |
459 | resolutions) or vary in other ways. | |
460 | ||
461 | entity | |
462 | The information transferred as the payload of a request or | |
463 | response. An entity consists of metainformation in the form of | |
464 | entity-header fields and content in the form of an entity-body, as | |
465 | described in section 7. | |
466 | ||
467 | representation | |
468 | An entity included with a response that is subject to content | |
469 | negotiation, as described in section 12. There may exist multiple | |
470 | representations associated with a particular response status. | |
471 | ||
472 | content negotiation | |
473 | The mechanism for selecting the appropriate representation when | |
474 | servicing a request, as described in section 12. The | |
475 | representation of entities in any response can be negotiated | |
476 | (including error responses). | |
477 | ||
478 | variant | |
479 | A resource may have one, or more than one, representation(s) | |
480 | associated with it at any given instant. Each of these | |
481 | representations is termed a `varriant'. Use of the term `variant' | |
482 | does not necessarily imply that the resource is subject to content | |
483 | negotiation. | |
484 | ||
485 | client | |
486 | A program that establishes connections for the purpose of sending | |
487 | requests. | |
488 | ||
489 | user agent | |
490 | The client which initiates a request. These are often browsers, | |
491 | editors, spiders (web-traversing robots), or other end user tools. | |
492 | ||
493 | server | |
494 | An application program that accepts connections in order to | |
495 | service requests by sending back responses. Any given program may | |
496 | be capable of being both a client and a server; our use of these | |
497 | terms refers only to the role being performed by the program for a | |
498 | particular connection, rather than to the program's capabilities | |
499 | in general. Likewise, any server may act as an origin server, | |
500 | proxy, gateway, or tunnel, switching behavior based on the nature | |
501 | of each request. | |
502 | ||
503 | ||
504 | ||
505 | ||
506 | Fielding, et al. Standards Track [Page 9] | |
507 | \f | |
508 | RFC 2616 HTTP/1.1 June 1999 | |
509 | ||
510 | ||
511 | origin server | |
512 | The server on which a given resource resides or is to be created. | |
513 | ||
514 | proxy | |
515 | An intermediary program which acts as both a server and a client | |
516 | for the purpose of making requests on behalf of other clients. | |
517 | Requests are serviced internally or by passing them on, with | |
518 | possible translation, to other servers. A proxy MUST implement | |
519 | both the client and server requirements of this specification. A | |
520 | "transparent proxy" is a proxy that does not modify the request or | |
521 | response beyond what is required for proxy authentication and | |
522 | identification. A "non-transparent proxy" is a proxy that modifies | |
523 | the request or response in order to provide some added service to | |
524 | the user agent, such as group annotation services, media type | |
525 | transformation, protocol reduction, or anonymity filtering. Except | |
526 | where either transparent or non-transparent behavior is explicitly | |
527 | stated, the HTTP proxy requirements apply to both types of | |
528 | proxies. | |
529 | ||
530 | gateway | |
531 | A server which acts as an intermediary for some other server. | |
532 | Unlike a proxy, a gateway receives requests as if it were the | |
533 | origin server for the requested resource; the requesting client | |
534 | may not be aware that it is communicating with a gateway. | |
535 | ||
536 | tunnel | |
537 | An intermediary program which is acting as a blind relay between | |
538 | two connections. Once active, a tunnel is not considered a party | |
539 | to the HTTP communication, though the tunnel may have been | |
540 | initiated by an HTTP request. The tunnel ceases to exist when both | |
541 | ends of the relayed connections are closed. | |
542 | ||
543 | cache | |
544 | A program's local store of response messages and the subsystem | |
545 | that controls its message storage, retrieval, and deletion. A | |
546 | cache stores cacheable responses in order to reduce the response | |
547 | time and network bandwidth consumption on future, equivalent | |
548 | requests. Any client or server may include a cache, though a cache | |
549 | cannot be used by a server that is acting as a tunnel. | |
550 | ||
551 | cacheable | |
552 | A response is cacheable if a cache is allowed to store a copy of | |
553 | the response message for use in answering subsequent requests. The | |
554 | rules for determining the cacheability of HTTP responses are | |
555 | defined in section 13. Even if a resource is cacheable, there may | |
556 | be additional constraints on whether a cache can use the cached | |
557 | copy for a particular request. | |
558 | ||
559 | ||
560 | ||
561 | ||
562 | Fielding, et al. Standards Track [Page 10] | |
563 | \f | |
564 | RFC 2616 HTTP/1.1 June 1999 | |
565 | ||
566 | ||
567 | first-hand | |
568 | A response is first-hand if it comes directly and without | |
569 | unnecessary delay from the origin server, perhaps via one or more | |
570 | proxies. A response is also first-hand if its validity has just | |
571 | been checked directly with the origin server. | |
572 | ||
573 | explicit expiration time | |
574 | The time at which the origin server intends that an entity should | |
575 | no longer be returned by a cache without further validation. | |
576 | ||
577 | heuristic expiration time | |
578 | An expiration time assigned by a cache when no explicit expiration | |
579 | time is available. | |
580 | ||
581 | age | |
582 | The age of a response is the time since it was sent by, or | |
583 | successfully validated with, the origin server. | |
584 | ||
585 | freshness lifetime | |
586 | The length of time between the generation of a response and its | |
587 | expiration time. | |
588 | ||
589 | fresh | |
590 | A response is fresh if its age has not yet exceeded its freshness | |
591 | lifetime. | |
592 | ||
593 | stale | |
594 | A response is stale if its age has passed its freshness lifetime. | |
595 | ||
596 | semantically transparent | |
597 | A cache behaves in a "semantically transparent" manner, with | |
598 | respect to a particular response, when its use affects neither the | |
599 | requesting client nor the origin server, except to improve | |
600 | performance. When a cache is semantically transparent, the client | |
601 | receives exactly the same response (except for hop-by-hop headers) | |
602 | that it would have received had its request been handled directly | |
603 | by the origin server. | |
604 | ||
605 | validator | |
606 | A protocol element (e.g., an entity tag or a Last-Modified time) | |
607 | that is used to find out whether a cache entry is an equivalent | |
608 | copy of an entity. | |
609 | ||
610 | upstream/downstream | |
611 | Upstream and downstream describe the flow of a message: all | |
612 | messages flow from upstream to downstream. | |
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Fielding, et al. Standards Track [Page 11] | |
619 | \f | |
620 | RFC 2616 HTTP/1.1 June 1999 | |
621 | ||
622 | ||
623 | inbound/outbound | |
624 | Inbound and outbound refer to the request and response paths for | |
625 | messages: "inbound" means "traveling toward the origin server", | |
626 | and "outbound" means "traveling toward the user agent" | |
627 | ||
628 | 1.4 Overall Operation | |
629 | ||
630 | The HTTP protocol is a request/response protocol. A client sends a | |
631 | request to the server in the form of a request method, URI, and | |
632 | protocol version, followed by a MIME-like message containing request | |
633 | modifiers, client information, and possible body content over a | |
634 | connection with a server. The server responds with a status line, | |
635 | including the message's protocol version and a success or error code, | |
636 | followed by a MIME-like message containing server information, entity | |
637 | metainformation, and possible entity-body content. The relationship | |
638 | between HTTP and MIME is described in appendix 19.4. | |
639 | ||
640 | Most HTTP communication is initiated by a user agent and consists of | |
641 | a request to be applied to a resource on some origin server. In the | |
642 | simplest case, this may be accomplished via a single connection (v) | |
643 | between the user agent (UA) and the origin server (O). | |
644 | ||
645 | request chain ------------------------> | |
646 | UA -------------------v------------------- O | |
647 | <----------------------- response chain | |
648 | ||
649 | A more complicated situation occurs when one or more intermediaries | |
650 | are present in the request/response chain. There are three common | |
651 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a | |
652 | forwarding agent, receiving requests for a URI in its absolute form, | |
653 | rewriting all or part of the message, and forwarding the reformatted | |
654 | request toward the server identified by the URI. A gateway is a | |
655 | receiving agent, acting as a layer above some other server(s) and, if | |
656 | necessary, translating the requests to the underlying server's | |
657 | protocol. A tunnel acts as a relay point between two connections | |
658 | without changing the messages; tunnels are used when the | |
659 | communication needs to pass through an intermediary (such as a | |
660 | firewall) even when the intermediary cannot understand the contents | |
661 | of the messages. | |
662 | ||
663 | request chain --------------------------------------> | |
664 | UA -----v----- A -----v----- B -----v----- C -----v----- O | |
665 | <------------------------------------- response chain | |
666 | ||
667 | The figure above shows three intermediaries (A, B, and C) between the | |
668 | user agent and origin server. A request or response message that | |
669 | travels the whole chain will pass through four separate connections. | |
670 | This distinction is important because some HTTP communication options | |
671 | ||
672 | ||
673 | ||
674 | Fielding, et al. Standards Track [Page 12] | |
675 | \f | |
676 | RFC 2616 HTTP/1.1 June 1999 | |
677 | ||
678 | ||
679 | may apply only to the connection with the nearest, non-tunnel | |
680 | neighbor, only to the end-points of the chain, or to all connections | |
681 | along the chain. Although the diagram is linear, each participant may | |
682 | be engaged in multiple, simultaneous communications. For example, B | |
683 | may be receiving requests from many clients other than A, and/or | |
684 | forwarding requests to servers other than C, at the same time that it | |
685 | is handling A's request. | |
686 | ||
687 | Any party to the communication which is not acting as a tunnel may | |
688 | employ an internal cache for handling requests. The effect of a cache | |
689 | is that the request/response chain is shortened if one of the | |
690 | participants along the chain has a cached response applicable to that | |
691 | request. The following illustrates the resulting chain if B has a | |
692 | cached copy of an earlier response from O (via C) for a request which | |
693 | has not been cached by UA or A. | |
694 | ||
695 | request chain ----------> | |
696 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O | |
697 | <--------- response chain | |
698 | ||
699 | Not all responses are usefully cacheable, and some requests may | |
700 | contain modifiers which place special requirements on cache behavior. | |
701 | HTTP requirements for cache behavior and cacheable responses are | |
702 | defined in section 13. | |
703 | ||
704 | In fact, there are a wide variety of architectures and configurations | |
705 | of caches and proxies currently being experimented with or deployed | |
706 | across the World Wide Web. These systems include national hierarchies | |
707 | of proxy caches to save transoceanic bandwidth, systems that | |
708 | broadcast or multicast cache entries, organizations that distribute | |
709 | subsets of cached data via CD-ROM, and so on. HTTP systems are used | |
710 | in corporate intranets over high-bandwidth links, and for access via | |
711 | PDAs with low-power radio links and intermittent connectivity. The | |
712 | goal of HTTP/1.1 is to support the wide diversity of configurations | |
713 | already deployed while introducing protocol constructs that meet the | |
714 | needs of those who build web applications that require high | |
715 | reliability and, failing that, at least reliable indications of | |
716 | failure. | |
717 | ||
718 | HTTP communication usually takes place over TCP/IP connections. The | |
719 | default port is TCP 80 [19], but other ports can be used. This does | |
720 | not preclude HTTP from being implemented on top of any other protocol | |
721 | on the Internet, or on other networks. HTTP only presumes a reliable | |
722 | transport; any protocol that provides such guarantees can be used; | |
723 | the mapping of the HTTP/1.1 request and response structures onto the | |
724 | transport data units of the protocol in question is outside the scope | |
725 | of this specification. | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Fielding, et al. Standards Track [Page 13] | |
731 | \f | |
732 | RFC 2616 HTTP/1.1 June 1999 | |
733 | ||
734 | ||
735 | In HTTP/1.0, most implementations used a new connection for each | |
736 | request/response exchange. In HTTP/1.1, a connection may be used for | |
737 | one or more request/response exchanges, although connections may be | |
738 | closed for a variety of reasons (see section 8.1). | |
739 | ||
740 | 2 Notational Conventions and Generic Grammar | |
741 | ||
742 | 2.1 Augmented BNF | |
743 | ||
744 | All of the mechanisms specified in this document are described in | |
745 | both prose and an augmented Backus-Naur Form (BNF) similar to that | |
746 | used by RFC 822 [9]. Implementors will need to be familiar with the | |
747 | notation in order to understand this specification. The augmented BNF | |
748 | includes the following constructs: | |
749 | ||
750 | name = definition | |
751 | The name of a rule is simply the name itself (without any | |
752 | enclosing "<" and ">") and is separated from its definition by the | |
753 | equal "=" character. White space is only significant in that | |
754 | indentation of continuation lines is used to indicate a rule | |
755 | definition that spans more than one line. Certain basic rules are | |
756 | in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle | |
757 | brackets are used within definitions whenever their presence will | |
758 | facilitate discerning the use of rule names. | |
759 | ||
760 | "literal" | |
761 | Quotation marks surround literal text. Unless stated otherwise, | |
762 | the text is case-insensitive. | |
763 | ||
764 | rule1 | rule2 | |
765 | Elements separated by a bar ("|") are alternatives, e.g., "yes | | |
766 | no" will accept yes or no. | |
767 | ||
768 | (rule1 rule2) | |
769 | Elements enclosed in parentheses are treated as a single element. | |
770 | Thus, "(elem (foo | bar) elem)" allows the token sequences "elem | |
771 | foo elem" and "elem bar elem". | |
772 | ||
773 | *rule | |
774 | The character "*" preceding an element indicates repetition. The | |
775 | full form is "<n>*<m>element" indicating at least <n> and at most | |
776 | <m> occurrences of element. Default values are 0 and infinity so | |
777 | that "*(element)" allows any number, including zero; "1*element" | |
778 | requires at least one; and "1*2element" allows one or two. | |
779 | ||
780 | [rule] | |
781 | Square brackets enclose optional elements; "[foo bar]" is | |
782 | equivalent to "*1(foo bar)". | |
783 | ||
784 | ||
785 | ||
786 | Fielding, et al. Standards Track [Page 14] | |
787 | \f | |
788 | RFC 2616 HTTP/1.1 June 1999 | |
789 | ||
790 | ||
791 | N rule | |
792 | Specific repetition: "<n>(element)" is equivalent to | |
793 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). | |
794 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three | |
795 | alphabetic characters. | |
796 | ||
797 | #rule | |
798 | A construct "#" is defined, similar to "*", for defining lists of | |
799 | elements. The full form is "<n>#<m>element" indicating at least | |
800 | <n> and at most <m> elements, each separated by one or more commas | |
801 | (",") and OPTIONAL linear white space (LWS). This makes the usual | |
802 | form of lists very easy; a rule such as | |
803 | ( *LWS element *( *LWS "," *LWS element )) | |
804 | can be shown as | |
805 | 1#element | |
806 | Wherever this construct is used, null elements are allowed, but do | |
807 | not contribute to the count of elements present. That is, | |
808 | "(element), , (element) " is permitted, but counts as only two | |
809 | elements. Therefore, where at least one element is required, at | |
810 | least one non-null element MUST be present. Default values are 0 | |
811 | and infinity so that "#element" allows any number, including zero; | |
812 | "1#element" requires at least one; and "1#2element" allows one or | |
813 | two. | |
814 | ||
815 | ; comment | |
816 | A semi-colon, set off some distance to the right of rule text, | |
817 | starts a comment that continues to the end of line. This is a | |
818 | simple way of including useful notes in parallel with the | |
819 | specifications. | |
820 | ||
821 | implied *LWS | |
822 | The grammar described by this specification is word-based. Except | |
823 | where noted otherwise, linear white space (LWS) can be included | |
824 | between any two adjacent words (token or quoted-string), and | |
825 | between adjacent words and separators, without changing the | |
826 | interpretation of a field. At least one delimiter (LWS and/or | |
827 | ||
828 | separators) MUST exist between any two tokens (for the definition | |
829 | of "token" below), since they would otherwise be interpreted as a | |
830 | single token. | |
831 | ||
832 | 2.2 Basic Rules | |
833 | ||
834 | The following rules are used throughout this specification to | |
835 | describe basic parsing constructs. The US-ASCII coded character set | |
836 | is defined by ANSI X3.4-1986 [21]. | |
837 | ||
838 | ||
839 | ||
840 | ||
841 | ||
842 | Fielding, et al. Standards Track [Page 15] | |
843 | \f | |
844 | RFC 2616 HTTP/1.1 June 1999 | |
845 | ||
846 | ||
847 | OCTET = <any 8-bit sequence of data> | |
848 | CHAR = <any US-ASCII character (octets 0 - 127)> | |
849 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |
850 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |
851 | ALPHA = UPALPHA | LOALPHA | |
852 | DIGIT = <any US-ASCII digit "0".."9"> | |
853 | CTL = <any US-ASCII control character | |
854 | (octets 0 - 31) and DEL (127)> | |
855 | CR = <US-ASCII CR, carriage return (13)> | |
856 | LF = <US-ASCII LF, linefeed (10)> | |
857 | SP = <US-ASCII SP, space (32)> | |
858 | HT = <US-ASCII HT, horizontal-tab (9)> | |
859 | <"> = <US-ASCII double-quote mark (34)> | |
860 | ||
861 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |
862 | protocol elements except the entity-body (see appendix 19.3 for | |
863 | tolerant applications). The end-of-line marker within an entity-body | |
864 | is defined by its associated media type, as described in section 3.7. | |
865 | ||
866 | CRLF = CR LF | |
867 | ||
868 | HTTP/1.1 header field values can be folded onto multiple lines if the | |
869 | continuation line begins with a space or horizontal tab. All linear | |
870 | white space, including folding, has the same semantics as SP. A | |
871 | recipient MAY replace any linear white space with a single SP before | |
872 | interpreting the field value or forwarding the message downstream. | |
873 | ||
874 | LWS = [CRLF] 1*( SP | HT ) | |
875 | ||
876 | The TEXT rule is only used for descriptive field contents and values | |
877 | that are not intended to be interpreted by the message parser. Words | |
878 | of *TEXT MAY contain characters from character sets other than ISO- | |
879 | 8859-1 [22] only when encoded according to the rules of RFC 2047 | |
880 | [14]. | |
881 | ||
882 | TEXT = <any OCTET except CTLs, | |
883 | but including LWS> | |
884 | ||
885 | A CRLF is allowed in the definition of TEXT only as part of a header | |
886 | field continuation. It is expected that the folding LWS will be | |
887 | replaced with a single SP before interpretation of the TEXT value. | |
888 | ||
889 | Hexadecimal numeric characters are used in several protocol elements. | |
890 | ||
891 | HEX = "A" | "B" | "C" | "D" | "E" | "F" | |
892 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |
893 | ||
894 | ||
895 | ||
896 | ||
897 | ||
898 | Fielding, et al. Standards Track [Page 16] | |
899 | \f | |
900 | RFC 2616 HTTP/1.1 June 1999 | |
901 | ||
902 | ||
903 | Many HTTP/1.1 header field values consist of words separated by LWS | |
904 | or special characters. These special characters MUST be in a quoted | |
905 | string to be used within a parameter value (as defined in section | |
906 | 3.6). | |
907 | ||
908 | token = 1*<any CHAR except CTLs or separators> | |
909 | separators = "(" | ")" | "<" | ">" | "@" | |
910 | | "," | ";" | ":" | "\" | <"> | |
911 | | "/" | "[" | "]" | "?" | "=" | |
912 | | "{" | "}" | SP | HT | |
913 | ||
914 | Comments can be included in some HTTP header fields by surrounding | |
915 | the comment text with parentheses. Comments are only allowed in | |
916 | fields containing "comment" as part of their field value definition. | |
917 | In all other fields, parentheses are considered part of the field | |
918 | value. | |
919 | ||
920 | comment = "(" *( ctext | quoted-pair | comment ) ")" | |
921 | ctext = <any TEXT excluding "(" and ")"> | |
922 | ||
923 | A string of text is parsed as a single word if it is quoted using | |
924 | double-quote marks. | |
925 | ||
926 | quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) | |
927 | qdtext = <any TEXT except <">> | |
928 | ||
929 | The backslash character ("\") MAY be used as a single-character | |
930 | quoting mechanism only within quoted-string and comment constructs. | |
931 | ||
932 | quoted-pair = "\" CHAR | |
933 | ||
934 | 3 Protocol Parameters | |
935 | ||
936 | 3.1 HTTP Version | |
937 | ||
938 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | |
939 | of the protocol. The protocol versioning policy is intended to allow | |
940 | the sender to indicate the format of a message and its capacity for | |
941 | understanding further HTTP communication, rather than the features | |
942 | obtained via that communication. No change is made to the version | |
943 | number for the addition of message components which do not affect | |
944 | communication behavior or which only add to extensible field values. | |
945 | The <minor> number is incremented when the changes made to the | |
946 | protocol add features which do not change the general message parsing | |
947 | algorithm, but which may add to the message semantics and imply | |
948 | additional capabilities of the sender. The <major> number is | |
949 | incremented when the format of a message within the protocol is | |
950 | changed. See RFC 2145 [36] for a fuller explanation. | |
951 | ||
952 | ||
953 | ||
954 | Fielding, et al. Standards Track [Page 17] | |
955 | \f | |
956 | RFC 2616 HTTP/1.1 June 1999 | |
957 | ||
958 | ||
959 | The version of an HTTP message is indicated by an HTTP-Version field | |
960 | in the first line of the message. | |
961 | ||
962 | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |
963 | ||
964 | Note that the major and minor numbers MUST be treated as separate | |
965 | integers and that each MAY be incremented higher than a single digit. | |
966 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |
967 | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and | |
968 | MUST NOT be sent. | |
969 | ||
970 | An application that sends a request or response message that includes | |
971 | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | |
972 | with this specification. Applications that are at least conditionally | |
973 | compliant with this specification SHOULD use an HTTP-Version of | |
974 | "HTTP/1.1" in their messages, and MUST do so for any message that is | |
975 | not compatible with HTTP/1.0. For more details on when to send | |
976 | specific HTTP-Version values, see RFC 2145 [36]. | |
977 | ||
978 | The HTTP version of an application is the highest HTTP version for | |
979 | which the application is at least conditionally compliant. | |
980 | ||
981 | Proxy and gateway applications need to be careful when forwarding | |
982 | messages in protocol versions different from that of the application. | |
983 | Since the protocol version indicates the protocol capability of the | |
984 | sender, a proxy/gateway MUST NOT send a message with a version | |
985 | indicator which is greater than its actual version. If a higher | |
986 | version request is received, the proxy/gateway MUST either downgrade | |
987 | the request version, or respond with an error, or switch to tunnel | |
988 | behavior. | |
989 | ||
990 | Due to interoperability problems with HTTP/1.0 proxies discovered | |
991 | since the publication of RFC 2068[33], caching proxies MUST, gateways | |
992 | MAY, and tunnels MUST NOT upgrade the request to the highest version | |
993 | they support. The proxy/gateway's response to that request MUST be in | |
994 | the same major version as the request. | |
995 | ||
996 | Note: Converting between versions of HTTP may involve modification | |
997 | of header fields required or forbidden by the versions involved. | |
998 | ||
999 | 3.2 Uniform Resource Identifiers | |
1000 | ||
1001 | URIs have been known by many names: WWW addresses, Universal Document | |
1002 | Identifiers, Universal Resource Identifiers [3], and finally the | |
1003 | combination of Uniform Resource Locators (URL) [4] and Names (URN) | |
1004 | [20]. As far as HTTP is concerned, Uniform Resource Identifiers are | |
1005 | simply formatted strings which identify--via name, location, or any | |
1006 | other characteristic--a resource. | |
1007 | ||
1008 | ||
1009 | ||
1010 | Fielding, et al. Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 2616 HTTP/1.1 June 1999 | |
1013 | ||
1014 | ||
1015 | 3.2.1 General Syntax | |
1016 | ||
1017 | URIs in HTTP can be represented in absolute form or relative to some | |
1018 | known base URI [11], depending upon the context of their use. The two | |
1019 | forms are differentiated by the fact that absolute URIs always begin | |
1020 | with a scheme name followed by a colon. For definitive information on | |
1021 | URL syntax and semantics, see "Uniform Resource Identifiers (URI): | |
1022 | Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs | |
1023 | 1738 [4] and RFC 1808 [11]). This specification adopts the | |
1024 | definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | |
1025 | "host","abs_path", "rel_path", and "authority" from that | |
1026 | specification. | |
1027 | ||
1028 | The HTTP protocol does not place any a priori limit on the length of | |
1029 | a URI. Servers MUST be able to handle the URI of any resource they | |
1030 | serve, and SHOULD be able to handle URIs of unbounded length if they | |
1031 | provide GET-based forms that could generate such URIs. A server | |
1032 | SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |
1033 | than the server can handle (see section 10.4.15). | |
1034 | ||
1035 | Note: Servers ought to be cautious about depending on URI lengths | |
1036 | above 255 bytes, because some older client or proxy | |
1037 | implementations might not properly support these lengths. | |
1038 | ||
1039 | 3.2.2 http URL | |
1040 | ||
1041 | The "http" scheme is used to locate network resources via the HTTP | |
1042 | protocol. This section defines the scheme-specific syntax and | |
1043 | semantics for http URLs. | |
1044 | ||
1045 | http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | |
1046 | ||
1047 | If the port is empty or not given, port 80 is assumed. The semantics | |
1048 | are that the identified resource is located at the server listening | |
1049 | for TCP connections on that port of that host, and the Request-URI | |
1050 | for the resource is abs_path (section 5.1.2). The use of IP addresses | |
1051 | in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If | |
1052 | the abs_path is not present in the URL, it MUST be given as "/" when | |
1053 | used as a Request-URI for a resource (section 5.1.2). If a proxy | |
1054 | receives a host name which is not a fully qualified domain name, it | |
1055 | MAY add its domain to the host name it received. If a proxy receives | |
1056 | a fully qualified domain name, the proxy MUST NOT change the host | |
1057 | name. | |
1058 | ||
1059 | ||
1060 | ||
1061 | ||
1062 | ||
1063 | ||
1064 | ||
1065 | ||
1066 | Fielding, et al. Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 2616 HTTP/1.1 June 1999 | |
1069 | ||
1070 | ||
1071 | 3.2.3 URI Comparison | |
1072 | ||
1073 | When comparing two URIs to decide if they match or not, a client | |
1074 | SHOULD use a case-sensitive octet-by-octet comparison of the entire | |
1075 | URIs, with these exceptions: | |
1076 | ||
1077 | - A port that is empty or not given is equivalent to the default | |
1078 | port for that URI-reference; | |
1079 | ||
1080 | - Comparisons of host names MUST be case-insensitive; | |
1081 | ||
1082 | - Comparisons of scheme names MUST be case-insensitive; | |
1083 | ||
1084 | - An empty abs_path is equivalent to an abs_path of "/". | |
1085 | ||
1086 | Characters other than those in the "reserved" and "unsafe" sets (see | |
1087 | RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. | |
1088 | ||
1089 | For example, the following three URIs are equivalent: | |
1090 | ||
1091 | http://abc.com:80/~smith/home.html | |
1092 | http://ABC.com/%7Esmith/home.html | |
1093 | http://ABC.com:/%7esmith/home.html | |
1094 | ||
1095 | 3.3 Date/Time Formats | |
1096 | ||
1097 | 3.3.1 Full Date | |
1098 | ||
1099 | HTTP applications have historically allowed three different formats | |
1100 | for the representation of date/time stamps: | |
1101 | ||
1102 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 | |
1103 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | |
1104 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |
1105 | ||
1106 | The first format is preferred as an Internet standard and represents | |
1107 | a fixed-length subset of that defined by RFC 1123 [8] (an update to | |
1108 | RFC 822 [9]). The second format is in common use, but is based on the | |
1109 | obsolete RFC 850 [12] date format and lacks a four-digit year. | |
1110 | HTTP/1.1 clients and servers that parse the date value MUST accept | |
1111 | all three formats (for compatibility with HTTP/1.0), though they MUST | |
1112 | only generate the RFC 1123 format for representing HTTP-date values | |
1113 | in header fields. See section 19.3 for further information. | |
1114 | ||
1115 | Note: Recipients of date values are encouraged to be robust in | |
1116 | accepting date values that may have been sent by non-HTTP | |
1117 | applications, as is sometimes the case when retrieving or posting | |
1118 | messages via proxies/gateways to SMTP or NNTP. | |
1119 | ||
1120 | ||
1121 | ||
1122 | Fielding, et al. Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 2616 HTTP/1.1 June 1999 | |
1125 | ||
1126 | ||
1127 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time | |
1128 | (GMT), without exception. For the purposes of HTTP, GMT is exactly | |
1129 | equal to UTC (Coordinated Universal Time). This is indicated in the | |
1130 | first two formats by the inclusion of "GMT" as the three-letter | |
1131 | abbreviation for time zone, and MUST be assumed when reading the | |
1132 | asctime format. HTTP-date is case sensitive and MUST NOT include | |
1133 | additional LWS beyond that specifically included as SP in the | |
1134 | grammar. | |
1135 | ||
1136 | HTTP-date = rfc1123-date | rfc850-date | asctime-date | |
1137 | rfc1123-date = wkday "," SP date1 SP time SP "GMT" | |
1138 | rfc850-date = weekday "," SP date2 SP time SP "GMT" | |
1139 | asctime-date = wkday SP date3 SP time SP 4DIGIT | |
1140 | date1 = 2DIGIT SP month SP 4DIGIT | |
1141 | ; day month year (e.g., 02 Jun 1982) | |
1142 | date2 = 2DIGIT "-" month "-" 2DIGIT | |
1143 | ; day-month-year (e.g., 02-Jun-82) | |
1144 | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | |
1145 | ; month day (e.g., Jun 2) | |
1146 | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |
1147 | ; 00:00:00 - 23:59:59 | |
1148 | wkday = "Mon" | "Tue" | "Wed" | |
1149 | | "Thu" | "Fri" | "Sat" | "Sun" | |
1150 | weekday = "Monday" | "Tuesday" | "Wednesday" | |
1151 | | "Thursday" | "Friday" | "Saturday" | "Sunday" | |
1152 | month = "Jan" | "Feb" | "Mar" | "Apr" | |
1153 | | "May" | "Jun" | "Jul" | "Aug" | |
1154 | | "Sep" | "Oct" | "Nov" | "Dec" | |
1155 | ||
1156 | Note: HTTP requirements for the date/time stamp format apply only | |
1157 | to their usage within the protocol stream. Clients and servers are | |
1158 | not required to use these formats for user presentation, request | |
1159 | logging, etc. | |
1160 | ||
1161 | 3.3.2 Delta Seconds | |
1162 | ||
1163 | Some HTTP header fields allow a time value to be specified as an | |
1164 | integer number of seconds, represented in decimal, after the time | |
1165 | that the message was received. | |
1166 | ||
1167 | delta-seconds = 1*DIGIT | |
1168 | ||
1169 | 3.4 Character Sets | |
1170 | ||
1171 | HTTP uses the same definition of the term "character set" as that | |
1172 | described for MIME: | |
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Fielding, et al. Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 2616 HTTP/1.1 June 1999 | |
1181 | ||
1182 | ||
1183 | The term "character set" is used in this document to refer to a | |
1184 | method used with one or more tables to convert a sequence of octets | |
1185 | into a sequence of characters. Note that unconditional conversion in | |
1186 | the other direction is not required, in that not all characters may | |
1187 | be available in a given character set and a character set may provide | |
1188 | more than one sequence of octets to represent a particular character. | |
1189 | This definition is intended to allow various kinds of character | |
1190 | encoding, from simple single-table mappings such as US-ASCII to | |
1191 | complex table switching methods such as those that use ISO-2022's | |
1192 | techniques. However, the definition associated with a MIME character | |
1193 | set name MUST fully specify the mapping to be performed from octets | |
1194 | to characters. In particular, use of external profiling information | |
1195 | to determine the exact mapping is not permitted. | |
1196 | ||
1197 | Note: This use of the term "character set" is more commonly | |
1198 | referred to as a "character encoding." However, since HTTP and | |
1199 | MIME share the same registry, it is important that the terminology | |
1200 | also be shared. | |
1201 | ||
1202 | HTTP character sets are identified by case-insensitive tokens. The | |
1203 | complete set of tokens is defined by the IANA Character Set registry | |
1204 | [19]. | |
1205 | ||
1206 | charset = token | |
1207 | ||
1208 | Although HTTP allows an arbitrary token to be used as a charset | |
1209 | value, any token that has a predefined value within the IANA | |
1210 | Character Set registry [19] MUST represent the character set defined | |
1211 | by that registry. Applications SHOULD limit their use of character | |
1212 | sets to those defined by the IANA registry. | |
1213 | ||
1214 | Implementors should be aware of IETF character set requirements [38] | |
1215 | [41]. | |
1216 | ||
1217 | 3.4.1 Missing Charset | |
1218 | ||
1219 | Some HTTP/1.0 software has interpreted a Content-Type header without | |
1220 | charset parameter incorrectly to mean "recipient should guess." | |
1221 | Senders wishing to defeat this behavior MAY include a charset | |
1222 | parameter even when the charset is ISO-8859-1 and SHOULD do so when | |
1223 | it is known that it will not confuse the recipient. | |
1224 | ||
1225 | Unfortunately, some older HTTP/1.0 clients did not deal properly with | |
1226 | an explicit charset parameter. HTTP/1.1 recipients MUST respect the | |
1227 | charset label provided by the sender; and those user agents that have | |
1228 | a provision to "guess" a charset MUST use the charset from the | |
1229 | ||
1230 | ||
1231 | ||
1232 | ||
1233 | ||
1234 | Fielding, et al. Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 2616 HTTP/1.1 June 1999 | |
1237 | ||
1238 | ||
1239 | content-type field if they support that charset, rather than the | |
1240 | recipient's preference, when initially displaying a document. See | |
1241 | section 3.7.1. | |
1242 | ||
1243 | 3.5 Content Codings | |
1244 | ||
1245 | Content coding values indicate an encoding transformation that has | |
1246 | been or can be applied to an entity. Content codings are primarily | |
1247 | used to allow a document to be compressed or otherwise usefully | |
1248 | transformed without losing the identity of its underlying media type | |
1249 | and without loss of information. Frequently, the entity is stored in | |
1250 | coded form, transmitted directly, and only decoded by the recipient. | |
1251 | ||
1252 | content-coding = token | |
1253 | ||
1254 | All content-coding values are case-insensitive. HTTP/1.1 uses | |
1255 | content-coding values in the Accept-Encoding (section 14.3) and | |
1256 | Content-Encoding (section 14.11) header fields. Although the value | |
1257 | describes the content-coding, what is more important is that it | |
1258 | indicates what decoding mechanism will be required to remove the | |
1259 | encoding. | |
1260 | ||
1261 | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |
1262 | content-coding value tokens. Initially, the registry contains the | |
1263 | following tokens: | |
1264 | ||
1265 | gzip An encoding format produced by the file compression program | |
1266 | "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a | |
1267 | Lempel-Ziv coding (LZ77) with a 32 bit CRC. | |
1268 | ||
1269 | compress | |
1270 | The encoding format produced by the common UNIX file compression | |
1271 | program "compress". This format is an adaptive Lempel-Ziv-Welch | |
1272 | coding (LZW). | |
1273 | ||
1274 | Use of program names for the identification of encoding formats | |
1275 | is not desirable and is discouraged for future encodings. Their | |
1276 | use here is representative of historical practice, not good | |
1277 | design. For compatibility with previous implementations of HTTP, | |
1278 | applications SHOULD consider "x-gzip" and "x-compress" to be | |
1279 | equivalent to "gzip" and "compress" respectively. | |
1280 | ||
1281 | deflate | |
1282 | The "zlib" format defined in RFC 1950 [31] in combination with | |
1283 | the "deflate" compression mechanism described in RFC 1951 [29]. | |
1284 | ||
1285 | ||
1286 | ||
1287 | ||
1288 | ||
1289 | ||
1290 | Fielding, et al. Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 2616 HTTP/1.1 June 1999 | |
1293 | ||
1294 | ||
1295 | identity | |
1296 | The default (identity) encoding; the use of no transformation | |
1297 | whatsoever. This content-coding is used only in the Accept- | |
1298 | Encoding header, and SHOULD NOT be used in the Content-Encoding | |
1299 | header. | |
1300 | ||
1301 | New content-coding value tokens SHOULD be registered; to allow | |
1302 | interoperability between clients and servers, specifications of the | |
1303 | content coding algorithms needed to implement a new value SHOULD be | |
1304 | publicly available and adequate for independent implementation, and | |
1305 | conform to the purpose of content coding defined in this section. | |
1306 | ||
1307 | 3.6 Transfer Codings | |
1308 | ||
1309 | Transfer-coding values are used to indicate an encoding | |
1310 | transformation that has been, can be, or may need to be applied to an | |
1311 | entity-body in order to ensure "safe transport" through the network. | |
1312 | This differs from a content coding in that the transfer-coding is a | |
1313 | property of the message, not of the original entity. | |
1314 | ||
1315 | transfer-coding = "chunked" | transfer-extension | |
1316 | transfer-extension = token *( ";" parameter ) | |
1317 | ||
1318 | Parameters are in the form of attribute/value pairs. | |
1319 | ||
1320 | parameter = attribute "=" value | |
1321 | attribute = token | |
1322 | value = token | quoted-string | |
1323 | ||
1324 | All transfer-coding values are case-insensitive. HTTP/1.1 uses | |
1325 | transfer-coding values in the TE header field (section 14.39) and in | |
1326 | the Transfer-Encoding header field (section 14.41). | |
1327 | ||
1328 | Whenever a transfer-coding is applied to a message-body, the set of | |
1329 | transfer-codings MUST include "chunked", unless the message is | |
1330 | terminated by closing the connection. When the "chunked" transfer- | |
1331 | coding is used, it MUST be the last transfer-coding applied to the | |
1332 | message-body. The "chunked" transfer-coding MUST NOT be applied more | |
1333 | than once to a message-body. These rules allow the recipient to | |
1334 | determine the transfer-length of the message (section 4.4). | |
1335 | ||
1336 | Transfer-codings are analogous to the Content-Transfer-Encoding | |
1337 | values of MIME [7], which were designed to enable safe transport of | |
1338 | binary data over a 7-bit transport service. However, safe transport | |
1339 | has a different focus for an 8bit-clean transfer protocol. In HTTP, | |
1340 | the only unsafe characteristic of message-bodies is the difficulty in | |
1341 | determining the exact body length (section 7.2.2), or the desire to | |
1342 | encrypt data over a shared transport. | |
1343 | ||
1344 | ||
1345 | ||
1346 | Fielding, et al. Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 2616 HTTP/1.1 June 1999 | |
1349 | ||
1350 | ||
1351 | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |
1352 | transfer-coding value tokens. Initially, the registry contains the | |
1353 | following tokens: "chunked" (section 3.6.1), "identity" (section | |
1354 | 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" | |
1355 | (section 3.5). | |
1356 | ||
1357 | New transfer-coding value tokens SHOULD be registered in the same way | |
1358 | as new content-coding value tokens (section 3.5). | |
1359 | ||
1360 | A server which receives an entity-body with a transfer-coding it does | |
1361 | not understand SHOULD return 501 (Unimplemented), and close the | |
1362 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | |
1363 | client. | |
1364 | ||
1365 | 3.6.1 Chunked Transfer Coding | |
1366 | ||
1367 | The chunked encoding modifies the body of a message in order to | |
1368 | transfer it as a series of chunks, each with its own size indicator, | |
1369 | followed by an OPTIONAL trailer containing entity-header fields. This | |
1370 | allows dynamically produced content to be transferred along with the | |
1371 | information necessary for the recipient to verify that it has | |
1372 | received the full message. | |
1373 | ||
1374 | Chunked-Body = *chunk | |
1375 | last-chunk | |
1376 | trailer | |
1377 | CRLF | |
1378 | ||
1379 | chunk = chunk-size [ chunk-extension ] CRLF | |
1380 | chunk-data CRLF | |
1381 | chunk-size = 1*HEX | |
1382 | last-chunk = 1*("0") [ chunk-extension ] CRLF | |
1383 | ||
1384 | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |
1385 | chunk-ext-name = token | |
1386 | chunk-ext-val = token | quoted-string | |
1387 | chunk-data = chunk-size(OCTET) | |
1388 | trailer = *(entity-header CRLF) | |
1389 | ||
1390 | The chunk-size field is a string of hex digits indicating the size of | |
1391 | the chunk. The chunked encoding is ended by any chunk whose size is | |
1392 | zero, followed by the trailer, which is terminated by an empty line. | |
1393 | ||
1394 | The trailer allows the sender to include additional HTTP header | |
1395 | fields at the end of the message. The Trailer header field can be | |
1396 | used to indicate which header fields are included in a trailer (see | |
1397 | section 14.40). | |
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Fielding, et al. Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 2616 HTTP/1.1 June 1999 | |
1405 | ||
1406 | ||
1407 | A server using chunked transfer-coding in a response MUST NOT use the | |
1408 | trailer for any header fields unless at least one of the following is | |
1409 | true: | |
1410 | ||
1411 | a)the request included a TE header field that indicates "trailers" is | |
1412 | acceptable in the transfer-coding of the response, as described in | |
1413 | section 14.39; or, | |
1414 | ||
1415 | b)the server is the origin server for the response, the trailer | |
1416 | fields consist entirely of optional metadata, and the recipient | |
1417 | could use the message (in a manner acceptable to the origin server) | |
1418 | without receiving this metadata. In other words, the origin server | |
1419 | is willing to accept the possibility that the trailer fields might | |
1420 | be silently discarded along the path to the client. | |
1421 | ||
1422 | This requirement prevents an interoperability failure when the | |
1423 | message is being received by an HTTP/1.1 (or later) proxy and | |
1424 | forwarded to an HTTP/1.0 recipient. It avoids a situation where | |
1425 | compliance with the protocol would have necessitated a possibly | |
1426 | infinite buffer on the proxy. | |
1427 | ||
1428 | An example process for decoding a Chunked-Body is presented in | |
1429 | appendix 19.4.6. | |
1430 | ||
1431 | All HTTP/1.1 applications MUST be able to receive and decode the | |
1432 | "chunked" transfer-coding, and MUST ignore chunk-extension extensions | |
1433 | they do not understand. | |
1434 | ||
1435 | 3.7 Media Types | |
1436 | ||
1437 | HTTP uses Internet Media Types [17] in the Content-Type (section | |
1438 | 14.17) and Accept (section 14.1) header fields in order to provide | |
1439 | open and extensible data typing and type negotiation. | |
1440 | ||
1441 | media-type = type "/" subtype *( ";" parameter ) | |
1442 | type = token | |
1443 | subtype = token | |
1444 | ||
1445 | Parameters MAY follow the type/subtype in the form of attribute/value | |
1446 | pairs (as defined in section 3.6). | |
1447 | ||
1448 | The type, subtype, and parameter attribute names are case- | |
1449 | insensitive. Parameter values might or might not be case-sensitive, | |
1450 | depending on the semantics of the parameter name. Linear white space | |
1451 | (LWS) MUST NOT be used between the type and subtype, nor between an | |
1452 | attribute and its value. The presence or absence of a parameter might | |
1453 | be significant to the processing of a media-type, depending on its | |
1454 | definition within the media type registry. | |
1455 | ||
1456 | ||
1457 | ||
1458 | Fielding, et al. Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 2616 HTTP/1.1 June 1999 | |
1461 | ||
1462 | ||
1463 | Note that some older HTTP applications do not recognize media type | |
1464 | parameters. When sending data to older HTTP applications, | |
1465 | implementations SHOULD only use media type parameters when they are | |
1466 | required by that type/subtype definition. | |
1467 | ||
1468 | Media-type values are registered with the Internet Assigned Number | |
1469 | Authority (IANA [19]). The media type registration process is | |
1470 | outlined in RFC 1590 [17]. Use of non-registered media types is | |
1471 | discouraged. | |
1472 | ||
1473 | 3.7.1 Canonicalization and Text Defaults | |
1474 | ||
1475 | Internet media types are registered with a canonical form. An | |
1476 | entity-body transferred via HTTP messages MUST be represented in the | |
1477 | appropriate canonical form prior to its transmission except for | |
1478 | "text" types, as defined in the next paragraph. | |
1479 | ||
1480 | When in canonical form, media subtypes of the "text" type use CRLF as | |
1481 | the text line break. HTTP relaxes this requirement and allows the | |
1482 | transport of text media with plain CR or LF alone representing a line | |
1483 | break when it is done consistently for an entire entity-body. HTTP | |
1484 | applications MUST accept CRLF, bare CR, and bare LF as being | |
1485 | representative of a line break in text media received via HTTP. In | |
1486 | addition, if the text is represented in a character set that does not | |
1487 | use octets 13 and 10 for CR and LF respectively, as is the case for | |
1488 | some multi-byte character sets, HTTP allows the use of whatever octet | |
1489 | sequences are defined by that character set to represent the | |
1490 | equivalent of CR and LF for line breaks. This flexibility regarding | |
1491 | line breaks applies only to text media in the entity-body; a bare CR | |
1492 | or LF MUST NOT be substituted for CRLF within any of the HTTP control | |
1493 | structures (such as header fields and multipart boundaries). | |
1494 | ||
1495 | If an entity-body is encoded with a content-coding, the underlying | |
1496 | data MUST be in a form defined above prior to being encoded. | |
1497 | ||
1498 | The "charset" parameter is used with some media types to define the | |
1499 | character set (section 3.4) of the data. When no explicit charset | |
1500 | parameter is provided by the sender, media subtypes of the "text" | |
1501 | type are defined to have a default charset value of "ISO-8859-1" when | |
1502 | received via HTTP. Data in character sets other than "ISO-8859-1" or | |
1503 | its subsets MUST be labeled with an appropriate charset value. See | |
1504 | section 3.4.1 for compatibility problems. | |
1505 | ||
1506 | 3.7.2 Multipart Types | |
1507 | ||
1508 | MIME provides for a number of "multipart" types -- encapsulations of | |
1509 | one or more entities within a single message-body. All multipart | |
1510 | types share a common syntax, as defined in section 5.1.1 of RFC 2046 | |
1511 | ||
1512 | ||
1513 | ||
1514 | Fielding, et al. Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 2616 HTTP/1.1 June 1999 | |
1517 | ||
1518 | ||
1519 | [40], and MUST include a boundary parameter as part of the media type | |
1520 | value. The message body is itself a protocol element and MUST | |
1521 | therefore use only CRLF to represent line breaks between body-parts. | |
1522 | Unlike in RFC 2046, the epilogue of any multipart message MUST be | |
1523 | empty; HTTP applications MUST NOT transmit the epilogue (even if the | |
1524 | original multipart contains an epilogue). These restrictions exist in | |
1525 | order to preserve the self-delimiting nature of a multipart message- | |
1526 | body, wherein the "end" of the message-body is indicated by the | |
1527 | ending multipart boundary. | |
1528 | ||
1529 | In general, HTTP treats a multipart message-body no differently than | |
1530 | any other media type: strictly as payload. The one exception is the | |
1531 | "multipart/byteranges" type (appendix 19.2) when it appears in a 206 | |
1532 | (Partial Content) response, which will be interpreted by some HTTP | |
1533 | caching mechanisms as described in sections 13.5.4 and 14.16. In all | |
1534 | other cases, an HTTP user agent SHOULD follow the same or similar | |
1535 | behavior as a MIME user agent would upon receipt of a multipart type. | |
1536 | The MIME header fields within each body-part of a multipart message- | |
1537 | body do not have any significance to HTTP beyond that defined by | |
1538 | their MIME semantics. | |
1539 | ||
1540 | In general, an HTTP user agent SHOULD follow the same or similar | |
1541 | behavior as a MIME user agent would upon receipt of a multipart type. | |
1542 | If an application receives an unrecognized multipart subtype, the | |
1543 | application MUST treat it as being equivalent to "multipart/mixed". | |
1544 | ||
1545 | Note: The "multipart/form-data" type has been specifically defined | |
1546 | for carrying form data suitable for processing via the POST | |
1547 | request method, as described in RFC 1867 [15]. | |
1548 | ||
1549 | 3.8 Product Tokens | |
1550 | ||
1551 | Product tokens are used to allow communicating applications to | |
1552 | identify themselves by software name and version. Most fields using | |
1553 | product tokens also allow sub-products which form a significant part | |
1554 | of the application to be listed, separated by white space. By | |
1555 | convention, the products are listed in order of their significance | |
1556 | for identifying the application. | |
1557 | ||
1558 | product = token ["/" product-version] | |
1559 | product-version = token | |
1560 | ||
1561 | Examples: | |
1562 | ||
1563 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |
1564 | Server: Apache/0.8.4 | |
1565 | ||
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | Fielding, et al. Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 2616 HTTP/1.1 June 1999 | |
1573 | ||
1574 | ||
1575 | Product tokens SHOULD be short and to the point. They MUST NOT be | |
1576 | used for advertising or other non-essential information. Although any | |
1577 | token character MAY appear in a product-version, this token SHOULD | |
1578 | only be used for a version identifier (i.e., successive versions of | |
1579 | the same product SHOULD only differ in the product-version portion of | |
1580 | the product value). | |
1581 | ||
1582 | 3.9 Quality Values | |
1583 | ||
1584 | HTTP content negotiation (section 12) uses short "floating point" | |
1585 | numbers to indicate the relative importance ("weight") of various | |
1586 | negotiable parameters. A weight is normalized to a real number in | |
1587 | the range 0 through 1, where 0 is the minimum and 1 the maximum | |
1588 | value. If a parameter has a quality value of 0, then content with | |
1589 | this parameter is `not acceptable' for the client. HTTP/1.1 | |
1590 | applications MUST NOT generate more than three digits after the | |
1591 | decimal point. User configuration of these values SHOULD also be | |
1592 | limited in this fashion. | |
1593 | ||
1594 | qvalue = ( "0" [ "." 0*3DIGIT ] ) | |
1595 | | ( "1" [ "." 0*3("0") ] ) | |
1596 | ||
1597 | "Quality values" is a misnomer, since these values merely represent | |
1598 | relative degradation in desired quality. | |
1599 | ||
1600 | 3.10 Language Tags | |
1601 | ||
1602 | A language tag identifies a natural language spoken, written, or | |
1603 | otherwise conveyed by human beings for communication of information | |
1604 | to other human beings. Computer languages are explicitly excluded. | |
1605 | HTTP uses language tags within the Accept-Language and Content- | |
1606 | Language fields. | |
1607 | ||
1608 | The syntax and registry of HTTP language tags is the same as that | |
1609 | defined by RFC 1766 [1]. In summary, a language tag is composed of 1 | |
1610 | or more parts: A primary language tag and a possibly empty series of | |
1611 | subtags: | |
1612 | ||
1613 | language-tag = primary-tag *( "-" subtag ) | |
1614 | primary-tag = 1*8ALPHA | |
1615 | subtag = 1*8ALPHA | |
1616 | ||
1617 | White space is not allowed within the tag and all tags are case- | |
1618 | insensitive. The name space of language tags is administered by the | |
1619 | IANA. Example tags include: | |
1620 | ||
1621 | en, en-US, en-cockney, i-cherokee, x-pig-latin | |
1622 | ||
1623 | ||
1624 | ||
1625 | ||
1626 | Fielding, et al. Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 2616 HTTP/1.1 June 1999 | |
1629 | ||
1630 | ||
1631 | where any two-letter primary-tag is an ISO-639 language abbreviation | |
1632 | and any two-letter initial subtag is an ISO-3166 country code. (The | |
1633 | last three tags above are not registered tags; all but the last are | |
1634 | examples of tags which could be registered in future.) | |
1635 | ||
1636 | 3.11 Entity Tags | |
1637 | ||
1638 | Entity tags are used for comparing two or more entities from the same | |
1639 | requested resource. HTTP/1.1 uses entity tags in the ETag (section | |
1640 | 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and | |
1641 | If-Range (section 14.27) header fields. The definition of how they | |
1642 | are used and compared as cache validators is in section 13.3.3. An | |
1643 | entity tag consists of an opaque quoted string, possibly prefixed by | |
1644 | a weakness indicator. | |
1645 | ||
1646 | entity-tag = [ weak ] opaque-tag | |
1647 | weak = "W/" | |
1648 | opaque-tag = quoted-string | |
1649 | ||
1650 | A "strong entity tag" MAY be shared by two entities of a resource | |
1651 | only if they are equivalent by octet equality. | |
1652 | ||
1653 | A "weak entity tag," indicated by the "W/" prefix, MAY be shared by | |
1654 | two entities of a resource only if the entities are equivalent and | |
1655 | could be substituted for each other with no significant change in | |
1656 | semantics. A weak entity tag can only be used for weak comparison. | |
1657 | ||
1658 | An entity tag MUST be unique across all versions of all entities | |
1659 | associated with a particular resource. A given entity tag value MAY | |
1660 | be used for entities obtained by requests on different URIs. The use | |
1661 | of the same entity tag value in conjunction with entities obtained by | |
1662 | requests on different URIs does not imply the equivalence of those | |
1663 | entities. | |
1664 | ||
1665 | 3.12 Range Units | |
1666 | ||
1667 | HTTP/1.1 allows a client to request that only part (a range of) the | |
1668 | response entity be included within the response. HTTP/1.1 uses range | |
1669 | units in the Range (section 14.35) and Content-Range (section 14.16) | |
1670 | header fields. An entity can be broken down into subranges according | |
1671 | to various structural units. | |
1672 | ||
1673 | range-unit = bytes-unit | other-range-unit | |
1674 | bytes-unit = "bytes" | |
1675 | other-range-unit = token | |
1676 | ||
1677 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | |
1678 | implementations MAY ignore ranges specified using other units. | |
1679 | ||
1680 | ||
1681 | ||
1682 | Fielding, et al. Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 2616 HTTP/1.1 June 1999 | |
1685 | ||
1686 | ||
1687 | HTTP/1.1 has been designed to allow implementations of applications | |
1688 | that do not depend on knowledge of ranges. | |
1689 | ||
1690 | 4 HTTP Message | |
1691 | ||
1692 | 4.1 Message Types | |
1693 | ||
1694 | HTTP messages consist of requests from client to server and responses | |
1695 | from server to client. | |
1696 | ||
1697 | HTTP-message = Request | Response ; HTTP/1.1 messages | |
1698 | ||
1699 | Request (section 5) and Response (section 6) messages use the generic | |
1700 | message format of RFC 822 [9] for transferring entities (the payload | |
1701 | of the message). Both types of message consist of a start-line, zero | |
1702 | or more header fields (also known as "headers"), an empty line (i.e., | |
1703 | a line with nothing preceding the CRLF) indicating the end of the | |
1704 | header fields, and possibly a message-body. | |
1705 | ||
1706 | generic-message = start-line | |
1707 | *(message-header CRLF) | |
1708 | CRLF | |
1709 | [ message-body ] | |
1710 | start-line = Request-Line | Status-Line | |
1711 | ||
1712 | In the interest of robustness, servers SHOULD ignore any empty | |
1713 | line(s) received where a Request-Line is expected. In other words, if | |
1714 | the server is reading the protocol stream at the beginning of a | |
1715 | message and receives a CRLF first, it should ignore the CRLF. | |
1716 | ||
1717 | Certain buggy HTTP/1.0 client implementations generate extra CRLF's | |
1718 | after a POST request. To restate what is explicitly forbidden by the | |
1719 | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an | |
1720 | extra CRLF. | |
1721 | ||
1722 | 4.2 Message Headers | |
1723 | ||
1724 | HTTP header fields, which include general-header (section 4.5), | |
1725 | request-header (section 5.3), response-header (section 6.2), and | |
1726 | entity-header (section 7.1) fields, follow the same generic format as | |
1727 | that given in Section 3.1 of RFC 822 [9]. Each header field consists | |
1728 | of a name followed by a colon (":") and the field value. Field names | |
1729 | are case-insensitive. The field value MAY be preceded by any amount | |
1730 | of LWS, though a single SP is preferred. Header fields can be | |
1731 | extended over multiple lines by preceding each extra line with at | |
1732 | least one SP or HT. Applications ought to follow "common form", where | |
1733 | one is known or indicated, when generating HTTP constructs, since | |
1734 | there might exist some implementations that fail to accept anything | |
1735 | ||
1736 | ||
1737 | ||
1738 | Fielding, et al. Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 2616 HTTP/1.1 June 1999 | |
1741 | ||
1742 | ||
1743 | beyond the common forms. | |
1744 | ||
1745 | message-header = field-name ":" [ field-value ] | |
1746 | field-name = token | |
1747 | field-value = *( field-content | LWS ) | |
1748 | field-content = <the OCTETs making up the field-value | |
1749 | and consisting of either *TEXT or combinations | |
1750 | of token, separators, and quoted-string> | |
1751 | ||
1752 | The field-content does not include any leading or trailing LWS: | |
1753 | linear white space occurring before the first non-whitespace | |
1754 | character of the field-value or after the last non-whitespace | |
1755 | character of the field-value. Such leading or trailing LWS MAY be | |
1756 | removed without changing the semantics of the field value. Any LWS | |
1757 | that occurs between field-content MAY be replaced with a single SP | |
1758 | before interpreting the field value or forwarding the message | |
1759 | downstream. | |
1760 | ||
1761 | The order in which header fields with differing field names are | |
1762 | received is not significant. However, it is "good practice" to send | |
1763 | general-header fields first, followed by request-header or response- | |
1764 | header fields, and ending with the entity-header fields. | |
1765 | ||
1766 | Multiple message-header fields with the same field-name MAY be | |
1767 | present in a message if and only if the entire field-value for that | |
1768 | header field is defined as a comma-separated list [i.e., #(values)]. | |
1769 | It MUST be possible to combine the multiple header fields into one | |
1770 | "field-name: field-value" pair, without changing the semantics of the | |
1771 | message, by appending each subsequent field-value to the first, each | |
1772 | separated by a comma. The order in which header fields with the same | |
1773 | field-name are received is therefore significant to the | |
1774 | interpretation of the combined field value, and thus a proxy MUST NOT | |
1775 | change the order of these field values when a message is forwarded. | |
1776 | ||
1777 | 4.3 Message Body | |
1778 | ||
1779 | The message-body (if any) of an HTTP message is used to carry the | |
1780 | entity-body associated with the request or response. The message-body | |
1781 | differs from the entity-body only when a transfer-coding has been | |
1782 | applied, as indicated by the Transfer-Encoding header field (section | |
1783 | 14.41). | |
1784 | ||
1785 | message-body = entity-body | |
1786 | | <entity-body encoded as per Transfer-Encoding> | |
1787 | ||
1788 | Transfer-Encoding MUST be used to indicate any transfer-codings | |
1789 | applied by an application to ensure safe and proper transfer of the | |
1790 | message. Transfer-Encoding is a property of the message, not of the | |
1791 | ||
1792 | ||
1793 | ||
1794 | Fielding, et al. Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 2616 HTTP/1.1 June 1999 | |
1797 | ||
1798 | ||
1799 | entity, and thus MAY be added or removed by any application along the | |
1800 | request/response chain. (However, section 3.6 places restrictions on | |
1801 | when certain transfer-codings may be used.) | |
1802 | ||
1803 | The rules for when a message-body is allowed in a message differ for | |
1804 | requests and responses. | |
1805 | ||
1806 | The presence of a message-body in a request is signaled by the | |
1807 | inclusion of a Content-Length or Transfer-Encoding header field in | |
1808 | the request's message-headers. A message-body MUST NOT be included in | |
1809 | a request if the specification of the request method (section 5.1.1) | |
1810 | does not allow sending an entity-body in requests. A server SHOULD | |
1811 | read and forward a message-body on any request; if the request method | |
1812 | does not include defined semantics for an entity-body, then the | |
1813 | message-body SHOULD be ignored when handling the request. | |
1814 | ||
1815 | For response messages, whether or not a message-body is included with | |
1816 | a message is dependent on both the request method and the response | |
1817 | status code (section 6.1.1). All responses to the HEAD request method | |
1818 | MUST NOT include a message-body, even though the presence of entity- | |
1819 | header fields might lead one to believe they do. All 1xx | |
1820 | (informational), 204 (no content), and 304 (not modified) responses | |
1821 | MUST NOT include a message-body. All other responses do include a | |
1822 | message-body, although it MAY be of zero length. | |
1823 | ||
1824 | 4.4 Message Length | |
1825 | ||
1826 | The transfer-length of a message is the length of the message-body as | |
1827 | it appears in the message; that is, after any transfer-codings have | |
1828 | been applied. When a message-body is included with a message, the | |
1829 | transfer-length of that body is determined by one of the following | |
1830 | (in order of precedence): | |
1831 | ||
1832 | 1.Any response message which "MUST NOT" include a message-body (such | |
1833 | as the 1xx, 204, and 304 responses and any response to a HEAD | |
1834 | request) is always terminated by the first empty line after the | |
1835 | header fields, regardless of the entity-header fields present in | |
1836 | the message. | |
1837 | ||
1838 | 2.If a Transfer-Encoding header field (section 14.41) is present and | |
1839 | has any value other than "identity", then the transfer-length is | |
1840 | defined by use of the "chunked" transfer-coding (section 3.6), | |
1841 | unless the message is terminated by closing the connection. | |
1842 | ||
1843 | 3.If a Content-Length header field (section 14.13) is present, its | |
1844 | decimal value in OCTETs represents both the entity-length and the | |
1845 | transfer-length. The Content-Length header field MUST NOT be sent | |
1846 | if these two lengths are different (i.e., if a Transfer-Encoding | |
1847 | ||
1848 | ||
1849 | ||
1850 | Fielding, et al. Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 2616 HTTP/1.1 June 1999 | |
1853 | ||
1854 | ||
1855 | header field is present). If a message is received with both a | |
1856 | Transfer-Encoding header field and a Content-Length header field, | |
1857 | the latter MUST be ignored. | |
1858 | ||
1859 | 4.If the message uses the media type "multipart/byteranges", and the | |
1860 | ransfer-length is not otherwise specified, then this self- | |
1861 | elimiting media type defines the transfer-length. This media type | |
1862 | UST NOT be used unless the sender knows that the recipient can arse | |
1863 | it; the presence in a request of a Range header with ultiple byte- | |
1864 | range specifiers from a 1.1 client implies that the lient can parse | |
1865 | multipart/byteranges responses. | |
1866 | ||
1867 | A range header might be forwarded by a 1.0 proxy that does not | |
1868 | understand multipart/byteranges; in this case the server MUST | |
1869 | delimit the message using methods defined in items 1,3 or 5 of | |
1870 | this section. | |
1871 | ||
1872 | 5.By the server closing the connection. (Closing the connection | |
1873 | cannot be used to indicate the end of a request body, since that | |
1874 | would leave no possibility for the server to send back a response.) | |
1875 | ||
1876 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | |
1877 | containing a message-body MUST include a valid Content-Length header | |
1878 | field unless the server is known to be HTTP/1.1 compliant. If a | |
1879 | request contains a message-body and a Content-Length is not given, | |
1880 | the server SHOULD respond with 400 (bad request) if it cannot | |
1881 | determine the length of the message, or with 411 (length required) if | |
1882 | it wishes to insist on receiving a valid Content-Length. | |
1883 | ||
1884 | All HTTP/1.1 applications that receive entities MUST accept the | |
1885 | "chunked" transfer-coding (section 3.6), thus allowing this mechanism | |
1886 | to be used for messages when the message length cannot be determined | |
1887 | in advance. | |
1888 | ||
1889 | Messages MUST NOT include both a Content-Length header field and a | |
1890 | non-identity transfer-coding. If the message does include a non- | |
1891 | identity transfer-coding, the Content-Length MUST be ignored. | |
1892 | ||
1893 | When a Content-Length is given in a message where a message-body is | |
1894 | allowed, its field value MUST exactly match the number of OCTETs in | |
1895 | the message-body. HTTP/1.1 user agents MUST notify the user when an | |
1896 | invalid length is received and detected. | |
1897 | ||
1898 | 4.5 General Header Fields | |
1899 | ||
1900 | There are a few header fields which have general applicability for | |
1901 | both request and response messages, but which do not apply to the | |
1902 | entity being transferred. These header fields apply only to the | |
1903 | ||
1904 | ||
1905 | ||
1906 | Fielding, et al. Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 2616 HTTP/1.1 June 1999 | |
1909 | ||
1910 | ||
1911 | message being transmitted. | |
1912 | ||
1913 | general-header = Cache-Control ; Section 14.9 | |
1914 | | Connection ; Section 14.10 | |
1915 | | Date ; Section 14.18 | |
1916 | | Pragma ; Section 14.32 | |
1917 | | Trailer ; Section 14.40 | |
1918 | | Transfer-Encoding ; Section 14.41 | |
1919 | | Upgrade ; Section 14.42 | |
1920 | | Via ; Section 14.45 | |
1921 | | Warning ; Section 14.46 | |
1922 | ||
1923 | General-header field names can be extended reliably only in | |
1924 | combination with a change in the protocol version. However, new or | |
1925 | experimental header fields may be given the semantics of general | |
1926 | header fields if all parties in the communication recognize them to | |
1927 | be general-header fields. Unrecognized header fields are treated as | |
1928 | entity-header fields. | |
1929 | ||
1930 | 5 Request | |
1931 | ||
1932 | A request message from a client to a server includes, within the | |
1933 | first line of that message, the method to be applied to the resource, | |
1934 | the identifier of the resource, and the protocol version in use. | |
1935 | ||
1936 | Request = Request-Line ; Section 5.1 | |
1937 | *(( general-header ; Section 4.5 | |
1938 | | request-header ; Section 5.3 | |
1939 | | entity-header ) CRLF) ; Section 7.1 | |
1940 | CRLF | |
1941 | [ message-body ] ; Section 4.3 | |
1942 | ||
1943 | 5.1 Request-Line | |
1944 | ||
1945 | The Request-Line begins with a method token, followed by the | |
1946 | Request-URI and the protocol version, and ending with CRLF. The | |
1947 | elements are separated by SP characters. No CR or LF is allowed | |
1948 | except in the final CRLF sequence. | |
1949 | ||
1950 | Request-Line = Method SP Request-URI SP HTTP-Version CRLF | |
1951 | ||
1952 | ||
1953 | ||
1954 | ||
1955 | ||
1956 | ||
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Fielding, et al. Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 2616 HTTP/1.1 June 1999 | |
1965 | ||
1966 | ||
1967 | 5.1.1 Method | |
1968 | ||
1969 | The Method token indicates the method to be performed on the | |
1970 | resource identified by the Request-URI. The method is case-sensitive. | |
1971 | ||
1972 | Method = "OPTIONS" ; Section 9.2 | |
1973 | | "GET" ; Section 9.3 | |
1974 | | "HEAD" ; Section 9.4 | |
1975 | | "POST" ; Section 9.5 | |
1976 | | "PUT" ; Section 9.6 | |
1977 | | "DELETE" ; Section 9.7 | |
1978 | | "TRACE" ; Section 9.8 | |
1979 | | "CONNECT" ; Section 9.9 | |
1980 | | extension-method | |
1981 | extension-method = token | |
1982 | ||
1983 | The list of methods allowed by a resource can be specified in an | |
1984 | Allow header field (section 14.7). The return code of the response | |
1985 | always notifies the client whether a method is currently allowed on a | |
1986 | resource, since the set of allowed methods can change dynamically. An | |
1987 | origin server SHOULD return the status code 405 (Method Not Allowed) | |
1988 | if the method is known by the origin server but not allowed for the | |
1989 | requested resource, and 501 (Not Implemented) if the method is | |
1990 | unrecognized or not implemented by the origin server. The methods GET | |
1991 | and HEAD MUST be supported by all general-purpose servers. All other | |
1992 | methods are OPTIONAL; however, if the above methods are implemented, | |
1993 | they MUST be implemented with the same semantics as those specified | |
1994 | in section 9. | |
1995 | ||
1996 | 5.1.2 Request-URI | |
1997 | ||
1998 | The Request-URI is a Uniform Resource Identifier (section 3.2) and | |
1999 | identifies the resource upon which to apply the request. | |
2000 | ||
2001 | Request-URI = "*" | absoluteURI | abs_path | authority | |
2002 | ||
2003 | The four options for Request-URI are dependent on the nature of the | |
2004 | request. The asterisk "*" means that the request does not apply to a | |
2005 | particular resource, but to the server itself, and is only allowed | |
2006 | when the method used does not necessarily apply to a resource. One | |
2007 | example would be | |
2008 | ||
2009 | OPTIONS * HTTP/1.1 | |
2010 | ||
2011 | The absoluteURI form is REQUIRED when the request is being made to a | |
2012 | proxy. The proxy is requested to forward the request or service it | |
2013 | from a valid cache, and return the response. Note that the proxy MAY | |
2014 | forward the request on to another proxy or directly to the server | |
2015 | ||
2016 | ||
2017 | ||
2018 | Fielding, et al. Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 2616 HTTP/1.1 June 1999 | |
2021 | ||
2022 | ||
2023 | specified by the absoluteURI. In order to avoid request loops, a | |
2024 | proxy MUST be able to recognize all of its server names, including | |
2025 | any aliases, local variations, and the numeric IP address. An example | |
2026 | Request-Line would be: | |
2027 | ||
2028 | GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 | |
2029 | ||
2030 | To allow for transition to absoluteURIs in all requests in future | |
2031 | versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI | |
2032 | form in requests, even though HTTP/1.1 clients will only generate | |
2033 | them in requests to proxies. | |
2034 | ||
2035 | The authority form is only used by the CONNECT method (section 9.9). | |
2036 | ||
2037 | The most common form of Request-URI is that used to identify a | |
2038 | resource on an origin server or gateway. In this case the absolute | |
2039 | path of the URI MUST be transmitted (see section 3.2.1, abs_path) as | |
2040 | the Request-URI, and the network location of the URI (authority) MUST | |
2041 | be transmitted in a Host header field. For example, a client wishing | |
2042 | to retrieve the resource above directly from the origin server would | |
2043 | create a TCP connection to port 80 of the host "www.w3.org" and send | |
2044 | the lines: | |
2045 | ||
2046 | GET /pub/WWW/TheProject.html HTTP/1.1 | |
2047 | Host: www.w3.org | |
2048 | ||
2049 | followed by the remainder of the Request. Note that the absolute path | |
2050 | cannot be empty; if none is present in the original URI, it MUST be | |
2051 | given as "/" (the server root). | |
2052 | ||
2053 | The Request-URI is transmitted in the format specified in section | |
2054 | 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding | |
2055 | [42], the origin server MUST decode the Request-URI in order to | |
2056 | properly interpret the request. Servers SHOULD respond to invalid | |
2057 | Request-URIs with an appropriate status code. | |
2058 | ||
2059 | A transparent proxy MUST NOT rewrite the "abs_path" part of the | |
2060 | received Request-URI when forwarding it to the next inbound server, | |
2061 | except as noted above to replace a null abs_path with "/". | |
2062 | ||
2063 | Note: The "no rewrite" rule prevents the proxy from changing the | |
2064 | meaning of the request when the origin server is improperly using | |
2065 | a non-reserved URI character for a reserved purpose. Implementors | |
2066 | should be aware that some pre-HTTP/1.1 proxies have been known to | |
2067 | rewrite the Request-URI. | |
2068 | ||
2069 | ||
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | Fielding, et al. Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 2616 HTTP/1.1 June 1999 | |
2077 | ||
2078 | ||
2079 | 5.2 The Resource Identified by a Request | |
2080 | ||
2081 | The exact resource identified by an Internet request is determined by | |
2082 | examining both the Request-URI and the Host header field. | |
2083 | ||
2084 | An origin server that does not allow resources to differ by the | |
2085 | requested host MAY ignore the Host header field value when | |
2086 | determining the resource identified by an HTTP/1.1 request. (But see | |
2087 | section 19.6.1.1 for other requirements on Host support in HTTP/1.1.) | |
2088 | ||
2089 | An origin server that does differentiate resources based on the host | |
2090 | requested (sometimes referred to as virtual hosts or vanity host | |
2091 | names) MUST use the following rules for determining the requested | |
2092 | resource on an HTTP/1.1 request: | |
2093 | ||
2094 | 1. If Request-URI is an absoluteURI, the host is part of the | |
2095 | Request-URI. Any Host header field value in the request MUST be | |
2096 | ignored. | |
2097 | ||
2098 | 2. If the Request-URI is not an absoluteURI, and the request includes | |
2099 | a Host header field, the host is determined by the Host header | |
2100 | field value. | |
2101 | ||
2102 | 3. If the host as determined by rule 1 or 2 is not a valid host on | |
2103 | the server, the response MUST be a 400 (Bad Request) error message. | |
2104 | ||
2105 | Recipients of an HTTP/1.0 request that lacks a Host header field MAY | |
2106 | attempt to use heuristics (e.g., examination of the URI path for | |
2107 | something unique to a particular host) in order to determine what | |
2108 | exact resource is being requested. | |
2109 | ||
2110 | 5.3 Request Header Fields | |
2111 | ||
2112 | The request-header fields allow the client to pass additional | |
2113 | information about the request, and about the client itself, to the | |
2114 | server. These fields act as request modifiers, with semantics | |
2115 | equivalent to the parameters on a programming language method | |
2116 | invocation. | |
2117 | ||
2118 | request-header = Accept ; Section 14.1 | |
2119 | | Accept-Charset ; Section 14.2 | |
2120 | | Accept-Encoding ; Section 14.3 | |
2121 | | Accept-Language ; Section 14.4 | |
2122 | | Authorization ; Section 14.8 | |
2123 | | Expect ; Section 14.20 | |
2124 | | From ; Section 14.22 | |
2125 | | Host ; Section 14.23 | |
2126 | | If-Match ; Section 14.24 | |
2127 | ||
2128 | ||
2129 | ||
2130 | Fielding, et al. Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 2616 HTTP/1.1 June 1999 | |
2133 | ||
2134 | ||
2135 | | If-Modified-Since ; Section 14.25 | |
2136 | | If-None-Match ; Section 14.26 | |
2137 | | If-Range ; Section 14.27 | |
2138 | | If-Unmodified-Since ; Section 14.28 | |
2139 | | Max-Forwards ; Section 14.31 | |
2140 | | Proxy-Authorization ; Section 14.34 | |
2141 | | Range ; Section 14.35 | |
2142 | | Referer ; Section 14.36 | |
2143 | | TE ; Section 14.39 | |
2144 | | User-Agent ; Section 14.43 | |
2145 | ||
2146 | Request-header field names can be extended reliably only in | |
2147 | combination with a change in the protocol version. However, new or | |
2148 | experimental header fields MAY be given the semantics of request- | |
2149 | header fields if all parties in the communication recognize them to | |
2150 | be request-header fields. Unrecognized header fields are treated as | |
2151 | entity-header fields. | |
2152 | ||
2153 | 6 Response | |
2154 | ||
2155 | After receiving and interpreting a request message, a server responds | |
2156 | with an HTTP response message. | |
2157 | ||
2158 | Response = Status-Line ; Section 6.1 | |
2159 | *(( general-header ; Section 4.5 | |
2160 | | response-header ; Section 6.2 | |
2161 | | entity-header ) CRLF) ; Section 7.1 | |
2162 | CRLF | |
2163 | [ message-body ] ; Section 7.2 | |
2164 | ||
2165 | 6.1 Status-Line | |
2166 | ||
2167 | The first line of a Response message is the Status-Line, consisting | |
2168 | of the protocol version followed by a numeric status code and its | |
2169 | associated textual phrase, with each element separated by SP | |
2170 | characters. No CR or LF is allowed except in the final CRLF sequence. | |
2171 | ||
2172 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | |
2173 | ||
2174 | 6.1.1 Status Code and Reason Phrase | |
2175 | ||
2176 | The Status-Code element is a 3-digit integer result code of the | |
2177 | attempt to understand and satisfy the request. These codes are fully | |
2178 | defined in section 10. The Reason-Phrase is intended to give a short | |
2179 | textual description of the Status-Code. The Status-Code is intended | |
2180 | for use by automata and the Reason-Phrase is intended for the human | |
2181 | user. The client is not required to examine or display the Reason- | |
2182 | Phrase. | |
2183 | ||
2184 | ||
2185 | ||
2186 | Fielding, et al. Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 2616 HTTP/1.1 June 1999 | |
2189 | ||
2190 | ||
2191 | The first digit of the Status-Code defines the class of response. The | |
2192 | last two digits do not have any categorization role. There are 5 | |
2193 | values for the first digit: | |
2194 | ||
2195 | - 1xx: Informational - Request received, continuing process | |
2196 | ||
2197 | - 2xx: Success - The action was successfully received, | |
2198 | understood, and accepted | |
2199 | ||
2200 | - 3xx: Redirection - Further action must be taken in order to | |
2201 | complete the request | |
2202 | ||
2203 | - 4xx: Client Error - The request contains bad syntax or cannot | |
2204 | be fulfilled | |
2205 | ||
2206 | - 5xx: Server Error - The server failed to fulfill an apparently | |
2207 | valid request | |
2208 | ||
2209 | The individual values of the numeric status codes defined for | |
2210 | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | |
2211 | presented below. The reason phrases listed here are only | |
2212 | recommendations -- they MAY be replaced by local equivalents without | |
2213 | affecting the protocol. | |
2214 | ||
2215 | Status-Code = | |
2216 | "100" ; Section 10.1.1: Continue | |
2217 | | "101" ; Section 10.1.2: Switching Protocols | |
2218 | | "200" ; Section 10.2.1: OK | |
2219 | | "201" ; Section 10.2.2: Created | |
2220 | | "202" ; Section 10.2.3: Accepted | |
2221 | | "203" ; Section 10.2.4: Non-Authoritative Information | |
2222 | | "204" ; Section 10.2.5: No Content | |
2223 | | "205" ; Section 10.2.6: Reset Content | |
2224 | | "206" ; Section 10.2.7: Partial Content | |
2225 | | "300" ; Section 10.3.1: Multiple Choices | |
2226 | | "301" ; Section 10.3.2: Moved Permanently | |
2227 | | "302" ; Section 10.3.3: Found | |
2228 | | "303" ; Section 10.3.4: See Other | |
2229 | | "304" ; Section 10.3.5: Not Modified | |
2230 | | "305" ; Section 10.3.6: Use Proxy | |
2231 | | "307" ; Section 10.3.8: Temporary Redirect | |
2232 | | "400" ; Section 10.4.1: Bad Request | |
2233 | | "401" ; Section 10.4.2: Unauthorized | |
2234 | | "402" ; Section 10.4.3: Payment Required | |
2235 | | "403" ; Section 10.4.4: Forbidden | |
2236 | | "404" ; Section 10.4.5: Not Found | |
2237 | | "405" ; Section 10.4.6: Method Not Allowed | |
2238 | | "406" ; Section 10.4.7: Not Acceptable | |
2239 | ||
2240 | ||
2241 | ||
2242 | Fielding, et al. Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 2616 HTTP/1.1 June 1999 | |
2245 | ||
2246 | ||
2247 | | "407" ; Section 10.4.8: Proxy Authentication Required | |
2248 | | "408" ; Section 10.4.9: Request Time-out | |
2249 | | "409" ; Section 10.4.10: Conflict | |
2250 | | "410" ; Section 10.4.11: Gone | |
2251 | | "411" ; Section 10.4.12: Length Required | |
2252 | | "412" ; Section 10.4.13: Precondition Failed | |
2253 | | "413" ; Section 10.4.14: Request Entity Too Large | |
2254 | | "414" ; Section 10.4.15: Request-URI Too Large | |
2255 | | "415" ; Section 10.4.16: Unsupported Media Type | |
2256 | | "416" ; Section 10.4.17: Requested range not satisfiable | |
2257 | | "417" ; Section 10.4.18: Expectation Failed | |
2258 | | "500" ; Section 10.5.1: Internal Server Error | |
2259 | | "501" ; Section 10.5.2: Not Implemented | |
2260 | | "502" ; Section 10.5.3: Bad Gateway | |
2261 | | "503" ; Section 10.5.4: Service Unavailable | |
2262 | | "504" ; Section 10.5.5: Gateway Time-out | |
2263 | | "505" ; Section 10.5.6: HTTP Version not supported | |
2264 | | extension-code | |
2265 | ||
2266 | extension-code = 3DIGIT | |
2267 | Reason-Phrase = *<TEXT, excluding CR, LF> | |
2268 | ||
2269 | HTTP status codes are extensible. HTTP applications are not required | |
2270 | to understand the meaning of all registered status codes, though such | |
2271 | understanding is obviously desirable. However, applications MUST | |
2272 | understand the class of any status code, as indicated by the first | |
2273 | digit, and treat any unrecognized response as being equivalent to the | |
2274 | x00 status code of that class, with the exception that an | |
2275 | unrecognized response MUST NOT be cached. For example, if an | |
2276 | unrecognized status code of 431 is received by the client, it can | |
2277 | safely assume that there was something wrong with its request and | |
2278 | treat the response as if it had received a 400 status code. In such | |
2279 | cases, user agents SHOULD present to the user the entity returned | |
2280 | with the response, since that entity is likely to include human- | |
2281 | readable information which will explain the unusual status. | |
2282 | ||
2283 | 6.2 Response Header Fields | |
2284 | ||
2285 | The response-header fields allow the server to pass additional | |
2286 | information about the response which cannot be placed in the Status- | |
2287 | Line. These header fields give information about the server and about | |
2288 | further access to the resource identified by the Request-URI. | |
2289 | ||
2290 | response-header = Accept-Ranges ; Section 14.5 | |
2291 | | Age ; Section 14.6 | |
2292 | | ETag ; Section 14.19 | |
2293 | | Location ; Section 14.30 | |
2294 | | Proxy-Authenticate ; Section 14.33 | |
2295 | ||
2296 | ||
2297 | ||
2298 | Fielding, et al. Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 2616 HTTP/1.1 June 1999 | |
2301 | ||
2302 | ||
2303 | | Retry-After ; Section 14.37 | |
2304 | | Server ; Section 14.38 | |
2305 | | Vary ; Section 14.44 | |
2306 | | WWW-Authenticate ; Section 14.47 | |
2307 | ||
2308 | Response-header field names can be extended reliably only in | |
2309 | combination with a change in the protocol version. However, new or | |
2310 | experimental header fields MAY be given the semantics of response- | |
2311 | header fields if all parties in the communication recognize them to | |
2312 | be response-header fields. Unrecognized header fields are treated as | |
2313 | entity-header fields. | |
2314 | ||
2315 | 7 Entity | |
2316 | ||
2317 | Request and Response messages MAY transfer an entity if not otherwise | |
2318 | restricted by the request method or response status code. An entity | |
2319 | consists of entity-header fields and an entity-body, although some | |
2320 | responses will only include the entity-headers. | |
2321 | ||
2322 | In this section, both sender and recipient refer to either the client | |
2323 | or the server, depending on who sends and who receives the entity. | |
2324 | ||
2325 | 7.1 Entity Header Fields | |
2326 | ||
2327 | Entity-header fields define metainformation about the entity-body or, | |
2328 | if no body is present, about the resource identified by the request. | |
2329 | Some of this metainformation is OPTIONAL; some might be REQUIRED by | |
2330 | portions of this specification. | |
2331 | ||
2332 | entity-header = Allow ; Section 14.7 | |
2333 | | Content-Encoding ; Section 14.11 | |
2334 | | Content-Language ; Section 14.12 | |
2335 | | Content-Length ; Section 14.13 | |
2336 | | Content-Location ; Section 14.14 | |
2337 | | Content-MD5 ; Section 14.15 | |
2338 | | Content-Range ; Section 14.16 | |
2339 | | Content-Type ; Section 14.17 | |
2340 | | Expires ; Section 14.21 | |
2341 | | Last-Modified ; Section 14.29 | |
2342 | | extension-header | |
2343 | ||
2344 | extension-header = message-header | |
2345 | ||
2346 | The extension-header mechanism allows additional entity-header fields | |
2347 | to be defined without changing the protocol, but these fields cannot | |
2348 | be assumed to be recognizable by the recipient. Unrecognized header | |
2349 | fields SHOULD be ignored by the recipient and MUST be forwarded by | |
2350 | transparent proxies. | |
2351 | ||
2352 | ||
2353 | ||
2354 | Fielding, et al. Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 2616 HTTP/1.1 June 1999 | |
2357 | ||
2358 | ||
2359 | 7.2 Entity Body | |
2360 | ||
2361 | The entity-body (if any) sent with an HTTP request or response is in | |
2362 | a format and encoding defined by the entity-header fields. | |
2363 | ||
2364 | entity-body = *OCTET | |
2365 | ||
2366 | An entity-body is only present in a message when a message-body is | |
2367 | present, as described in section 4.3. The entity-body is obtained | |
2368 | from the message-body by decoding any Transfer-Encoding that might | |
2369 | have been applied to ensure safe and proper transfer of the message. | |
2370 | ||
2371 | 7.2.1 Type | |
2372 | ||
2373 | When an entity-body is included with a message, the data type of that | |
2374 | body is determined via the header fields Content-Type and Content- | |
2375 | Encoding. These define a two-layer, ordered encoding model: | |
2376 | ||
2377 | entity-body := Content-Encoding( Content-Type( data ) ) | |
2378 | ||
2379 | Content-Type specifies the media type of the underlying data. | |
2380 | Content-Encoding may be used to indicate any additional content | |
2381 | codings applied to the data, usually for the purpose of data | |
2382 | compression, that are a property of the requested resource. There is | |
2383 | no default encoding. | |
2384 | ||
2385 | Any HTTP/1.1 message containing an entity-body SHOULD include a | |
2386 | Content-Type header field defining the media type of that body. If | |
2387 | and only if the media type is not given by a Content-Type field, the | |
2388 | recipient MAY attempt to guess the media type via inspection of its | |
2389 | content and/or the name extension(s) of the URI used to identify the | |
2390 | resource. If the media type remains unknown, the recipient SHOULD | |
2391 | treat it as type "application/octet-stream". | |
2392 | ||
2393 | 7.2.2 Entity Length | |
2394 | ||
2395 | The entity-length of a message is the length of the message-body | |
2396 | before any transfer-codings have been applied. Section 4.4 defines | |
2397 | how the transfer-length of a message-body is determined. | |
2398 | ||
2399 | ||
2400 | ||
2401 | ||
2402 | ||
2403 | ||
2404 | ||
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | Fielding, et al. Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 2616 HTTP/1.1 June 1999 | |
2413 | ||
2414 | ||
2415 | 8 Connections | |
2416 | ||
2417 | 8.1 Persistent Connections | |
2418 | ||
2419 | 8.1.1 Purpose | |
2420 | ||
2421 | Prior to persistent connections, a separate TCP connection was | |
2422 | established to fetch each URL, increasing the load on HTTP servers | |
2423 | and causing congestion on the Internet. The use of inline images and | |
2424 | other associated data often require a client to make multiple | |
2425 | requests of the same server in a short amount of time. Analysis of | |
2426 | these performance problems and results from a prototype | |
2427 | implementation are available [26] [30]. Implementation experience and | |
2428 | measurements of actual HTTP/1.1 (RFC 2068) implementations show good | |
2429 | results [39]. Alternatives have also been explored, for example, | |
2430 | T/TCP [27]. | |
2431 | ||
2432 | Persistent HTTP connections have a number of advantages: | |
2433 | ||
2434 | - By opening and closing fewer TCP connections, CPU time is saved | |
2435 | in routers and hosts (clients, servers, proxies, gateways, | |
2436 | tunnels, or caches), and memory used for TCP protocol control | |
2437 | blocks can be saved in hosts. | |
2438 | ||
2439 | - HTTP requests and responses can be pipelined on a connection. | |
2440 | Pipelining allows a client to make multiple requests without | |
2441 | waiting for each response, allowing a single TCP connection to | |
2442 | be used much more efficiently, with much lower elapsed time. | |
2443 | ||
2444 | - Network congestion is reduced by reducing the number of packets | |
2445 | caused by TCP opens, and by allowing TCP sufficient time to | |
2446 | determine the congestion state of the network. | |
2447 | ||
2448 | - Latency on subsequent requests is reduced since there is no time | |
2449 | spent in TCP's connection opening handshake. | |
2450 | ||
2451 | - HTTP can evolve more gracefully, since errors can be reported | |
2452 | without the penalty of closing the TCP connection. Clients using | |
2453 | future versions of HTTP might optimistically try a new feature, | |
2454 | but if communicating with an older server, retry with old | |
2455 | semantics after an error is reported. | |
2456 | ||
2457 | HTTP implementations SHOULD implement persistent connections. | |
2458 | ||
2459 | ||
2460 | ||
2461 | ||
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | Fielding, et al. Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 2616 HTTP/1.1 June 1999 | |
2469 | ||
2470 | ||
2471 | 8.1.2 Overall Operation | |
2472 | ||
2473 | A significant difference between HTTP/1.1 and earlier versions of | |
2474 | HTTP is that persistent connections are the default behavior of any | |
2475 | HTTP connection. That is, unless otherwise indicated, the client | |
2476 | SHOULD assume that the server will maintain a persistent connection, | |
2477 | even after error responses from the server. | |
2478 | ||
2479 | Persistent connections provide a mechanism by which a client and a | |
2480 | server can signal the close of a TCP connection. This signaling takes | |
2481 | place using the Connection header field (section 14.10). Once a close | |
2482 | has been signaled, the client MUST NOT send any more requests on that | |
2483 | connection. | |
2484 | ||
2485 | 8.1.2.1 Negotiation | |
2486 | ||
2487 | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | |
2488 | maintain a persistent connection unless a Connection header including | |
2489 | the connection-token "close" was sent in the request. If the server | |
2490 | chooses to close the connection immediately after sending the | |
2491 | response, it SHOULD send a Connection header including the | |
2492 | connection-token close. | |
2493 | ||
2494 | An HTTP/1.1 client MAY expect a connection to remain open, but would | |
2495 | decide to keep it open based on whether the response from a server | |
2496 | contains a Connection header with the connection-token close. In case | |
2497 | the client does not want to maintain a connection for more than that | |
2498 | request, it SHOULD send a Connection header including the | |
2499 | connection-token close. | |
2500 | ||
2501 | If either the client or the server sends the close token in the | |
2502 | Connection header, that request becomes the last one for the | |
2503 | connection. | |
2504 | ||
2505 | Clients and servers SHOULD NOT assume that a persistent connection is | |
2506 | maintained for HTTP versions less than 1.1 unless it is explicitly | |
2507 | signaled. See section 19.6.2 for more information on backward | |
2508 | compatibility with HTTP/1.0 clients. | |
2509 | ||
2510 | In order to remain persistent, all messages on the connection MUST | |
2511 | have a self-defined message length (i.e., one not defined by closure | |
2512 | of the connection), as described in section 4.4. | |
2513 | ||
2514 | ||
2515 | ||
2516 | ||
2517 | ||
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | Fielding, et al. Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 2616 HTTP/1.1 June 1999 | |
2525 | ||
2526 | ||
2527 | 8.1.2.2 Pipelining | |
2528 | ||
2529 | A client that supports persistent connections MAY "pipeline" its | |
2530 | requests (i.e., send multiple requests without waiting for each | |
2531 | response). A server MUST send its responses to those requests in the | |
2532 | same order that the requests were received. | |
2533 | ||
2534 | Clients which assume persistent connections and pipeline immediately | |
2535 | after connection establishment SHOULD be prepared to retry their | |
2536 | connection if the first pipelined attempt fails. If a client does | |
2537 | such a retry, it MUST NOT pipeline before it knows the connection is | |
2538 | persistent. Clients MUST also be prepared to resend their requests if | |
2539 | the server closes the connection before sending all of the | |
2540 | corresponding responses. | |
2541 | ||
2542 | Clients SHOULD NOT pipeline requests using non-idempotent methods or | |
2543 | non-idempotent sequences of methods (see section 9.1.2). Otherwise, a | |
2544 | premature termination of the transport connection could lead to | |
2545 | indeterminate results. A client wishing to send a non-idempotent | |
2546 | request SHOULD wait to send that request until it has received the | |
2547 | response status for the previous request. | |
2548 | ||
2549 | 8.1.3 Proxy Servers | |
2550 | ||
2551 | It is especially important that proxies correctly implement the | |
2552 | properties of the Connection header field as specified in section | |
2553 | 14.10. | |
2554 | ||
2555 | The proxy server MUST signal persistent connections separately with | |
2556 | its clients and the origin servers (or other proxy servers) that it | |
2557 | connects to. Each persistent connection applies to only one transport | |
2558 | link. | |
2559 | ||
2560 | A proxy server MUST NOT establish a HTTP/1.1 persistent connection | |
2561 | with an HTTP/1.0 client (but see RFC 2068 [33] for information and | |
2562 | discussion of the problems with the Keep-Alive header implemented by | |
2563 | many HTTP/1.0 clients). | |
2564 | ||
2565 | 8.1.4 Practical Considerations | |
2566 | ||
2567 | Servers will usually have some time-out value beyond which they will | |
2568 | no longer maintain an inactive connection. Proxy servers might make | |
2569 | this a higher value since it is likely that the client will be making | |
2570 | more connections through the same server. The use of persistent | |
2571 | connections places no requirements on the length (or existence) of | |
2572 | this time-out for either the client or the server. | |
2573 | ||
2574 | ||
2575 | ||
2576 | ||
2577 | ||
2578 | Fielding, et al. Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 2616 HTTP/1.1 June 1999 | |
2581 | ||
2582 | ||
2583 | When a client or server wishes to time-out it SHOULD issue a graceful | |
2584 | close on the transport connection. Clients and servers SHOULD both | |
2585 | constantly watch for the other side of the transport close, and | |
2586 | respond to it as appropriate. If a client or server does not detect | |
2587 | the other side's close promptly it could cause unnecessary resource | |
2588 | drain on the network. | |
2589 | ||
2590 | A client, server, or proxy MAY close the transport connection at any | |
2591 | time. For example, a client might have started to send a new request | |
2592 | at the same time that the server has decided to close the "idle" | |
2593 | connection. From the server's point of view, the connection is being | |
2594 | closed while it was idle, but from the client's point of view, a | |
2595 | request is in progress. | |
2596 | ||
2597 | This means that clients, servers, and proxies MUST be able to recover | |
2598 | from asynchronous close events. Client software SHOULD reopen the | |
2599 | transport connection and retransmit the aborted sequence of requests | |
2600 | without user interaction so long as the request sequence is | |
2601 | idempotent (see section 9.1.2). Non-idempotent methods or sequences | |
2602 | MUST NOT be automatically retried, although user agents MAY offer a | |
2603 | human operator the choice of retrying the request(s). Confirmation by | |
2604 | user-agent software with semantic understanding of the application | |
2605 | MAY substitute for user confirmation. The automatic retry SHOULD NOT | |
2606 | be repeated if the second sequence of requests fails. | |
2607 | ||
2608 | Servers SHOULD always respond to at least one request per connection, | |
2609 | if at all possible. Servers SHOULD NOT close a connection in the | |
2610 | middle of transmitting a response, unless a network or client failure | |
2611 | is suspected. | |
2612 | ||
2613 | Clients that use persistent connections SHOULD limit the number of | |
2614 | simultaneous connections that they maintain to a given server. A | |
2615 | single-user client SHOULD NOT maintain more than 2 connections with | |
2616 | any server or proxy. A proxy SHOULD use up to 2*N connections to | |
2617 | another server or proxy, where N is the number of simultaneously | |
2618 | active users. These guidelines are intended to improve HTTP response | |
2619 | times and avoid congestion. | |
2620 | ||
2621 | 8.2 Message Transmission Requirements | |
2622 | ||
2623 | 8.2.1 Persistent Connections and Flow Control | |
2624 | ||
2625 | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's | |
2626 | flow control mechanisms to resolve temporary overloads, rather than | |
2627 | terminating connections with the expectation that clients will retry. | |
2628 | The latter technique can exacerbate network congestion. | |
2629 | ||
2630 | ||
2631 | ||
2632 | ||
2633 | ||
2634 | Fielding, et al. Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 2616 HTTP/1.1 June 1999 | |
2637 | ||
2638 | ||
2639 | 8.2.2 Monitoring Connections for Error Status Messages | |
2640 | ||
2641 | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor | |
2642 | the network connection for an error status while it is transmitting | |
2643 | the request. If the client sees an error status, it SHOULD | |
2644 | immediately cease transmitting the body. If the body is being sent | |
2645 | using a "chunked" encoding (section 3.6), a zero length chunk and | |
2646 | empty trailer MAY be used to prematurely mark the end of the message. | |
2647 | If the body was preceded by a Content-Length header, the client MUST | |
2648 | close the connection. | |
2649 | ||
2650 | 8.2.3 Use of the 100 (Continue) Status | |
2651 | ||
2652 | The purpose of the 100 (Continue) status (see section 10.1.1) is to | |
2653 | allow a client that is sending a request message with a request body | |
2654 | to determine if the origin server is willing to accept the request | |
2655 | (based on the request headers) before the client sends the request | |
2656 | body. In some cases, it might either be inappropriate or highly | |
2657 | inefficient for the client to send the body if the server will reject | |
2658 | the message without looking at the body. | |
2659 | ||
2660 | Requirements for HTTP/1.1 clients: | |
2661 | ||
2662 | - If a client will wait for a 100 (Continue) response before | |
2663 | sending the request body, it MUST send an Expect request-header | |
2664 | field (section 14.20) with the "100-continue" expectation. | |
2665 | ||
2666 | - A client MUST NOT send an Expect request-header field (section | |
2667 | 14.20) with the "100-continue" expectation if it does not intend | |
2668 | to send a request body. | |
2669 | ||
2670 | Because of the presence of older implementations, the protocol allows | |
2671 | ambiguous situations in which a client may send "Expect: 100- | |
2672 | continue" without receiving either a 417 (Expectation Failed) status | |
2673 | or a 100 (Continue) status. Therefore, when a client sends this | |
2674 | header field to an origin server (possibly via a proxy) from which it | |
2675 | has never seen a 100 (Continue) status, the client SHOULD NOT wait | |
2676 | for an indefinite period before sending the request body. | |
2677 | ||
2678 | Requirements for HTTP/1.1 origin servers: | |
2679 | ||
2680 | - Upon receiving a request which includes an Expect request-header | |
2681 | field with the "100-continue" expectation, an origin server MUST | |
2682 | either respond with 100 (Continue) status and continue to read | |
2683 | from the input stream, or respond with a final status code. The | |
2684 | origin server MUST NOT wait for the request body before sending | |
2685 | the 100 (Continue) response. If it responds with a final status | |
2686 | code, it MAY close the transport connection or it MAY continue | |
2687 | ||
2688 | ||
2689 | ||
2690 | Fielding, et al. Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 2616 HTTP/1.1 June 1999 | |
2693 | ||
2694 | ||
2695 | to read and discard the rest of the request. It MUST NOT | |
2696 | perform the requested method if it returns a final status code. | |
2697 | ||
2698 | - An origin server SHOULD NOT send a 100 (Continue) response if | |
2699 | the request message does not include an Expect request-header | |
2700 | field with the "100-continue" expectation, and MUST NOT send a | |
2701 | 100 (Continue) response if such a request comes from an HTTP/1.0 | |
2702 | (or earlier) client. There is an exception to this rule: for | |
2703 | compatibility with RFC 2068, a server MAY send a 100 (Continue) | |
2704 | status in response to an HTTP/1.1 PUT or POST request that does | |
2705 | not include an Expect request-header field with the "100- | |
2706 | continue" expectation. This exception, the purpose of which is | |
2707 | to minimize any client processing delays associated with an | |
2708 | undeclared wait for 100 (Continue) status, applies only to | |
2709 | HTTP/1.1 requests, and not to requests with any other HTTP- | |
2710 | version value. | |
2711 | ||
2712 | - An origin server MAY omit a 100 (Continue) response if it has | |
2713 | already received some or all of the request body for the | |
2714 | corresponding request. | |
2715 | ||
2716 | - An origin server that sends a 100 (Continue) response MUST | |
2717 | ultimately send a final status code, once the request body is | |
2718 | received and processed, unless it terminates the transport | |
2719 | connection prematurely. | |
2720 | ||
2721 | - If an origin server receives a request that does not include an | |
2722 | Expect request-header field with the "100-continue" expectation, | |
2723 | the request includes a request body, and the server responds | |
2724 | with a final status code before reading the entire request body | |
2725 | from the transport connection, then the server SHOULD NOT close | |
2726 | the transport connection until it has read the entire request, | |
2727 | or until the client closes the connection. Otherwise, the client | |
2728 | might not reliably receive the response message. However, this | |
2729 | requirement is not be construed as preventing a server from | |
2730 | defending itself against denial-of-service attacks, or from | |
2731 | badly broken client implementations. | |
2732 | ||
2733 | Requirements for HTTP/1.1 proxies: | |
2734 | ||
2735 | - If a proxy receives a request that includes an Expect request- | |
2736 | header field with the "100-continue" expectation, and the proxy | |
2737 | either knows that the next-hop server complies with HTTP/1.1 or | |
2738 | higher, or does not know the HTTP version of the next-hop | |
2739 | server, it MUST forward the request, including the Expect header | |
2740 | field. | |
2741 | ||
2742 | ||
2743 | ||
2744 | ||
2745 | ||
2746 | Fielding, et al. Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 2616 HTTP/1.1 June 1999 | |
2749 | ||
2750 | ||
2751 | - If the proxy knows that the version of the next-hop server is | |
2752 | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST | |
2753 | respond with a 417 (Expectation Failed) status. | |
2754 | ||
2755 | - Proxies SHOULD maintain a cache recording the HTTP version | |
2756 | numbers received from recently-referenced next-hop servers. | |
2757 | ||
2758 | - A proxy MUST NOT forward a 100 (Continue) response if the | |
2759 | request message was received from an HTTP/1.0 (or earlier) | |
2760 | client and did not include an Expect request-header field with | |
2761 | the "100-continue" expectation. This requirement overrides the | |
2762 | general rule for forwarding of 1xx responses (see section 10.1). | |
2763 | ||
2764 | 8.2.4 Client Behavior if Server Prematurely Closes Connection | |
2765 | ||
2766 | If an HTTP/1.1 client sends a request which includes a request body, | |
2767 | but which does not include an Expect request-header field with the | |
2768 | "100-continue" expectation, and if the client is not directly | |
2769 | connected to an HTTP/1.1 origin server, and if the client sees the | |
2770 | connection close before receiving any status from the server, the | |
2771 | client SHOULD retry the request. If the client does retry this | |
2772 | request, it MAY use the following "binary exponential backoff" | |
2773 | algorithm to be assured of obtaining a reliable response: | |
2774 | ||
2775 | 1. Initiate a new connection to the server | |
2776 | ||
2777 | 2. Transmit the request-headers | |
2778 | ||
2779 | 3. Initialize a variable R to the estimated round-trip time to the | |
2780 | server (e.g., based on the time it took to establish the | |
2781 | connection), or to a constant value of 5 seconds if the round- | |
2782 | trip time is not available. | |
2783 | ||
2784 | 4. Compute T = R * (2**N), where N is the number of previous | |
2785 | retries of this request. | |
2786 | ||
2787 | 5. Wait either for an error response from the server, or for T | |
2788 | seconds (whichever comes first) | |
2789 | ||
2790 | 6. If no error response is received, after T seconds transmit the | |
2791 | body of the request. | |
2792 | ||
2793 | 7. If client sees that the connection is closed prematurely, | |
2794 | repeat from step 1 until the request is accepted, an error | |
2795 | response is received, or the user becomes impatient and | |
2796 | terminates the retry process. | |
2797 | ||
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | Fielding, et al. Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 2616 HTTP/1.1 June 1999 | |
2805 | ||
2806 | ||
2807 | If at any point an error status is received, the client | |
2808 | ||
2809 | - SHOULD NOT continue and | |
2810 | ||
2811 | - SHOULD close the connection if it has not completed sending the | |
2812 | request message. | |
2813 | ||
2814 | 9 Method Definitions | |
2815 | ||
2816 | The set of common methods for HTTP/1.1 is defined below. Although | |
2817 | this set can be expanded, additional methods cannot be assumed to | |
2818 | share the same semantics for separately extended clients and servers. | |
2819 | ||
2820 | The Host request-header field (section 14.23) MUST accompany all | |
2821 | HTTP/1.1 requests. | |
2822 | ||
2823 | 9.1 Safe and Idempotent Methods | |
2824 | ||
2825 | 9.1.1 Safe Methods | |
2826 | ||
2827 | Implementors should be aware that the software represents the user in | |
2828 | their interactions over the Internet, and should be careful to allow | |
2829 | the user to be aware of any actions they might take which may have an | |
2830 | unexpected significance to themselves or others. | |
2831 | ||
2832 | In particular, the convention has been established that the GET and | |
2833 | HEAD methods SHOULD NOT have the significance of taking an action | |
2834 | other than retrieval. These methods ought to be considered "safe". | |
2835 | This allows user agents to represent other methods, such as POST, PUT | |
2836 | and DELETE, in a special way, so that the user is made aware of the | |
2837 | fact that a possibly unsafe action is being requested. | |
2838 | ||
2839 | Naturally, it is not possible to ensure that the server does not | |
2840 | generate side-effects as a result of performing a GET request; in | |
2841 | fact, some dynamic resources consider that a feature. The important | |
2842 | distinction here is that the user did not request the side-effects, | |
2843 | so therefore cannot be held accountable for them. | |
2844 | ||
2845 | 9.1.2 Idempotent Methods | |
2846 | ||
2847 | Methods can also have the property of "idempotence" in that (aside | |
2848 | from error or expiration issues) the side-effects of N > 0 identical | |
2849 | requests is the same as for a single request. The methods GET, HEAD, | |
2850 | PUT and DELETE share this property. Also, the methods OPTIONS and | |
2851 | TRACE SHOULD NOT have side effects, and so are inherently idempotent. | |
2852 | ||
2853 | ||
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | Fielding, et al. Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 2616 HTTP/1.1 June 1999 | |
2861 | ||
2862 | ||
2863 | However, it is possible that a sequence of several requests is non- | |
2864 | idempotent, even if all of the methods executed in that sequence are | |
2865 | idempotent. (A sequence is idempotent if a single execution of the | |
2866 | entire sequence always yields a result that is not changed by a | |
2867 | reexecution of all, or part, of that sequence.) For example, a | |
2868 | sequence is non-idempotent if its result depends on a value that is | |
2869 | later modified in the same sequence. | |
2870 | ||
2871 | A sequence that never has side effects is idempotent, by definition | |
2872 | (provided that no concurrent operations are being executed on the | |
2873 | same set of resources). | |
2874 | ||
2875 | 9.2 OPTIONS | |
2876 | ||
2877 | The OPTIONS method represents a request for information about the | |
2878 | communication options available on the request/response chain | |
2879 | identified by the Request-URI. This method allows the client to | |
2880 | determine the options and/or requirements associated with a resource, | |
2881 | or the capabilities of a server, without implying a resource action | |
2882 | or initiating a resource retrieval. | |
2883 | ||
2884 | Responses to this method are not cacheable. | |
2885 | ||
2886 | If the OPTIONS request includes an entity-body (as indicated by the | |
2887 | presence of Content-Length or Transfer-Encoding), then the media type | |
2888 | MUST be indicated by a Content-Type field. Although this | |
2889 | specification does not define any use for such a body, future | |
2890 | extensions to HTTP might use the OPTIONS body to make more detailed | |
2891 | queries on the server. A server that does not support such an | |
2892 | extension MAY discard the request body. | |
2893 | ||
2894 | If the Request-URI is an asterisk ("*"), the OPTIONS request is | |
2895 | intended to apply to the server in general rather than to a specific | |
2896 | resource. Since a server's communication options typically depend on | |
2897 | the resource, the "*" request is only useful as a "ping" or "no-op" | |
2898 | type of method; it does nothing beyond allowing the client to test | |
2899 | the capabilities of the server. For example, this can be used to test | |
2900 | a proxy for HTTP/1.1 compliance (or lack thereof). | |
2901 | ||
2902 | If the Request-URI is not an asterisk, the OPTIONS request applies | |
2903 | only to the options that are available when communicating with that | |
2904 | resource. | |
2905 | ||
2906 | A 200 response SHOULD include any header fields that indicate | |
2907 | optional features implemented by the server and applicable to that | |
2908 | resource (e.g., Allow), possibly including extensions not defined by | |
2909 | this specification. The response body, if any, SHOULD also include | |
2910 | information about the communication options. The format for such a | |
2911 | ||
2912 | ||
2913 | ||
2914 | Fielding, et al. Standards Track [Page 52] | |
2915 | \f | |
2916 | RFC 2616 HTTP/1.1 June 1999 | |
2917 | ||
2918 | ||
2919 | body is not defined by this specification, but might be defined by | |
2920 | future extensions to HTTP. Content negotiation MAY be used to select | |
2921 | the appropriate response format. If no response body is included, the | |
2922 | response MUST include a Content-Length field with a field-value of | |
2923 | "0". | |
2924 | ||
2925 | The Max-Forwards request-header field MAY be used to target a | |
2926 | specific proxy in the request chain. When a proxy receives an OPTIONS | |
2927 | request on an absoluteURI for which request forwarding is permitted, | |
2928 | the proxy MUST check for a Max-Forwards field. If the Max-Forwards | |
2929 | field-value is zero ("0"), the proxy MUST NOT forward the message; | |
2930 | instead, the proxy SHOULD respond with its own communication options. | |
2931 | If the Max-Forwards field-value is an integer greater than zero, the | |
2932 | proxy MUST decrement the field-value when it forwards the request. If | |
2933 | no Max-Forwards field is present in the request, then the forwarded | |
2934 | request MUST NOT include a Max-Forwards field. | |
2935 | ||
2936 | 9.3 GET | |
2937 | ||
2938 | The GET method means retrieve whatever information (in the form of an | |
2939 | entity) is identified by the Request-URI. If the Request-URI refers | |
2940 | to a data-producing process, it is the produced data which shall be | |
2941 | returned as the entity in the response and not the source text of the | |
2942 | process, unless that text happens to be the output of the process. | |
2943 | ||
2944 | The semantics of the GET method change to a "conditional GET" if the | |
2945 | request message includes an If-Modified-Since, If-Unmodified-Since, | |
2946 | If-Match, If-None-Match, or If-Range header field. A conditional GET | |
2947 | method requests that the entity be transferred only under the | |
2948 | circumstances described by the conditional header field(s). The | |
2949 | conditional GET method is intended to reduce unnecessary network | |
2950 | usage by allowing cached entities to be refreshed without requiring | |
2951 | multiple requests or transferring data already held by the client. | |
2952 | ||
2953 | The semantics of the GET method change to a "partial GET" if the | |
2954 | request message includes a Range header field. A partial GET requests | |
2955 | that only part of the entity be transferred, as described in section | |
2956 | 14.35. The partial GET method is intended to reduce unnecessary | |
2957 | network usage by allowing partially-retrieved entities to be | |
2958 | completed without transferring data already held by the client. | |
2959 | ||
2960 | The response to a GET request is cacheable if and only if it meets | |
2961 | the requirements for HTTP caching described in section 13. | |
2962 | ||
2963 | See section 15.1.3 for security considerations when used for forms. | |
2964 | ||
2965 | ||
2966 | ||
2967 | ||
2968 | ||
2969 | ||
2970 | Fielding, et al. Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 2616 HTTP/1.1 June 1999 | |
2973 | ||
2974 | ||
2975 | 9.4 HEAD | |
2976 | ||
2977 | The HEAD method is identical to GET except that the server MUST NOT | |
2978 | return a message-body in the response. The metainformation contained | |
2979 | in the HTTP headers in response to a HEAD request SHOULD be identical | |
2980 | to the information sent in response to a GET request. This method can | |
2981 | be used for obtaining metainformation about the entity implied by the | |
2982 | request without transferring the entity-body itself. This method is | |
2983 | often used for testing hypertext links for validity, accessibility, | |
2984 | and recent modification. | |
2985 | ||
2986 | The response to a HEAD request MAY be cacheable in the sense that the | |
2987 | information contained in the response MAY be used to update a | |
2988 | previously cached entity from that resource. If the new field values | |
2989 | indicate that the cached entity differs from the current entity (as | |
2990 | would be indicated by a change in Content-Length, Content-MD5, ETag | |
2991 | or Last-Modified), then the cache MUST treat the cache entry as | |
2992 | stale. | |
2993 | ||
2994 | 9.5 POST | |
2995 | ||
2996 | The POST method is used to request that the origin server accept the | |
2997 | entity enclosed in the request as a new subordinate of the resource | |
2998 | identified by the Request-URI in the Request-Line. POST is designed | |
2999 | to allow a uniform method to cover the following functions: | |
3000 | ||
3001 | - Annotation of existing resources; | |
3002 | ||
3003 | - Posting a message to a bulletin board, newsgroup, mailing list, | |
3004 | or similar group of articles; | |
3005 | ||
3006 | - Providing a block of data, such as the result of submitting a | |
3007 | form, to a data-handling process; | |
3008 | ||
3009 | - Extending a database through an append operation. | |
3010 | ||
3011 | The actual function performed by the POST method is determined by the | |
3012 | server and is usually dependent on the Request-URI. The posted entity | |
3013 | is subordinate to that URI in the same way that a file is subordinate | |
3014 | to a directory containing it, a news article is subordinate to a | |
3015 | newsgroup to which it is posted, or a record is subordinate to a | |
3016 | database. | |
3017 | ||
3018 | The action performed by the POST method might not result in a | |
3019 | resource that can be identified by a URI. In this case, either 200 | |
3020 | (OK) or 204 (No Content) is the appropriate response status, | |
3021 | depending on whether or not the response includes an entity that | |
3022 | describes the result. | |
3023 | ||
3024 | ||
3025 | ||
3026 | Fielding, et al. Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 2616 HTTP/1.1 June 1999 | |
3029 | ||
3030 | ||
3031 | If a resource has been created on the origin server, the response | |
3032 | SHOULD be 201 (Created) and contain an entity which describes the | |
3033 | status of the request and refers to the new resource, and a Location | |
3034 | header (see section 14.30). | |
3035 | ||
3036 | Responses to this method are not cacheable, unless the response | |
3037 | includes appropriate Cache-Control or Expires header fields. However, | |
3038 | the 303 (See Other) response can be used to direct the user agent to | |
3039 | retrieve a cacheable resource. | |
3040 | ||
3041 | POST requests MUST obey the message transmission requirements set out | |
3042 | in section 8.2. | |
3043 | ||
3044 | See section 15.1.3 for security considerations. | |
3045 | ||
3046 | 9.6 PUT | |
3047 | ||
3048 | The PUT method requests that the enclosed entity be stored under the | |
3049 | supplied Request-URI. If the Request-URI refers to an already | |
3050 | existing resource, the enclosed entity SHOULD be considered as a | |
3051 | modified version of the one residing on the origin server. If the | |
3052 | Request-URI does not point to an existing resource, and that URI is | |
3053 | capable of being defined as a new resource by the requesting user | |
3054 | agent, the origin server can create the resource with that URI. If a | |
3055 | new resource is created, the origin server MUST inform the user agent | |
3056 | via the 201 (Created) response. If an existing resource is modified, | |
3057 | either the 200 (OK) or 204 (No Content) response codes SHOULD be sent | |
3058 | to indicate successful completion of the request. If the resource | |
3059 | could not be created or modified with the Request-URI, an appropriate | |
3060 | error response SHOULD be given that reflects the nature of the | |
3061 | problem. The recipient of the entity MUST NOT ignore any Content-* | |
3062 | (e.g. Content-Range) headers that it does not understand or implement | |
3063 | and MUST return a 501 (Not Implemented) response in such cases. | |
3064 | ||
3065 | If the request passes through a cache and the Request-URI identifies | |
3066 | one or more currently cached entities, those entries SHOULD be | |
3067 | treated as stale. Responses to this method are not cacheable. | |
3068 | ||
3069 | The fundamental difference between the POST and PUT requests is | |
3070 | reflected in the different meaning of the Request-URI. The URI in a | |
3071 | POST request identifies the resource that will handle the enclosed | |
3072 | entity. That resource might be a data-accepting process, a gateway to | |
3073 | some other protocol, or a separate entity that accepts annotations. | |
3074 | In contrast, the URI in a PUT request identifies the entity enclosed | |
3075 | with the request -- the user agent knows what URI is intended and the | |
3076 | server MUST NOT attempt to apply the request to some other resource. | |
3077 | If the server desires that the request be applied to a different URI, | |
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Fielding, et al. Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 2616 HTTP/1.1 June 1999 | |
3085 | ||
3086 | ||
3087 | it MUST send a 301 (Moved Permanently) response; the user agent MAY | |
3088 | then make its own decision regarding whether or not to redirect the | |
3089 | request. | |
3090 | ||
3091 | A single resource MAY be identified by many different URIs. For | |
3092 | example, an article might have a URI for identifying "the current | |
3093 | version" which is separate from the URI identifying each particular | |
3094 | version. In this case, a PUT request on a general URI might result in | |
3095 | several other URIs being defined by the origin server. | |
3096 | ||
3097 | HTTP/1.1 does not define how a PUT method affects the state of an | |
3098 | origin server. | |
3099 | ||
3100 | PUT requests MUST obey the message transmission requirements set out | |
3101 | in section 8.2. | |
3102 | ||
3103 | Unless otherwise specified for a particular entity-header, the | |
3104 | entity-headers in the PUT request SHOULD be applied to the resource | |
3105 | created or modified by the PUT. | |
3106 | ||
3107 | 9.7 DELETE | |
3108 | ||
3109 | The DELETE method requests that the origin server delete the resource | |
3110 | identified by the Request-URI. This method MAY be overridden by human | |
3111 | intervention (or other means) on the origin server. The client cannot | |
3112 | be guaranteed that the operation has been carried out, even if the | |
3113 | status code returned from the origin server indicates that the action | |
3114 | has been completed successfully. However, the server SHOULD NOT | |
3115 | indicate success unless, at the time the response is given, it | |
3116 | intends to delete the resource or move it to an inaccessible | |
3117 | location. | |
3118 | ||
3119 | A successful response SHOULD be 200 (OK) if the response includes an | |
3120 | entity describing the status, 202 (Accepted) if the action has not | |
3121 | yet been enacted, or 204 (No Content) if the action has been enacted | |
3122 | but the response does not include an entity. | |
3123 | ||
3124 | If the request passes through a cache and the Request-URI identifies | |
3125 | one or more currently cached entities, those entries SHOULD be | |
3126 | treated as stale. Responses to this method are not cacheable. | |
3127 | ||
3128 | 9.8 TRACE | |
3129 | ||
3130 | The TRACE method is used to invoke a remote, application-layer loop- | |
3131 | back of the request message. The final recipient of the request | |
3132 | SHOULD reflect the message received back to the client as the | |
3133 | entity-body of a 200 (OK) response. The final recipient is either the | |
3134 | ||
3135 | ||
3136 | ||
3137 | ||
3138 | Fielding, et al. Standards Track [Page 56] | |
3139 | \f | |
3140 | RFC 2616 HTTP/1.1 June 1999 | |
3141 | ||
3142 | ||
3143 | origin server or the first proxy or gateway to receive a Max-Forwards | |
3144 | value of zero (0) in the request (see section 14.31). A TRACE request | |
3145 | MUST NOT include an entity. | |
3146 | ||
3147 | TRACE allows the client to see what is being received at the other | |
3148 | end of the request chain and use that data for testing or diagnostic | |
3149 | information. The value of the Via header field (section 14.45) is of | |
3150 | particular interest, since it acts as a trace of the request chain. | |
3151 | Use of the Max-Forwards header field allows the client to limit the | |
3152 | length of the request chain, which is useful for testing a chain of | |
3153 | proxies forwarding messages in an infinite loop. | |
3154 | ||
3155 | If the request is valid, the response SHOULD contain the entire | |
3156 | request message in the entity-body, with a Content-Type of | |
3157 | "message/http". Responses to this method MUST NOT be cached. | |
3158 | ||
3159 | 9.9 CONNECT | |
3160 | ||
3161 | This specification reserves the method name CONNECT for use with a | |
3162 | proxy that can dynamically switch to being a tunnel (e.g. SSL | |
3163 | tunneling [44]). | |
3164 | ||
3165 | 10 Status Code Definitions | |
3166 | ||
3167 | Each Status-Code is described below, including a description of which | |
3168 | method(s) it can follow and any metainformation required in the | |
3169 | response. | |
3170 | ||
3171 | 10.1 Informational 1xx | |
3172 | ||
3173 | This class of status code indicates a provisional response, | |
3174 | consisting only of the Status-Line and optional headers, and is | |
3175 | terminated by an empty line. There are no required headers for this | |
3176 | class of status code. Since HTTP/1.0 did not define any 1xx status | |
3177 | codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client | |
3178 | except under experimental conditions. | |
3179 | ||
3180 | A client MUST be prepared to accept one or more 1xx status responses | |
3181 | prior to a regular response, even if the client does not expect a 100 | |
3182 | (Continue) status message. Unexpected 1xx status responses MAY be | |
3183 | ignored by a user agent. | |
3184 | ||
3185 | Proxies MUST forward 1xx responses, unless the connection between the | |
3186 | proxy and its client has been closed, or unless the proxy itself | |
3187 | requested the generation of the 1xx response. (For example, if a | |
3188 | ||
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Fielding, et al. Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 2616 HTTP/1.1 June 1999 | |
3197 | ||
3198 | ||
3199 | proxy adds a "Expect: 100-continue" field when it forwards a request, | |
3200 | then it need not forward the corresponding 100 (Continue) | |
3201 | response(s).) | |
3202 | ||
3203 | 10.1.1 100 Continue | |
3204 | ||
3205 | The client SHOULD continue with its request. This interim response is | |
3206 | used to inform the client that the initial part of the request has | |
3207 | been received and has not yet been rejected by the server. The client | |
3208 | SHOULD continue by sending the remainder of the request or, if the | |
3209 | request has already been completed, ignore this response. The server | |
3210 | MUST send a final response after the request has been completed. See | |
3211 | section 8.2.3 for detailed discussion of the use and handling of this | |
3212 | status code. | |
3213 | ||
3214 | 10.1.2 101 Switching Protocols | |
3215 | ||
3216 | The server understands and is willing to comply with the client's | |
3217 | request, via the Upgrade message header field (section 14.42), for a | |
3218 | change in the application protocol being used on this connection. The | |
3219 | server will switch protocols to those defined by the response's | |
3220 | Upgrade header field immediately after the empty line which | |
3221 | terminates the 101 response. | |
3222 | ||
3223 | The protocol SHOULD be switched only when it is advantageous to do | |
3224 | so. For example, switching to a newer version of HTTP is advantageous | |
3225 | over older versions, and switching to a real-time, synchronous | |
3226 | protocol might be advantageous when delivering resources that use | |
3227 | such features. | |
3228 | ||
3229 | 10.2 Successful 2xx | |
3230 | ||
3231 | This class of status code indicates that the client's request was | |
3232 | successfully received, understood, and accepted. | |
3233 | ||
3234 | 10.2.1 200 OK | |
3235 | ||
3236 | The request has succeeded. The information returned with the response | |
3237 | is dependent on the method used in the request, for example: | |
3238 | ||
3239 | GET an entity corresponding to the requested resource is sent in | |
3240 | the response; | |
3241 | ||
3242 | HEAD the entity-header fields corresponding to the requested | |
3243 | resource are sent in the response without any message-body; | |
3244 | ||
3245 | POST an entity describing or containing the result of the action; | |
3246 | ||
3247 | ||
3248 | ||
3249 | ||
3250 | Fielding, et al. Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 2616 HTTP/1.1 June 1999 | |
3253 | ||
3254 | ||
3255 | TRACE an entity containing the request message as received by the | |
3256 | end server. | |
3257 | ||
3258 | 10.2.2 201 Created | |
3259 | ||
3260 | The request has been fulfilled and resulted in a new resource being | |
3261 | created. The newly created resource can be referenced by the URI(s) | |
3262 | returned in the entity of the response, with the most specific URI | |
3263 | for the resource given by a Location header field. The response | |
3264 | SHOULD include an entity containing a list of resource | |
3265 | characteristics and location(s) from which the user or user agent can | |
3266 | choose the one most appropriate. The entity format is specified by | |
3267 | the media type given in the Content-Type header field. The origin | |
3268 | server MUST create the resource before returning the 201 status code. | |
3269 | If the action cannot be carried out immediately, the server SHOULD | |
3270 | respond with 202 (Accepted) response instead. | |
3271 | ||
3272 | A 201 response MAY contain an ETag response header field indicating | |
3273 | the current value of the entity tag for the requested variant just | |
3274 | created, see section 14.19. | |
3275 | ||
3276 | 10.2.3 202 Accepted | |
3277 | ||
3278 | The request has been accepted for processing, but the processing has | |
3279 | not been completed. The request might or might not eventually be | |
3280 | acted upon, as it might be disallowed when processing actually takes | |
3281 | place. There is no facility for re-sending a status code from an | |
3282 | asynchronous operation such as this. | |
3283 | ||
3284 | The 202 response is intentionally non-committal. Its purpose is to | |
3285 | allow a server to accept a request for some other process (perhaps a | |
3286 | batch-oriented process that is only run once per day) without | |
3287 | requiring that the user agent's connection to the server persist | |
3288 | until the process is completed. The entity returned with this | |
3289 | response SHOULD include an indication of the request's current status | |
3290 | and either a pointer to a status monitor or some estimate of when the | |
3291 | user can expect the request to be fulfilled. | |
3292 | ||
3293 | 10.2.4 203 Non-Authoritative Information | |
3294 | ||
3295 | The returned metainformation in the entity-header is not the | |
3296 | definitive set as available from the origin server, but is gathered | |
3297 | from a local or a third-party copy. The set presented MAY be a subset | |
3298 | or superset of the original version. For example, including local | |
3299 | annotation information about the resource might result in a superset | |
3300 | of the metainformation known by the origin server. Use of this | |
3301 | response code is not required and is only appropriate when the | |
3302 | response would otherwise be 200 (OK). | |
3303 | ||
3304 | ||
3305 | ||
3306 | Fielding, et al. Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 2616 HTTP/1.1 June 1999 | |
3309 | ||
3310 | ||
3311 | 10.2.5 204 No Content | |
3312 | ||
3313 | The server has fulfilled the request but does not need to return an | |
3314 | entity-body, and might want to return updated metainformation. The | |
3315 | response MAY include new or updated metainformation in the form of | |
3316 | entity-headers, which if present SHOULD be associated with the | |
3317 | requested variant. | |
3318 | ||
3319 | If the client is a user agent, it SHOULD NOT change its document view | |
3320 | from that which caused the request to be sent. This response is | |
3321 | primarily intended to allow input for actions to take place without | |
3322 | causing a change to the user agent's active document view, although | |
3323 | any new or updated metainformation SHOULD be applied to the document | |
3324 | currently in the user agent's active view. | |
3325 | ||
3326 | The 204 response MUST NOT include a message-body, and thus is always | |
3327 | terminated by the first empty line after the header fields. | |
3328 | ||
3329 | 10.2.6 205 Reset Content | |
3330 | ||
3331 | The server has fulfilled the request and the user agent SHOULD reset | |
3332 | the document view which caused the request to be sent. This response | |
3333 | is primarily intended to allow input for actions to take place via | |
3334 | user input, followed by a clearing of the form in which the input is | |
3335 | given so that the user can easily initiate another input action. The | |
3336 | response MUST NOT include an entity. | |
3337 | ||
3338 | 10.2.7 206 Partial Content | |
3339 | ||
3340 | The server has fulfilled the partial GET request for the resource. | |
3341 | The request MUST have included a Range header field (section 14.35) | |
3342 | indicating the desired range, and MAY have included an If-Range | |
3343 | header field (section 14.27) to make the request conditional. | |
3344 | ||
3345 | The response MUST include the following header fields: | |
3346 | ||
3347 | - Either a Content-Range header field (section 14.16) indicating | |
3348 | the range included with this response, or a multipart/byteranges | |
3349 | Content-Type including Content-Range fields for each part. If a | |
3350 | Content-Length header field is present in the response, its | |
3351 | value MUST match the actual number of OCTETs transmitted in the | |
3352 | message-body. | |
3353 | ||
3354 | - Date | |
3355 | ||
3356 | - ETag and/or Content-Location, if the header would have been sent | |
3357 | in a 200 response to the same request | |
3358 | ||
3359 | ||
3360 | ||
3361 | ||
3362 | Fielding, et al. Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 2616 HTTP/1.1 June 1999 | |
3365 | ||
3366 | ||
3367 | - Expires, Cache-Control, and/or Vary, if the field-value might | |
3368 | differ from that sent in any previous response for the same | |
3369 | variant | |
3370 | ||
3371 | If the 206 response is the result of an If-Range request that used a | |
3372 | strong cache validator (see section 13.3.3), the response SHOULD NOT | |
3373 | include other entity-headers. If the response is the result of an | |
3374 | If-Range request that used a weak validator, the response MUST NOT | |
3375 | include other entity-headers; this prevents inconsistencies between | |
3376 | cached entity-bodies and updated headers. Otherwise, the response | |
3377 | MUST include all of the entity-headers that would have been returned | |
3378 | with a 200 (OK) response to the same request. | |
3379 | ||
3380 | A cache MUST NOT combine a 206 response with other previously cached | |
3381 | content if the ETag or Last-Modified headers do not match exactly, | |
3382 | see 13.5.4. | |
3383 | ||
3384 | A cache that does not support the Range and Content-Range headers | |
3385 | MUST NOT cache 206 (Partial) responses. | |
3386 | ||
3387 | 10.3 Redirection 3xx | |
3388 | ||
3389 | This class of status code indicates that further action needs to be | |
3390 | taken by the user agent in order to fulfill the request. The action | |
3391 | required MAY be carried out by the user agent without interaction | |
3392 | with the user if and only if the method used in the second request is | |
3393 | GET or HEAD. A client SHOULD detect infinite redirection loops, since | |
3394 | such loops generate network traffic for each redirection. | |
3395 | ||
3396 | Note: previous versions of this specification recommended a | |
3397 | maximum of five redirections. Content developers should be aware | |
3398 | that there might be clients that implement such a fixed | |
3399 | limitation. | |
3400 | ||
3401 | 10.3.1 300 Multiple Choices | |
3402 | ||
3403 | The requested resource corresponds to any one of a set of | |
3404 | representations, each with its own specific location, and agent- | |
3405 | driven negotiation information (section 12) is being provided so that | |
3406 | the user (or user agent) can select a preferred representation and | |
3407 | redirect its request to that location. | |
3408 | ||
3409 | Unless it was a HEAD request, the response SHOULD include an entity | |
3410 | containing a list of resource characteristics and location(s) from | |
3411 | which the user or user agent can choose the one most appropriate. The | |
3412 | entity format is specified by the media type given in the Content- | |
3413 | Type header field. Depending upon the format and the capabilities of | |
3414 | ||
3415 | ||
3416 | ||
3417 | ||
3418 | Fielding, et al. Standards Track [Page 61] | |
3419 | \f | |
3420 | RFC 2616 HTTP/1.1 June 1999 | |
3421 | ||
3422 | ||
3423 | the user agent, selection of the most appropriate choice MAY be | |
3424 | performed automatically. However, this specification does not define | |
3425 | any standard for such automatic selection. | |
3426 | ||
3427 | If the server has a preferred choice of representation, it SHOULD | |
3428 | include the specific URI for that representation in the Location | |
3429 | field; user agents MAY use the Location field value for automatic | |
3430 | redirection. This response is cacheable unless indicated otherwise. | |
3431 | ||
3432 | 10.3.2 301 Moved Permanently | |
3433 | ||
3434 | The requested resource has been assigned a new permanent URI and any | |
3435 | future references to this resource SHOULD use one of the returned | |
3436 | URIs. Clients with link editing capabilities ought to automatically | |
3437 | re-link references to the Request-URI to one or more of the new | |
3438 | references returned by the server, where possible. This response is | |
3439 | cacheable unless indicated otherwise. | |
3440 | ||
3441 | The new permanent URI SHOULD be given by the Location field in the | |
3442 | response. Unless the request method was HEAD, the entity of the | |
3443 | response SHOULD contain a short hypertext note with a hyperlink to | |
3444 | the new URI(s). | |
3445 | ||
3446 | If the 301 status code is received in response to a request other | |
3447 | than GET or HEAD, the user agent MUST NOT automatically redirect the | |
3448 | request unless it can be confirmed by the user, since this might | |
3449 | change the conditions under which the request was issued. | |
3450 | ||
3451 | Note: When automatically redirecting a POST request after | |
3452 | receiving a 301 status code, some existing HTTP/1.0 user agents | |
3453 | will erroneously change it into a GET request. | |
3454 | ||
3455 | 10.3.3 302 Found | |
3456 | ||
3457 | The requested resource resides temporarily under a different URI. | |
3458 | Since the redirection might be altered on occasion, the client SHOULD | |
3459 | continue to use the Request-URI for future requests. This response | |
3460 | is only cacheable if indicated by a Cache-Control or Expires header | |
3461 | field. | |
3462 | ||
3463 | The temporary URI SHOULD be given by the Location field in the | |
3464 | response. Unless the request method was HEAD, the entity of the | |
3465 | response SHOULD contain a short hypertext note with a hyperlink to | |
3466 | the new URI(s). | |
3467 | ||
3468 | ||
3469 | ||
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | Fielding, et al. Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 2616 HTTP/1.1 June 1999 | |
3477 | ||
3478 | ||
3479 | If the 302 status code is received in response to a request other | |
3480 | than GET or HEAD, the user agent MUST NOT automatically redirect the | |
3481 | request unless it can be confirmed by the user, since this might | |
3482 | change the conditions under which the request was issued. | |
3483 | ||
3484 | Note: RFC 1945 and RFC 2068 specify that the client is not allowed | |
3485 | to change the method on the redirected request. However, most | |
3486 | existing user agent implementations treat 302 as if it were a 303 | |
3487 | response, performing a GET on the Location field-value regardless | |
3488 | of the original request method. The status codes 303 and 307 have | |
3489 | been added for servers that wish to make unambiguously clear which | |
3490 | kind of reaction is expected of the client. | |
3491 | ||
3492 | 10.3.4 303 See Other | |
3493 | ||
3494 | The response to the request can be found under a different URI and | |
3495 | SHOULD be retrieved using a GET method on that resource. This method | |
3496 | exists primarily to allow the output of a POST-activated script to | |
3497 | redirect the user agent to a selected resource. The new URI is not a | |
3498 | substitute reference for the originally requested resource. The 303 | |
3499 | response MUST NOT be cached, but the response to the second | |
3500 | (redirected) request might be cacheable. | |
3501 | ||
3502 | The different URI SHOULD be given by the Location field in the | |
3503 | response. Unless the request method was HEAD, the entity of the | |
3504 | response SHOULD contain a short hypertext note with a hyperlink to | |
3505 | the new URI(s). | |
3506 | ||
3507 | Note: Many pre-HTTP/1.1 user agents do not understand the 303 | |
3508 | status. When interoperability with such clients is a concern, the | |
3509 | 302 status code may be used instead, since most user agents react | |
3510 | to a 302 response as described here for 303. | |
3511 | ||
3512 | 10.3.5 304 Not Modified | |
3513 | ||
3514 | If the client has performed a conditional GET request and access is | |
3515 | allowed, but the document has not been modified, the server SHOULD | |
3516 | respond with this status code. The 304 response MUST NOT contain a | |
3517 | message-body, and thus is always terminated by the first empty line | |
3518 | after the header fields. | |
3519 | ||
3520 | The response MUST include the following header fields: | |
3521 | ||
3522 | - Date, unless its omission is required by section 14.18.1 | |
3523 | ||
3524 | ||
3525 | ||
3526 | ||
3527 | ||
3528 | ||
3529 | ||
3530 | Fielding, et al. Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 2616 HTTP/1.1 June 1999 | |
3533 | ||
3534 | ||
3535 | If a clockless origin server obeys these rules, and proxies and | |
3536 | clients add their own Date to any response received without one (as | |
3537 | already specified by [RFC 2068], section 14.19), caches will operate | |
3538 | correctly. | |
3539 | ||
3540 | - ETag and/or Content-Location, if the header would have been sent | |
3541 | in a 200 response to the same request | |
3542 | ||
3543 | - Expires, Cache-Control, and/or Vary, if the field-value might | |
3544 | differ from that sent in any previous response for the same | |
3545 | variant | |
3546 | ||
3547 | If the conditional GET used a strong cache validator (see section | |
3548 | 13.3.3), the response SHOULD NOT include other entity-headers. | |
3549 | Otherwise (i.e., the conditional GET used a weak validator), the | |
3550 | response MUST NOT include other entity-headers; this prevents | |
3551 | inconsistencies between cached entity-bodies and updated headers. | |
3552 | ||
3553 | If a 304 response indicates an entity not currently cached, then the | |
3554 | cache MUST disregard the response and repeat the request without the | |
3555 | conditional. | |
3556 | ||
3557 | If a cache uses a received 304 response to update a cache entry, the | |
3558 | cache MUST update the entry to reflect any new field values given in | |
3559 | the response. | |
3560 | ||
3561 | 10.3.6 305 Use Proxy | |
3562 | ||
3563 | The requested resource MUST be accessed through the proxy given by | |
3564 | the Location field. The Location field gives the URI of the proxy. | |
3565 | The recipient is expected to repeat this single request via the | |
3566 | proxy. 305 responses MUST only be generated by origin servers. | |
3567 | ||
3568 | Note: RFC 2068 was not clear that 305 was intended to redirect a | |
3569 | single request, and to be generated by origin servers only. Not | |
3570 | observing these limitations has significant security consequences. | |
3571 | ||
3572 | 10.3.7 306 (Unused) | |
3573 | ||
3574 | The 306 status code was used in a previous version of the | |
3575 | specification, is no longer used, and the code is reserved. | |
3576 | ||
3577 | ||
3578 | ||
3579 | ||
3580 | ||
3581 | ||
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | Fielding, et al. Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 2616 HTTP/1.1 June 1999 | |
3589 | ||
3590 | ||
3591 | 10.3.8 307 Temporary Redirect | |
3592 | ||
3593 | The requested resource resides temporarily under a different URI. | |
3594 | Since the redirection MAY be altered on occasion, the client SHOULD | |
3595 | continue to use the Request-URI for future requests. This response | |
3596 | is only cacheable if indicated by a Cache-Control or Expires header | |
3597 | field. | |
3598 | ||
3599 | The temporary URI SHOULD be given by the Location field in the | |
3600 | response. Unless the request method was HEAD, the entity of the | |
3601 | response SHOULD contain a short hypertext note with a hyperlink to | |
3602 | the new URI(s) , since many pre-HTTP/1.1 user agents do not | |
3603 | understand the 307 status. Therefore, the note SHOULD contain the | |
3604 | information necessary for a user to repeat the original request on | |
3605 | the new URI. | |
3606 | ||
3607 | If the 307 status code is received in response to a request other | |
3608 | than GET or HEAD, the user agent MUST NOT automatically redirect the | |
3609 | request unless it can be confirmed by the user, since this might | |
3610 | change the conditions under which the request was issued. | |
3611 | ||
3612 | 10.4 Client Error 4xx | |
3613 | ||
3614 | The 4xx class of status code is intended for cases in which the | |
3615 | client seems to have erred. Except when responding to a HEAD request, | |
3616 | the server SHOULD include an entity containing an explanation of the | |
3617 | error situation, and whether it is a temporary or permanent | |
3618 | condition. These status codes are applicable to any request method. | |
3619 | User agents SHOULD display any included entity to the user. | |
3620 | ||
3621 | If the client is sending data, a server implementation using TCP | |
3622 | SHOULD be careful to ensure that the client acknowledges receipt of | |
3623 | the packet(s) containing the response, before the server closes the | |
3624 | input connection. If the client continues sending data to the server | |
3625 | after the close, the server's TCP stack will send a reset packet to | |
3626 | the client, which may erase the client's unacknowledged input buffers | |
3627 | before they can be read and interpreted by the HTTP application. | |
3628 | ||
3629 | 10.4.1 400 Bad Request | |
3630 | ||
3631 | The request could not be understood by the server due to malformed | |
3632 | syntax. The client SHOULD NOT repeat the request without | |
3633 | modifications. | |
3634 | ||
3635 | ||
3636 | ||
3637 | ||
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | Fielding, et al. Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 2616 HTTP/1.1 June 1999 | |
3645 | ||
3646 | ||
3647 | 10.4.2 401 Unauthorized | |
3648 | ||
3649 | The request requires user authentication. The response MUST include a | |
3650 | WWW-Authenticate header field (section 14.47) containing a challenge | |
3651 | applicable to the requested resource. The client MAY repeat the | |
3652 | request with a suitable Authorization header field (section 14.8). If | |
3653 | the request already included Authorization credentials, then the 401 | |
3654 | response indicates that authorization has been refused for those | |
3655 | credentials. If the 401 response contains the same challenge as the | |
3656 | prior response, and the user agent has already attempted | |
3657 | authentication at least once, then the user SHOULD be presented the | |
3658 | entity that was given in the response, since that entity might | |
3659 | include relevant diagnostic information. HTTP access authentication | |
3660 | is explained in "HTTP Authentication: Basic and Digest Access | |
3661 | Authentication" [43]. | |
3662 | ||
3663 | 10.4.3 402 Payment Required | |
3664 | ||
3665 | This code is reserved for future use. | |
3666 | ||
3667 | 10.4.4 403 Forbidden | |
3668 | ||
3669 | The server understood the request, but is refusing to fulfill it. | |
3670 | Authorization will not help and the request SHOULD NOT be repeated. | |
3671 | If the request method was not HEAD and the server wishes to make | |
3672 | public why the request has not been fulfilled, it SHOULD describe the | |
3673 | reason for the refusal in the entity. If the server does not wish to | |
3674 | make this information available to the client, the status code 404 | |
3675 | (Not Found) can be used instead. | |
3676 | ||
3677 | 10.4.5 404 Not Found | |
3678 | ||
3679 | The server has not found anything matching the Request-URI. No | |
3680 | indication is given of whether the condition is temporary or | |
3681 | permanent. The 410 (Gone) status code SHOULD be used if the server | |
3682 | knows, through some internally configurable mechanism, that an old | |
3683 | resource is permanently unavailable and has no forwarding address. | |
3684 | This status code is commonly used when the server does not wish to | |
3685 | reveal exactly why the request has been refused, or when no other | |
3686 | response is applicable. | |
3687 | ||
3688 | 10.4.6 405 Method Not Allowed | |
3689 | ||
3690 | The method specified in the Request-Line is not allowed for the | |
3691 | resource identified by the Request-URI. The response MUST include an | |
3692 | Allow header containing a list of valid methods for the requested | |
3693 | resource. | |
3694 | ||
3695 | ||
3696 | ||
3697 | ||
3698 | Fielding, et al. Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 2616 HTTP/1.1 June 1999 | |
3701 | ||
3702 | ||
3703 | 10.4.7 406 Not Acceptable | |
3704 | ||
3705 | The resource identified by the request is only capable of generating | |
3706 | response entities which have content characteristics not acceptable | |
3707 | according to the accept headers sent in the request. | |
3708 | ||
3709 | Unless it was a HEAD request, the response SHOULD include an entity | |
3710 | containing a list of available entity characteristics and location(s) | |
3711 | from which the user or user agent can choose the one most | |
3712 | appropriate. The entity format is specified by the media type given | |
3713 | in the Content-Type header field. Depending upon the format and the | |
3714 | capabilities of the user agent, selection of the most appropriate | |
3715 | choice MAY be performed automatically. However, this specification | |
3716 | does not define any standard for such automatic selection. | |
3717 | ||
3718 | Note: HTTP/1.1 servers are allowed to return responses which are | |
3719 | not acceptable according to the accept headers sent in the | |
3720 | request. In some cases, this may even be preferable to sending a | |
3721 | 406 response. User agents are encouraged to inspect the headers of | |
3722 | an incoming response to determine if it is acceptable. | |
3723 | ||
3724 | If the response could be unacceptable, a user agent SHOULD | |
3725 | temporarily stop receipt of more data and query the user for a | |
3726 | decision on further actions. | |
3727 | ||
3728 | 10.4.8 407 Proxy Authentication Required | |
3729 | ||
3730 | This code is similar to 401 (Unauthorized), but indicates that the | |
3731 | client must first authenticate itself with the proxy. The proxy MUST | |
3732 | return a Proxy-Authenticate header field (section 14.33) containing a | |
3733 | challenge applicable to the proxy for the requested resource. The | |
3734 | client MAY repeat the request with a suitable Proxy-Authorization | |
3735 | header field (section 14.34). HTTP access authentication is explained | |
3736 | in "HTTP Authentication: Basic and Digest Access Authentication" | |
3737 | [43]. | |
3738 | ||
3739 | 10.4.9 408 Request Timeout | |
3740 | ||
3741 | The client did not produce a request within the time that the server | |
3742 | was prepared to wait. The client MAY repeat the request without | |
3743 | modifications at any later time. | |
3744 | ||
3745 | 10.4.10 409 Conflict | |
3746 | ||
3747 | The request could not be completed due to a conflict with the current | |
3748 | state of the resource. This code is only allowed in situations where | |
3749 | it is expected that the user might be able to resolve the conflict | |
3750 | and resubmit the request. The response body SHOULD include enough | |
3751 | ||
3752 | ||
3753 | ||
3754 | Fielding, et al. Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 2616 HTTP/1.1 June 1999 | |
3757 | ||
3758 | ||
3759 | information for the user to recognize the source of the conflict. | |
3760 | Ideally, the response entity would include enough information for the | |
3761 | user or user agent to fix the problem; however, that might not be | |
3762 | possible and is not required. | |
3763 | ||
3764 | Conflicts are most likely to occur in response to a PUT request. For | |
3765 | example, if versioning were being used and the entity being PUT | |
3766 | included changes to a resource which conflict with those made by an | |
3767 | earlier (third-party) request, the server might use the 409 response | |
3768 | to indicate that it can't complete the request. In this case, the | |
3769 | response entity would likely contain a list of the differences | |
3770 | between the two versions in a format defined by the response | |
3771 | Content-Type. | |
3772 | ||
3773 | 10.4.11 410 Gone | |
3774 | ||
3775 | The requested resource is no longer available at the server and no | |
3776 | forwarding address is known. This condition is expected to be | |
3777 | considered permanent. Clients with link editing capabilities SHOULD | |
3778 | delete references to the Request-URI after user approval. If the | |
3779 | server does not know, or has no facility to determine, whether or not | |
3780 | the condition is permanent, the status code 404 (Not Found) SHOULD be | |
3781 | used instead. This response is cacheable unless indicated otherwise. | |
3782 | ||
3783 | The 410 response is primarily intended to assist the task of web | |
3784 | maintenance by notifying the recipient that the resource is | |
3785 | intentionally unavailable and that the server owners desire that | |
3786 | remote links to that resource be removed. Such an event is common for | |
3787 | limited-time, promotional services and for resources belonging to | |
3788 | individuals no longer working at the server's site. It is not | |
3789 | necessary to mark all permanently unavailable resources as "gone" or | |
3790 | to keep the mark for any length of time -- that is left to the | |
3791 | discretion of the server owner. | |
3792 | ||
3793 | 10.4.12 411 Length Required | |
3794 | ||
3795 | The server refuses to accept the request without a defined Content- | |
3796 | Length. The client MAY repeat the request if it adds a valid | |
3797 | Content-Length header field containing the length of the message-body | |
3798 | in the request message. | |
3799 | ||
3800 | 10.4.13 412 Precondition Failed | |
3801 | ||
3802 | The precondition given in one or more of the request-header fields | |
3803 | evaluated to false when it was tested on the server. This response | |
3804 | code allows the client to place preconditions on the current resource | |
3805 | metainformation (header field data) and thus prevent the requested | |
3806 | method from being applied to a resource other than the one intended. | |
3807 | ||
3808 | ||
3809 | ||
3810 | Fielding, et al. Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 2616 HTTP/1.1 June 1999 | |
3813 | ||
3814 | ||
3815 | 10.4.14 413 Request Entity Too Large | |
3816 | ||
3817 | The server is refusing to process a request because the request | |
3818 | entity is larger than the server is willing or able to process. The | |
3819 | server MAY close the connection to prevent the client from continuing | |
3820 | the request. | |
3821 | ||
3822 | If the condition is temporary, the server SHOULD include a Retry- | |
3823 | After header field to indicate that it is temporary and after what | |
3824 | time the client MAY try again. | |
3825 | ||
3826 | 10.4.15 414 Request-URI Too Long | |
3827 | ||
3828 | The server is refusing to service the request because the Request-URI | |
3829 | is longer than the server is willing to interpret. This rare | |
3830 | condition is only likely to occur when a client has improperly | |
3831 | converted a POST request to a GET request with long query | |
3832 | information, when the client has descended into a URI "black hole" of | |
3833 | redirection (e.g., a redirected URI prefix that points to a suffix of | |
3834 | itself), or when the server is under attack by a client attempting to | |
3835 | exploit security holes present in some servers using fixed-length | |
3836 | buffers for reading or manipulating the Request-URI. | |
3837 | ||
3838 | 10.4.16 415 Unsupported Media Type | |
3839 | ||
3840 | The server is refusing to service the request because the entity of | |
3841 | the request is in a format not supported by the requested resource | |
3842 | for the requested method. | |
3843 | ||
3844 | 10.4.17 416 Requested Range Not Satisfiable | |
3845 | ||
3846 | A server SHOULD return a response with this status code if a request | |
3847 | included a Range request-header field (section 14.35), and none of | |
3848 | the range-specifier values in this field overlap the current extent | |
3849 | of the selected resource, and the request did not include an If-Range | |
3850 | request-header field. (For byte-ranges, this means that the first- | |
3851 | byte-pos of all of the byte-range-spec values were greater than the | |
3852 | current length of the selected resource.) | |
3853 | ||
3854 | When this status code is returned for a byte-range request, the | |
3855 | response SHOULD include a Content-Range entity-header field | |
3856 | specifying the current length of the selected resource (see section | |
3857 | 14.16). This response MUST NOT use the multipart/byteranges content- | |
3858 | type. | |
3859 | ||
3860 | ||
3861 | ||
3862 | ||
3863 | ||
3864 | ||
3865 | ||
3866 | Fielding, et al. Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 2616 HTTP/1.1 June 1999 | |
3869 | ||
3870 | ||
3871 | 10.4.18 417 Expectation Failed | |
3872 | ||
3873 | The expectation given in an Expect request-header field (see section | |
3874 | 14.20) could not be met by this server, or, if the server is a proxy, | |
3875 | the server has unambiguous evidence that the request could not be met | |
3876 | by the next-hop server. | |
3877 | ||
3878 | 10.5 Server Error 5xx | |
3879 | ||
3880 | Response status codes beginning with the digit "5" indicate cases in | |
3881 | which the server is aware that it has erred or is incapable of | |
3882 | performing the request. Except when responding to a HEAD request, the | |
3883 | server SHOULD include an entity containing an explanation of the | |
3884 | error situation, and whether it is a temporary or permanent | |
3885 | condition. User agents SHOULD display any included entity to the | |
3886 | user. These response codes are applicable to any request method. | |
3887 | ||
3888 | 10.5.1 500 Internal Server Error | |
3889 | ||
3890 | The server encountered an unexpected condition which prevented it | |
3891 | from fulfilling the request. | |
3892 | ||
3893 | 10.5.2 501 Not Implemented | |
3894 | ||
3895 | The server does not support the functionality required to fulfill the | |
3896 | request. This is the appropriate response when the server does not | |
3897 | recognize the request method and is not capable of supporting it for | |
3898 | any resource. | |
3899 | ||
3900 | 10.5.3 502 Bad Gateway | |
3901 | ||
3902 | The server, while acting as a gateway or proxy, received an invalid | |
3903 | response from the upstream server it accessed in attempting to | |
3904 | fulfill the request. | |
3905 | ||
3906 | 10.5.4 503 Service Unavailable | |
3907 | ||
3908 | The server is currently unable to handle the request due to a | |
3909 | temporary overloading or maintenance of the server. The implication | |
3910 | is that this is a temporary condition which will be alleviated after | |
3911 | some delay. If known, the length of the delay MAY be indicated in a | |
3912 | Retry-After header. If no Retry-After is given, the client SHOULD | |
3913 | handle the response as it would for a 500 response. | |
3914 | ||
3915 | Note: The existence of the 503 status code does not imply that a | |
3916 | server must use it when becoming overloaded. Some servers may wish | |
3917 | to simply refuse the connection. | |
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | Fielding, et al. Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 2616 HTTP/1.1 June 1999 | |
3925 | ||
3926 | ||
3927 | 10.5.5 504 Gateway Timeout | |
3928 | ||
3929 | The server, while acting as a gateway or proxy, did not receive a | |
3930 | timely response from the upstream server specified by the URI (e.g. | |
3931 | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed | |
3932 | to access in attempting to complete the request. | |
3933 | ||
3934 | Note: Note to implementors: some deployed proxies are known to | |
3935 | return 400 or 500 when DNS lookups time out. | |
3936 | ||
3937 | 10.5.6 505 HTTP Version Not Supported | |
3938 | ||
3939 | The server does not support, or refuses to support, the HTTP protocol | |
3940 | version that was used in the request message. The server is | |
3941 | indicating that it is unable or unwilling to complete the request | |
3942 | using the same major version as the client, as described in section | |
3943 | 3.1, other than with this error message. The response SHOULD contain | |
3944 | an entity describing why that version is not supported and what other | |
3945 | protocols are supported by that server. | |
3946 | ||
3947 | 11 Access Authentication | |
3948 | ||
3949 | HTTP provides several OPTIONAL challenge-response authentication | |
3950 | mechanisms which can be used by a server to challenge a client | |
3951 | request and by a client to provide authentication information. The | |
3952 | general framework for access authentication, and the specification of | |
3953 | "basic" and "digest" authentication, are specified in "HTTP | |
3954 | Authentication: Basic and Digest Access Authentication" [43]. This | |
3955 | specification adopts the definitions of "challenge" and "credentials" | |
3956 | from that specification. | |
3957 | ||
3958 | 12 Content Negotiation | |
3959 | ||
3960 | Most HTTP responses include an entity which contains information for | |
3961 | interpretation by a human user. Naturally, it is desirable to supply | |
3962 | the user with the "best available" entity corresponding to the | |
3963 | request. Unfortunately for servers and caches, not all users have the | |
3964 | same preferences for what is "best," and not all user agents are | |
3965 | equally capable of rendering all entity types. For that reason, HTTP | |
3966 | has provisions for several mechanisms for "content negotiation" -- | |
3967 | the process of selecting the best representation for a given response | |
3968 | when there are multiple representations available. | |
3969 | ||
3970 | Note: This is not called "format negotiation" because the | |
3971 | alternate representations may be of the same media type, but use | |
3972 | different capabilities of that type, be in different languages, | |
3973 | etc. | |
3974 | ||
3975 | ||
3976 | ||
3977 | ||
3978 | Fielding, et al. Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 2616 HTTP/1.1 June 1999 | |
3981 | ||
3982 | ||
3983 | Any response containing an entity-body MAY be subject to negotiation, | |
3984 | including error responses. | |
3985 | ||
3986 | There are two kinds of content negotiation which are possible in | |
3987 | HTTP: server-driven and agent-driven negotiation. These two kinds of | |
3988 | negotiation are orthogonal and thus may be used separately or in | |
3989 | combination. One method of combination, referred to as transparent | |
3990 | negotiation, occurs when a cache uses the agent-driven negotiation | |
3991 | information provided by the origin server in order to provide | |
3992 | server-driven negotiation for subsequent requests. | |
3993 | ||
3994 | 12.1 Server-driven Negotiation | |
3995 | ||
3996 | If the selection of the best representation for a response is made by | |
3997 | an algorithm located at the server, it is called server-driven | |
3998 | negotiation. Selection is based on the available representations of | |
3999 | the response (the dimensions over which it can vary; e.g. language, | |
4000 | content-coding, etc.) and the contents of particular header fields in | |
4001 | the request message or on other information pertaining to the request | |
4002 | (such as the network address of the client). | |
4003 | ||
4004 | Server-driven negotiation is advantageous when the algorithm for | |
4005 | selecting from among the available representations is difficult to | |
4006 | describe to the user agent, or when the server desires to send its | |
4007 | "best guess" to the client along with the first response (hoping to | |
4008 | avoid the round-trip delay of a subsequent request if the "best | |
4009 | guess" is good enough for the user). In order to improve the server's | |
4010 | guess, the user agent MAY include request header fields (Accept, | |
4011 | Accept-Language, Accept-Encoding, etc.) which describe its | |
4012 | preferences for such a response. | |
4013 | ||
4014 | Server-driven negotiation has disadvantages: | |
4015 | ||
4016 | 1. It is impossible for the server to accurately determine what | |
4017 | might be "best" for any given user, since that would require | |
4018 | complete knowledge of both the capabilities of the user agent | |
4019 | and the intended use for the response (e.g., does the user want | |
4020 | to view it on screen or print it on paper?). | |
4021 | ||
4022 | 2. Having the user agent describe its capabilities in every | |
4023 | request can be both very inefficient (given that only a small | |
4024 | percentage of responses have multiple representations) and a | |
4025 | potential violation of the user's privacy. | |
4026 | ||
4027 | 3. It complicates the implementation of an origin server and the | |
4028 | algorithms for generating responses to a request. | |
4029 | ||
4030 | ||
4031 | ||
4032 | ||
4033 | ||
4034 | Fielding, et al. Standards Track [Page 72] | |
4035 | \f | |
4036 | RFC 2616 HTTP/1.1 June 1999 | |
4037 | ||
4038 | ||
4039 | 4. It may limit a public cache's ability to use the same response | |
4040 | for multiple user's requests. | |
4041 | ||
4042 | HTTP/1.1 includes the following request-header fields for enabling | |
4043 | server-driven negotiation through description of user agent | |
4044 | capabilities and user preferences: Accept (section 14.1), Accept- | |
4045 | Charset (section 14.2), Accept-Encoding (section 14.3), Accept- | |
4046 | Language (section 14.4), and User-Agent (section 14.43). However, an | |
4047 | origin server is not limited to these dimensions and MAY vary the | |
4048 | response based on any aspect of the request, including information | |
4049 | outside the request-header fields or within extension header fields | |
4050 | not defined by this specification. | |
4051 | ||
4052 | The Vary header field can be used to express the parameters the | |
4053 | server uses to select a representation that is subject to server- | |
4054 | driven negotiation. See section 13.6 for use of the Vary header field | |
4055 | by caches and section 14.44 for use of the Vary header field by | |
4056 | servers. | |
4057 | ||
4058 | 12.2 Agent-driven Negotiation | |
4059 | ||
4060 | With agent-driven negotiation, selection of the best representation | |
4061 | for a response is performed by the user agent after receiving an | |
4062 | initial response from the origin server. Selection is based on a list | |
4063 | of the available representations of the response included within the | |
4064 | header fields or entity-body of the initial response, with each | |
4065 | representation identified by its own URI. Selection from among the | |
4066 | representations may be performed automatically (if the user agent is | |
4067 | capable of doing so) or manually by the user selecting from a | |
4068 | generated (possibly hypertext) menu. | |
4069 | ||
4070 | Agent-driven negotiation is advantageous when the response would vary | |
4071 | over commonly-used dimensions (such as type, language, or encoding), | |
4072 | when the origin server is unable to determine a user agent's | |
4073 | capabilities from examining the request, and generally when public | |
4074 | caches are used to distribute server load and reduce network usage. | |
4075 | ||
4076 | Agent-driven negotiation suffers from the disadvantage of needing a | |
4077 | second request to obtain the best alternate representation. This | |
4078 | second request is only efficient when caching is used. In addition, | |
4079 | this specification does not define any mechanism for supporting | |
4080 | automatic selection, though it also does not prevent any such | |
4081 | mechanism from being developed as an extension and used within | |
4082 | HTTP/1.1. | |
4083 | ||
4084 | ||
4085 | ||
4086 | ||
4087 | ||
4088 | ||
4089 | ||
4090 | Fielding, et al. Standards Track [Page 73] | |
4091 | \f | |
4092 | RFC 2616 HTTP/1.1 June 1999 | |
4093 | ||
4094 | ||
4095 | HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | |
4096 | status codes for enabling agent-driven negotiation when the server is | |
4097 | unwilling or unable to provide a varying response using server-driven | |
4098 | negotiation. | |
4099 | ||
4100 | 12.3 Transparent Negotiation | |
4101 | ||
4102 | Transparent negotiation is a combination of both server-driven and | |
4103 | agent-driven negotiation. When a cache is supplied with a form of the | |
4104 | list of available representations of the response (as in agent-driven | |
4105 | negotiation) and the dimensions of variance are completely understood | |
4106 | by the cache, then the cache becomes capable of performing server- | |
4107 | driven negotiation on behalf of the origin server for subsequent | |
4108 | requests on that resource. | |
4109 | ||
4110 | Transparent negotiation has the advantage of distributing the | |
4111 | negotiation work that would otherwise be required of the origin | |
4112 | server and also removing the second request delay of agent-driven | |
4113 | negotiation when the cache is able to correctly guess the right | |
4114 | response. | |
4115 | ||
4116 | This specification does not define any mechanism for transparent | |
4117 | negotiation, though it also does not prevent any such mechanism from | |
4118 | being developed as an extension that could be used within HTTP/1.1. | |
4119 | ||
4120 | 13 Caching in HTTP | |
4121 | ||
4122 | HTTP is typically used for distributed information systems, where | |
4123 | performance can be improved by the use of response caches. The | |
4124 | HTTP/1.1 protocol includes a number of elements intended to make | |
4125 | caching work as well as possible. Because these elements are | |
4126 | inextricable from other aspects of the protocol, and because they | |
4127 | interact with each other, it is useful to describe the basic caching | |
4128 | design of HTTP separately from the detailed descriptions of methods, | |
4129 | headers, response codes, etc. | |
4130 | ||
4131 | Caching would be useless if it did not significantly improve | |
4132 | performance. The goal of caching in HTTP/1.1 is to eliminate the need | |
4133 | to send requests in many cases, and to eliminate the need to send | |
4134 | full responses in many other cases. The former reduces the number of | |
4135 | network round-trips required for many operations; we use an | |
4136 | "expiration" mechanism for this purpose (see section 13.2). The | |
4137 | latter reduces network bandwidth requirements; we use a "validation" | |
4138 | mechanism for this purpose (see section 13.3). | |
4139 | ||
4140 | Requirements for performance, availability, and disconnected | |
4141 | operation require us to be able to relax the goal of semantic | |
4142 | transparency. The HTTP/1.1 protocol allows origin servers, caches, | |
4143 | ||
4144 | ||
4145 | ||
4146 | Fielding, et al. Standards Track [Page 74] | |
4147 | \f | |
4148 | RFC 2616 HTTP/1.1 June 1999 | |
4149 | ||
4150 | ||
4151 | and clients to explicitly reduce transparency when necessary. | |
4152 | However, because non-transparent operation may confuse non-expert | |
4153 | users, and might be incompatible with certain server applications | |
4154 | (such as those for ordering merchandise), the protocol requires that | |
4155 | transparency be relaxed | |
4156 | ||
4157 | - only by an explicit protocol-level request when relaxed by | |
4158 | client or origin server | |
4159 | ||
4160 | - only with an explicit warning to the end user when relaxed by | |
4161 | cache or client | |
4162 | ||
4163 | Therefore, the HTTP/1.1 protocol provides these important elements: | |
4164 | ||
4165 | 1. Protocol features that provide full semantic transparency when | |
4166 | this is required by all parties. | |
4167 | ||
4168 | 2. Protocol features that allow an origin server or user agent to | |
4169 | explicitly request and control non-transparent operation. | |
4170 | ||
4171 | 3. Protocol features that allow a cache to attach warnings to | |
4172 | responses that do not preserve the requested approximation of | |
4173 | semantic transparency. | |
4174 | ||
4175 | A basic principle is that it must be possible for the clients to | |
4176 | detect any potential relaxation of semantic transparency. | |
4177 | ||
4178 | Note: The server, cache, or client implementor might be faced with | |
4179 | design decisions not explicitly discussed in this specification. | |
4180 | If a decision might affect semantic transparency, the implementor | |
4181 | ought to err on the side of maintaining transparency unless a | |
4182 | careful and complete analysis shows significant benefits in | |
4183 | breaking transparency. | |
4184 | ||
4185 | 13.1.1 Cache Correctness | |
4186 | ||
4187 | A correct cache MUST respond to a request with the most up-to-date | |
4188 | response held by the cache that is appropriate to the request (see | |
4189 | sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | |
4190 | conditions: | |
4191 | ||
4192 | 1. It has been checked for equivalence with what the origin server | |
4193 | would have returned by revalidating the response with the | |
4194 | origin server (section 13.3); | |
4195 | ||
4196 | ||
4197 | ||
4198 | ||
4199 | ||
4200 | ||
4201 | ||
4202 | Fielding, et al. Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 2616 HTTP/1.1 June 1999 | |
4205 | ||
4206 | ||
4207 | 2. It is "fresh enough" (see section 13.2). In the default case, | |
4208 | this means it meets the least restrictive freshness requirement | |
4209 | of the client, origin server, and cache (see section 14.9); if | |
4210 | the origin server so specifies, it is the freshness requirement | |
4211 | of the origin server alone. | |
4212 | ||
4213 | If a stored response is not "fresh enough" by the most | |
4214 | restrictive freshness requirement of both the client and the | |
4215 | origin server, in carefully considered circumstances the cache | |
4216 | MAY still return the response with the appropriate Warning | |
4217 | header (see section 13.1.5 and 14.46), unless such a response | |
4218 | is prohibited (e.g., by a "no-store" cache-directive, or by a | |
4219 | "no-cache" cache-request-directive; see section 14.9). | |
4220 | ||
4221 | 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), | |
4222 | or error (4xx or 5xx) response message. | |
4223 | ||
4224 | If the cache can not communicate with the origin server, then a | |
4225 | correct cache SHOULD respond as above if the response can be | |
4226 | correctly served from the cache; if not it MUST return an error or | |
4227 | warning indicating that there was a communication failure. | |
4228 | ||
4229 | If a cache receives a response (either an entire response, or a 304 | |
4230 | (Not Modified) response) that it would normally forward to the | |
4231 | requesting client, and the received response is no longer fresh, the | |
4232 | cache SHOULD forward it to the requesting client without adding a new | |
4233 | Warning (but without removing any existing Warning headers). A cache | |
4234 | SHOULD NOT attempt to revalidate a response simply because that | |
4235 | response became stale in transit; this might lead to an infinite | |
4236 | loop. A user agent that receives a stale response without a Warning | |
4237 | MAY display a warning indication to the user. | |
4238 | ||
4239 | 13.1.2 Warnings | |
4240 | ||
4241 | Whenever a cache returns a response that is neither first-hand nor | |
4242 | "fresh enough" (in the sense of condition 2 in section 13.1.1), it | |
4243 | MUST attach a warning to that effect, using a Warning general-header. | |
4244 | The Warning header and the currently defined warnings are described | |
4245 | in section 14.46. The warning allows clients to take appropriate | |
4246 | action. | |
4247 | ||
4248 | Warnings MAY be used for other purposes, both cache-related and | |
4249 | otherwise. The use of a warning, rather than an error status code, | |
4250 | distinguish these responses from true failures. | |
4251 | ||
4252 | Warnings are assigned three digit warn-codes. The first digit | |
4253 | indicates whether the Warning MUST or MUST NOT be deleted from a | |
4254 | stored cache entry after a successful revalidation: | |
4255 | ||
4256 | ||
4257 | ||
4258 | Fielding, et al. Standards Track [Page 76] | |
4259 | \f | |
4260 | RFC 2616 HTTP/1.1 June 1999 | |
4261 | ||
4262 | ||
4263 | 1xx Warnings that describe the freshness or revalidation status of | |
4264 | the response, and so MUST be deleted after a successful | |
4265 | revalidation. 1XX warn-codes MAY be generated by a cache only when | |
4266 | validating a cached entry. It MUST NOT be generated by clients. | |
4267 | ||
4268 | 2xx Warnings that describe some aspect of the entity body or entity | |
4269 | headers that is not rectified by a revalidation (for example, a | |
4270 | lossy compression of the entity bodies) and which MUST NOT be | |
4271 | deleted after a successful revalidation. | |
4272 | ||
4273 | See section 14.46 for the definitions of the codes themselves. | |
4274 | ||
4275 | HTTP/1.0 caches will cache all Warnings in responses, without | |
4276 | deleting the ones in the first category. Warnings in responses that | |
4277 | are passed to HTTP/1.0 caches carry an extra warning-date field, | |
4278 | which prevents a future HTTP/1.1 recipient from believing an | |
4279 | erroneously cached Warning. | |
4280 | ||
4281 | Warnings also carry a warning text. The text MAY be in any | |
4282 | appropriate natural language (perhaps based on the client's Accept | |
4283 | headers), and include an OPTIONAL indication of what character set is | |
4284 | used. | |
4285 | ||
4286 | Multiple warnings MAY be attached to a response (either by the origin | |
4287 | server or by a cache), including multiple warnings with the same code | |
4288 | number. For example, a server might provide the same warning with | |
4289 | texts in both English and Basque. | |
4290 | ||
4291 | When multiple warnings are attached to a response, it might not be | |
4292 | practical or reasonable to display all of them to the user. This | |
4293 | version of HTTP does not specify strict priority rules for deciding | |
4294 | which warnings to display and in what order, but does suggest some | |
4295 | heuristics. | |
4296 | ||
4297 | 13.1.3 Cache-control Mechanisms | |
4298 | ||
4299 | The basic cache mechanisms in HTTP/1.1 (server-specified expiration | |
4300 | times and validators) are implicit directives to caches. In some | |
4301 | cases, a server or client might need to provide explicit directives | |
4302 | to the HTTP caches. We use the Cache-Control header for this purpose. | |
4303 | ||
4304 | The Cache-Control header allows a client or server to transmit a | |
4305 | variety of directives in either requests or responses. These | |
4306 | directives typically override the default caching algorithms. As a | |
4307 | general rule, if there is any apparent conflict between header | |
4308 | values, the most restrictive interpretation is applied (that is, the | |
4309 | one that is most likely to preserve semantic transparency). However, | |
4310 | ||
4311 | ||
4312 | ||
4313 | ||
4314 | Fielding, et al. Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 2616 HTTP/1.1 June 1999 | |
4317 | ||
4318 | ||
4319 | in some cases, cache-control directives are explicitly specified as | |
4320 | weakening the approximation of semantic transparency (for example, | |
4321 | "max-stale" or "public"). | |
4322 | ||
4323 | The cache-control directives are described in detail in section 14.9. | |
4324 | ||
4325 | 13.1.4 Explicit User Agent Warnings | |
4326 | ||
4327 | Many user agents make it possible for users to override the basic | |
4328 | caching mechanisms. For example, the user agent might allow the user | |
4329 | to specify that cached entities (even explicitly stale ones) are | |
4330 | never validated. Or the user agent might habitually add "Cache- | |
4331 | Control: max-stale=3600" to every request. The user agent SHOULD NOT | |
4332 | default to either non-transparent behavior, or behavior that results | |
4333 | in abnormally ineffective caching, but MAY be explicitly configured | |
4334 | to do so by an explicit action of the user. | |
4335 | ||
4336 | If the user has overridden the basic caching mechanisms, the user | |
4337 | agent SHOULD explicitly indicate to the user whenever this results in | |
4338 | the display of information that might not meet the server's | |
4339 | transparency requirements (in particular, if the displayed entity is | |
4340 | known to be stale). Since the protocol normally allows the user agent | |
4341 | to determine if responses are stale or not, this indication need only | |
4342 | be displayed when this actually happens. The indication need not be a | |
4343 | dialog box; it could be an icon (for example, a picture of a rotting | |
4344 | fish) or some other indicator. | |
4345 | ||
4346 | If the user has overridden the caching mechanisms in a way that would | |
4347 | abnormally reduce the effectiveness of caches, the user agent SHOULD | |
4348 | continually indicate this state to the user (for example, by a | |
4349 | display of a picture of currency in flames) so that the user does not | |
4350 | inadvertently consume excess resources or suffer from excessive | |
4351 | latency. | |
4352 | ||
4353 | 13.1.5 Exceptions to the Rules and Warnings | |
4354 | ||
4355 | In some cases, the operator of a cache MAY choose to configure it to | |
4356 | return stale responses even when not requested by clients. This | |
4357 | decision ought not be made lightly, but may be necessary for reasons | |
4358 | of availability or performance, especially when the cache is poorly | |
4359 | connected to the origin server. Whenever a cache returns a stale | |
4360 | response, it MUST mark it as such (using a Warning header) enabling | |
4361 | the client software to alert the user that there might be a potential | |
4362 | problem. | |
4363 | ||
4364 | ||
4365 | ||
4366 | ||
4367 | ||
4368 | ||
4369 | ||
4370 | Fielding, et al. Standards Track [Page 78] | |
4371 | \f | |
4372 | RFC 2616 HTTP/1.1 June 1999 | |
4373 | ||
4374 | ||
4375 | It also allows the user agent to take steps to obtain a first-hand or | |
4376 | fresh response. For this reason, a cache SHOULD NOT return a stale | |
4377 | response if the client explicitly requests a first-hand or fresh one, | |
4378 | unless it is impossible to comply for technical or policy reasons. | |
4379 | ||
4380 | 13.1.6 Client-controlled Behavior | |
4381 | ||
4382 | While the origin server (and to a lesser extent, intermediate caches, | |
4383 | by their contribution to the age of a response) are the primary | |
4384 | source of expiration information, in some cases the client might need | |
4385 | to control a cache's decision about whether to return a cached | |
4386 | response without validating it. Clients do this using several | |
4387 | directives of the Cache-Control header. | |
4388 | ||
4389 | A client's request MAY specify the maximum age it is willing to | |
4390 | accept of an unvalidated response; specifying a value of zero forces | |
4391 | the cache(s) to revalidate all responses. A client MAY also specify | |
4392 | the minimum time remaining before a response expires. Both of these | |
4393 | options increase constraints on the behavior of caches, and so cannot | |
4394 | further relax the cache's approximation of semantic transparency. | |
4395 | ||
4396 | A client MAY also specify that it will accept stale responses, up to | |
4397 | some maximum amount of staleness. This loosens the constraints on the | |
4398 | caches, and so might violate the origin server's specified | |
4399 | constraints on semantic transparency, but might be necessary to | |
4400 | support disconnected operation, or high availability in the face of | |
4401 | poor connectivity. | |
4402 | ||
4403 | 13.2 Expiration Model | |
4404 | ||
4405 | 13.2.1 Server-Specified Expiration | |
4406 | ||
4407 | HTTP caching works best when caches can entirely avoid making | |
4408 | requests to the origin server. The primary mechanism for avoiding | |
4409 | requests is for an origin server to provide an explicit expiration | |
4410 | time in the future, indicating that a response MAY be used to satisfy | |
4411 | subsequent requests. In other words, a cache can return a fresh | |
4412 | response without first contacting the server. | |
4413 | ||
4414 | Our expectation is that servers will assign future explicit | |
4415 | expiration times to responses in the belief that the entity is not | |
4416 | likely to change, in a semantically significant way, before the | |
4417 | expiration time is reached. This normally preserves semantic | |
4418 | transparency, as long as the server's expiration times are carefully | |
4419 | chosen. | |
4420 | ||
4421 | ||
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | Fielding, et al. Standards Track [Page 79] | |
4427 | \f | |
4428 | RFC 2616 HTTP/1.1 June 1999 | |
4429 | ||
4430 | ||
4431 | The expiration mechanism applies only to responses taken from a cache | |
4432 | and not to first-hand responses forwarded immediately to the | |
4433 | requesting client. | |
4434 | ||
4435 | If an origin server wishes to force a semantically transparent cache | |
4436 | to validate every request, it MAY assign an explicit expiration time | |
4437 | in the past. This means that the response is always stale, and so the | |
4438 | cache SHOULD validate it before using it for subsequent requests. See | |
4439 | section 14.9.4 for a more restrictive way to force revalidation. | |
4440 | ||
4441 | If an origin server wishes to force any HTTP/1.1 cache, no matter how | |
4442 | it is configured, to validate every request, it SHOULD use the "must- | |
4443 | revalidate" cache-control directive (see section 14.9). | |
4444 | ||
4445 | Servers specify explicit expiration times using either the Expires | |
4446 | header, or the max-age directive of the Cache-Control header. | |
4447 | ||
4448 | An expiration time cannot be used to force a user agent to refresh | |
4449 | its display or reload a resource; its semantics apply only to caching | |
4450 | mechanisms, and such mechanisms need only check a resource's | |
4451 | expiration status when a new request for that resource is initiated. | |
4452 | See section 13.13 for an explanation of the difference between caches | |
4453 | and history mechanisms. | |
4454 | ||
4455 | 13.2.2 Heuristic Expiration | |
4456 | ||
4457 | Since origin servers do not always provide explicit expiration times, | |
4458 | HTTP caches typically assign heuristic expiration times, employing | |
4459 | algorithms that use other header values (such as the Last-Modified | |
4460 | time) to estimate a plausible expiration time. The HTTP/1.1 | |
4461 | specification does not provide specific algorithms, but does impose | |
4462 | worst-case constraints on their results. Since heuristic expiration | |
4463 | times might compromise semantic transparency, they ought to used | |
4464 | cautiously, and we encourage origin servers to provide explicit | |
4465 | expiration times as much as possible. | |
4466 | ||
4467 | 13.2.3 Age Calculations | |
4468 | ||
4469 | In order to know if a cached entry is fresh, a cache needs to know if | |
4470 | its age exceeds its freshness lifetime. We discuss how to calculate | |
4471 | the latter in section 13.2.4; this section describes how to calculate | |
4472 | the age of a response or cache entry. | |
4473 | ||
4474 | In this discussion, we use the term "now" to mean "the current value | |
4475 | of the clock at the host performing the calculation." Hosts that use | |
4476 | HTTP, but especially hosts running origin servers and caches, SHOULD | |
4477 | use NTP [28] or some similar protocol to synchronize their clocks to | |
4478 | a globally accurate time standard. | |
4479 | ||
4480 | ||
4481 | ||
4482 | Fielding, et al. Standards Track [Page 80] | |
4483 | \f | |
4484 | RFC 2616 HTTP/1.1 June 1999 | |
4485 | ||
4486 | ||
4487 | HTTP/1.1 requires origin servers to send a Date header, if possible, | |
4488 | with every response, giving the time at which the response was | |
4489 | generated (see section 14.18). We use the term "date_value" to denote | |
4490 | the value of the Date header, in a form appropriate for arithmetic | |
4491 | operations. | |
4492 | ||
4493 | HTTP/1.1 uses the Age response-header to convey the estimated age of | |
4494 | the response message when obtained from a cache. The Age field value | |
4495 | is the cache's estimate of the amount of time since the response was | |
4496 | generated or revalidated by the origin server. | |
4497 | ||
4498 | In essence, the Age value is the sum of the time that the response | |
4499 | has been resident in each of the caches along the path from the | |
4500 | origin server, plus the amount of time it has been in transit along | |
4501 | network paths. | |
4502 | ||
4503 | We use the term "age_value" to denote the value of the Age header, in | |
4504 | a form appropriate for arithmetic operations. | |
4505 | ||
4506 | A response's age can be calculated in two entirely independent ways: | |
4507 | ||
4508 | 1. now minus date_value, if the local clock is reasonably well | |
4509 | synchronized to the origin server's clock. If the result is | |
4510 | negative, the result is replaced by zero. | |
4511 | ||
4512 | 2. age_value, if all of the caches along the response path | |
4513 | implement HTTP/1.1. | |
4514 | ||
4515 | Given that we have two independent ways to compute the age of a | |
4516 | response when it is received, we can combine these as | |
4517 | ||
4518 | corrected_received_age = max(now - date_value, age_value) | |
4519 | ||
4520 | and as long as we have either nearly synchronized clocks or all- | |
4521 | HTTP/1.1 paths, one gets a reliable (conservative) result. | |
4522 | ||
4523 | Because of network-imposed delays, some significant interval might | |
4524 | pass between the time that a server generates a response and the time | |
4525 | it is received at the next outbound cache or client. If uncorrected, | |
4526 | this delay could result in improperly low ages. | |
4527 | ||
4528 | Because the request that resulted in the returned Age value must have | |
4529 | been initiated prior to that Age value's generation, we can correct | |
4530 | for delays imposed by the network by recording the time at which the | |
4531 | request was initiated. Then, when an Age value is received, it MUST | |
4532 | be interpreted relative to the time the request was initiated, not | |
4533 | ||
4534 | ||
4535 | ||
4536 | ||
4537 | ||
4538 | Fielding, et al. Standards Track [Page 81] | |
4539 | \f | |
4540 | RFC 2616 HTTP/1.1 June 1999 | |
4541 | ||
4542 | ||
4543 | the time that the response was received. This algorithm results in | |
4544 | conservative behavior no matter how much delay is experienced. So, we | |
4545 | compute: | |
4546 | ||
4547 | corrected_initial_age = corrected_received_age | |
4548 | + (now - request_time) | |
4549 | ||
4550 | where "request_time" is the time (according to the local clock) when | |
4551 | the request that elicited this response was sent. | |
4552 | ||
4553 | Summary of age calculation algorithm, when a cache receives a | |
4554 | response: | |
4555 | ||
4556 | /* | |
4557 | * age_value | |
4558 | * is the value of Age: header received by the cache with | |
4559 | * this response. | |
4560 | * date_value | |
4561 | * is the value of the origin server's Date: header | |
4562 | * request_time | |
4563 | * is the (local) time when the cache made the request | |
4564 | * that resulted in this cached response | |
4565 | * response_time | |
4566 | * is the (local) time when the cache received the | |
4567 | * response | |
4568 | * now | |
4569 | * is the current (local) time | |
4570 | */ | |
4571 | ||
4572 | apparent_age = max(0, response_time - date_value); | |
4573 | corrected_received_age = max(apparent_age, age_value); | |
4574 | response_delay = response_time - request_time; | |
4575 | corrected_initial_age = corrected_received_age + response_delay; | |
4576 | resident_time = now - response_time; | |
4577 | current_age = corrected_initial_age + resident_time; | |
4578 | ||
4579 | The current_age of a cache entry is calculated by adding the amount | |
4580 | of time (in seconds) since the cache entry was last validated by the | |
4581 | origin server to the corrected_initial_age. When a response is | |
4582 | generated from a cache entry, the cache MUST include a single Age | |
4583 | header field in the response with a value equal to the cache entry's | |
4584 | current_age. | |
4585 | ||
4586 | The presence of an Age header field in a response implies that a | |
4587 | response is not first-hand. However, the converse is not true, since | |
4588 | the lack of an Age header field in a response does not imply that the | |
4589 | ||
4590 | ||
4591 | ||
4592 | ||
4593 | ||
4594 | Fielding, et al. Standards Track [Page 82] | |
4595 | \f | |
4596 | RFC 2616 HTTP/1.1 June 1999 | |
4597 | ||
4598 | ||
4599 | response is first-hand unless all caches along the request path are | |
4600 | compliant with HTTP/1.1 (i.e., older HTTP caches did not implement | |
4601 | the Age header field). | |
4602 | ||
4603 | 13.2.4 Expiration Calculations | |
4604 | ||
4605 | In order to decide whether a response is fresh or stale, we need to | |
4606 | compare its freshness lifetime to its age. The age is calculated as | |
4607 | described in section 13.2.3; this section describes how to calculate | |
4608 | the freshness lifetime, and to determine if a response has expired. | |
4609 | In the discussion below, the values can be represented in any form | |
4610 | appropriate for arithmetic operations. | |
4611 | ||
4612 | We use the term "expires_value" to denote the value of the Expires | |
4613 | header. We use the term "max_age_value" to denote an appropriate | |
4614 | value of the number of seconds carried by the "max-age" directive of | |
4615 | the Cache-Control header in a response (see section 14.9.3). | |
4616 | ||
4617 | The max-age directive takes priority over Expires, so if max-age is | |
4618 | present in a response, the calculation is simply: | |
4619 | ||
4620 | freshness_lifetime = max_age_value | |
4621 | ||
4622 | Otherwise, if Expires is present in the response, the calculation is: | |
4623 | ||
4624 | freshness_lifetime = expires_value - date_value | |
4625 | ||
4626 | Note that neither of these calculations is vulnerable to clock skew, | |
4627 | since all of the information comes from the origin server. | |
4628 | ||
4629 | If none of Expires, Cache-Control: max-age, or Cache-Control: s- | |
4630 | maxage (see section 14.9.3) appears in the response, and the response | |
4631 | does not include other restrictions on caching, the cache MAY compute | |
4632 | a freshness lifetime using a heuristic. The cache MUST attach Warning | |
4633 | 113 to any response whose age is more than 24 hours if such warning | |
4634 | has not already been added. | |
4635 | ||
4636 | Also, if the response does have a Last-Modified time, the heuristic | |
4637 | expiration value SHOULD be no more than some fraction of the interval | |
4638 | since that time. A typical setting of this fraction might be 10%. | |
4639 | ||
4640 | The calculation to determine if a response has expired is quite | |
4641 | simple: | |
4642 | ||
4643 | response_is_fresh = (freshness_lifetime > current_age) | |
4644 | ||
4645 | ||
4646 | ||
4647 | ||
4648 | ||
4649 | ||
4650 | Fielding, et al. Standards Track [Page 83] | |
4651 | \f | |
4652 | RFC 2616 HTTP/1.1 June 1999 | |
4653 | ||
4654 | ||
4655 | 13.2.5 Disambiguating Expiration Values | |
4656 | ||
4657 | Because expiration values are assigned optimistically, it is possible | |
4658 | for two caches to contain fresh values for the same resource that are | |
4659 | different. | |
4660 | ||
4661 | If a client performing a retrieval receives a non-first-hand response | |
4662 | for a request that was already fresh in its own cache, and the Date | |
4663 | header in its existing cache entry is newer than the Date on the new | |
4664 | response, then the client MAY ignore the response. If so, it MAY | |
4665 | retry the request with a "Cache-Control: max-age=0" directive (see | |
4666 | section 14.9), to force a check with the origin server. | |
4667 | ||
4668 | If a cache has two fresh responses for the same representation with | |
4669 | different validators, it MUST use the one with the more recent Date | |
4670 | header. This situation might arise because the cache is pooling | |
4671 | responses from other caches, or because a client has asked for a | |
4672 | reload or a revalidation of an apparently fresh cache entry. | |
4673 | ||
4674 | 13.2.6 Disambiguating Multiple Responses | |
4675 | ||
4676 | Because a client might be receiving responses via multiple paths, so | |
4677 | that some responses flow through one set of caches and other | |
4678 | responses flow through a different set of caches, a client might | |
4679 | receive responses in an order different from that in which the origin | |
4680 | server sent them. We would like the client to use the most recently | |
4681 | generated response, even if older responses are still apparently | |
4682 | fresh. | |
4683 | ||
4684 | Neither the entity tag nor the expiration value can impose an | |
4685 | ordering on responses, since it is possible that a later response | |
4686 | intentionally carries an earlier expiration time. The Date values are | |
4687 | ordered to a granularity of one second. | |
4688 | ||
4689 | When a client tries to revalidate a cache entry, and the response it | |
4690 | receives contains a Date header that appears to be older than the one | |
4691 | for the existing entry, then the client SHOULD repeat the request | |
4692 | unconditionally, and include | |
4693 | ||
4694 | Cache-Control: max-age=0 | |
4695 | ||
4696 | to force any intermediate caches to validate their copies directly | |
4697 | with the origin server, or | |
4698 | ||
4699 | Cache-Control: no-cache | |
4700 | ||
4701 | to force any intermediate caches to obtain a new copy from the origin | |
4702 | server. | |
4703 | ||
4704 | ||
4705 | ||
4706 | Fielding, et al. Standards Track [Page 84] | |
4707 | \f | |
4708 | RFC 2616 HTTP/1.1 June 1999 | |
4709 | ||
4710 | ||
4711 | If the Date values are equal, then the client MAY use either response | |
4712 | (or MAY, if it is being extremely prudent, request a new response). | |
4713 | Servers MUST NOT depend on clients being able to choose | |
4714 | deterministically between responses generated during the same second, | |
4715 | if their expiration times overlap. | |
4716 | ||
4717 | 13.3 Validation Model | |
4718 | ||
4719 | When a cache has a stale entry that it would like to use as a | |
4720 | response to a client's request, it first has to check with the origin | |
4721 | server (or possibly an intermediate cache with a fresh response) to | |
4722 | see if its cached entry is still usable. We call this "validating" | |
4723 | the cache entry. Since we do not want to have to pay the overhead of | |
4724 | retransmitting the full response if the cached entry is good, and we | |
4725 | do not want to pay the overhead of an extra round trip if the cached | |
4726 | entry is invalid, the HTTP/1.1 protocol supports the use of | |
4727 | conditional methods. | |
4728 | ||
4729 | The key protocol features for supporting conditional methods are | |
4730 | those concerned with "cache validators." When an origin server | |
4731 | generates a full response, it attaches some sort of validator to it, | |
4732 | which is kept with the cache entry. When a client (user agent or | |
4733 | proxy cache) makes a conditional request for a resource for which it | |
4734 | has a cache entry, it includes the associated validator in the | |
4735 | request. | |
4736 | ||
4737 | The server then checks that validator against the current validator | |
4738 | for the entity, and, if they match (see section 13.3.3), it responds | |
4739 | with a special status code (usually, 304 (Not Modified)) and no | |
4740 | entity-body. Otherwise, it returns a full response (including | |
4741 | entity-body). Thus, we avoid transmitting the full response if the | |
4742 | validator matches, and we avoid an extra round trip if it does not | |
4743 | match. | |
4744 | ||
4745 | In HTTP/1.1, a conditional request looks exactly the same as a normal | |
4746 | request for the same resource, except that it carries a special | |
4747 | header (which includes the validator) that implicitly turns the | |
4748 | method (usually, GET) into a conditional. | |
4749 | ||
4750 | The protocol includes both positive and negative senses of cache- | |
4751 | validating conditions. That is, it is possible to request either that | |
4752 | a method be performed if and only if a validator matches or if and | |
4753 | only if no validators match. | |
4754 | ||
4755 | ||
4756 | ||
4757 | ||
4758 | ||
4759 | ||
4760 | ||
4761 | ||
4762 | Fielding, et al. Standards Track [Page 85] | |
4763 | \f | |
4764 | RFC 2616 HTTP/1.1 June 1999 | |
4765 | ||
4766 | ||
4767 | Note: a response that lacks a validator may still be cached, and | |
4768 | served from cache until it expires, unless this is explicitly | |
4769 | prohibited by a cache-control directive. However, a cache cannot | |
4770 | do a conditional retrieval if it does not have a validator for the | |
4771 | entity, which means it will not be refreshable after it expires. | |
4772 | ||
4773 | 13.3.1 Last-Modified Dates | |
4774 | ||
4775 | The Last-Modified entity-header field value is often used as a cache | |
4776 | validator. In simple terms, a cache entry is considered to be valid | |
4777 | if the entity has not been modified since the Last-Modified value. | |
4778 | ||
4779 | 13.3.2 Entity Tag Cache Validators | |
4780 | ||
4781 | The ETag response-header field value, an entity tag, provides for an | |
4782 | "opaque" cache validator. This might allow more reliable validation | |
4783 | in situations where it is inconvenient to store modification dates, | |
4784 | where the one-second resolution of HTTP date values is not | |
4785 | sufficient, or where the origin server wishes to avoid certain | |
4786 | paradoxes that might arise from the use of modification dates. | |
4787 | ||
4788 | Entity Tags are described in section 3.11. The headers used with | |
4789 | entity tags are described in sections 14.19, 14.24, 14.26 and 14.44. | |
4790 | ||
4791 | 13.3.3 Weak and Strong Validators | |
4792 | ||
4793 | Since both origin servers and caches will compare two validators to | |
4794 | decide if they represent the same or different entities, one normally | |
4795 | would expect that if the entity (the entity-body or any entity- | |
4796 | headers) changes in any way, then the associated validator would | |
4797 | change as well. If this is true, then we call this validator a | |
4798 | "strong validator." | |
4799 | ||
4800 | However, there might be cases when a server prefers to change the | |
4801 | validator only on semantically significant changes, and not when | |
4802 | insignificant aspects of the entity change. A validator that does not | |
4803 | always change when the resource changes is a "weak validator." | |
4804 | ||
4805 | Entity tags are normally "strong validators," but the protocol | |
4806 | provides a mechanism to tag an entity tag as "weak." One can think of | |
4807 | a strong validator as one that changes whenever the bits of an entity | |
4808 | changes, while a weak value changes whenever the meaning of an entity | |
4809 | changes. Alternatively, one can think of a strong validator as part | |
4810 | of an identifier for a specific entity, while a weak validator is | |
4811 | part of an identifier for a set of semantically equivalent entities. | |
4812 | ||
4813 | Note: One example of a strong validator is an integer that is | |
4814 | incremented in stable storage every time an entity is changed. | |
4815 | ||
4816 | ||
4817 | ||
4818 | Fielding, et al. Standards Track [Page 86] | |
4819 | \f | |
4820 | RFC 2616 HTTP/1.1 June 1999 | |
4821 | ||
4822 | ||
4823 | An entity's modification time, if represented with one-second | |
4824 | resolution, could be a weak validator, since it is possible that | |
4825 | the resource might be modified twice during a single second. | |
4826 | ||
4827 | Support for weak validators is optional. However, weak validators | |
4828 | allow for more efficient caching of equivalent objects; for | |
4829 | example, a hit counter on a site is probably good enough if it is | |
4830 | updated every few days or weeks, and any value during that period | |
4831 | is likely "good enough" to be equivalent. | |
4832 | ||
4833 | A "use" of a validator is either when a client generates a request | |
4834 | and includes the validator in a validating header field, or when a | |
4835 | server compares two validators. | |
4836 | ||
4837 | Strong validators are usable in any context. Weak validators are only | |
4838 | usable in contexts that do not depend on exact equality of an entity. | |
4839 | For example, either kind is usable for a conditional GET of a full | |
4840 | entity. However, only a strong validator is usable for a sub-range | |
4841 | retrieval, since otherwise the client might end up with an internally | |
4842 | inconsistent entity. | |
4843 | ||
4844 | Clients MAY issue simple (non-subrange) GET requests with either weak | |
4845 | validators or strong validators. Clients MUST NOT use weak validators | |
4846 | in other forms of request. | |
4847 | ||
4848 | The only function that the HTTP/1.1 protocol defines on validators is | |
4849 | comparison. There are two validator comparison functions, depending | |
4850 | on whether the comparison context allows the use of weak validators | |
4851 | or not: | |
4852 | ||
4853 | - The strong comparison function: in order to be considered equal, | |
4854 | both validators MUST be identical in every way, and both MUST | |
4855 | NOT be weak. | |
4856 | ||
4857 | - The weak comparison function: in order to be considered equal, | |
4858 | both validators MUST be identical in every way, but either or | |
4859 | both of them MAY be tagged as "weak" without affecting the | |
4860 | result. | |
4861 | ||
4862 | An entity tag is strong unless it is explicitly tagged as weak. | |
4863 | Section 3.11 gives the syntax for entity tags. | |
4864 | ||
4865 | A Last-Modified time, when used as a validator in a request, is | |
4866 | implicitly weak unless it is possible to deduce that it is strong, | |
4867 | using the following rules: | |
4868 | ||
4869 | - The validator is being compared by an origin server to the | |
4870 | actual current validator for the entity and, | |
4871 | ||
4872 | ||
4873 | ||
4874 | Fielding, et al. Standards Track [Page 87] | |
4875 | \f | |
4876 | RFC 2616 HTTP/1.1 June 1999 | |
4877 | ||
4878 | ||
4879 | - That origin server reliably knows that the associated entity did | |
4880 | not change twice during the second covered by the presented | |
4881 | validator. | |
4882 | ||
4883 | or | |
4884 | ||
4885 | - The validator is about to be used by a client in an If- | |
4886 | Modified-Since or If-Unmodified-Since header, because the client | |
4887 | has a cache entry for the associated entity, and | |
4888 | ||
4889 | - That cache entry includes a Date value, which gives the time | |
4890 | when the origin server sent the original response, and | |
4891 | ||
4892 | - The presented Last-Modified time is at least 60 seconds before | |
4893 | the Date value. | |
4894 | ||
4895 | or | |
4896 | ||
4897 | - The validator is being compared by an intermediate cache to the | |
4898 | validator stored in its cache entry for the entity, and | |
4899 | ||
4900 | - That cache entry includes a Date value, which gives the time | |
4901 | when the origin server sent the original response, and | |
4902 | ||
4903 | - The presented Last-Modified time is at least 60 seconds before | |
4904 | the Date value. | |
4905 | ||
4906 | This method relies on the fact that if two different responses were | |
4907 | sent by the origin server during the same second, but both had the | |
4908 | same Last-Modified time, then at least one of those responses would | |
4909 | have a Date value equal to its Last-Modified time. The arbitrary 60- | |
4910 | second limit guards against the possibility that the Date and Last- | |
4911 | Modified values are generated from different clocks, or at somewhat | |
4912 | different times during the preparation of the response. An | |
4913 | implementation MAY use a value larger than 60 seconds, if it is | |
4914 | believed that 60 seconds is too short. | |
4915 | ||
4916 | If a client wishes to perform a sub-range retrieval on a value for | |
4917 | which it has only a Last-Modified time and no opaque validator, it | |
4918 | MAY do this only if the Last-Modified time is strong in the sense | |
4919 | described here. | |
4920 | ||
4921 | A cache or origin server receiving a conditional request, other than | |
4922 | a full-body GET request, MUST use the strong comparison function to | |
4923 | evaluate the condition. | |
4924 | ||
4925 | These rules allow HTTP/1.1 caches and clients to safely perform sub- | |
4926 | range retrievals on values that have been obtained from HTTP/1.0 | |
4927 | ||
4928 | ||
4929 | ||
4930 | Fielding, et al. Standards Track [Page 88] | |
4931 | \f | |
4932 | RFC 2616 HTTP/1.1 June 1999 | |
4933 | ||
4934 | ||
4935 | servers. | |
4936 | ||
4937 | 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates | |
4938 | ||
4939 | We adopt a set of rules and recommendations for origin servers, | |
4940 | clients, and caches regarding when various validator types ought to | |
4941 | be used, and for what purposes. | |
4942 | ||
4943 | HTTP/1.1 origin servers: | |
4944 | ||
4945 | - SHOULD send an entity tag validator unless it is not feasible to | |
4946 | generate one. | |
4947 | ||
4948 | - MAY send a weak entity tag instead of a strong entity tag, if | |
4949 | performance considerations support the use of weak entity tags, | |
4950 | or if it is unfeasible to send a strong entity tag. | |
4951 | ||
4952 | - SHOULD send a Last-Modified value if it is feasible to send one, | |
4953 | unless the risk of a breakdown in semantic transparency that | |
4954 | could result from using this date in an If-Modified-Since header | |
4955 | would lead to serious problems. | |
4956 | ||
4957 | In other words, the preferred behavior for an HTTP/1.1 origin server | |
4958 | is to send both a strong entity tag and a Last-Modified value. | |
4959 | ||
4960 | In order to be legal, a strong entity tag MUST change whenever the | |
4961 | associated entity value changes in any way. A weak entity tag SHOULD | |
4962 | change whenever the associated entity changes in a semantically | |
4963 | significant way. | |
4964 | ||
4965 | Note: in order to provide semantically transparent caching, an | |
4966 | origin server must avoid reusing a specific strong entity tag | |
4967 | value for two different entities, or reusing a specific weak | |
4968 | entity tag value for two semantically different entities. Cache | |
4969 | entries might persist for arbitrarily long periods, regardless of | |
4970 | expiration times, so it might be inappropriate to expect that a | |
4971 | cache will never again attempt to validate an entry using a | |
4972 | validator that it obtained at some point in the past. | |
4973 | ||
4974 | HTTP/1.1 clients: | |
4975 | ||
4976 | - If an entity tag has been provided by the origin server, MUST | |
4977 | use that entity tag in any cache-conditional request (using If- | |
4978 | Match or If-None-Match). | |
4979 | ||
4980 | - If only a Last-Modified value has been provided by the origin | |
4981 | server, SHOULD use that value in non-subrange cache-conditional | |
4982 | requests (using If-Modified-Since). | |
4983 | ||
4984 | ||
4985 | ||
4986 | Fielding, et al. Standards Track [Page 89] | |
4987 | \f | |
4988 | RFC 2616 HTTP/1.1 June 1999 | |
4989 | ||
4990 | ||
4991 | - If only a Last-Modified value has been provided by an HTTP/1.0 | |
4992 | origin server, MAY use that value in subrange cache-conditional | |
4993 | requests (using If-Unmodified-Since:). The user agent SHOULD | |
4994 | provide a way to disable this, in case of difficulty. | |
4995 | ||
4996 | - If both an entity tag and a Last-Modified value have been | |
4997 | provided by the origin server, SHOULD use both validators in | |
4998 | cache-conditional requests. This allows both HTTP/1.0 and | |
4999 | HTTP/1.1 caches to respond appropriately. | |
5000 | ||
5001 | An HTTP/1.1 origin server, upon receiving a conditional request that | |
5002 | includes both a Last-Modified date (e.g., in an If-Modified-Since or | |
5003 | If-Unmodified-Since header field) and one or more entity tags (e.g., | |
5004 | in an If-Match, If-None-Match, or If-Range header field) as cache | |
5005 | validators, MUST NOT return a response status of 304 (Not Modified) | |
5006 | unless doing so is consistent with all of the conditional header | |
5007 | fields in the request. | |
5008 | ||
5009 | An HTTP/1.1 caching proxy, upon receiving a conditional request that | |
5010 | includes both a Last-Modified date and one or more entity tags as | |
5011 | cache validators, MUST NOT return a locally cached response to the | |
5012 | client unless that cached response is consistent with all of the | |
5013 | conditional header fields in the request. | |
5014 | ||
5015 | Note: The general principle behind these rules is that HTTP/1.1 | |
5016 | servers and clients should transmit as much non-redundant | |
5017 | information as is available in their responses and requests. | |
5018 | HTTP/1.1 systems receiving this information will make the most | |
5019 | conservative assumptions about the validators they receive. | |
5020 | ||
5021 | HTTP/1.0 clients and caches will ignore entity tags. Generally, | |
5022 | last-modified values received or used by these systems will | |
5023 | support transparent and efficient caching, and so HTTP/1.1 origin | |
5024 | servers should provide Last-Modified values. In those rare cases | |
5025 | where the use of a Last-Modified value as a validator by an | |
5026 | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 | |
5027 | origin servers should not provide one. | |
5028 | ||
5029 | 13.3.5 Non-validating Conditionals | |
5030 | ||
5031 | The principle behind entity tags is that only the service author | |
5032 | knows the semantics of a resource well enough to select an | |
5033 | appropriate cache validation mechanism, and the specification of any | |
5034 | validator comparison function more complex than byte-equality would | |
5035 | open up a can of worms. Thus, comparisons of any other headers | |
5036 | (except Last-Modified, for compatibility with HTTP/1.0) are never | |
5037 | used for purposes of validating a cache entry. | |
5038 | ||
5039 | ||
5040 | ||
5041 | ||
5042 | Fielding, et al. Standards Track [Page 90] | |
5043 | \f | |
5044 | RFC 2616 HTTP/1.1 June 1999 | |
5045 | ||
5046 | ||
5047 | 13.4 Response Cacheability | |
5048 | ||
5049 | Unless specifically constrained by a cache-control (section 14.9) | |
5050 | directive, a caching system MAY always store a successful response | |
5051 | (see section 13.8) as a cache entry, MAY return it without validation | |
5052 | if it is fresh, and MAY return it after successful validation. If | |
5053 | there is neither a cache validator nor an explicit expiration time | |
5054 | associated with a response, we do not expect it to be cached, but | |
5055 | certain caches MAY violate this expectation (for example, when little | |
5056 | or no network connectivity is available). A client can usually detect | |
5057 | that such a response was taken from a cache by comparing the Date | |
5058 | header to the current time. | |
5059 | ||
5060 | Note: some HTTP/1.0 caches are known to violate this expectation | |
5061 | without providing any Warning. | |
5062 | ||
5063 | However, in some cases it might be inappropriate for a cache to | |
5064 | retain an entity, or to return it in response to a subsequent | |
5065 | request. This might be because absolute semantic transparency is | |
5066 | deemed necessary by the service author, or because of security or | |
5067 | privacy considerations. Certain cache-control directives are | |
5068 | therefore provided so that the server can indicate that certain | |
5069 | resource entities, or portions thereof, are not to be cached | |
5070 | regardless of other considerations. | |
5071 | ||
5072 | Note that section 14.8 normally prevents a shared cache from saving | |
5073 | and returning a response to a previous request if that request | |
5074 | included an Authorization header. | |
5075 | ||
5076 | A response received with a status code of 200, 203, 206, 300, 301 or | |
5077 | 410 MAY be stored by a cache and used in reply to a subsequent | |
5078 | request, subject to the expiration mechanism, unless a cache-control | |
5079 | directive prohibits caching. However, a cache that does not support | |
5080 | the Range and Content-Range headers MUST NOT cache 206 (Partial | |
5081 | Content) responses. | |
5082 | ||
5083 | A response received with any other status code (e.g. status codes 302 | |
5084 | and 307) MUST NOT be returned in a reply to a subsequent request | |
5085 | unless there are cache-control directives or another header(s) that | |
5086 | explicitly allow it. For example, these include the following: an | |
5087 | Expires header (section 14.21); a "max-age", "s-maxage", "must- | |
5088 | revalidate", "proxy-revalidate", "public" or "private" cache-control | |
5089 | directive (section 14.9). | |
5090 | ||
5091 | ||
5092 | ||
5093 | ||
5094 | ||
5095 | ||
5096 | ||
5097 | ||
5098 | Fielding, et al. Standards Track [Page 91] | |
5099 | \f | |
5100 | RFC 2616 HTTP/1.1 June 1999 | |
5101 | ||
5102 | ||
5103 | 13.5 Constructing Responses From Caches | |
5104 | ||
5105 | The purpose of an HTTP cache is to store information received in | |
5106 | response to requests for use in responding to future requests. In | |
5107 | many cases, a cache simply returns the appropriate parts of a | |
5108 | response to the requester. However, if the cache holds a cache entry | |
5109 | based on a previous response, it might have to combine parts of a new | |
5110 | response with what is held in the cache entry. | |
5111 | ||
5112 | 13.5.1 End-to-end and Hop-by-hop Headers | |
5113 | ||
5114 | For the purpose of defining the behavior of caches and non-caching | |
5115 | proxies, we divide HTTP headers into two categories: | |
5116 | ||
5117 | - End-to-end headers, which are transmitted to the ultimate | |
5118 | recipient of a request or response. End-to-end headers in | |
5119 | responses MUST be stored as part of a cache entry and MUST be | |
5120 | transmitted in any response formed from a cache entry. | |
5121 | ||
5122 | - Hop-by-hop headers, which are meaningful only for a single | |
5123 | transport-level connection, and are not stored by caches or | |
5124 | forwarded by proxies. | |
5125 | ||
5126 | The following HTTP/1.1 headers are hop-by-hop headers: | |
5127 | ||
5128 | - Connection | |
5129 | - Keep-Alive | |
5130 | - Proxy-Authenticate | |
5131 | - Proxy-Authorization | |
5132 | - TE | |
5133 | - Trailers | |
5134 | - Transfer-Encoding | |
5135 | - Upgrade | |
5136 | ||
5137 | All other headers defined by HTTP/1.1 are end-to-end headers. | |
5138 | ||
5139 | Other hop-by-hop headers MUST be listed in a Connection header, | |
5140 | (section 14.10) to be introduced into HTTP/1.1 (or later). | |
5141 | ||
5142 | 13.5.2 Non-modifiable Headers | |
5143 | ||
5144 | Some features of the HTTP/1.1 protocol, such as Digest | |
5145 | Authentication, depend on the value of certain end-to-end headers. A | |
5146 | transparent proxy SHOULD NOT modify an end-to-end header unless the | |
5147 | definition of that header requires or specifically allows that. | |
5148 | ||
5149 | ||
5150 | ||
5151 | ||
5152 | ||
5153 | ||
5154 | Fielding, et al. Standards Track [Page 92] | |
5155 | \f | |
5156 | RFC 2616 HTTP/1.1 June 1999 | |
5157 | ||
5158 | ||
5159 | A transparent proxy MUST NOT modify any of the following fields in a | |
5160 | request or response, and it MUST NOT add any of these fields if not | |
5161 | already present: | |
5162 | ||
5163 | - Content-Location | |
5164 | ||
5165 | - Content-MD5 | |
5166 | ||
5167 | - ETag | |
5168 | ||
5169 | - Last-Modified | |
5170 | ||
5171 | A transparent proxy MUST NOT modify any of the following fields in a | |
5172 | response: | |
5173 | ||
5174 | - Expires | |
5175 | ||
5176 | but it MAY add any of these fields if not already present. If an | |
5177 | Expires header is added, it MUST be given a field-value identical to | |
5178 | that of the Date header in that response. | |
5179 | ||
5180 | A proxy MUST NOT modify or add any of the following fields in a | |
5181 | message that contains the no-transform cache-control directive, or in | |
5182 | any request: | |
5183 | ||
5184 | - Content-Encoding | |
5185 | ||
5186 | - Content-Range | |
5187 | ||
5188 | - Content-Type | |
5189 | ||
5190 | A non-transparent proxy MAY modify or add these fields to a message | |
5191 | that does not include no-transform, but if it does so, it MUST add a | |
5192 | Warning 214 (Transformation applied) if one does not already appear | |
5193 | in the message (see section 14.46). | |
5194 | ||
5195 | Warning: unnecessary modification of end-to-end headers might | |
5196 | cause authentication failures if stronger authentication | |
5197 | mechanisms are introduced in later versions of HTTP. Such | |
5198 | authentication mechanisms MAY rely on the values of header fields | |
5199 | not listed here. | |
5200 | ||
5201 | The Content-Length field of a request or response is added or deleted | |
5202 | according to the rules in section 4.4. A transparent proxy MUST | |
5203 | preserve the entity-length (section 7.2.2) of the entity-body, | |
5204 | although it MAY change the transfer-length (section 4.4). | |
5205 | ||
5206 | ||
5207 | ||
5208 | ||
5209 | ||
5210 | Fielding, et al. Standards Track [Page 93] | |
5211 | \f | |
5212 | RFC 2616 HTTP/1.1 June 1999 | |
5213 | ||
5214 | ||
5215 | 13.5.3 Combining Headers | |
5216 | ||
5217 | When a cache makes a validating request to a server, and the server | |
5218 | provides a 304 (Not Modified) response or a 206 (Partial Content) | |
5219 | response, the cache then constructs a response to send to the | |
5220 | requesting client. | |
5221 | ||
5222 | If the status code is 304 (Not Modified), the cache uses the entity- | |
5223 | body stored in the cache entry as the entity-body of this outgoing | |
5224 | response. If the status code is 206 (Partial Content) and the ETag or | |
5225 | Last-Modified headers match exactly, the cache MAY combine the | |
5226 | contents stored in the cache entry with the new contents received in | |
5227 | the response and use the result as the entity-body of this outgoing | |
5228 | response, (see 13.5.4). | |
5229 | ||
5230 | The end-to-end headers stored in the cache entry are used for the | |
5231 | constructed response, except that | |
5232 | ||
5233 | - any stored Warning headers with warn-code 1xx (see section | |
5234 | 14.46) MUST be deleted from the cache entry and the forwarded | |
5235 | response. | |
5236 | ||
5237 | - any stored Warning headers with warn-code 2xx MUST be retained | |
5238 | in the cache entry and the forwarded response. | |
5239 | ||
5240 | - any end-to-end headers provided in the 304 or 206 response MUST | |
5241 | replace the corresponding headers from the cache entry. | |
5242 | ||
5243 | Unless the cache decides to remove the cache entry, it MUST also | |
5244 | replace the end-to-end headers stored with the cache entry with | |
5245 | corresponding headers received in the incoming response, except for | |
5246 | Warning headers as described immediately above. If a header field- | |
5247 | name in the incoming response matches more than one header in the | |
5248 | cache entry, all such old headers MUST be replaced. | |
5249 | ||
5250 | In other words, the set of end-to-end headers received in the | |
5251 | incoming response overrides all corresponding end-to-end headers | |
5252 | stored with the cache entry (except for stored Warning headers with | |
5253 | warn-code 1xx, which are deleted even if not overridden). | |
5254 | ||
5255 | Note: this rule allows an origin server to use a 304 (Not | |
5256 | Modified) or a 206 (Partial Content) response to update any header | |
5257 | associated with a previous response for the same entity or sub- | |
5258 | ranges thereof, although it might not always be meaningful or | |
5259 | correct to do so. This rule does not allow an origin server to use | |
5260 | a 304 (Not Modified) or a 206 (Partial Content) response to | |
5261 | entirely delete a header that it had provided with a previous | |
5262 | response. | |
5263 | ||
5264 | ||
5265 | ||
5266 | Fielding, et al. Standards Track [Page 94] | |
5267 | \f | |
5268 | RFC 2616 HTTP/1.1 June 1999 | |
5269 | ||
5270 | ||
5271 | 13.5.4 Combining Byte Ranges | |
5272 | ||
5273 | A response might transfer only a subrange of the bytes of an entity- | |
5274 | body, either because the request included one or more Range | |
5275 | specifications, or because a connection was broken prematurely. After | |
5276 | several such transfers, a cache might have received several ranges of | |
5277 | the same entity-body. | |
5278 | ||
5279 | If a cache has a stored non-empty set of subranges for an entity, and | |
5280 | an incoming response transfers another subrange, the cache MAY | |
5281 | combine the new subrange with the existing set if both the following | |
5282 | conditions are met: | |
5283 | ||
5284 | - Both the incoming response and the cache entry have a cache | |
5285 | validator. | |
5286 | ||
5287 | - The two cache validators match using the strong comparison | |
5288 | function (see section 13.3.3). | |
5289 | ||
5290 | If either requirement is not met, the cache MUST use only the most | |
5291 | recent partial response (based on the Date values transmitted with | |
5292 | every response, and using the incoming response if these values are | |
5293 | equal or missing), and MUST discard the other partial information. | |
5294 | ||
5295 | 13.6 Caching Negotiated Responses | |
5296 | ||
5297 | Use of server-driven content negotiation (section 12.1), as indicated | |
5298 | by the presence of a Vary header field in a response, alters the | |
5299 | conditions and procedure by which a cache can use the response for | |
5300 | subsequent requests. See section 14.44 for use of the Vary header | |
5301 | field by servers. | |
5302 | ||
5303 | A server SHOULD use the Vary header field to inform a cache of what | |
5304 | request-header fields were used to select among multiple | |
5305 | representations of a cacheable response subject to server-driven | |
5306 | negotiation. The set of header fields named by the Vary field value | |
5307 | is known as the "selecting" request-headers. | |
5308 | ||
5309 | When the cache receives a subsequent request whose Request-URI | |
5310 | specifies one or more cache entries including a Vary header field, | |
5311 | the cache MUST NOT use such a cache entry to construct a response to | |
5312 | the new request unless all of the selecting request-headers present | |
5313 | in the new request match the corresponding stored request-headers in | |
5314 | the original request. | |
5315 | ||
5316 | The selecting request-headers from two requests are defined to match | |
5317 | if and only if the selecting request-headers in the first request can | |
5318 | be transformed to the selecting request-headers in the second request | |
5319 | ||
5320 | ||
5321 | ||
5322 | Fielding, et al. Standards Track [Page 95] | |
5323 | \f | |
5324 | RFC 2616 HTTP/1.1 June 1999 | |
5325 | ||
5326 | ||
5327 | by adding or removing linear white space (LWS) at places where this | |
5328 | is allowed by the corresponding BNF, and/or combining multiple | |
5329 | message-header fields with the same field name following the rules | |
5330 | about message headers in section 4.2. | |
5331 | ||
5332 | A Vary header field-value of "*" always fails to match and subsequent | |
5333 | requests on that resource can only be properly interpreted by the | |
5334 | origin server. | |
5335 | ||
5336 | If the selecting request header fields for the cached entry do not | |
5337 | match the selecting request header fields of the new request, then | |
5338 | the cache MUST NOT use a cached entry to satisfy the request unless | |
5339 | it first relays the new request to the origin server in a conditional | |
5340 | request and the server responds with 304 (Not Modified), including an | |
5341 | entity tag or Content-Location that indicates the entity to be used. | |
5342 | ||
5343 | If an entity tag was assigned to a cached representation, the | |
5344 | forwarded request SHOULD be conditional and include the entity tags | |
5345 | in an If-None-Match header field from all its cache entries for the | |
5346 | resource. This conveys to the server the set of entities currently | |
5347 | held by the cache, so that if any one of these entities matches the | |
5348 | requested entity, the server can use the ETag header field in its 304 | |
5349 | (Not Modified) response to tell the cache which entry is appropriate. | |
5350 | If the entity-tag of the new response matches that of an existing | |
5351 | entry, the new response SHOULD be used to update the header fields of | |
5352 | the existing entry, and the result MUST be returned to the client. | |
5353 | ||
5354 | If any of the existing cache entries contains only partial content | |
5355 | for the associated entity, its entity-tag SHOULD NOT be included in | |
5356 | the If-None-Match header field unless the request is for a range that | |
5357 | would be fully satisfied by that entry. | |
5358 | ||
5359 | If a cache receives a successful response whose Content-Location | |
5360 | field matches that of an existing cache entry for the same Request- | |
5361 | ]URI, whose entity-tag differs from that of the existing entry, and | |
5362 | whose Date is more recent than that of the existing entry, the | |
5363 | existing entry SHOULD NOT be returned in response to future requests | |
5364 | and SHOULD be deleted from the cache. | |
5365 | ||
5366 | 13.7 Shared and Non-Shared Caches | |
5367 | ||
5368 | For reasons of security and privacy, it is necessary to make a | |
5369 | distinction between "shared" and "non-shared" caches. A non-shared | |
5370 | cache is one that is accessible only to a single user. Accessibility | |
5371 | in this case SHOULD be enforced by appropriate security mechanisms. | |
5372 | All other caches are considered to be "shared." Other sections of | |
5373 | ||
5374 | ||
5375 | ||
5376 | ||
5377 | ||
5378 | Fielding, et al. Standards Track [Page 96] | |
5379 | \f | |
5380 | RFC 2616 HTTP/1.1 June 1999 | |
5381 | ||
5382 | ||
5383 | this specification place certain constraints on the operation of | |
5384 | shared caches in order to prevent loss of privacy or failure of | |
5385 | access controls. | |
5386 | ||
5387 | 13.8 Errors or Incomplete Response Cache Behavior | |
5388 | ||
5389 | A cache that receives an incomplete response (for example, with fewer | |
5390 | bytes of data than specified in a Content-Length header) MAY store | |
5391 | the response. However, the cache MUST treat this as a partial | |
5392 | response. Partial responses MAY be combined as described in section | |
5393 | 13.5.4; the result might be a full response or might still be | |
5394 | partial. A cache MUST NOT return a partial response to a client | |
5395 | without explicitly marking it as such, using the 206 (Partial | |
5396 | Content) status code. A cache MUST NOT return a partial response | |
5397 | using a status code of 200 (OK). | |
5398 | ||
5399 | If a cache receives a 5xx response while attempting to revalidate an | |
5400 | entry, it MAY either forward this response to the requesting client, | |
5401 | or act as if the server failed to respond. In the latter case, it MAY | |
5402 | return a previously received response unless the cached entry | |
5403 | includes the "must-revalidate" cache-control directive (see section | |
5404 | 14.9). | |
5405 | ||
5406 | 13.9 Side Effects of GET and HEAD | |
5407 | ||
5408 | Unless the origin server explicitly prohibits the caching of their | |
5409 | responses, the application of GET and HEAD methods to any resources | |
5410 | SHOULD NOT have side effects that would lead to erroneous behavior if | |
5411 | these responses are taken from a cache. They MAY still have side | |
5412 | effects, but a cache is not required to consider such side effects in | |
5413 | its caching decisions. Caches are always expected to observe an | |
5414 | origin server's explicit restrictions on caching. | |
5415 | ||
5416 | We note one exception to this rule: since some applications have | |
5417 | traditionally used GETs and HEADs with query URLs (those containing a | |
5418 | "?" in the rel_path part) to perform operations with significant side | |
5419 | effects, caches MUST NOT treat responses to such URIs as fresh unless | |
5420 | the server provides an explicit expiration time. This specifically | |
5421 | means that responses from HTTP/1.0 servers for such URIs SHOULD NOT | |
5422 | be taken from a cache. See section 9.1.1 for related information. | |
5423 | ||
5424 | 13.10 Invalidation After Updates or Deletions | |
5425 | ||
5426 | The effect of certain methods performed on a resource at the origin | |
5427 | server might cause one or more existing cache entries to become non- | |
5428 | transparently invalid. That is, although they might continue to be | |
5429 | "fresh," they do not accurately reflect what the origin server would | |
5430 | return for a new request on that resource. | |
5431 | ||
5432 | ||
5433 | ||
5434 | Fielding, et al. Standards Track [Page 97] | |
5435 | \f | |
5436 | RFC 2616 HTTP/1.1 June 1999 | |
5437 | ||
5438 | ||
5439 | There is no way for the HTTP protocol to guarantee that all such | |
5440 | cache entries are marked invalid. For example, the request that | |
5441 | caused the change at the origin server might not have gone through | |
5442 | the proxy where a cache entry is stored. However, several rules help | |
5443 | reduce the likelihood of erroneous behavior. | |
5444 | ||
5445 | In this section, the phrase "invalidate an entity" means that the | |
5446 | cache will either remove all instances of that entity from its | |
5447 | storage, or will mark these as "invalid" and in need of a mandatory | |
5448 | revalidation before they can be returned in response to a subsequent | |
5449 | request. | |
5450 | ||
5451 | Some HTTP methods MUST cause a cache to invalidate an entity. This is | |
5452 | either the entity referred to by the Request-URI, or by the Location | |
5453 | or Content-Location headers (if present). These methods are: | |
5454 | ||
5455 | - PUT | |
5456 | ||
5457 | - DELETE | |
5458 | ||
5459 | - POST | |
5460 | ||
5461 | In order to prevent denial of service attacks, an invalidation based | |
5462 | on the URI in a Location or Content-Location header MUST only be | |
5463 | performed if the host part is the same as in the Request-URI. | |
5464 | ||
5465 | A cache that passes through requests for methods it does not | |
5466 | understand SHOULD invalidate any entities referred to by the | |
5467 | Request-URI. | |
5468 | ||
5469 | 13.11 Write-Through Mandatory | |
5470 | ||
5471 | All methods that might be expected to cause modifications to the | |
5472 | origin server's resources MUST be written through to the origin | |
5473 | server. This currently includes all methods except for GET and HEAD. | |
5474 | A cache MUST NOT reply to such a request from a client before having | |
5475 | transmitted the request to the inbound server, and having received a | |
5476 | corresponding response from the inbound server. This does not prevent | |
5477 | a proxy cache from sending a 100 (Continue) response before the | |
5478 | inbound server has sent its final reply. | |
5479 | ||
5480 | The alternative (known as "write-back" or "copy-back" caching) is not | |
5481 | allowed in HTTP/1.1, due to the difficulty of providing consistent | |
5482 | updates and the problems arising from server, cache, or network | |
5483 | failure prior to write-back. | |
5484 | ||
5485 | ||
5486 | ||
5487 | ||
5488 | ||
5489 | ||
5490 | Fielding, et al. Standards Track [Page 98] | |
5491 | \f | |
5492 | RFC 2616 HTTP/1.1 June 1999 | |
5493 | ||
5494 | ||
5495 | 13.12 Cache Replacement | |
5496 | ||
5497 | If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) | |
5498 | response is received from a resource while any existing responses for | |
5499 | the same resource are cached, the cache SHOULD use the new response | |
5500 | to reply to the current request. It MAY insert it into cache storage | |
5501 | and MAY, if it meets all other requirements, use it to respond to any | |
5502 | future requests that would previously have caused the old response to | |
5503 | be returned. If it inserts the new response into cache storage the | |
5504 | rules in section 13.5.3 apply. | |
5505 | ||
5506 | Note: a new response that has an older Date header value than | |
5507 | existing cached responses is not cacheable. | |
5508 | ||
5509 | 13.13 History Lists | |
5510 | ||
5511 | User agents often have history mechanisms, such as "Back" buttons and | |
5512 | history lists, which can be used to redisplay an entity retrieved | |
5513 | earlier in a session. | |
5514 | ||
5515 | History mechanisms and caches are different. In particular history | |
5516 | mechanisms SHOULD NOT try to show a semantically transparent view of | |
5517 | the current state of a resource. Rather, a history mechanism is meant | |
5518 | to show exactly what the user saw at the time when the resource was | |
5519 | retrieved. | |
5520 | ||
5521 | By default, an expiration time does not apply to history mechanisms. | |
5522 | If the entity is still in storage, a history mechanism SHOULD display | |
5523 | it even if the entity has expired, unless the user has specifically | |
5524 | configured the agent to refresh expired history documents. | |
5525 | ||
5526 | This is not to be construed to prohibit the history mechanism from | |
5527 | telling the user that a view might be stale. | |
5528 | ||
5529 | Note: if history list mechanisms unnecessarily prevent users from | |
5530 | viewing stale resources, this will tend to force service authors | |
5531 | to avoid using HTTP expiration controls and cache controls when | |
5532 | they would otherwise like to. Service authors may consider it | |
5533 | important that users not be presented with error messages or | |
5534 | warning messages when they use navigation controls (such as BACK) | |
5535 | to view previously fetched resources. Even though sometimes such | |
5536 | resources ought not to cached, or ought to expire quickly, user | |
5537 | interface considerations may force service authors to resort to | |
5538 | other means of preventing caching (e.g. "once-only" URLs) in order | |
5539 | not to suffer the effects of improperly functioning history | |
5540 | mechanisms. | |
5541 | ||
5542 | ||
5543 | ||
5544 | ||
5545 | ||
5546 | Fielding, et al. Standards Track [Page 99] | |
5547 | \f | |
5548 | RFC 2616 HTTP/1.1 June 1999 | |
5549 | ||
5550 | ||
5551 | 14 Header Field Definitions | |
5552 | ||
5553 | This section defines the syntax and semantics of all standard | |
5554 | HTTP/1.1 header fields. For entity-header fields, both sender and | |
5555 | recipient refer to either the client or the server, depending on who | |
5556 | sends and who receives the entity. | |
5557 | ||
5558 | 14.1 Accept | |
5559 | ||
5560 | The Accept request-header field can be used to specify certain media | |
5561 | types which are acceptable for the response. Accept headers can be | |
5562 | used to indicate that the request is specifically limited to a small | |
5563 | set of desired types, as in the case of a request for an in-line | |
5564 | image. | |
5565 | ||
5566 | Accept = "Accept" ":" | |
5567 | #( media-range [ accept-params ] ) | |
5568 | ||
5569 | media-range = ( "*/*" | |
5570 | | ( type "/" "*" ) | |
5571 | | ( type "/" subtype ) | |
5572 | ) *( ";" parameter ) | |
5573 | accept-params = ";" "q" "=" qvalue *( accept-extension ) | |
5574 | accept-extension = ";" token [ "=" ( token | quoted-string ) ] | |
5575 | ||
5576 | The asterisk "*" character is used to group media types into ranges, | |
5577 | with "*/*" indicating all media types and "type/*" indicating all | |
5578 | subtypes of that type. The media-range MAY include media type | |
5579 | parameters that are applicable to that range. | |
5580 | ||
5581 | Each media-range MAY be followed by one or more accept-params, | |
5582 | beginning with the "q" parameter for indicating a relative quality | |
5583 | factor. The first "q" parameter (if any) separates the media-range | |
5584 | parameter(s) from the accept-params. Quality factors allow the user | |
5585 | or user agent to indicate the relative degree of preference for that | |
5586 | media-range, using the qvalue scale from 0 to 1 (section 3.9). The | |
5587 | default value is q=1. | |
5588 | ||
5589 | Note: Use of the "q" parameter name to separate media type | |
5590 | parameters from Accept extension parameters is due to historical | |
5591 | practice. Although this prevents any media type parameter named | |
5592 | "q" from being used with a media range, such an event is believed | |
5593 | to be unlikely given the lack of any "q" parameters in the IANA | |
5594 | media type registry and the rare usage of any media type | |
5595 | parameters in Accept. Future media types are discouraged from | |
5596 | registering any parameter named "q". | |
5597 | ||
5598 | ||
5599 | ||
5600 | ||
5601 | ||
5602 | Fielding, et al. Standards Track [Page 100] | |
5603 | \f | |
5604 | RFC 2616 HTTP/1.1 June 1999 | |
5605 | ||
5606 | ||
5607 | The example | |
5608 | ||
5609 | Accept: audio/*; q=0.2, audio/basic | |
5610 | ||
5611 | SHOULD be interpreted as "I prefer audio/basic, but send me any audio | |
5612 | type if it is the best available after an 80% mark-down in quality." | |
5613 | ||
5614 | If no Accept header field is present, then it is assumed that the | |
5615 | client accepts all media types. If an Accept header field is present, | |
5616 | and if the server cannot send a response which is acceptable | |
5617 | according to the combined Accept field value, then the server SHOULD | |
5618 | send a 406 (not acceptable) response. | |
5619 | ||
5620 | A more elaborate example is | |
5621 | ||
5622 | Accept: text/plain; q=0.5, text/html, | |
5623 | text/x-dvi; q=0.8, text/x-c | |
5624 | ||
5625 | Verbally, this would be interpreted as "text/html and text/x-c are | |
5626 | the preferred media types, but if they do not exist, then send the | |
5627 | text/x-dvi entity, and if that does not exist, send the text/plain | |
5628 | entity." | |
5629 | ||
5630 | Media ranges can be overridden by more specific media ranges or | |
5631 | specific media types. If more than one media range applies to a given | |
5632 | type, the most specific reference has precedence. For example, | |
5633 | ||
5634 | Accept: text/*, text/html, text/html;level=1, */* | |
5635 | ||
5636 | have the following precedence: | |
5637 | ||
5638 | 1) text/html;level=1 | |
5639 | 2) text/html | |
5640 | 3) text/* | |
5641 | 4) */* | |
5642 | ||
5643 | The media type quality factor associated with a given type is | |
5644 | determined by finding the media range with the highest precedence | |
5645 | which matches that type. For example, | |
5646 | ||
5647 | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, | |
5648 | text/html;level=2;q=0.4, */*;q=0.5 | |
5649 | ||
5650 | would cause the following values to be associated: | |
5651 | ||
5652 | text/html;level=1 = 1 | |
5653 | text/html = 0.7 | |
5654 | text/plain = 0.3 | |
5655 | ||
5656 | ||
5657 | ||
5658 | Fielding, et al. Standards Track [Page 101] | |
5659 | \f | |
5660 | RFC 2616 HTTP/1.1 June 1999 | |
5661 | ||
5662 | ||
5663 | image/jpeg = 0.5 | |
5664 | text/html;level=2 = 0.4 | |
5665 | text/html;level=3 = 0.7 | |
5666 | ||
5667 | Note: A user agent might be provided with a default set of quality | |
5668 | values for certain media ranges. However, unless the user agent is | |
5669 | a closed system which cannot interact with other rendering agents, | |
5670 | this default set ought to be configurable by the user. | |
5671 | ||
5672 | 14.2 Accept-Charset | |
5673 | ||
5674 | The Accept-Charset request-header field can be used to indicate what | |
5675 | character sets are acceptable for the response. This field allows | |
5676 | clients capable of understanding more comprehensive or special- | |
5677 | purpose character sets to signal that capability to a server which is | |
5678 | capable of representing documents in those character sets. | |
5679 | ||
5680 | Accept-Charset = "Accept-Charset" ":" | |
5681 | 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) | |
5682 | ||
5683 | ||
5684 | Character set values are described in section 3.4. Each charset MAY | |
5685 | be given an associated quality value which represents the user's | |
5686 | preference for that charset. The default value is q=1. An example is | |
5687 | ||
5688 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | |
5689 | ||
5690 | The special value "*", if present in the Accept-Charset field, | |
5691 | matches every character set (including ISO-8859-1) which is not | |
5692 | mentioned elsewhere in the Accept-Charset field. If no "*" is present | |
5693 | in an Accept-Charset field, then all character sets not explicitly | |
5694 | mentioned get a quality value of 0, except for ISO-8859-1, which gets | |
5695 | a quality value of 1 if not explicitly mentioned. | |
5696 | ||
5697 | If no Accept-Charset header is present, the default is that any | |
5698 | character set is acceptable. If an Accept-Charset header is present, | |
5699 | and if the server cannot send a response which is acceptable | |
5700 | according to the Accept-Charset header, then the server SHOULD send | |
5701 | an error response with the 406 (not acceptable) status code, though | |
5702 | the sending of an unacceptable response is also allowed. | |
5703 | ||
5704 | 14.3 Accept-Encoding | |
5705 | ||
5706 | The Accept-Encoding request-header field is similar to Accept, but | |
5707 | restricts the content-codings (section 3.5) that are acceptable in | |
5708 | the response. | |
5709 | ||
5710 | Accept-Encoding = "Accept-Encoding" ":" | |
5711 | ||
5712 | ||
5713 | ||
5714 | Fielding, et al. Standards Track [Page 102] | |
5715 | \f | |
5716 | RFC 2616 HTTP/1.1 June 1999 | |
5717 | ||
5718 | ||
5719 | 1#( codings [ ";" "q" "=" qvalue ] ) | |
5720 | codings = ( content-coding | "*" ) | |
5721 | ||
5722 | Examples of its use are: | |
5723 | ||
5724 | Accept-Encoding: compress, gzip | |
5725 | Accept-Encoding: | |
5726 | Accept-Encoding: * | |
5727 | Accept-Encoding: compress;q=0.5, gzip;q=1.0 | |
5728 | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | |
5729 | ||
5730 | A server tests whether a content-coding is acceptable, according to | |
5731 | an Accept-Encoding field, using these rules: | |
5732 | ||
5733 | 1. If the content-coding is one of the content-codings listed in | |
5734 | the Accept-Encoding field, then it is acceptable, unless it is | |
5735 | accompanied by a qvalue of 0. (As defined in section 3.9, a | |
5736 | qvalue of 0 means "not acceptable.") | |
5737 | ||
5738 | 2. The special "*" symbol in an Accept-Encoding field matches any | |
5739 | available content-coding not explicitly listed in the header | |
5740 | field. | |
5741 | ||
5742 | 3. If multiple content-codings are acceptable, then the acceptable | |
5743 | content-coding with the highest non-zero qvalue is preferred. | |
5744 | ||
5745 | 4. The "identity" content-coding is always acceptable, unless | |
5746 | specifically refused because the Accept-Encoding field includes | |
5747 | "identity;q=0", or because the field includes "*;q=0" and does | |
5748 | not explicitly include the "identity" content-coding. If the | |
5749 | Accept-Encoding field-value is empty, then only the "identity" | |
5750 | encoding is acceptable. | |
5751 | ||
5752 | If an Accept-Encoding field is present in a request, and if the | |
5753 | server cannot send a response which is acceptable according to the | |
5754 | Accept-Encoding header, then the server SHOULD send an error response | |
5755 | with the 406 (Not Acceptable) status code. | |
5756 | ||
5757 | If no Accept-Encoding field is present in a request, the server MAY | |
5758 | assume that the client will accept any content coding. In this case, | |
5759 | if "identity" is one of the available content-codings, then the | |
5760 | server SHOULD use the "identity" content-coding, unless it has | |
5761 | additional information that a different content-coding is meaningful | |
5762 | to the client. | |
5763 | ||
5764 | Note: If the request does not include an Accept-Encoding field, | |
5765 | and if the "identity" content-coding is unavailable, then | |
5766 | content-codings commonly understood by HTTP/1.0 clients (i.e., | |
5767 | ||
5768 | ||
5769 | ||
5770 | Fielding, et al. Standards Track [Page 103] | |
5771 | \f | |
5772 | RFC 2616 HTTP/1.1 June 1999 | |
5773 | ||
5774 | ||
5775 | "gzip" and "compress") are preferred; some older clients | |
5776 | improperly display messages sent with other content-codings. The | |
5777 | server might also make this decision based on information about | |
5778 | the particular user-agent or client. | |
5779 | ||
5780 | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |
5781 | associated with content-codings. This means that qvalues will not | |
5782 | work and are not permitted with x-gzip or x-compress. | |
5783 | ||
5784 | 14.4 Accept-Language | |
5785 | ||
5786 | The Accept-Language request-header field is similar to Accept, but | |
5787 | restricts the set of natural languages that are preferred as a | |
5788 | response to the request. Language tags are defined in section 3.10. | |
5789 | ||
5790 | Accept-Language = "Accept-Language" ":" | |
5791 | 1#( language-range [ ";" "q" "=" qvalue ] ) | |
5792 | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |
5793 | ||
5794 | Each language-range MAY be given an associated quality value which | |
5795 | represents an estimate of the user's preference for the languages | |
5796 | specified by that range. The quality value defaults to "q=1". For | |
5797 | example, | |
5798 | ||
5799 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 | |
5800 | ||
5801 | would mean: "I prefer Danish, but will accept British English and | |
5802 | other types of English." A language-range matches a language-tag if | |
5803 | it exactly equals the tag, or if it exactly equals a prefix of the | |
5804 | tag such that the first tag character following the prefix is "-". | |
5805 | The special range "*", if present in the Accept-Language field, | |
5806 | matches every tag not matched by any other range present in the | |
5807 | Accept-Language field. | |
5808 | ||
5809 | Note: This use of a prefix matching rule does not imply that | |
5810 | language tags are assigned to languages in such a way that it is | |
5811 | always true that if a user understands a language with a certain | |
5812 | tag, then this user will also understand all languages with tags | |
5813 | for which this tag is a prefix. The prefix rule simply allows the | |
5814 | use of prefix tags if this is the case. | |
5815 | ||
5816 | The language quality factor assigned to a language-tag by the | |
5817 | Accept-Language field is the quality value of the longest language- | |
5818 | range in the field that matches the language-tag. If no language- | |
5819 | range in the field matches the tag, the language quality factor | |
5820 | assigned is 0. If no Accept-Language header is present in the | |
5821 | request, the server | |
5822 | ||
5823 | ||
5824 | ||
5825 | ||
5826 | Fielding, et al. Standards Track [Page 104] | |
5827 | \f | |
5828 | RFC 2616 HTTP/1.1 June 1999 | |
5829 | ||
5830 | ||
5831 | SHOULD assume that all languages are equally acceptable. If an | |
5832 | Accept-Language header is present, then all languages which are | |
5833 | assigned a quality factor greater than 0 are acceptable. | |
5834 | ||
5835 | It might be contrary to the privacy expectations of the user to send | |
5836 | an Accept-Language header with the complete linguistic preferences of | |
5837 | the user in every request. For a discussion of this issue, see | |
5838 | section 15.1.4. | |
5839 | ||
5840 | As intelligibility is highly dependent on the individual user, it is | |
5841 | recommended that client applications make the choice of linguistic | |
5842 | preference available to the user. If the choice is not made | |
5843 | available, then the Accept-Language header field MUST NOT be given in | |
5844 | the request. | |
5845 | ||
5846 | Note: When making the choice of linguistic preference available to | |
5847 | the user, we remind implementors of the fact that users are not | |
5848 | familiar with the details of language matching as described above, | |
5849 | and should provide appropriate guidance. As an example, users | |
5850 | might assume that on selecting "en-gb", they will be served any | |
5851 | kind of English document if British English is not available. A | |
5852 | user agent might suggest in such a case to add "en" to get the | |
5853 | best matching behavior. | |
5854 | ||
5855 | 14.5 Accept-Ranges | |
5856 | ||
5857 | The Accept-Ranges response-header field allows the server to | |
5858 | indicate its acceptance of range requests for a resource: | |
5859 | ||
5860 | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | |
5861 | acceptable-ranges = 1#range-unit | "none" | |
5862 | ||
5863 | Origin servers that accept byte-range requests MAY send | |
5864 | ||
5865 | Accept-Ranges: bytes | |
5866 | ||
5867 | but are not required to do so. Clients MAY generate byte-range | |
5868 | requests without having received this header for the resource | |
5869 | involved. Range units are defined in section 3.12. | |
5870 | ||
5871 | Servers that do not accept any kind of range request for a | |
5872 | resource MAY send | |
5873 | ||
5874 | Accept-Ranges: none | |
5875 | ||
5876 | to advise the client not to attempt a range request. | |
5877 | ||
5878 | ||
5879 | ||
5880 | ||
5881 | ||
5882 | Fielding, et al. Standards Track [Page 105] | |
5883 | \f | |
5884 | RFC 2616 HTTP/1.1 June 1999 | |
5885 | ||
5886 | ||
5887 | 14.6 Age | |
5888 | ||
5889 | The Age response-header field conveys the sender's estimate of the | |
5890 | amount of time since the response (or its revalidation) was | |
5891 | generated at the origin server. A cached response is "fresh" if | |
5892 | its age does not exceed its freshness lifetime. Age values are | |
5893 | calculated as specified in section 13.2.3. | |
5894 | ||
5895 | Age = "Age" ":" age-value | |
5896 | age-value = delta-seconds | |
5897 | ||
5898 | Age values are non-negative decimal integers, representing time in | |
5899 | seconds. | |
5900 | ||
5901 | If a cache receives a value larger than the largest positive | |
5902 | integer it can represent, or if any of its age calculations | |
5903 | overflows, it MUST transmit an Age header with a value of | |
5904 | 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST | |
5905 | include an Age header field in every response generated from its | |
5906 | own cache. Caches SHOULD use an arithmetic type of at least 31 | |
5907 | bits of range. | |
5908 | ||
5909 | 14.7 Allow | |
5910 | ||
5911 | The Allow entity-header field lists the set of methods supported | |
5912 | by the resource identified by the Request-URI. The purpose of this | |
5913 | field is strictly to inform the recipient of valid methods | |
5914 | associated with the resource. An Allow header field MUST be | |
5915 | present in a 405 (Method Not Allowed) response. | |
5916 | ||
5917 | Allow = "Allow" ":" #Method | |
5918 | ||
5919 | Example of use: | |
5920 | ||
5921 | Allow: GET, HEAD, PUT | |
5922 | ||
5923 | This field cannot prevent a client from trying other methods. | |
5924 | However, the indications given by the Allow header field value | |
5925 | SHOULD be followed. The actual set of allowed methods is defined | |
5926 | by the origin server at the time of each request. | |
5927 | ||
5928 | The Allow header field MAY be provided with a PUT request to | |
5929 | recommend the methods to be supported by the new or modified | |
5930 | resource. The server is not required to support these methods and | |
5931 | SHOULD include an Allow header in the response giving the actual | |
5932 | supported methods. | |
5933 | ||
5934 | ||
5935 | ||
5936 | ||
5937 | ||
5938 | Fielding, et al. Standards Track [Page 106] | |
5939 | \f | |
5940 | RFC 2616 HTTP/1.1 June 1999 | |
5941 | ||
5942 | ||
5943 | A proxy MUST NOT modify the Allow header field even if it does not | |
5944 | understand all the methods specified, since the user agent might | |
5945 | have other means of communicating with the origin server. | |
5946 | ||
5947 | 14.8 Authorization | |
5948 | ||
5949 | A user agent that wishes to authenticate itself with a server-- | |
5950 | usually, but not necessarily, after receiving a 401 response--does | |
5951 | so by including an Authorization request-header field with the | |
5952 | request. The Authorization field value consists of credentials | |
5953 | containing the authentication information of the user agent for | |
5954 | the realm of the resource being requested. | |
5955 | ||
5956 | Authorization = "Authorization" ":" credentials | |
5957 | ||
5958 | HTTP access authentication is described in "HTTP Authentication: | |
5959 | Basic and Digest Access Authentication" [43]. If a request is | |
5960 | authenticated and a realm specified, the same credentials SHOULD | |
5961 | be valid for all other requests within this realm (assuming that | |
5962 | the authentication scheme itself does not require otherwise, such | |
5963 | as credentials that vary according to a challenge value or using | |
5964 | synchronized clocks). | |
5965 | ||
5966 | When a shared cache (see section 13.7) receives a request | |
5967 | containing an Authorization field, it MUST NOT return the | |
5968 | corresponding response as a reply to any other request, unless one | |
5969 | of the following specific exceptions holds: | |
5970 | ||
5971 | 1. If the response includes the "s-maxage" cache-control | |
5972 | directive, the cache MAY use that response in replying to a | |
5973 | subsequent request. But (if the specified maximum age has | |
5974 | passed) a proxy cache MUST first revalidate it with the origin | |
5975 | server, using the request-headers from the new request to allow | |
5976 | the origin server to authenticate the new request. (This is the | |
5977 | defined behavior for s-maxage.) If the response includes "s- | |
5978 | maxage=0", the proxy MUST always revalidate it before re-using | |
5979 | it. | |
5980 | ||
5981 | 2. If the response includes the "must-revalidate" cache-control | |
5982 | directive, the cache MAY use that response in replying to a | |
5983 | subsequent request. But if the response is stale, all caches | |
5984 | MUST first revalidate it with the origin server, using the | |
5985 | request-headers from the new request to allow the origin server | |
5986 | to authenticate the new request. | |
5987 | ||
5988 | 3. If the response includes the "public" cache-control directive, | |
5989 | it MAY be returned in reply to any subsequent request. | |
5990 | ||
5991 | ||
5992 | ||
5993 | ||
5994 | Fielding, et al. Standards Track [Page 107] | |
5995 | \f | |
5996 | RFC 2616 HTTP/1.1 June 1999 | |
5997 | ||
5998 | ||
5999 | 14.9 Cache-Control | |
6000 | ||
6001 | The Cache-Control general-header field is used to specify directives | |
6002 | that MUST be obeyed by all caching mechanisms along the | |
6003 | request/response chain. The directives specify behavior intended to | |
6004 | prevent caches from adversely interfering with the request or | |
6005 | response. These directives typically override the default caching | |
6006 | algorithms. Cache directives are unidirectional in that the presence | |
6007 | of a directive in a request does not imply that the same directive is | |
6008 | to be given in the response. | |
6009 | ||
6010 | Note that HTTP/1.0 caches might not implement Cache-Control and | |
6011 | might only implement Pragma: no-cache (see section 14.32). | |
6012 | ||
6013 | Cache directives MUST be passed through by a proxy or gateway | |
6014 | application, regardless of their significance to that application, | |
6015 | since the directives might be applicable to all recipients along the | |
6016 | request/response chain. It is not possible to specify a cache- | |
6017 | directive for a specific cache. | |
6018 | ||
6019 | Cache-Control = "Cache-Control" ":" 1#cache-directive | |
6020 | ||
6021 | cache-directive = cache-request-directive | |
6022 | | cache-response-directive | |
6023 | ||
6024 | cache-request-directive = | |
6025 | "no-cache" ; Section 14.9.1 | |
6026 | | "no-store" ; Section 14.9.2 | |
6027 | | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | |
6028 | | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | |
6029 | | "min-fresh" "=" delta-seconds ; Section 14.9.3 | |
6030 | | "no-transform" ; Section 14.9.5 | |
6031 | | "only-if-cached" ; Section 14.9.4 | |
6032 | | cache-extension ; Section 14.9.6 | |
6033 | ||
6034 | cache-response-directive = | |
6035 | "public" ; Section 14.9.1 | |
6036 | | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | |
6037 | | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | |
6038 | | "no-store" ; Section 14.9.2 | |
6039 | | "no-transform" ; Section 14.9.5 | |
6040 | | "must-revalidate" ; Section 14.9.4 | |
6041 | | "proxy-revalidate" ; Section 14.9.4 | |
6042 | | "max-age" "=" delta-seconds ; Section 14.9.3 | |
6043 | | "s-maxage" "=" delta-seconds ; Section 14.9.3 | |
6044 | | cache-extension ; Section 14.9.6 | |
6045 | ||
6046 | cache-extension = token [ "=" ( token | quoted-string ) ] | |
6047 | ||
6048 | ||
6049 | ||
6050 | Fielding, et al. Standards Track [Page 108] | |
6051 | \f | |
6052 | RFC 2616 HTTP/1.1 June 1999 | |
6053 | ||
6054 | ||
6055 | When a directive appears without any 1#field-name parameter, the | |
6056 | directive applies to the entire request or response. When such a | |
6057 | directive appears with a 1#field-name parameter, it applies only to | |
6058 | the named field or fields, and not to the rest of the request or | |
6059 | response. This mechanism supports extensibility; implementations of | |
6060 | future versions of the HTTP protocol might apply these directives to | |
6061 | header fields not defined in HTTP/1.1. | |
6062 | ||
6063 | The cache-control directives can be broken down into these general | |
6064 | categories: | |
6065 | ||
6066 | - Restrictions on what are cacheable; these may only be imposed by | |
6067 | the origin server. | |
6068 | ||
6069 | - Restrictions on what may be stored by a cache; these may be | |
6070 | imposed by either the origin server or the user agent. | |
6071 | ||
6072 | - Modifications of the basic expiration mechanism; these may be | |
6073 | imposed by either the origin server or the user agent. | |
6074 | ||
6075 | - Controls over cache revalidation and reload; these may only be | |
6076 | imposed by a user agent. | |
6077 | ||
6078 | - Control over transformation of entities. | |
6079 | ||
6080 | - Extensions to the caching system. | |
6081 | ||
6082 | 14.9.1 What is Cacheable | |
6083 | ||
6084 | By default, a response is cacheable if the requirements of the | |
6085 | request method, request header fields, and the response status | |
6086 | indicate that it is cacheable. Section 13.4 summarizes these defaults | |
6087 | for cacheability. The following Cache-Control response directives | |
6088 | allow an origin server to override the default cacheability of a | |
6089 | response: | |
6090 | ||
6091 | public | |
6092 | Indicates that the response MAY be cached by any cache, even if it | |
6093 | would normally be non-cacheable or cacheable only within a non- | |
6094 | shared cache. (See also Authorization, section 14.8, for | |
6095 | additional details.) | |
6096 | ||
6097 | private | |
6098 | Indicates that all or part of the response message is intended for | |
6099 | a single user and MUST NOT be cached by a shared cache. This | |
6100 | allows an origin server to state that the specified parts of the | |
6101 | ||
6102 | ||
6103 | ||
6104 | ||
6105 | ||
6106 | Fielding, et al. Standards Track [Page 109] | |
6107 | \f | |
6108 | RFC 2616 HTTP/1.1 June 1999 | |
6109 | ||
6110 | ||
6111 | response are intended for only one user and are not a valid | |
6112 | response for requests by other users. A private (non-shared) cache | |
6113 | MAY cache the response. | |
6114 | ||
6115 | Note: This usage of the word private only controls where the | |
6116 | response may be cached, and cannot ensure the privacy of the | |
6117 | message content. | |
6118 | ||
6119 | no-cache | |
6120 | If the no-cache directive does not specify a field-name, then a | |
6121 | cache MUST NOT use the response to satisfy a subsequent request | |
6122 | without successful revalidation with the origin server. This | |
6123 | allows an origin server to prevent caching even by caches that | |
6124 | have been configured to return stale responses to client requests. | |
6125 | ||
6126 | If the no-cache directive does specify one or more field-names, | |
6127 | then a cache MAY use the response to satisfy a subsequent request, | |
6128 | subject to any other restrictions on caching. However, the | |
6129 | specified field-name(s) MUST NOT be sent in the response to a | |
6130 | subsequent request without successful revalidation with the origin | |
6131 | server. This allows an origin server to prevent the re-use of | |
6132 | certain header fields in a response, while still allowing caching | |
6133 | of the rest of the response. | |
6134 | ||
6135 | Note: Most HTTP/1.0 caches will not recognize or obey this | |
6136 | directive. | |
6137 | ||
6138 | 14.9.2 What May be Stored by Caches | |
6139 | ||
6140 | no-store | |
6141 | The purpose of the no-store directive is to prevent the | |
6142 | inadvertent release or retention of sensitive information (for | |
6143 | example, on backup tapes). The no-store directive applies to the | |
6144 | entire message, and MAY be sent either in a response or in a | |
6145 | request. If sent in a request, a cache MUST NOT store any part of | |
6146 | either this request or any response to it. If sent in a response, | |
6147 | a cache MUST NOT store any part of either this response or the | |
6148 | request that elicited it. This directive applies to both non- | |
6149 | shared and shared caches. "MUST NOT store" in this context means | |
6150 | that the cache MUST NOT intentionally store the information in | |
6151 | non-volatile storage, and MUST make a best-effort attempt to | |
6152 | remove the information from volatile storage as promptly as | |
6153 | possible after forwarding it. | |
6154 | ||
6155 | Even when this directive is associated with a response, users | |
6156 | might explicitly store such a response outside of the caching | |
6157 | system (e.g., with a "Save As" dialog). History buffers MAY store | |
6158 | such responses as part of their normal operation. | |
6159 | ||
6160 | ||
6161 | ||
6162 | Fielding, et al. Standards Track [Page 110] | |
6163 | \f | |
6164 | RFC 2616 HTTP/1.1 June 1999 | |
6165 | ||
6166 | ||
6167 | The purpose of this directive is to meet the stated requirements | |
6168 | of certain users and service authors who are concerned about | |
6169 | accidental releases of information via unanticipated accesses to | |
6170 | cache data structures. While the use of this directive might | |
6171 | improve privacy in some cases, we caution that it is NOT in any | |
6172 | way a reliable or sufficient mechanism for ensuring privacy. In | |
6173 | particular, malicious or compromised caches might not recognize or | |
6174 | obey this directive, and communications networks might be | |
6175 | vulnerable to eavesdropping. | |
6176 | ||
6177 | 14.9.3 Modifications of the Basic Expiration Mechanism | |
6178 | ||
6179 | The expiration time of an entity MAY be specified by the origin | |
6180 | server using the Expires header (see section 14.21). Alternatively, | |
6181 | it MAY be specified using the max-age directive in a response. When | |
6182 | the max-age cache-control directive is present in a cached response, | |
6183 | the response is stale if its current age is greater than the age | |
6184 | value given (in seconds) at the time of a new request for that | |
6185 | resource. The max-age directive on a response implies that the | |
6186 | response is cacheable (i.e., "public") unless some other, more | |
6187 | restrictive cache directive is also present. | |
6188 | ||
6189 | If a response includes both an Expires header and a max-age | |
6190 | directive, the max-age directive overrides the Expires header, even | |
6191 | if the Expires header is more restrictive. This rule allows an origin | |
6192 | server to provide, for a given response, a longer expiration time to | |
6193 | an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be | |
6194 | useful if certain HTTP/1.0 caches improperly calculate ages or | |
6195 | expiration times, perhaps due to desynchronized clocks. | |
6196 | ||
6197 | Many HTTP/1.0 cache implementations will treat an Expires value that | |
6198 | is less than or equal to the response Date value as being equivalent | |
6199 | to the Cache-Control response directive "no-cache". If an HTTP/1.1 | |
6200 | cache receives such a response, and the response does not include a | |
6201 | Cache-Control header field, it SHOULD consider the response to be | |
6202 | non-cacheable in order to retain compatibility with HTTP/1.0 servers. | |
6203 | ||
6204 | Note: An origin server might wish to use a relatively new HTTP | |
6205 | cache control feature, such as the "private" directive, on a | |
6206 | network including older caches that do not understand that | |
6207 | feature. The origin server will need to combine the new feature | |
6208 | with an Expires field whose value is less than or equal to the | |
6209 | Date value. This will prevent older caches from improperly | |
6210 | caching the response. | |
6211 | ||
6212 | ||
6213 | ||
6214 | ||
6215 | ||
6216 | ||
6217 | ||
6218 | Fielding, et al. Standards Track [Page 111] | |
6219 | \f | |
6220 | RFC 2616 HTTP/1.1 June 1999 | |
6221 | ||
6222 | ||
6223 | s-maxage | |
6224 | If a response includes an s-maxage directive, then for a shared | |
6225 | cache (but not for a private cache), the maximum age specified by | |
6226 | this directive overrides the maximum age specified by either the | |
6227 | max-age directive or the Expires header. The s-maxage directive | |
6228 | also implies the semantics of the proxy-revalidate directive (see | |
6229 | section 14.9.4), i.e., that the shared cache must not use the | |
6230 | entry after it becomes stale to respond to a subsequent request | |
6231 | without first revalidating it with the origin server. The s- | |
6232 | maxage directive is always ignored by a private cache. | |
6233 | ||
6234 | Note that most older caches, not compliant with this specification, | |
6235 | do not implement any cache-control directives. An origin server | |
6236 | wishing to use a cache-control directive that restricts, but does not | |
6237 | prevent, caching by an HTTP/1.1-compliant cache MAY exploit the | |
6238 | requirement that the max-age directive overrides the Expires header, | |
6239 | and the fact that pre-HTTP/1.1-compliant caches do not observe the | |
6240 | max-age directive. | |
6241 | ||
6242 | Other directives allow a user agent to modify the basic expiration | |
6243 | mechanism. These directives MAY be specified on a request: | |
6244 | ||
6245 | max-age | |
6246 | Indicates that the client is willing to accept a response whose | |
6247 | age is no greater than the specified time in seconds. Unless max- | |
6248 | stale directive is also included, the client is not willing to | |
6249 | accept a stale response. | |
6250 | ||
6251 | min-fresh | |
6252 | Indicates that the client is willing to accept a response whose | |
6253 | freshness lifetime is no less than its current age plus the | |
6254 | specified time in seconds. That is, the client wants a response | |
6255 | that will still be fresh for at least the specified number of | |
6256 | seconds. | |
6257 | ||
6258 | max-stale | |
6259 | Indicates that the client is willing to accept a response that has | |
6260 | exceeded its expiration time. If max-stale is assigned a value, | |
6261 | then the client is willing to accept a response that has exceeded | |
6262 | its expiration time by no more than the specified number of | |
6263 | seconds. If no value is assigned to max-stale, then the client is | |
6264 | willing to accept a stale response of any age. | |
6265 | ||
6266 | If a cache returns a stale response, either because of a max-stale | |
6267 | directive on a request, or because the cache is configured to | |
6268 | override the expiration time of a response, the cache MUST attach a | |
6269 | Warning header to the stale response, using Warning 110 (Response is | |
6270 | stale). | |
6271 | ||
6272 | ||
6273 | ||
6274 | Fielding, et al. Standards Track [Page 112] | |
6275 | \f | |
6276 | RFC 2616 HTTP/1.1 June 1999 | |
6277 | ||
6278 | ||
6279 | A cache MAY be configured to return stale responses without | |
6280 | validation, but only if this does not conflict with any "MUST"-level | |
6281 | requirements concerning cache validation (e.g., a "must-revalidate" | |
6282 | cache-control directive). | |
6283 | ||
6284 | If both the new request and the cached entry include "max-age" | |
6285 | directives, then the lesser of the two values is used for determining | |
6286 | the freshness of the cached entry for that request. | |
6287 | ||
6288 | 14.9.4 Cache Revalidation and Reload Controls | |
6289 | ||
6290 | Sometimes a user agent might want or need to insist that a cache | |
6291 | revalidate its cache entry with the origin server (and not just with | |
6292 | the next cache along the path to the origin server), or to reload its | |
6293 | cache entry from the origin server. End-to-end revalidation might be | |
6294 | necessary if either the cache or the origin server has overestimated | |
6295 | the expiration time of the cached response. End-to-end reload may be | |
6296 | necessary if the cache entry has become corrupted for some reason. | |
6297 | ||
6298 | End-to-end revalidation may be requested either when the client does | |
6299 | not have its own local cached copy, in which case we call it | |
6300 | "unspecified end-to-end revalidation", or when the client does have a | |
6301 | local cached copy, in which case we call it "specific end-to-end | |
6302 | revalidation." | |
6303 | ||
6304 | The client can specify these three kinds of action using Cache- | |
6305 | Control request directives: | |
6306 | ||
6307 | End-to-end reload | |
6308 | The request includes a "no-cache" cache-control directive or, for | |
6309 | compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field | |
6310 | names MUST NOT be included with the no-cache directive in a | |
6311 | request. The server MUST NOT use a cached copy when responding to | |
6312 | such a request. | |
6313 | ||
6314 | Specific end-to-end revalidation | |
6315 | The request includes a "max-age=0" cache-control directive, which | |
6316 | forces each cache along the path to the origin server to | |
6317 | revalidate its own entry, if any, with the next cache or server. | |
6318 | The initial request includes a cache-validating conditional with | |
6319 | the client's current validator. | |
6320 | ||
6321 | Unspecified end-to-end revalidation | |
6322 | The request includes "max-age=0" cache-control directive, which | |
6323 | forces each cache along the path to the origin server to | |
6324 | revalidate its own entry, if any, with the next cache or server. | |
6325 | The initial request does not include a cache-validating | |
6326 | ||
6327 | ||
6328 | ||
6329 | ||
6330 | Fielding, et al. Standards Track [Page 113] | |
6331 | \f | |
6332 | RFC 2616 HTTP/1.1 June 1999 | |
6333 | ||
6334 | ||
6335 | conditional; the first cache along the path (if any) that holds a | |
6336 | cache entry for this resource includes a cache-validating | |
6337 | conditional with its current validator. | |
6338 | ||
6339 | max-age | |
6340 | When an intermediate cache is forced, by means of a max-age=0 | |
6341 | directive, to revalidate its own cache entry, and the client has | |
6342 | supplied its own validator in the request, the supplied validator | |
6343 | might differ from the validator currently stored with the cache | |
6344 | entry. In this case, the cache MAY use either validator in making | |
6345 | its own request without affecting semantic transparency. | |
6346 | ||
6347 | However, the choice of validator might affect performance. The | |
6348 | best approach is for the intermediate cache to use its own | |
6349 | validator when making its request. If the server replies with 304 | |
6350 | (Not Modified), then the cache can return its now validated copy | |
6351 | to the client with a 200 (OK) response. If the server replies with | |
6352 | a new entity and cache validator, however, the intermediate cache | |
6353 | can compare the returned validator with the one provided in the | |
6354 | client's request, using the strong comparison function. If the | |
6355 | client's validator is equal to the origin server's, then the | |
6356 | intermediate cache simply returns 304 (Not Modified). Otherwise, | |
6357 | it returns the new entity with a 200 (OK) response. | |
6358 | ||
6359 | If a request includes the no-cache directive, it SHOULD NOT | |
6360 | include min-fresh, max-stale, or max-age. | |
6361 | ||
6362 | only-if-cached | |
6363 | In some cases, such as times of extremely poor network | |
6364 | connectivity, a client may want a cache to return only those | |
6365 | responses that it currently has stored, and not to reload or | |
6366 | revalidate with the origin server. To do this, the client may | |
6367 | include the only-if-cached directive in a request. If it receives | |
6368 | this directive, a cache SHOULD either respond using a cached entry | |
6369 | that is consistent with the other constraints of the request, or | |
6370 | respond with a 504 (Gateway Timeout) status. However, if a group | |
6371 | of caches is being operated as a unified system with good internal | |
6372 | connectivity, such a request MAY be forwarded within that group of | |
6373 | caches. | |
6374 | ||
6375 | must-revalidate | |
6376 | Because a cache MAY be configured to ignore a server's specified | |
6377 | expiration time, and because a client request MAY include a max- | |
6378 | stale directive (which has a similar effect), the protocol also | |
6379 | includes a mechanism for the origin server to require revalidation | |
6380 | of a cache entry on any subsequent use. When the must-revalidate | |
6381 | directive is present in a response received by a cache, that cache | |
6382 | MUST NOT use the entry after it becomes stale to respond to a | |
6383 | ||
6384 | ||
6385 | ||
6386 | Fielding, et al. Standards Track [Page 114] | |
6387 | \f | |
6388 | RFC 2616 HTTP/1.1 June 1999 | |
6389 | ||
6390 | ||
6391 | subsequent request without first revalidating it with the origin | |
6392 | server. (I.e., the cache MUST do an end-to-end revalidation every | |
6393 | time, if, based solely on the origin server's Expires or max-age | |
6394 | value, the cached response is stale.) | |
6395 | ||
6396 | The must-revalidate directive is necessary to support reliable | |
6397 | operation for certain protocol features. In all circumstances an | |
6398 | HTTP/1.1 cache MUST obey the must-revalidate directive; in | |
6399 | particular, if the cache cannot reach the origin server for any | |
6400 | reason, it MUST generate a 504 (Gateway Timeout) response. | |
6401 | ||
6402 | Servers SHOULD send the must-revalidate directive if and only if | |
6403 | failure to revalidate a request on the entity could result in | |
6404 | incorrect operation, such as a silently unexecuted financial | |
6405 | transaction. Recipients MUST NOT take any automated action that | |
6406 | violates this directive, and MUST NOT automatically provide an | |
6407 | unvalidated copy of the entity if revalidation fails. | |
6408 | ||
6409 | Although this is not recommended, user agents operating under | |
6410 | severe connectivity constraints MAY violate this directive but, if | |
6411 | so, MUST explicitly warn the user that an unvalidated response has | |
6412 | been provided. The warning MUST be provided on each unvalidated | |
6413 | access, and SHOULD require explicit user confirmation. | |
6414 | ||
6415 | proxy-revalidate | |
6416 | The proxy-revalidate directive has the same meaning as the must- | |
6417 | revalidate directive, except that it does not apply to non-shared | |
6418 | user agent caches. It can be used on a response to an | |
6419 | authenticated request to permit the user's cache to store and | |
6420 | later return the response without needing to revalidate it (since | |
6421 | it has already been authenticated once by that user), while still | |
6422 | requiring proxies that service many users to revalidate each time | |
6423 | (in order to make sure that each user has been authenticated). | |
6424 | Note that such authenticated responses also need the public cache | |
6425 | control directive in order to allow them to be cached at all. | |
6426 | ||
6427 | 14.9.5 No-Transform Directive | |
6428 | ||
6429 | no-transform | |
6430 | Implementors of intermediate caches (proxies) have found it useful | |
6431 | to convert the media type of certain entity bodies. A non- | |
6432 | transparent proxy might, for example, convert between image | |
6433 | formats in order to save cache space or to reduce the amount of | |
6434 | traffic on a slow link. | |
6435 | ||
6436 | Serious operational problems occur, however, when these | |
6437 | transformations are applied to entity bodies intended for certain | |
6438 | kinds of applications. For example, applications for medical | |
6439 | ||
6440 | ||
6441 | ||
6442 | Fielding, et al. Standards Track [Page 115] | |
6443 | \f | |
6444 | RFC 2616 HTTP/1.1 June 1999 | |
6445 | ||
6446 | ||
6447 | imaging, scientific data analysis and those using end-to-end | |
6448 | authentication, all depend on receiving an entity body that is bit | |
6449 | for bit identical to the original entity-body. | |
6450 | ||
6451 | Therefore, if a message includes the no-transform directive, an | |
6452 | intermediate cache or proxy MUST NOT change those headers that are | |
6453 | listed in section 13.5.2 as being subject to the no-transform | |
6454 | directive. This implies that the cache or proxy MUST NOT change | |
6455 | any aspect of the entity-body that is specified by these headers, | |
6456 | including the value of the entity-body itself. | |
6457 | ||
6458 | 14.9.6 Cache Control Extensions | |
6459 | ||
6460 | The Cache-Control header field can be extended through the use of one | |
6461 | or more cache-extension tokens, each with an optional assigned value. | |
6462 | Informational extensions (those which do not require a change in | |
6463 | cache behavior) MAY be added without changing the semantics of other | |
6464 | directives. Behavioral extensions are designed to work by acting as | |
6465 | modifiers to the existing base of cache directives. Both the new | |
6466 | directive and the standard directive are supplied, such that | |
6467 | applications which do not understand the new directive will default | |
6468 | to the behavior specified by the standard directive, and those that | |
6469 | understand the new directive will recognize it as modifying the | |
6470 | requirements associated with the standard directive. In this way, | |
6471 | extensions to the cache-control directives can be made without | |
6472 | requiring changes to the base protocol. | |
6473 | ||
6474 | This extension mechanism depends on an HTTP cache obeying all of the | |
6475 | cache-control directives defined for its native HTTP-version, obeying | |
6476 | certain extensions, and ignoring all directives that it does not | |
6477 | understand. | |
6478 | ||
6479 | For example, consider a hypothetical new response directive called | |
6480 | community which acts as a modifier to the private directive. We | |
6481 | define this new directive to mean that, in addition to any non-shared | |
6482 | cache, any cache which is shared only by members of the community | |
6483 | named within its value may cache the response. An origin server | |
6484 | wishing to allow the UCI community to use an otherwise private | |
6485 | response in their shared cache(s) could do so by including | |
6486 | ||
6487 | Cache-Control: private, community="UCI" | |
6488 | ||
6489 | A cache seeing this header field will act correctly even if the cache | |
6490 | does not understand the community cache-extension, since it will also | |
6491 | see and understand the private directive and thus default to the safe | |
6492 | behavior. | |
6493 | ||
6494 | ||
6495 | ||
6496 | ||
6497 | ||
6498 | Fielding, et al. Standards Track [Page 116] | |
6499 | \f | |
6500 | RFC 2616 HTTP/1.1 June 1999 | |
6501 | ||
6502 | ||
6503 | Unrecognized cache-directives MUST be ignored; it is assumed that any | |
6504 | cache-directive likely to be unrecognized by an HTTP/1.1 cache will | |
6505 | be combined with standard directives (or the response's default | |
6506 | cacheability) such that the cache behavior will remain minimally | |
6507 | correct even if the cache does not understand the extension(s). | |
6508 | ||
6509 | 14.10 Connection | |
6510 | ||
6511 | The Connection general-header field allows the sender to specify | |
6512 | options that are desired for that particular connection and MUST NOT | |
6513 | be communicated by proxies over further connections. | |
6514 | ||
6515 | The Connection header has the following grammar: | |
6516 | ||
6517 | Connection = "Connection" ":" 1#(connection-token) | |
6518 | connection-token = token | |
6519 | ||
6520 | HTTP/1.1 proxies MUST parse the Connection header field before a | |
6521 | message is forwarded and, for each connection-token in this field, | |
6522 | remove any header field(s) from the message with the same name as the | |
6523 | connection-token. Connection options are signaled by the presence of | |
6524 | a connection-token in the Connection header field, not by any | |
6525 | corresponding additional header field(s), since the additional header | |
6526 | field may not be sent if there are no parameters associated with that | |
6527 | connection option. | |
6528 | ||
6529 | Message headers listed in the Connection header MUST NOT include | |
6530 | end-to-end headers, such as Cache-Control. | |
6531 | ||
6532 | HTTP/1.1 defines the "close" connection option for the sender to | |
6533 | signal that the connection will be closed after completion of the | |
6534 | response. For example, | |
6535 | ||
6536 | Connection: close | |
6537 | ||
6538 | in either the request or the response header fields indicates that | |
6539 | the connection SHOULD NOT be considered `persistent' (section 8.1) | |
6540 | after the current request/response is complete. | |
6541 | ||
6542 | HTTP/1.1 applications that do not support persistent connections MUST | |
6543 | include the "close" connection option in every message. | |
6544 | ||
6545 | A system receiving an HTTP/1.0 (or lower-version) message that | |
6546 | includes a Connection header MUST, for each connection-token in this | |
6547 | field, remove and ignore any header field(s) from the message with | |
6548 | the same name as the connection-token. This protects against mistaken | |
6549 | forwarding of such header fields by pre-HTTP/1.1 proxies. See section | |
6550 | 19.6.2. | |
6551 | ||
6552 | ||
6553 | ||
6554 | Fielding, et al. Standards Track [Page 117] | |
6555 | \f | |
6556 | RFC 2616 HTTP/1.1 June 1999 | |
6557 | ||
6558 | ||
6559 | 14.11 Content-Encoding | |
6560 | ||
6561 | The Content-Encoding entity-header field is used as a modifier to the | |
6562 | media-type. When present, its value indicates what additional content | |
6563 | codings have been applied to the entity-body, and thus what decoding | |
6564 | mechanisms must be applied in order to obtain the media-type | |
6565 | referenced by the Content-Type header field. Content-Encoding is | |
6566 | primarily used to allow a document to be compressed without losing | |
6567 | the identity of its underlying media type. | |
6568 | ||
6569 | Content-Encoding = "Content-Encoding" ":" 1#content-coding | |
6570 | ||
6571 | Content codings are defined in section 3.5. An example of its use is | |
6572 | ||
6573 | Content-Encoding: gzip | |
6574 | ||
6575 | The content-coding is a characteristic of the entity identified by | |
6576 | the Request-URI. Typically, the entity-body is stored with this | |
6577 | encoding and is only decoded before rendering or analogous usage. | |
6578 | However, a non-transparent proxy MAY modify the content-coding if the | |
6579 | new coding is known to be acceptable to the recipient, unless the | |
6580 | "no-transform" cache-control directive is present in the message. | |
6581 | ||
6582 | If the content-coding of an entity is not "identity", then the | |
6583 | response MUST include a Content-Encoding entity-header (section | |
6584 | 14.11) that lists the non-identity content-coding(s) used. | |
6585 | ||
6586 | If the content-coding of an entity in a request message is not | |
6587 | acceptable to the origin server, the server SHOULD respond with a | |
6588 | status code of 415 (Unsupported Media Type). | |
6589 | ||
6590 | If multiple encodings have been applied to an entity, the content | |
6591 | codings MUST be listed in the order in which they were applied. | |
6592 | Additional information about the encoding parameters MAY be provided | |
6593 | by other entity-header fields not defined by this specification. | |
6594 | ||
6595 | 14.12 Content-Language | |
6596 | ||
6597 | The Content-Language entity-header field describes the natural | |
6598 | language(s) of the intended audience for the enclosed entity. Note | |
6599 | that this might not be equivalent to all the languages used within | |
6600 | the entity-body. | |
6601 | ||
6602 | Content-Language = "Content-Language" ":" 1#language-tag | |
6603 | ||
6604 | ||
6605 | ||
6606 | ||
6607 | ||
6608 | ||
6609 | ||
6610 | Fielding, et al. Standards Track [Page 118] | |
6611 | \f | |
6612 | RFC 2616 HTTP/1.1 June 1999 | |
6613 | ||
6614 | ||
6615 | Language tags are defined in section 3.10. The primary purpose of | |
6616 | Content-Language is to allow a user to identify and differentiate | |
6617 | entities according to the user's own preferred language. Thus, if the | |
6618 | body content is intended only for a Danish-literate audience, the | |
6619 | appropriate field is | |
6620 | ||
6621 | Content-Language: da | |
6622 | ||
6623 | If no Content-Language is specified, the default is that the content | |
6624 | is intended for all language audiences. This might mean that the | |
6625 | sender does not consider it to be specific to any natural language, | |
6626 | or that the sender does not know for which language it is intended. | |
6627 | ||
6628 | Multiple languages MAY be listed for content that is intended for | |
6629 | multiple audiences. For example, a rendition of the "Treaty of | |
6630 | Waitangi," presented simultaneously in the original Maori and English | |
6631 | versions, would call for | |
6632 | ||
6633 | Content-Language: mi, en | |
6634 | ||
6635 | However, just because multiple languages are present within an entity | |
6636 | does not mean that it is intended for multiple linguistic audiences. | |
6637 | An example would be a beginner's language primer, such as "A First | |
6638 | Lesson in Latin," which is clearly intended to be used by an | |
6639 | English-literate audience. In this case, the Content-Language would | |
6640 | properly only include "en". | |
6641 | ||
6642 | Content-Language MAY be applied to any media type -- it is not | |
6643 | limited to textual documents. | |
6644 | ||
6645 | 14.13 Content-Length | |
6646 | ||
6647 | The Content-Length entity-header field indicates the size of the | |
6648 | entity-body, in decimal number of OCTETs, sent to the recipient or, | |
6649 | in the case of the HEAD method, the size of the entity-body that | |
6650 | would have been sent had the request been a GET. | |
6651 | ||
6652 | Content-Length = "Content-Length" ":" 1*DIGIT | |
6653 | ||
6654 | An example is | |
6655 | ||
6656 | Content-Length: 3495 | |
6657 | ||
6658 | Applications SHOULD use this field to indicate the transfer-length of | |
6659 | the message-body, unless this is prohibited by the rules in section | |
6660 | 4.4. | |
6661 | ||
6662 | ||
6663 | ||
6664 | ||
6665 | ||
6666 | Fielding, et al. Standards Track [Page 119] | |
6667 | \f | |
6668 | RFC 2616 HTTP/1.1 June 1999 | |
6669 | ||
6670 | ||
6671 | Any Content-Length greater than or equal to zero is a valid value. | |
6672 | Section 4.4 describes how to determine the length of a message-body | |
6673 | if a Content-Length is not given. | |
6674 | ||
6675 | Note that the meaning of this field is significantly different from | |
6676 | the corresponding definition in MIME, where it is an optional field | |
6677 | used within the "message/external-body" content-type. In HTTP, it | |
6678 | SHOULD be sent whenever the message's length can be determined prior | |
6679 | to being transferred, unless this is prohibited by the rules in | |
6680 | section 4.4. | |
6681 | ||
6682 | 14.14 Content-Location | |
6683 | ||
6684 | The Content-Location entity-header field MAY be used to supply the | |
6685 | resource location for the entity enclosed in the message when that | |
6686 | entity is accessible from a location separate from the requested | |
6687 | resource's URI. A server SHOULD provide a Content-Location for the | |
6688 | variant corresponding to the response entity; especially in the case | |
6689 | where a resource has multiple entities associated with it, and those | |
6690 | entities actually have separate locations by which they might be | |
6691 | individually accessed, the server SHOULD provide a Content-Location | |
6692 | for the particular variant which is returned. | |
6693 | ||
6694 | Content-Location = "Content-Location" ":" | |
6695 | ( absoluteURI | relativeURI ) | |
6696 | ||
6697 | The value of Content-Location also defines the base URI for the | |
6698 | entity. | |
6699 | ||
6700 | The Content-Location value is not a replacement for the original | |
6701 | requested URI; it is only a statement of the location of the resource | |
6702 | corresponding to this particular entity at the time of the request. | |
6703 | Future requests MAY specify the Content-Location URI as the request- | |
6704 | URI if the desire is to identify the source of that particular | |
6705 | entity. | |
6706 | ||
6707 | A cache cannot assume that an entity with a Content-Location | |
6708 | different from the URI used to retrieve it can be used to respond to | |
6709 | later requests on that Content-Location URI. However, the Content- | |
6710 | Location can be used to differentiate between multiple entities | |
6711 | retrieved from a single requested resource, as described in section | |
6712 | 13.6. | |
6713 | ||
6714 | If the Content-Location is a relative URI, the relative URI is | |
6715 | interpreted relative to the Request-URI. | |
6716 | ||
6717 | The meaning of the Content-Location header in PUT or POST requests is | |
6718 | undefined; servers are free to ignore it in those cases. | |
6719 | ||
6720 | ||
6721 | ||
6722 | Fielding, et al. Standards Track [Page 120] | |
6723 | \f | |
6724 | RFC 2616 HTTP/1.1 June 1999 | |
6725 | ||
6726 | ||
6727 | 14.15 Content-MD5 | |
6728 | ||
6729 | The Content-MD5 entity-header field, as defined in RFC 1864 [23], is | |
6730 | an MD5 digest of the entity-body for the purpose of providing an | |
6731 | end-to-end message integrity check (MIC) of the entity-body. (Note: a | |
6732 | MIC is good for detecting accidental modification of the entity-body | |
6733 | in transit, but is not proof against malicious attacks.) | |
6734 | ||
6735 | Content-MD5 = "Content-MD5" ":" md5-digest | |
6736 | md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> | |
6737 | ||
6738 | The Content-MD5 header field MAY be generated by an origin server or | |
6739 | client to function as an integrity check of the entity-body. Only | |
6740 | origin servers or clients MAY generate the Content-MD5 header field; | |
6741 | proxies and gateways MUST NOT generate it, as this would defeat its | |
6742 | value as an end-to-end integrity check. Any recipient of the entity- | |
6743 | body, including gateways and proxies, MAY check that the digest value | |
6744 | in this header field matches that of the entity-body as received. | |
6745 | ||
6746 | The MD5 digest is computed based on the content of the entity-body, | |
6747 | including any content-coding that has been applied, but not including | |
6748 | any transfer-encoding applied to the message-body. If the message is | |
6749 | received with a transfer-encoding, that encoding MUST be removed | |
6750 | prior to checking the Content-MD5 value against the received entity. | |
6751 | ||
6752 | This has the result that the digest is computed on the octets of the | |
6753 | entity-body exactly as, and in the order that, they would be sent if | |
6754 | no transfer-encoding were being applied. | |
6755 | ||
6756 | HTTP extends RFC 1864 to permit the digest to be computed for MIME | |
6757 | composite media-types (e.g., multipart/* and message/rfc822), but | |
6758 | this does not change how the digest is computed as defined in the | |
6759 | preceding paragraph. | |
6760 | ||
6761 | There are several consequences of this. The entity-body for composite | |
6762 | types MAY contain many body-parts, each with its own MIME and HTTP | |
6763 | headers (including Content-MD5, Content-Transfer-Encoding, and | |
6764 | Content-Encoding headers). If a body-part has a Content-Transfer- | |
6765 | Encoding or Content-Encoding header, it is assumed that the content | |
6766 | of the body-part has had the encoding applied, and the body-part is | |
6767 | included in the Content-MD5 digest as is -- i.e., after the | |
6768 | application. The Transfer-Encoding header field is not allowed within | |
6769 | body-parts. | |
6770 | ||
6771 | Conversion of all line breaks to CRLF MUST NOT be done before | |
6772 | computing or checking the digest: the line break convention used in | |
6773 | the text actually transmitted MUST be left unaltered when computing | |
6774 | the digest. | |
6775 | ||
6776 | ||
6777 | ||
6778 | Fielding, et al. Standards Track [Page 121] | |
6779 | \f | |
6780 | RFC 2616 HTTP/1.1 June 1999 | |
6781 | ||
6782 | ||
6783 | Note: while the definition of Content-MD5 is exactly the same for | |
6784 | HTTP as in RFC 1864 for MIME entity-bodies, there are several ways | |
6785 | in which the application of Content-MD5 to HTTP entity-bodies | |
6786 | differs from its application to MIME entity-bodies. One is that | |
6787 | HTTP, unlike MIME, does not use Content-Transfer-Encoding, and | |
6788 | does use Transfer-Encoding and Content-Encoding. Another is that | |
6789 | HTTP more frequently uses binary content types than MIME, so it is | |
6790 | worth noting that, in such cases, the byte order used to compute | |
6791 | the digest is the transmission byte order defined for the type. | |
6792 | Lastly, HTTP allows transmission of text types with any of several | |
6793 | line break conventions and not just the canonical form using CRLF. | |
6794 | ||
6795 | 14.16 Content-Range | |
6796 | ||
6797 | The Content-Range entity-header is sent with a partial entity-body to | |
6798 | specify where in the full entity-body the partial body should be | |
6799 | applied. Range units are defined in section 3.12. | |
6800 | ||
6801 | Content-Range = "Content-Range" ":" content-range-spec | |
6802 | ||
6803 | content-range-spec = byte-content-range-spec | |
6804 | byte-content-range-spec = bytes-unit SP | |
6805 | byte-range-resp-spec "/" | |
6806 | ( instance-length | "*" ) | |
6807 | ||
6808 | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | |
6809 | | "*" | |
6810 | instance-length = 1*DIGIT | |
6811 | ||
6812 | The header SHOULD indicate the total length of the full entity-body, | |
6813 | unless this length is unknown or difficult to determine. The asterisk | |
6814 | "*" character means that the instance-length is unknown at the time | |
6815 | when the response was generated. | |
6816 | ||
6817 | Unlike byte-ranges-specifier values (see section 14.35.1), a byte- | |
6818 | range-resp-spec MUST only specify one range, and MUST contain | |
6819 | absolute byte positions for both the first and last byte of the | |
6820 | range. | |
6821 | ||
6822 | A byte-content-range-spec with a byte-range-resp-spec whose last- | |
6823 | byte-pos value is less than its first-byte-pos value, or whose | |
6824 | instance-length value is less than or equal to its last-byte-pos | |
6825 | value, is invalid. The recipient of an invalid byte-content-range- | |
6826 | spec MUST ignore it and any content transferred along with it. | |
6827 | ||
6828 | A server sending a response with status code 416 (Requested range not | |
6829 | satisfiable) SHOULD include a Content-Range field with a byte-range- | |
6830 | resp-spec of "*". The instance-length specifies the current length of | |
6831 | ||
6832 | ||
6833 | ||
6834 | Fielding, et al. Standards Track [Page 122] | |
6835 | \f | |
6836 | RFC 2616 HTTP/1.1 June 1999 | |
6837 | ||
6838 | ||
6839 | the selected resource. A response with status code 206 (Partial | |
6840 | Content) MUST NOT include a Content-Range field with a byte-range- | |
6841 | resp-spec of "*". | |
6842 | ||
6843 | Examples of byte-content-range-spec values, assuming that the entity | |
6844 | contains a total of 1234 bytes: | |
6845 | ||
6846 | . The first 500 bytes: | |
6847 | bytes 0-499/1234 | |
6848 | ||
6849 | . The second 500 bytes: | |
6850 | bytes 500-999/1234 | |
6851 | ||
6852 | . All except for the first 500 bytes: | |
6853 | bytes 500-1233/1234 | |
6854 | ||
6855 | . The last 500 bytes: | |
6856 | bytes 734-1233/1234 | |
6857 | ||
6858 | When an HTTP message includes the content of a single range (for | |
6859 | example, a response to a request for a single range, or to a request | |
6860 | for a set of ranges that overlap without any holes), this content is | |
6861 | transmitted with a Content-Range header, and a Content-Length header | |
6862 | showing the number of bytes actually transferred. For example, | |
6863 | ||
6864 | HTTP/1.1 206 Partial content | |
6865 | Date: Wed, 15 Nov 1995 06:25:24 GMT | |
6866 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |
6867 | Content-Range: bytes 21010-47021/47022 | |
6868 | Content-Length: 26012 | |
6869 | Content-Type: image/gif | |
6870 | ||
6871 | When an HTTP message includes the content of multiple ranges (for | |
6872 | example, a response to a request for multiple non-overlapping | |
6873 | ranges), these are transmitted as a multipart message. The multipart | |
6874 | media type used for this purpose is "multipart/byteranges" as defined | |
6875 | in appendix 19.2. See appendix 19.6.3 for a compatibility issue. | |
6876 | ||
6877 | A response to a request for a single range MUST NOT be sent using the | |
6878 | multipart/byteranges media type. A response to a request for | |
6879 | multiple ranges, whose result is a single range, MAY be sent as a | |
6880 | multipart/byteranges media type with one part. A client that cannot | |
6881 | decode a multipart/byteranges message MUST NOT ask for multiple | |
6882 | byte-ranges in a single request. | |
6883 | ||
6884 | When a client requests multiple byte-ranges in one request, the | |
6885 | server SHOULD return them in the order that they appeared in the | |
6886 | request. | |
6887 | ||
6888 | ||
6889 | ||
6890 | Fielding, et al. Standards Track [Page 123] | |
6891 | \f | |
6892 | RFC 2616 HTTP/1.1 June 1999 | |
6893 | ||
6894 | ||
6895 | If the server ignores a byte-range-spec because it is syntactically | |
6896 | invalid, the server SHOULD treat the request as if the invalid Range | |
6897 | header field did not exist. (Normally, this means return a 200 | |
6898 | response containing the full entity). | |
6899 | ||
6900 | If the server receives a request (other than one including an If- | |
6901 | Range request-header field) with an unsatisfiable Range request- | |
6902 | header field (that is, all of whose byte-range-spec values have a | |
6903 | first-byte-pos value greater than the current length of the selected | |
6904 | resource), it SHOULD return a response code of 416 (Requested range | |
6905 | not satisfiable) (section 10.4.17). | |
6906 | ||
6907 | Note: clients cannot depend on servers to send a 416 (Requested | |
6908 | range not satisfiable) response instead of a 200 (OK) response for | |
6909 | an unsatisfiable Range request-header, since not all servers | |
6910 | implement this request-header. | |
6911 | ||
6912 | 14.17 Content-Type | |
6913 | ||
6914 | The Content-Type entity-header field indicates the media type of the | |
6915 | entity-body sent to the recipient or, in the case of the HEAD method, | |
6916 | the media type that would have been sent had the request been a GET. | |
6917 | ||
6918 | Content-Type = "Content-Type" ":" media-type | |
6919 | ||
6920 | Media types are defined in section 3.7. An example of the field is | |
6921 | ||
6922 | Content-Type: text/html; charset=ISO-8859-4 | |
6923 | ||
6924 | Further discussion of methods for identifying the media type of an | |
6925 | entity is provided in section 7.2.1. | |
6926 | ||
6927 | 14.18 Date | |
6928 | ||
6929 | The Date general-header field represents the date and time at which | |
6930 | the message was originated, having the same semantics as orig-date in | |
6931 | RFC 822. The field value is an HTTP-date, as described in section | |
6932 | 3.3.1; it MUST be sent in RFC 1123 [8]-date format. | |
6933 | ||
6934 | Date = "Date" ":" HTTP-date | |
6935 | ||
6936 | An example is | |
6937 | ||
6938 | Date: Tue, 15 Nov 1994 08:12:31 GMT | |
6939 | ||
6940 | Origin servers MUST include a Date header field in all responses, | |
6941 | except in these cases: | |
6942 | ||
6943 | ||
6944 | ||
6945 | ||
6946 | Fielding, et al. Standards Track [Page 124] | |
6947 | \f | |
6948 | RFC 2616 HTTP/1.1 June 1999 | |
6949 | ||
6950 | ||
6951 | 1. If the response status code is 100 (Continue) or 101 (Switching | |
6952 | Protocols), the response MAY include a Date header field, at | |
6953 | the server's option. | |
6954 | ||
6955 | 2. If the response status code conveys a server error, e.g. 500 | |
6956 | (Internal Server Error) or 503 (Service Unavailable), and it is | |
6957 | inconvenient or impossible to generate a valid Date. | |
6958 | ||
6959 | 3. If the server does not have a clock that can provide a | |
6960 | reasonable approximation of the current time, its responses | |
6961 | MUST NOT include a Date header field. In this case, the rules | |
6962 | in section 14.18.1 MUST be followed. | |
6963 | ||
6964 | A received message that does not have a Date header field MUST be | |
6965 | assigned one by the recipient if the message will be cached by that | |
6966 | recipient or gatewayed via a protocol which requires a Date. An HTTP | |
6967 | implementation without a clock MUST NOT cache responses without | |
6968 | revalidating them on every use. An HTTP cache, especially a shared | |
6969 | cache, SHOULD use a mechanism, such as NTP [28], to synchronize its | |
6970 | clock with a reliable external standard. | |
6971 | ||
6972 | Clients SHOULD only send a Date header field in messages that include | |
6973 | an entity-body, as in the case of the PUT and POST requests, and even | |
6974 | then it is optional. A client without a clock MUST NOT send a Date | |
6975 | header field in a request. | |
6976 | ||
6977 | The HTTP-date sent in a Date header SHOULD NOT represent a date and | |
6978 | time subsequent to the generation of the message. It SHOULD represent | |
6979 | the best available approximation of the date and time of message | |
6980 | generation, unless the implementation has no means of generating a | |
6981 | reasonably accurate date and time. In theory, the date ought to | |
6982 | represent the moment just before the entity is generated. In | |
6983 | practice, the date can be generated at any time during the message | |
6984 | origination without affecting its semantic value. | |
6985 | ||
6986 | 14.18.1 Clockless Origin Server Operation | |
6987 | ||
6988 | Some origin server implementations might not have a clock available. | |
6989 | An origin server without a clock MUST NOT assign Expires or Last- | |
6990 | Modified values to a response, unless these values were associated | |
6991 | with the resource by a system or user with a reliable clock. It MAY | |
6992 | assign an Expires value that is known, at or before server | |
6993 | configuration time, to be in the past (this allows "pre-expiration" | |
6994 | of responses without storing separate Expires values for each | |
6995 | resource). | |
6996 | ||
6997 | ||
6998 | ||
6999 | ||
7000 | ||
7001 | ||
7002 | Fielding, et al. Standards Track [Page 125] | |
7003 | \f | |
7004 | RFC 2616 HTTP/1.1 June 1999 | |
7005 | ||
7006 | ||
7007 | 14.19 ETag | |
7008 | ||
7009 | The ETag response-header field provides the current value of the | |
7010 | entity tag for the requested variant. The headers used with entity | |
7011 | tags are described in sections 14.24, 14.26 and 14.44. The entity tag | |
7012 | MAY be used for comparison with other entities from the same resource | |
7013 | (see section 13.3.3). | |
7014 | ||
7015 | ETag = "ETag" ":" entity-tag | |
7016 | ||
7017 | Examples: | |
7018 | ||
7019 | ETag: "xyzzy" | |
7020 | ETag: W/"xyzzy" | |
7021 | ETag: "" | |
7022 | ||
7023 | 14.20 Expect | |
7024 | ||
7025 | The Expect request-header field is used to indicate that particular | |
7026 | server behaviors are required by the client. | |
7027 | ||
7028 | Expect = "Expect" ":" 1#expectation | |
7029 | ||
7030 | expectation = "100-continue" | expectation-extension | |
7031 | expectation-extension = token [ "=" ( token | quoted-string ) | |
7032 | *expect-params ] | |
7033 | expect-params = ";" token [ "=" ( token | quoted-string ) ] | |
7034 | ||
7035 | ||
7036 | A server that does not understand or is unable to comply with any of | |
7037 | the expectation values in the Expect field of a request MUST respond | |
7038 | with appropriate error status. The server MUST respond with a 417 | |
7039 | (Expectation Failed) status if any of the expectations cannot be met | |
7040 | or, if there are other problems with the request, some other 4xx | |
7041 | status. | |
7042 | ||
7043 | This header field is defined with extensible syntax to allow for | |
7044 | future extensions. If a server receives a request containing an | |
7045 | Expect field that includes an expectation-extension that it does not | |
7046 | support, it MUST respond with a 417 (Expectation Failed) status. | |
7047 | ||
7048 | Comparison of expectation values is case-insensitive for unquoted | |
7049 | tokens (including the 100-continue token), and is case-sensitive for | |
7050 | quoted-string expectation-extensions. | |
7051 | ||
7052 | ||
7053 | ||
7054 | ||
7055 | ||
7056 | ||
7057 | ||
7058 | Fielding, et al. Standards Track [Page 126] | |
7059 | \f | |
7060 | RFC 2616 HTTP/1.1 June 1999 | |
7061 | ||
7062 | ||
7063 | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST | |
7064 | return a 417 (Expectation Failed) status if it receives a request | |
7065 | with an expectation that it cannot meet. However, the Expect | |
7066 | request-header itself is end-to-end; it MUST be forwarded if the | |
7067 | request is forwarded. | |
7068 | ||
7069 | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | |
7070 | Expect header. | |
7071 | ||
7072 | See section 8.2.3 for the use of the 100 (continue) status. | |
7073 | ||
7074 | 14.21 Expires | |
7075 | ||
7076 | The Expires entity-header field gives the date/time after which the | |
7077 | response is considered stale. A stale cache entry may not normally be | |
7078 | returned by a cache (either a proxy cache or a user agent cache) | |
7079 | unless it is first validated with the origin server (or with an | |
7080 | intermediate cache that has a fresh copy of the entity). See section | |
7081 | 13.2 for further discussion of the expiration model. | |
7082 | ||
7083 | The presence of an Expires field does not imply that the original | |
7084 | resource will change or cease to exist at, before, or after that | |
7085 | time. | |
7086 | ||
7087 | The format is an absolute date and time as defined by HTTP-date in | |
7088 | section 3.3.1; it MUST be in RFC 1123 date format: | |
7089 | ||
7090 | Expires = "Expires" ":" HTTP-date | |
7091 | ||
7092 | An example of its use is | |
7093 | ||
7094 | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |
7095 | ||
7096 | Note: if a response includes a Cache-Control field with the max- | |
7097 | age directive (see section 14.9.3), that directive overrides the | |
7098 | Expires field. | |
7099 | ||
7100 | HTTP/1.1 clients and caches MUST treat other invalid date formats, | |
7101 | especially including the value "0", as in the past (i.e., "already | |
7102 | expired"). | |
7103 | ||
7104 | To mark a response as "already expired," an origin server sends an | |
7105 | Expires date that is equal to the Date header value. (See the rules | |
7106 | for expiration calculations in section 13.2.4.) | |
7107 | ||
7108 | ||
7109 | ||
7110 | ||
7111 | ||
7112 | ||
7113 | ||
7114 | Fielding, et al. Standards Track [Page 127] | |
7115 | \f | |
7116 | RFC 2616 HTTP/1.1 June 1999 | |
7117 | ||
7118 | ||
7119 | To mark a response as "never expires," an origin server sends an | |
7120 | Expires date approximately one year from the time the response is | |
7121 | sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one | |
7122 | year in the future. | |
7123 | ||
7124 | The presence of an Expires header field with a date value of some | |
7125 | time in the future on a response that otherwise would by default be | |
7126 | non-cacheable indicates that the response is cacheable, unless | |
7127 | indicated otherwise by a Cache-Control header field (section 14.9). | |
7128 | ||
7129 | 14.22 From | |
7130 | ||
7131 | The From request-header field, if given, SHOULD contain an Internet | |
7132 | e-mail address for the human user who controls the requesting user | |
7133 | agent. The address SHOULD be machine-usable, as defined by "mailbox" | |
7134 | in RFC 822 [9] as updated by RFC 1123 [8]: | |
7135 | ||
7136 | From = "From" ":" mailbox | |
7137 | ||
7138 | An example is: | |
7139 | ||
7140 | From: webmaster@w3.org | |
7141 | ||
7142 | This header field MAY be used for logging purposes and as a means for | |
7143 | identifying the source of invalid or unwanted requests. It SHOULD NOT | |
7144 | be used as an insecure form of access protection. The interpretation | |
7145 | of this field is that the request is being performed on behalf of the | |
7146 | person given, who accepts responsibility for the method performed. In | |
7147 | particular, robot agents SHOULD include this header so that the | |
7148 | person responsible for running the robot can be contacted if problems | |
7149 | occur on the receiving end. | |
7150 | ||
7151 | The Internet e-mail address in this field MAY be separate from the | |
7152 | Internet host which issued the request. For example, when a request | |
7153 | is passed through a proxy the original issuer's address SHOULD be | |
7154 | used. | |
7155 | ||
7156 | The client SHOULD NOT send the From header field without the user's | |
7157 | approval, as it might conflict with the user's privacy interests or | |
7158 | their site's security policy. It is strongly recommended that the | |
7159 | user be able to disable, enable, and modify the value of this field | |
7160 | at any time prior to a request. | |
7161 | ||
7162 | 14.23 Host | |
7163 | ||
7164 | The Host request-header field specifies the Internet host and port | |
7165 | number of the resource being requested, as obtained from the original | |
7166 | URI given by the user or referring resource (generally an HTTP URL, | |
7167 | ||
7168 | ||
7169 | ||
7170 | Fielding, et al. Standards Track [Page 128] | |
7171 | \f | |
7172 | RFC 2616 HTTP/1.1 June 1999 | |
7173 | ||
7174 | ||
7175 | as described in section 3.2.2). The Host field value MUST represent | |
7176 | the naming authority of the origin server or gateway given by the | |
7177 | original URL. This allows the origin server or gateway to | |
7178 | differentiate between internally-ambiguous URLs, such as the root "/" | |
7179 | URL of a server for multiple host names on a single IP address. | |
7180 | ||
7181 | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | |
7182 | ||
7183 | A "host" without any trailing port information implies the default | |
7184 | port for the service requested (e.g., "80" for an HTTP URL). For | |
7185 | example, a request on the origin server for | |
7186 | <http://www.w3.org/pub/WWW/> would properly include: | |
7187 | ||
7188 | GET /pub/WWW/ HTTP/1.1 | |
7189 | Host: www.w3.org | |
7190 | ||
7191 | A client MUST include a Host header field in all HTTP/1.1 request | |
7192 | messages . If the requested URI does not include an Internet host | |
7193 | name for the service being requested, then the Host header field MUST | |
7194 | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | |
7195 | request message it forwards does contain an appropriate Host header | |
7196 | field that identifies the service being requested by the proxy. All | |
7197 | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | |
7198 | status code to any HTTP/1.1 request message which lacks a Host header | |
7199 | field. | |
7200 | ||
7201 | See sections 5.2 and 19.6.1.1 for other requirements relating to | |
7202 | Host. | |
7203 | ||
7204 | 14.24 If-Match | |
7205 | ||
7206 | The If-Match request-header field is used with a method to make it | |
7207 | conditional. A client that has one or more entities previously | |
7208 | obtained from the resource can verify that one of those entities is | |
7209 | current by including a list of their associated entity tags in the | |
7210 | If-Match header field. Entity tags are defined in section 3.11. The | |
7211 | purpose of this feature is to allow efficient updates of cached | |
7212 | information with a minimum amount of transaction overhead. It is also | |
7213 | used, on updating requests, to prevent inadvertent modification of | |
7214 | the wrong version of a resource. As a special case, the value "*" | |
7215 | matches any current entity of the resource. | |
7216 | ||
7217 | If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | |
7218 | ||
7219 | If any of the entity tags match the entity tag of the entity that | |
7220 | would have been returned in the response to a similar GET request | |
7221 | (without the If-Match header) on that resource, or if "*" is given | |
7222 | ||
7223 | ||
7224 | ||
7225 | ||
7226 | Fielding, et al. Standards Track [Page 129] | |
7227 | \f | |
7228 | RFC 2616 HTTP/1.1 June 1999 | |
7229 | ||
7230 | ||
7231 | and any current entity exists for that resource, then the server MAY | |
7232 | perform the requested method as if the If-Match header field did not | |
7233 | exist. | |
7234 | ||
7235 | A server MUST use the strong comparison function (see section 13.3.3) | |
7236 | to compare the entity tags in If-Match. | |
7237 | ||
7238 | If none of the entity tags match, or if "*" is given and no current | |
7239 | entity exists, the server MUST NOT perform the requested method, and | |
7240 | MUST return a 412 (Precondition Failed) response. This behavior is | |
7241 | most useful when the client wants to prevent an updating method, such | |
7242 | as PUT, from modifying a resource that has changed since the client | |
7243 | last retrieved it. | |
7244 | ||
7245 | If the request would, without the If-Match header field, result in | |
7246 | anything other than a 2xx or 412 status, then the If-Match header | |
7247 | MUST be ignored. | |
7248 | ||
7249 | The meaning of "If-Match: *" is that the method SHOULD be performed | |
7250 | if the representation selected by the origin server (or by a cache, | |
7251 | possibly using the Vary mechanism, see section 14.44) exists, and | |
7252 | MUST NOT be performed if the representation does not exist. | |
7253 | ||
7254 | A request intended to update a resource (e.g., a PUT) MAY include an | |
7255 | If-Match header field to signal that the request method MUST NOT be | |
7256 | applied if the entity corresponding to the If-Match value (a single | |
7257 | entity tag) is no longer a representation of that resource. This | |
7258 | allows the user to indicate that they do not wish the request to be | |
7259 | successful if the resource has been changed without their knowledge. | |
7260 | Examples: | |
7261 | ||
7262 | If-Match: "xyzzy" | |
7263 | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |
7264 | If-Match: * | |
7265 | ||
7266 | The result of a request having both an If-Match header field and | |
7267 | either an If-None-Match or an If-Modified-Since header fields is | |
7268 | undefined by this specification. | |
7269 | ||
7270 | 14.25 If-Modified-Since | |
7271 | ||
7272 | The If-Modified-Since request-header field is used with a method to | |
7273 | make it conditional: if the requested variant has not been modified | |
7274 | since the time specified in this field, an entity will not be | |
7275 | returned from the server; instead, a 304 (not modified) response will | |
7276 | be returned without any message-body. | |
7277 | ||
7278 | If-Modified-Since = "If-Modified-Since" ":" HTTP-date | |
7279 | ||
7280 | ||
7281 | ||
7282 | Fielding, et al. Standards Track [Page 130] | |
7283 | \f | |
7284 | RFC 2616 HTTP/1.1 June 1999 | |
7285 | ||
7286 | ||
7287 | An example of the field is: | |
7288 | ||
7289 | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |
7290 | ||
7291 | A GET method with an If-Modified-Since header and no Range header | |
7292 | requests that the identified entity be transferred only if it has | |
7293 | been modified since the date given by the If-Modified-Since header. | |
7294 | The algorithm for determining this includes the following cases: | |
7295 | ||
7296 | a) If the request would normally result in anything other than a | |
7297 | 200 (OK) status, or if the passed If-Modified-Since date is | |
7298 | invalid, the response is exactly the same as for a normal GET. | |
7299 | A date which is later than the server's current time is | |
7300 | invalid. | |
7301 | ||
7302 | b) If the variant has been modified since the If-Modified-Since | |
7303 | date, the response is exactly the same as for a normal GET. | |
7304 | ||
7305 | c) If the variant has not been modified since a valid If- | |
7306 | Modified-Since date, the server SHOULD return a 304 (Not | |
7307 | Modified) response. | |
7308 | ||
7309 | The purpose of this feature is to allow efficient updates of cached | |
7310 | information with a minimum amount of transaction overhead. | |
7311 | ||
7312 | Note: The Range request-header field modifies the meaning of If- | |
7313 | Modified-Since; see section 14.35 for full details. | |
7314 | ||
7315 | Note: If-Modified-Since times are interpreted by the server, whose | |
7316 | clock might not be synchronized with the client. | |
7317 | ||
7318 | Note: When handling an If-Modified-Since header field, some | |
7319 | servers will use an exact date comparison function, rather than a | |
7320 | less-than function, for deciding whether to send a 304 (Not | |
7321 | Modified) response. To get best results when sending an If- | |
7322 | Modified-Since header field for cache validation, clients are | |
7323 | advised to use the exact date string received in a previous Last- | |
7324 | Modified header field whenever possible. | |
7325 | ||
7326 | Note: If a client uses an arbitrary date in the If-Modified-Since | |
7327 | header instead of a date taken from the Last-Modified header for | |
7328 | the same request, the client should be aware of the fact that this | |
7329 | date is interpreted in the server's understanding of time. The | |
7330 | client should consider unsynchronized clocks and rounding problems | |
7331 | due to the different encodings of time between the client and | |
7332 | server. This includes the possibility of race conditions if the | |
7333 | document has changed between the time it was first requested and | |
7334 | the If-Modified-Since date of a subsequent request, and the | |
7335 | ||
7336 | ||
7337 | ||
7338 | Fielding, et al. Standards Track [Page 131] | |
7339 | \f | |
7340 | RFC 2616 HTTP/1.1 June 1999 | |
7341 | ||
7342 | ||
7343 | possibility of clock-skew-related problems if the If-Modified- | |
7344 | Since date is derived from the client's clock without correction | |
7345 | to the server's clock. Corrections for different time bases | |
7346 | between client and server are at best approximate due to network | |
7347 | latency. | |
7348 | ||
7349 | The result of a request having both an If-Modified-Since header field | |
7350 | and either an If-Match or an If-Unmodified-Since header fields is | |
7351 | undefined by this specification. | |
7352 | ||
7353 | 14.26 If-None-Match | |
7354 | ||
7355 | The If-None-Match request-header field is used with a method to make | |
7356 | it conditional. A client that has one or more entities previously | |
7357 | obtained from the resource can verify that none of those entities is | |
7358 | current by including a list of their associated entity tags in the | |
7359 | If-None-Match header field. The purpose of this feature is to allow | |
7360 | efficient updates of cached information with a minimum amount of | |
7361 | transaction overhead. It is also used to prevent a method (e.g. PUT) | |
7362 | from inadvertently modifying an existing resource when the client | |
7363 | believes that the resource does not exist. | |
7364 | ||
7365 | As a special case, the value "*" matches any current entity of the | |
7366 | resource. | |
7367 | ||
7368 | If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | |
7369 | ||
7370 | If any of the entity tags match the entity tag of the entity that | |
7371 | would have been returned in the response to a similar GET request | |
7372 | (without the If-None-Match header) on that resource, or if "*" is | |
7373 | given and any current entity exists for that resource, then the | |
7374 | server MUST NOT perform the requested method, unless required to do | |
7375 | so because the resource's modification date fails to match that | |
7376 | supplied in an If-Modified-Since header field in the request. | |
7377 | Instead, if the request method was GET or HEAD, the server SHOULD | |
7378 | respond with a 304 (Not Modified) response, including the cache- | |
7379 | related header fields (particularly ETag) of one of the entities that | |
7380 | matched. For all other request methods, the server MUST respond with | |
7381 | a status of 412 (Precondition Failed). | |
7382 | ||
7383 | See section 13.3.3 for rules on how to determine if two entities tags | |
7384 | match. The weak comparison function can only be used with GET or HEAD | |
7385 | requests. | |
7386 | ||
7387 | ||
7388 | ||
7389 | ||
7390 | ||
7391 | ||
7392 | ||
7393 | ||
7394 | Fielding, et al. Standards Track [Page 132] | |
7395 | \f | |
7396 | RFC 2616 HTTP/1.1 June 1999 | |
7397 | ||
7398 | ||
7399 | If none of the entity tags match, then the server MAY perform the | |
7400 | requested method as if the If-None-Match header field did not exist, | |
7401 | but MUST also ignore any If-Modified-Since header field(s) in the | |
7402 | request. That is, if no entity tags match, then the server MUST NOT | |
7403 | return a 304 (Not Modified) response. | |
7404 | ||
7405 | If the request would, without the If-None-Match header field, result | |
7406 | in anything other than a 2xx or 304 status, then the If-None-Match | |
7407 | header MUST be ignored. (See section 13.3.4 for a discussion of | |
7408 | server behavior when both If-Modified-Since and If-None-Match appear | |
7409 | in the same request.) | |
7410 | ||
7411 | The meaning of "If-None-Match: *" is that the method MUST NOT be | |
7412 | performed if the representation selected by the origin server (or by | |
7413 | a cache, possibly using the Vary mechanism, see section 14.44) | |
7414 | exists, and SHOULD be performed if the representation does not exist. | |
7415 | This feature is intended to be useful in preventing races between PUT | |
7416 | operations. | |
7417 | ||
7418 | Examples: | |
7419 | ||
7420 | If-None-Match: "xyzzy" | |
7421 | If-None-Match: W/"xyzzy" | |
7422 | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |
7423 | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | |
7424 | If-None-Match: * | |
7425 | ||
7426 | The result of a request having both an If-None-Match header field and | |
7427 | either an If-Match or an If-Unmodified-Since header fields is | |
7428 | undefined by this specification. | |
7429 | ||
7430 | 14.27 If-Range | |
7431 | ||
7432 | If a client has a partial copy of an entity in its cache, and wishes | |
7433 | to have an up-to-date copy of the entire entity in its cache, it | |
7434 | could use the Range request-header with a conditional GET (using | |
7435 | either or both of If-Unmodified-Since and If-Match.) However, if the | |
7436 | condition fails because the entity has been modified, the client | |
7437 | would then have to make a second request to obtain the entire current | |
7438 | entity-body. | |
7439 | ||
7440 | The If-Range header allows a client to "short-circuit" the second | |
7441 | request. Informally, its meaning is `if the entity is unchanged, send | |
7442 | me the part(s) that I am missing; otherwise, send me the entire new | |
7443 | entity'. | |
7444 | ||
7445 | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | |
7446 | ||
7447 | ||
7448 | ||
7449 | ||
7450 | Fielding, et al. Standards Track [Page 133] | |
7451 | \f | |
7452 | RFC 2616 HTTP/1.1 June 1999 | |
7453 | ||
7454 | ||
7455 | If the client has no entity tag for an entity, but does have a Last- | |
7456 | Modified date, it MAY use that date in an If-Range header. (The | |
7457 | server can distinguish between a valid HTTP-date and any form of | |
7458 | entity-tag by examining no more than two characters.) The If-Range | |
7459 | header SHOULD only be used together with a Range header, and MUST be | |
7460 | ignored if the request does not include a Range header, or if the | |
7461 | server does not support the sub-range operation. | |
7462 | ||
7463 | If the entity tag given in the If-Range header matches the current | |
7464 | entity tag for the entity, then the server SHOULD provide the | |
7465 | specified sub-range of the entity using a 206 (Partial content) | |
7466 | response. If the entity tag does not match, then the server SHOULD | |
7467 | return the entire entity using a 200 (OK) response. | |
7468 | ||
7469 | 14.28 If-Unmodified-Since | |
7470 | ||
7471 | The If-Unmodified-Since request-header field is used with a method to | |
7472 | make it conditional. If the requested resource has not been modified | |
7473 | since the time specified in this field, the server SHOULD perform the | |
7474 | requested operation as if the If-Unmodified-Since header were not | |
7475 | present. | |
7476 | ||
7477 | If the requested variant has been modified since the specified time, | |
7478 | the server MUST NOT perform the requested operation, and MUST return | |
7479 | a 412 (Precondition Failed). | |
7480 | ||
7481 | If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | |
7482 | ||
7483 | An example of the field is: | |
7484 | ||
7485 | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |
7486 | ||
7487 | If the request normally (i.e., without the If-Unmodified-Since | |
7488 | header) would result in anything other than a 2xx or 412 status, the | |
7489 | If-Unmodified-Since header SHOULD be ignored. | |
7490 | ||
7491 | If the specified date is invalid, the header is ignored. | |
7492 | ||
7493 | The result of a request having both an If-Unmodified-Since header | |
7494 | field and either an If-None-Match or an If-Modified-Since header | |
7495 | fields is undefined by this specification. | |
7496 | ||
7497 | 14.29 Last-Modified | |
7498 | ||
7499 | The Last-Modified entity-header field indicates the date and time at | |
7500 | which the origin server believes the variant was last modified. | |
7501 | ||
7502 | Last-Modified = "Last-Modified" ":" HTTP-date | |
7503 | ||
7504 | ||
7505 | ||
7506 | Fielding, et al. Standards Track [Page 134] | |
7507 | \f | |
7508 | RFC 2616 HTTP/1.1 June 1999 | |
7509 | ||
7510 | ||
7511 | An example of its use is | |
7512 | ||
7513 | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |
7514 | ||
7515 | The exact meaning of this header field depends on the implementation | |
7516 | of the origin server and the nature of the original resource. For | |
7517 | files, it may be just the file system last-modified time. For | |
7518 | entities with dynamically included parts, it may be the most recent | |
7519 | of the set of last-modify times for its component parts. For database | |
7520 | gateways, it may be the last-update time stamp of the record. For | |
7521 | virtual objects, it may be the last time the internal state changed. | |
7522 | ||
7523 | An origin server MUST NOT send a Last-Modified date which is later | |
7524 | than the server's time of message origination. In such cases, where | |
7525 | the resource's last modification would indicate some time in the | |
7526 | future, the server MUST replace that date with the message | |
7527 | origination date. | |
7528 | ||
7529 | An origin server SHOULD obtain the Last-Modified value of the entity | |
7530 | as close as possible to the time that it generates the Date value of | |
7531 | its response. This allows a recipient to make an accurate assessment | |
7532 | of the entity's modification time, especially if the entity changes | |
7533 | near the time that the response is generated. | |
7534 | ||
7535 | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. | |
7536 | ||
7537 | 14.30 Location | |
7538 | ||
7539 | The Location response-header field is used to redirect the recipient | |
7540 | to a location other than the Request-URI for completion of the | |
7541 | request or identification of a new resource. For 201 (Created) | |
7542 | responses, the Location is that of the new resource which was created | |
7543 | by the request. For 3xx responses, the location SHOULD indicate the | |
7544 | server's preferred URI for automatic redirection to the resource. The | |
7545 | field value consists of a single absolute URI. | |
7546 | ||
7547 | Location = "Location" ":" absoluteURI | |
7548 | ||
7549 | An example is: | |
7550 | ||
7551 | Location: http://www.w3.org/pub/WWW/People.html | |
7552 | ||
7553 | Note: The Content-Location header field (section 14.14) differs | |
7554 | from Location in that the Content-Location identifies the original | |
7555 | location of the entity enclosed in the request. It is therefore | |
7556 | possible for a response to contain header fields for both Location | |
7557 | and Content-Location. Also see section 13.10 for cache | |
7558 | requirements of some methods. | |
7559 | ||
7560 | ||
7561 | ||
7562 | Fielding, et al. Standards Track [Page 135] | |
7563 | \f | |
7564 | RFC 2616 HTTP/1.1 June 1999 | |
7565 | ||
7566 | ||
7567 | 14.31 Max-Forwards | |
7568 | ||
7569 | The Max-Forwards request-header field provides a mechanism with the | |
7570 | TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the | |
7571 | number of proxies or gateways that can forward the request to the | |
7572 | next inbound server. This can be useful when the client is attempting | |
7573 | to trace a request chain which appears to be failing or looping in | |
7574 | mid-chain. | |
7575 | ||
7576 | Max-Forwards = "Max-Forwards" ":" 1*DIGIT | |
7577 | ||
7578 | The Max-Forwards value is a decimal integer indicating the remaining | |
7579 | number of times this request message may be forwarded. | |
7580 | ||
7581 | Each proxy or gateway recipient of a TRACE or OPTIONS request | |
7582 | containing a Max-Forwards header field MUST check and update its | |
7583 | value prior to forwarding the request. If the received value is zero | |
7584 | (0), the recipient MUST NOT forward the request; instead, it MUST | |
7585 | respond as the final recipient. If the received Max-Forwards value is | |
7586 | greater than zero, then the forwarded message MUST contain an updated | |
7587 | Max-Forwards field with a value decremented by one (1). | |
7588 | ||
7589 | The Max-Forwards header field MAY be ignored for all other methods | |
7590 | defined by this specification and for any extension methods for which | |
7591 | it is not explicitly referred to as part of that method definition. | |
7592 | ||
7593 | 14.32 Pragma | |
7594 | ||
7595 | The Pragma general-header field is used to include implementation- | |
7596 | specific directives that might apply to any recipient along the | |
7597 | request/response chain. All pragma directives specify optional | |
7598 | behavior from the viewpoint of the protocol; however, some systems | |
7599 | MAY require that behavior be consistent with the directives. | |
7600 | ||
7601 | Pragma = "Pragma" ":" 1#pragma-directive | |
7602 | pragma-directive = "no-cache" | extension-pragma | |
7603 | extension-pragma = token [ "=" ( token | quoted-string ) ] | |
7604 | ||
7605 | When the no-cache directive is present in a request message, an | |
7606 | application SHOULD forward the request toward the origin server even | |
7607 | if it has a cached copy of what is being requested. This pragma | |
7608 | directive has the same semantics as the no-cache cache-directive (see | |
7609 | section 14.9) and is defined here for backward compatibility with | |
7610 | HTTP/1.0. Clients SHOULD include both header fields when a no-cache | |
7611 | request is sent to a server not known to be HTTP/1.1 compliant. | |
7612 | ||
7613 | ||
7614 | ||
7615 | ||
7616 | ||
7617 | ||
7618 | Fielding, et al. Standards Track [Page 136] | |
7619 | \f | |
7620 | RFC 2616 HTTP/1.1 June 1999 | |
7621 | ||
7622 | ||
7623 | Pragma directives MUST be passed through by a proxy or gateway | |
7624 | application, regardless of their significance to that application, | |
7625 | since the directives might be applicable to all recipients along the | |
7626 | request/response chain. It is not possible to specify a pragma for a | |
7627 | specific recipient; however, any pragma directive not relevant to a | |
7628 | recipient SHOULD be ignored by that recipient. | |
7629 | ||
7630 | HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had | |
7631 | sent "Cache-Control: no-cache". No new Pragma directives will be | |
7632 | defined in HTTP. | |
7633 | ||
7634 | Note: because the meaning of "Pragma: no-cache as a response | |
7635 | header field is not actually specified, it does not provide a | |
7636 | reliable replacement for "Cache-Control: no-cache" in a response | |
7637 | ||
7638 | 14.33 Proxy-Authenticate | |
7639 | ||
7640 | The Proxy-Authenticate response-header field MUST be included as part | |
7641 | of a 407 (Proxy Authentication Required) response. The field value | |
7642 | consists of a challenge that indicates the authentication scheme and | |
7643 | parameters applicable to the proxy for this Request-URI. | |
7644 | ||
7645 | Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge | |
7646 | ||
7647 | The HTTP access authentication process is described in "HTTP | |
7648 | Authentication: Basic and Digest Access Authentication" [43]. Unlike | |
7649 | WWW-Authenticate, the Proxy-Authenticate header field applies only to | |
7650 | the current connection and SHOULD NOT be passed on to downstream | |
7651 | clients. However, an intermediate proxy might need to obtain its own | |
7652 | credentials by requesting them from the downstream client, which in | |
7653 | some circumstances will appear as if the proxy is forwarding the | |
7654 | Proxy-Authenticate header field. | |
7655 | ||
7656 | 14.34 Proxy-Authorization | |
7657 | ||
7658 | The Proxy-Authorization request-header field allows the client to | |
7659 | identify itself (or its user) to a proxy which requires | |
7660 | authentication. The Proxy-Authorization field value consists of | |
7661 | credentials containing the authentication information of the user | |
7662 | agent for the proxy and/or realm of the resource being requested. | |
7663 | ||
7664 | Proxy-Authorization = "Proxy-Authorization" ":" credentials | |
7665 | ||
7666 | The HTTP access authentication process is described in "HTTP | |
7667 | Authentication: Basic and Digest Access Authentication" [43] . Unlike | |
7668 | Authorization, the Proxy-Authorization header field applies only to | |
7669 | the next outbound proxy that demanded authentication using the Proxy- | |
7670 | Authenticate field. When multiple proxies are used in a chain, the | |
7671 | ||
7672 | ||
7673 | ||
7674 | Fielding, et al. Standards Track [Page 137] | |
7675 | \f | |
7676 | RFC 2616 HTTP/1.1 June 1999 | |
7677 | ||
7678 | ||
7679 | Proxy-Authorization header field is consumed by the first outbound | |
7680 | proxy that was expecting to receive credentials. A proxy MAY relay | |
7681 | the credentials from the client request to the next proxy if that is | |
7682 | the mechanism by which the proxies cooperatively authenticate a given | |
7683 | request. | |
7684 | ||
7685 | 14.35 Range | |
7686 | ||
7687 | 14.35.1 Byte Ranges | |
7688 | ||
7689 | Since all HTTP entities are represented in HTTP messages as sequences | |
7690 | of bytes, the concept of a byte range is meaningful for any HTTP | |
7691 | entity. (However, not all clients and servers need to support byte- | |
7692 | range operations.) | |
7693 | ||
7694 | Byte range specifications in HTTP apply to the sequence of bytes in | |
7695 | the entity-body (not necessarily the same as the message-body). | |
7696 | ||
7697 | A byte range operation MAY specify a single range of bytes, or a set | |
7698 | of ranges within a single entity. | |
7699 | ||
7700 | ranges-specifier = byte-ranges-specifier | |
7701 | byte-ranges-specifier = bytes-unit "=" byte-range-set | |
7702 | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | |
7703 | byte-range-spec = first-byte-pos "-" [last-byte-pos] | |
7704 | first-byte-pos = 1*DIGIT | |
7705 | last-byte-pos = 1*DIGIT | |
7706 | ||
7707 | The first-byte-pos value in a byte-range-spec gives the byte-offset | |
7708 | of the first byte in a range. The last-byte-pos value gives the | |
7709 | byte-offset of the last byte in the range; that is, the byte | |
7710 | positions specified are inclusive. Byte offsets start at zero. | |
7711 | ||
7712 | If the last-byte-pos value is present, it MUST be greater than or | |
7713 | equal to the first-byte-pos in that byte-range-spec, or the byte- | |
7714 | range-spec is syntactically invalid. The recipient of a byte-range- | |
7715 | set that includes one or more syntactically invalid byte-range-spec | |
7716 | values MUST ignore the header field that includes that byte-range- | |
7717 | set. | |
7718 | ||
7719 | If the last-byte-pos value is absent, or if the value is greater than | |
7720 | or equal to the current length of the entity-body, last-byte-pos is | |
7721 | taken to be equal to one less than the current length of the entity- | |
7722 | body in bytes. | |
7723 | ||
7724 | By its choice of last-byte-pos, a client can limit the number of | |
7725 | bytes retrieved without knowing the size of the entity. | |
7726 | ||
7727 | ||
7728 | ||
7729 | ||
7730 | Fielding, et al. Standards Track [Page 138] | |
7731 | \f | |
7732 | RFC 2616 HTTP/1.1 June 1999 | |
7733 | ||
7734 | ||
7735 | suffix-byte-range-spec = "-" suffix-length | |
7736 | suffix-length = 1*DIGIT | |
7737 | ||
7738 | A suffix-byte-range-spec is used to specify the suffix of the | |
7739 | entity-body, of a length given by the suffix-length value. (That is, | |
7740 | this form specifies the last N bytes of an entity-body.) If the | |
7741 | entity is shorter than the specified suffix-length, the entire | |
7742 | entity-body is used. | |
7743 | ||
7744 | If a syntactically valid byte-range-set includes at least one byte- | |
7745 | range-spec whose first-byte-pos is less than the current length of | |
7746 | the entity-body, or at least one suffix-byte-range-spec with a non- | |
7747 | zero suffix-length, then the byte-range-set is satisfiable. | |
7748 | Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set | |
7749 | is unsatisfiable, the server SHOULD return a response with a status | |
7750 | of 416 (Requested range not satisfiable). Otherwise, the server | |
7751 | SHOULD return a response with a status of 206 (Partial Content) | |
7752 | containing the satisfiable ranges of the entity-body. | |
7753 | ||
7754 | Examples of byte-ranges-specifier values (assuming an entity-body of | |
7755 | length 10000): | |
7756 | ||
7757 | - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0- | |
7758 | 499 | |
7759 | ||
7760 | - The second 500 bytes (byte offsets 500-999, inclusive): | |
7761 | bytes=500-999 | |
7762 | ||
7763 | - The final 500 bytes (byte offsets 9500-9999, inclusive): | |
7764 | bytes=-500 | |
7765 | ||
7766 | - Or bytes=9500- | |
7767 | ||
7768 | - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 | |
7769 | ||
7770 | - Several legal but not canonical specifications of the second 500 | |
7771 | bytes (byte offsets 500-999, inclusive): | |
7772 | bytes=500-600,601-999 | |
7773 | bytes=500-700,601-999 | |
7774 | ||
7775 | 14.35.2 Range Retrieval Requests | |
7776 | ||
7777 | HTTP retrieval requests using conditional or unconditional GET | |
7778 | methods MAY request one or more sub-ranges of the entity, instead of | |
7779 | the entire entity, using the Range request header, which applies to | |
7780 | the entity returned as the result of the request: | |
7781 | ||
7782 | Range = "Range" ":" ranges-specifier | |
7783 | ||
7784 | ||
7785 | ||
7786 | Fielding, et al. Standards Track [Page 139] | |
7787 | \f | |
7788 | RFC 2616 HTTP/1.1 June 1999 | |
7789 | ||
7790 | ||
7791 | A server MAY ignore the Range header. However, HTTP/1.1 origin | |
7792 | servers and intermediate caches ought to support byte ranges when | |
7793 | possible, since Range supports efficient recovery from partially | |
7794 | failed transfers, and supports efficient partial retrieval of large | |
7795 | entities. | |
7796 | ||
7797 | If the server supports the Range header and the specified range or | |
7798 | ranges are appropriate for the entity: | |
7799 | ||
7800 | - The presence of a Range header in an unconditional GET modifies | |
7801 | what is returned if the GET is otherwise successful. In other | |
7802 | words, the response carries a status code of 206 (Partial | |
7803 | Content) instead of 200 (OK). | |
7804 | ||
7805 | - The presence of a Range header in a conditional GET (a request | |
7806 | using one or both of If-Modified-Since and If-None-Match, or | |
7807 | one or both of If-Unmodified-Since and If-Match) modifies what | |
7808 | is returned if the GET is otherwise successful and the | |
7809 | condition is true. It does not affect the 304 (Not Modified) | |
7810 | response returned if the conditional is false. | |
7811 | ||
7812 | In some cases, it might be more appropriate to use the If-Range | |
7813 | header (see section 14.27) in addition to the Range header. | |
7814 | ||
7815 | If a proxy that supports ranges receives a Range request, forwards | |
7816 | the request to an inbound server, and receives an entire entity in | |
7817 | reply, it SHOULD only return the requested range to its client. It | |
7818 | SHOULD store the entire received response in its cache if that is | |
7819 | consistent with its cache allocation policies. | |
7820 | ||
7821 | 14.36 Referer | |
7822 | ||
7823 | The Referer[sic] request-header field allows the client to specify, | |
7824 | for the server's benefit, the address (URI) of the resource from | |
7825 | which the Request-URI was obtained (the "referrer", although the | |
7826 | header field is misspelled.) The Referer request-header allows a | |
7827 | server to generate lists of back-links to resources for interest, | |
7828 | logging, optimized caching, etc. It also allows obsolete or mistyped | |
7829 | links to be traced for maintenance. The Referer field MUST NOT be | |
7830 | sent if the Request-URI was obtained from a source that does not have | |
7831 | its own URI, such as input from the user keyboard. | |
7832 | ||
7833 | Referer = "Referer" ":" ( absoluteURI | relativeURI ) | |
7834 | ||
7835 | Example: | |
7836 | ||
7837 | Referer: http://www.w3.org/hypertext/DataSources/Overview.html | |
7838 | ||
7839 | ||
7840 | ||
7841 | ||
7842 | Fielding, et al. Standards Track [Page 140] | |
7843 | \f | |
7844 | RFC 2616 HTTP/1.1 June 1999 | |
7845 | ||
7846 | ||
7847 | If the field value is a relative URI, it SHOULD be interpreted | |
7848 | relative to the Request-URI. The URI MUST NOT include a fragment. See | |
7849 | section 15.1.3 for security considerations. | |
7850 | ||
7851 | 14.37 Retry-After | |
7852 | ||
7853 | The Retry-After response-header field can be used with a 503 (Service | |
7854 | Unavailable) response to indicate how long the service is expected to | |
7855 | be unavailable to the requesting client. This field MAY also be used | |
7856 | with any 3xx (Redirection) response to indicate the minimum time the | |
7857 | user-agent is asked wait before issuing the redirected request. The | |
7858 | value of this field can be either an HTTP-date or an integer number | |
7859 | of seconds (in decimal) after the time of the response. | |
7860 | ||
7861 | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | |
7862 | ||
7863 | Two examples of its use are | |
7864 | ||
7865 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | |
7866 | Retry-After: 120 | |
7867 | ||
7868 | In the latter example, the delay is 2 minutes. | |
7869 | ||
7870 | 14.38 Server | |
7871 | ||
7872 | The Server response-header field contains information about the | |
7873 | software used by the origin server to handle the request. The field | |
7874 | can contain multiple product tokens (section 3.8) and comments | |
7875 | identifying the server and any significant subproducts. The product | |
7876 | tokens are listed in order of their significance for identifying the | |
7877 | application. | |
7878 | ||
7879 | Server = "Server" ":" 1*( product | comment ) | |
7880 | ||
7881 | Example: | |
7882 | ||
7883 | Server: CERN/3.0 libwww/2.17 | |
7884 | ||
7885 | If the response is being forwarded through a proxy, the proxy | |
7886 | application MUST NOT modify the Server response-header. Instead, it | |
7887 | SHOULD include a Via field (as described in section 14.45). | |
7888 | ||
7889 | Note: Revealing the specific software version of the server might | |
7890 | allow the server machine to become more vulnerable to attacks | |
7891 | against software that is known to contain security holes. Server | |
7892 | implementors are encouraged to make this field a configurable | |
7893 | option. | |
7894 | ||
7895 | ||
7896 | ||
7897 | ||
7898 | Fielding, et al. Standards Track [Page 141] | |
7899 | \f | |
7900 | RFC 2616 HTTP/1.1 June 1999 | |
7901 | ||
7902 | ||
7903 | 14.39 TE | |
7904 | ||
7905 | The TE request-header field indicates what extension transfer-codings | |
7906 | it is willing to accept in the response and whether or not it is | |
7907 | willing to accept trailer fields in a chunked transfer-coding. Its | |
7908 | value may consist of the keyword "trailers" and/or a comma-separated | |
7909 | list of extension transfer-coding names with optional accept | |
7910 | parameters (as described in section 3.6). | |
7911 | ||
7912 | TE = "TE" ":" #( t-codings ) | |
7913 | t-codings = "trailers" | ( transfer-extension [ accept-params ] ) | |
7914 | ||
7915 | The presence of the keyword "trailers" indicates that the client is | |
7916 | willing to accept trailer fields in a chunked transfer-coding, as | |
7917 | defined in section 3.6.1. This keyword is reserved for use with | |
7918 | transfer-coding values even though it does not itself represent a | |
7919 | transfer-coding. | |
7920 | ||
7921 | Examples of its use are: | |
7922 | ||
7923 | TE: deflate | |
7924 | TE: | |
7925 | TE: trailers, deflate;q=0.5 | |
7926 | ||
7927 | The TE header field only applies to the immediate connection. | |
7928 | Therefore, the keyword MUST be supplied within a Connection header | |
7929 | field (section 14.10) whenever TE is present in an HTTP/1.1 message. | |
7930 | ||
7931 | A server tests whether a transfer-coding is acceptable, according to | |
7932 | a TE field, using these rules: | |
7933 | ||
7934 | 1. The "chunked" transfer-coding is always acceptable. If the | |
7935 | keyword "trailers" is listed, the client indicates that it is | |
7936 | willing to accept trailer fields in the chunked response on | |
7937 | behalf of itself and any downstream clients. The implication is | |
7938 | that, if given, the client is stating that either all | |
7939 | downstream clients are willing to accept trailer fields in the | |
7940 | forwarded response, or that it will attempt to buffer the | |
7941 | response on behalf of downstream recipients. | |
7942 | ||
7943 | Note: HTTP/1.1 does not define any means to limit the size of a | |
7944 | chunked response such that a client can be assured of buffering | |
7945 | the entire response. | |
7946 | ||
7947 | 2. If the transfer-coding being tested is one of the transfer- | |
7948 | codings listed in the TE field, then it is acceptable unless it | |
7949 | is accompanied by a qvalue of 0. (As defined in section 3.9, a | |
7950 | qvalue of 0 means "not acceptable.") | |
7951 | ||
7952 | ||
7953 | ||
7954 | Fielding, et al. Standards Track [Page 142] | |
7955 | \f | |
7956 | RFC 2616 HTTP/1.1 June 1999 | |
7957 | ||
7958 | ||
7959 | 3. If multiple transfer-codings are acceptable, then the | |
7960 | acceptable transfer-coding with the highest non-zero qvalue is | |
7961 | preferred. The "chunked" transfer-coding always has a qvalue | |
7962 | of 1. | |
7963 | ||
7964 | If the TE field-value is empty or if no TE field is present, the only | |
7965 | transfer-coding is "chunked". A message with no transfer-coding is | |
7966 | always acceptable. | |
7967 | ||
7968 | 14.40 Trailer | |
7969 | ||
7970 | The Trailer general field value indicates that the given set of | |
7971 | header fields is present in the trailer of a message encoded with | |
7972 | chunked transfer-coding. | |
7973 | ||
7974 | Trailer = "Trailer" ":" 1#field-name | |
7975 | ||
7976 | An HTTP/1.1 message SHOULD include a Trailer header field in a | |
7977 | message using chunked transfer-coding with a non-empty trailer. Doing | |
7978 | so allows the recipient to know which header fields to expect in the | |
7979 | trailer. | |
7980 | ||
7981 | If no Trailer header field is present, the trailer SHOULD NOT include | |
7982 | any header fields. See section 3.6.1 for restrictions on the use of | |
7983 | trailer fields in a "chunked" transfer-coding. | |
7984 | ||
7985 | Message header fields listed in the Trailer header field MUST NOT | |
7986 | include the following header fields: | |
7987 | ||
7988 | . Transfer-Encoding | |
7989 | ||
7990 | . Content-Length | |
7991 | ||
7992 | . Trailer | |
7993 | ||
7994 | 14.41 Transfer-Encoding | |
7995 | ||
7996 | The Transfer-Encoding general-header field indicates what (if any) | |
7997 | type of transformation has been applied to the message body in order | |
7998 | to safely transfer it between the sender and the recipient. This | |
7999 | differs from the content-coding in that the transfer-coding is a | |
8000 | property of the message, not of the entity. | |
8001 | ||
8002 | Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding | |
8003 | ||
8004 | Transfer-codings are defined in section 3.6. An example is: | |
8005 | ||
8006 | Transfer-Encoding: chunked | |
8007 | ||
8008 | ||
8009 | ||
8010 | Fielding, et al. Standards Track [Page 143] | |
8011 | \f | |
8012 | RFC 2616 HTTP/1.1 June 1999 | |
8013 | ||
8014 | ||
8015 | If multiple encodings have been applied to an entity, the transfer- | |
8016 | codings MUST be listed in the order in which they were applied. | |
8017 | Additional information about the encoding parameters MAY be provided | |
8018 | by other entity-header fields not defined by this specification. | |
8019 | ||
8020 | Many older HTTP/1.0 applications do not understand the Transfer- | |
8021 | Encoding header. | |
8022 | ||
8023 | 14.42 Upgrade | |
8024 | ||
8025 | The Upgrade general-header allows the client to specify what | |
8026 | additional communication protocols it supports and would like to use | |
8027 | if the server finds it appropriate to switch protocols. The server | |
8028 | MUST use the Upgrade header field within a 101 (Switching Protocols) | |
8029 | response to indicate which protocol(s) are being switched. | |
8030 | ||
8031 | Upgrade = "Upgrade" ":" 1#product | |
8032 | ||
8033 | For example, | |
8034 | ||
8035 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | |
8036 | ||
8037 | The Upgrade header field is intended to provide a simple mechanism | |
8038 | for transition from HTTP/1.1 to some other, incompatible protocol. It | |
8039 | does so by allowing the client to advertise its desire to use another | |
8040 | protocol, such as a later version of HTTP with a higher major version | |
8041 | number, even though the current request has been made using HTTP/1.1. | |
8042 | This eases the difficult transition between incompatible protocols by | |
8043 | allowing the client to initiate a request in the more commonly | |
8044 | supported protocol while indicating to the server that it would like | |
8045 | to use a "better" protocol if available (where "better" is determined | |
8046 | by the server, possibly according to the nature of the method and/or | |
8047 | resource being requested). | |
8048 | ||
8049 | The Upgrade header field only applies to switching application-layer | |
8050 | protocols upon the existing transport-layer connection. Upgrade | |
8051 | cannot be used to insist on a protocol change; its acceptance and use | |
8052 | by the server is optional. The capabilities and nature of the | |
8053 | application-layer communication after the protocol change is entirely | |
8054 | dependent upon the new protocol chosen, although the first action | |
8055 | after changing the protocol MUST be a response to the initial HTTP | |
8056 | request containing the Upgrade header field. | |
8057 | ||
8058 | The Upgrade header field only applies to the immediate connection. | |
8059 | Therefore, the upgrade keyword MUST be supplied within a Connection | |
8060 | header field (section 14.10) whenever Upgrade is present in an | |
8061 | HTTP/1.1 message. | |
8062 | ||
8063 | ||
8064 | ||
8065 | ||
8066 | Fielding, et al. Standards Track [Page 144] | |
8067 | \f | |
8068 | RFC 2616 HTTP/1.1 June 1999 | |
8069 | ||
8070 | ||
8071 | The Upgrade header field cannot be used to indicate a switch to a | |
8072 | protocol on a different connection. For that purpose, it is more | |
8073 | appropriate to use a 301, 302, 303, or 305 redirection response. | |
8074 | ||
8075 | This specification only defines the protocol name "HTTP" for use by | |
8076 | the family of Hypertext Transfer Protocols, as defined by the HTTP | |
8077 | version rules of section 3.1 and future updates to this | |
8078 | specification. Any token can be used as a protocol name; however, it | |
8079 | will only be useful if both the client and server associate the name | |
8080 | with the same protocol. | |
8081 | ||
8082 | 14.43 User-Agent | |
8083 | ||
8084 | The User-Agent request-header field contains information about the | |
8085 | user agent originating the request. This is for statistical purposes, | |
8086 | the tracing of protocol violations, and automated recognition of user | |
8087 | agents for the sake of tailoring responses to avoid particular user | |
8088 | agent limitations. User agents SHOULD include this field with | |
8089 | requests. The field can contain multiple product tokens (section 3.8) | |
8090 | and comments identifying the agent and any subproducts which form a | |
8091 | significant part of the user agent. By convention, the product tokens | |
8092 | are listed in order of their significance for identifying the | |
8093 | application. | |
8094 | ||
8095 | User-Agent = "User-Agent" ":" 1*( product | comment ) | |
8096 | ||
8097 | Example: | |
8098 | ||
8099 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |
8100 | ||
8101 | 14.44 Vary | |
8102 | ||
8103 | The Vary field value indicates the set of request-header fields that | |
8104 | fully determines, while the response is fresh, whether a cache is | |
8105 | permitted to use the response to reply to a subsequent request | |
8106 | without revalidation. For uncacheable or stale responses, the Vary | |
8107 | field value advises the user agent about the criteria that were used | |
8108 | to select the representation. A Vary field value of "*" implies that | |
8109 | a cache cannot determine from the request headers of a subsequent | |
8110 | request whether this response is the appropriate representation. See | |
8111 | section 13.6 for use of the Vary header field by caches. | |
8112 | ||
8113 | Vary = "Vary" ":" ( "*" | 1#field-name ) | |
8114 | ||
8115 | An HTTP/1.1 server SHOULD include a Vary header field with any | |
8116 | cacheable response that is subject to server-driven negotiation. | |
8117 | Doing so allows a cache to properly interpret future requests on that | |
8118 | resource and informs the user agent about the presence of negotiation | |
8119 | ||
8120 | ||
8121 | ||
8122 | Fielding, et al. Standards Track [Page 145] | |
8123 | \f | |
8124 | RFC 2616 HTTP/1.1 June 1999 | |
8125 | ||
8126 | ||
8127 | on that resource. A server MAY include a Vary header field with a | |
8128 | non-cacheable response that is subject to server-driven negotiation, | |
8129 | since this might provide the user agent with useful information about | |
8130 | the dimensions over which the response varies at the time of the | |
8131 | response. | |
8132 | ||
8133 | A Vary field value consisting of a list of field-names signals that | |
8134 | the representation selected for the response is based on a selection | |
8135 | algorithm which considers ONLY the listed request-header field values | |
8136 | in selecting the most appropriate representation. A cache MAY assume | |
8137 | that the same selection will be made for future requests with the | |
8138 | same values for the listed field names, for the duration of time for | |
8139 | which the response is fresh. | |
8140 | ||
8141 | The field-names given are not limited to the set of standard | |
8142 | request-header fields defined by this specification. Field names are | |
8143 | case-insensitive. | |
8144 | ||
8145 | A Vary field value of "*" signals that unspecified parameters not | |
8146 | limited to the request-headers (e.g., the network address of the | |
8147 | client), play a role in the selection of the response representation. | |
8148 | The "*" value MUST NOT be generated by a proxy server; it may only be | |
8149 | generated by an origin server. | |
8150 | ||
8151 | 14.45 Via | |
8152 | ||
8153 | The Via general-header field MUST be used by gateways and proxies to | |
8154 | indicate the intermediate protocols and recipients between the user | |
8155 | agent and the server on requests, and between the origin server and | |
8156 | the client on responses. It is analogous to the "Received" field of | |
8157 | RFC 822 [9] and is intended to be used for tracking message forwards, | |
8158 | avoiding request loops, and identifying the protocol capabilities of | |
8159 | all senders along the request/response chain. | |
8160 | ||
8161 | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |
8162 | received-protocol = [ protocol-name "/" ] protocol-version | |
8163 | protocol-name = token | |
8164 | protocol-version = token | |
8165 | received-by = ( host [ ":" port ] ) | pseudonym | |
8166 | pseudonym = token | |
8167 | ||
8168 | The received-protocol indicates the protocol version of the message | |
8169 | received by the server or client along each segment of the | |
8170 | request/response chain. The received-protocol version is appended to | |
8171 | the Via field value when the message is forwarded so that information | |
8172 | about the protocol capabilities of upstream applications remains | |
8173 | visible to all recipients. | |
8174 | ||
8175 | ||
8176 | ||
8177 | ||
8178 | Fielding, et al. Standards Track [Page 146] | |
8179 | \f | |
8180 | RFC 2616 HTTP/1.1 June 1999 | |
8181 | ||
8182 | ||
8183 | The protocol-name is optional if and only if it would be "HTTP". The | |
8184 | received-by field is normally the host and optional port number of a | |
8185 | recipient server or client that subsequently forwarded the message. | |
8186 | However, if the real host is considered to be sensitive information, | |
8187 | it MAY be replaced by a pseudonym. If the port is not given, it MAY | |
8188 | be assumed to be the default port of the received-protocol. | |
8189 | ||
8190 | Multiple Via field values represents each proxy or gateway that has | |
8191 | forwarded the message. Each recipient MUST append its information | |
8192 | such that the end result is ordered according to the sequence of | |
8193 | forwarding applications. | |
8194 | ||
8195 | Comments MAY be used in the Via header field to identify the software | |
8196 | of the recipient proxy or gateway, analogous to the User-Agent and | |
8197 | Server header fields. However, all comments in the Via field are | |
8198 | optional and MAY be removed by any recipient prior to forwarding the | |
8199 | message. | |
8200 | ||
8201 | For example, a request message could be sent from an HTTP/1.0 user | |
8202 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to | |
8203 | forward the request to a public proxy at nowhere.com, which completes | |
8204 | the request by forwarding it to the origin server at www.ics.uci.edu. | |
8205 | The request received by www.ics.uci.edu would then have the following | |
8206 | Via header field: | |
8207 | ||
8208 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) | |
8209 | ||
8210 | Proxies and gateways used as a portal through a network firewall | |
8211 | SHOULD NOT, by default, forward the names and ports of hosts within | |
8212 | the firewall region. This information SHOULD only be propagated if | |
8213 | explicitly enabled. If not enabled, the received-by host of any host | |
8214 | behind the firewall SHOULD be replaced by an appropriate pseudonym | |
8215 | for that host. | |
8216 | ||
8217 | For organizations that have strong privacy requirements for hiding | |
8218 | internal structures, a proxy MAY combine an ordered subsequence of | |
8219 | Via header field entries with identical received-protocol values into | |
8220 | a single such entry. For example, | |
8221 | ||
8222 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy | |
8223 | ||
8224 | could be collapsed to | |
8225 | ||
8226 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | |
8227 | ||
8228 | ||
8229 | ||
8230 | ||
8231 | ||
8232 | ||
8233 | ||
8234 | Fielding, et al. Standards Track [Page 147] | |
8235 | \f | |
8236 | RFC 2616 HTTP/1.1 June 1999 | |
8237 | ||
8238 | ||
8239 | Applications SHOULD NOT combine multiple entries unless they are all | |
8240 | under the same organizational control and the hosts have already been | |
8241 | replaced by pseudonyms. Applications MUST NOT combine entries which | |
8242 | have different received-protocol values. | |
8243 | ||
8244 | 14.46 Warning | |
8245 | ||
8246 | The Warning general-header field is used to carry additional | |
8247 | information about the status or transformation of a message which | |
8248 | might not be reflected in the message. This information is typically | |
8249 | used to warn about a possible lack of semantic transparency from | |
8250 | caching operations or transformations applied to the entity body of | |
8251 | the message. | |
8252 | ||
8253 | Warning headers are sent with responses using: | |
8254 | ||
8255 | Warning = "Warning" ":" 1#warning-value | |
8256 | ||
8257 | warning-value = warn-code SP warn-agent SP warn-text | |
8258 | [SP warn-date] | |
8259 | ||
8260 | warn-code = 3DIGIT | |
8261 | warn-agent = ( host [ ":" port ] ) | pseudonym | |
8262 | ; the name or pseudonym of the server adding | |
8263 | ; the Warning header, for use in debugging | |
8264 | warn-text = quoted-string | |
8265 | warn-date = <"> HTTP-date <"> | |
8266 | ||
8267 | A response MAY carry more than one Warning header. | |
8268 | ||
8269 | The warn-text SHOULD be in a natural language and character set that | |
8270 | is most likely to be intelligible to the human user receiving the | |
8271 | response. This decision MAY be based on any available knowledge, such | |
8272 | as the location of the cache or user, the Accept-Language field in a | |
8273 | request, the Content-Language field in a response, etc. The default | |
8274 | language is English and the default character set is ISO-8859-1. | |
8275 | ||
8276 | If a character set other than ISO-8859-1 is used, it MUST be encoded | |
8277 | in the warn-text using the method described in RFC 2047 [14]. | |
8278 | ||
8279 | Warning headers can in general be applied to any message, however | |
8280 | some specific warn-codes are specific to caches and can only be | |
8281 | applied to response messages. New Warning headers SHOULD be added | |
8282 | after any existing Warning headers. A cache MUST NOT delete any | |
8283 | Warning header that it received with a message. However, if a cache | |
8284 | successfully validates a cache entry, it SHOULD remove any Warning | |
8285 | headers previously attached to that entry except as specified for | |
8286 | ||
8287 | ||
8288 | ||
8289 | ||
8290 | Fielding, et al. Standards Track [Page 148] | |
8291 | \f | |
8292 | RFC 2616 HTTP/1.1 June 1999 | |
8293 | ||
8294 | ||
8295 | specific Warning codes. It MUST then add any Warning headers received | |
8296 | in the validating response. In other words, Warning headers are those | |
8297 | that would be attached to the most recent relevant response. | |
8298 | ||
8299 | When multiple Warning headers are attached to a response, the user | |
8300 | agent ought to inform the user of as many of them as possible, in the | |
8301 | order that they appear in the response. If it is not possible to | |
8302 | inform the user of all of the warnings, the user agent SHOULD follow | |
8303 | these heuristics: | |
8304 | ||
8305 | - Warnings that appear early in the response take priority over | |
8306 | those appearing later in the response. | |
8307 | ||
8308 | - Warnings in the user's preferred character set take priority | |
8309 | over warnings in other character sets but with identical warn- | |
8310 | codes and warn-agents. | |
8311 | ||
8312 | Systems that generate multiple Warning headers SHOULD order them with | |
8313 | this user agent behavior in mind. | |
8314 | ||
8315 | Requirements for the behavior of caches with respect to Warnings are | |
8316 | stated in section 13.1.2. | |
8317 | ||
8318 | This is a list of the currently-defined warn-codes, each with a | |
8319 | recommended warn-text in English, and a description of its meaning. | |
8320 | ||
8321 | 110 Response is stale | |
8322 | MUST be included whenever the returned response is stale. | |
8323 | ||
8324 | 111 Revalidation failed | |
8325 | MUST be included if a cache returns a stale response because an | |
8326 | attempt to revalidate the response failed, due to an inability to | |
8327 | reach the server. | |
8328 | ||
8329 | 112 Disconnected operation | |
8330 | SHOULD be included if the cache is intentionally disconnected from | |
8331 | the rest of the network for a period of time. | |
8332 | ||
8333 | 113 Heuristic expiration | |
8334 | MUST be included if the cache heuristically chose a freshness | |
8335 | lifetime greater than 24 hours and the response's age is greater | |
8336 | than 24 hours. | |
8337 | ||
8338 | 199 Miscellaneous warning | |
8339 | The warning text MAY include arbitrary information to be presented | |
8340 | to a human user, or logged. A system receiving this warning MUST | |
8341 | NOT take any automated action, besides presenting the warning to | |
8342 | the user. | |
8343 | ||
8344 | ||
8345 | ||
8346 | Fielding, et al. Standards Track [Page 149] | |
8347 | \f | |
8348 | RFC 2616 HTTP/1.1 June 1999 | |
8349 | ||
8350 | ||
8351 | 214 Transformation applied | |
8352 | MUST be added by an intermediate cache or proxy if it applies any | |
8353 | transformation changing the content-coding (as specified in the | |
8354 | Content-Encoding header) or media-type (as specified in the | |
8355 | Content-Type header) of the response, or the entity-body of the | |
8356 | response, unless this Warning code already appears in the response. | |
8357 | ||
8358 | 299 Miscellaneous persistent warning | |
8359 | The warning text MAY include arbitrary information to be presented | |
8360 | to a human user, or logged. A system receiving this warning MUST | |
8361 | NOT take any automated action. | |
8362 | ||
8363 | If an implementation sends a message with one or more Warning headers | |
8364 | whose version is HTTP/1.0 or lower, then the sender MUST include in | |
8365 | each warning-value a warn-date that matches the date in the response. | |
8366 | ||
8367 | If an implementation receives a message with a warning-value that | |
8368 | includes a warn-date, and that warn-date is different from the Date | |
8369 | value in the response, then that warning-value MUST be deleted from | |
8370 | the message before storing, forwarding, or using it. (This prevents | |
8371 | bad consequences of naive caching of Warning header fields.) If all | |
8372 | of the warning-values are deleted for this reason, the Warning header | |
8373 | MUST be deleted as well. | |
8374 | ||
8375 | 14.47 WWW-Authenticate | |
8376 | ||
8377 | The WWW-Authenticate response-header field MUST be included in 401 | |
8378 | (Unauthorized) response messages. The field value consists of at | |
8379 | least one challenge that indicates the authentication scheme(s) and | |
8380 | parameters applicable to the Request-URI. | |
8381 | ||
8382 | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | |
8383 | ||
8384 | The HTTP access authentication process is described in "HTTP | |
8385 | Authentication: Basic and Digest Access Authentication" [43]. User | |
8386 | agents are advised to take special care in parsing the WWW- | |
8387 | Authenticate field value as it might contain more than one challenge, | |
8388 | or if more than one WWW-Authenticate header field is provided, the | |
8389 | contents of a challenge itself can contain a comma-separated list of | |
8390 | authentication parameters. | |
8391 | ||
8392 | 15 Security Considerations | |
8393 | ||
8394 | This section is meant to inform application developers, information | |
8395 | providers, and users of the security limitations in HTTP/1.1 as | |
8396 | described by this document. The discussion does not include | |
8397 | definitive solutions to the problems revealed, though it does make | |
8398 | some suggestions for reducing security risks. | |
8399 | ||
8400 | ||
8401 | ||
8402 | Fielding, et al. Standards Track [Page 150] | |
8403 | \f | |
8404 | RFC 2616 HTTP/1.1 June 1999 | |
8405 | ||
8406 | ||
8407 | 15.1 Personal Information | |
8408 | ||
8409 | HTTP clients are often privy to large amounts of personal information | |
8410 | (e.g. the user's name, location, mail address, passwords, encryption | |
8411 | keys, etc.), and SHOULD be very careful to prevent unintentional | |
8412 | leakage of this information via the HTTP protocol to other sources. | |
8413 | We very strongly recommend that a convenient interface be provided | |
8414 | for the user to control dissemination of such information, and that | |
8415 | designers and implementors be particularly careful in this area. | |
8416 | History shows that errors in this area often create serious security | |
8417 | and/or privacy problems and generate highly adverse publicity for the | |
8418 | implementor's company. | |
8419 | ||
8420 | 15.1.1 Abuse of Server Log Information | |
8421 | ||
8422 | A server is in the position to save personal data about a user's | |
8423 | requests which might identify their reading patterns or subjects of | |
8424 | interest. This information is clearly confidential in nature and its | |
8425 | handling can be constrained by law in certain countries. People using | |
8426 | the HTTP protocol to provide data are responsible for ensuring that | |
8427 | such material is not distributed without the permission of any | |
8428 | individuals that are identifiable by the published results. | |
8429 | ||
8430 | 15.1.2 Transfer of Sensitive Information | |
8431 | ||
8432 | Like any generic data transfer protocol, HTTP cannot regulate the | |
8433 | content of the data that is transferred, nor is there any a priori | |
8434 | method of determining the sensitivity of any particular piece of | |
8435 | information within the context of any given request. Therefore, | |
8436 | applications SHOULD supply as much control over this information as | |
8437 | possible to the provider of that information. Four header fields are | |
8438 | worth special mention in this context: Server, Via, Referer and From. | |
8439 | ||
8440 | Revealing the specific software version of the server might allow the | |
8441 | server machine to become more vulnerable to attacks against software | |
8442 | that is known to contain security holes. Implementors SHOULD make the | |
8443 | Server header field a configurable option. | |
8444 | ||
8445 | Proxies which serve as a portal through a network firewall SHOULD | |
8446 | take special precautions regarding the transfer of header information | |
8447 | that identifies the hosts behind the firewall. In particular, they | |
8448 | SHOULD remove, or replace with sanitized versions, any Via fields | |
8449 | generated behind the firewall. | |
8450 | ||
8451 | The Referer header allows reading patterns to be studied and reverse | |
8452 | links drawn. Although it can be very useful, its power can be abused | |
8453 | if user details are not separated from the information contained in | |
8454 | ||
8455 | ||
8456 | ||
8457 | ||
8458 | Fielding, et al. Standards Track [Page 151] | |
8459 | \f | |
8460 | RFC 2616 HTTP/1.1 June 1999 | |
8461 | ||
8462 | ||
8463 | the Referer. Even when the personal information has been removed, the | |
8464 | Referer header might indicate a private document's URI whose | |
8465 | publication would be inappropriate. | |
8466 | ||
8467 | The information sent in the From field might conflict with the user's | |
8468 | privacy interests or their site's security policy, and hence it | |
8469 | SHOULD NOT be transmitted without the user being able to disable, | |
8470 | enable, and modify the contents of the field. The user MUST be able | |
8471 | to set the contents of this field within a user preference or | |
8472 | application defaults configuration. | |
8473 | ||
8474 | We suggest, though do not require, that a convenient toggle interface | |
8475 | be provided for the user to enable or disable the sending of From and | |
8476 | Referer information. | |
8477 | ||
8478 | The User-Agent (section 14.43) or Server (section 14.38) header | |
8479 | fields can sometimes be used to determine that a specific client or | |
8480 | server have a particular security hole which might be exploited. | |
8481 | Unfortunately, this same information is often used for other valuable | |
8482 | purposes for which HTTP currently has no better mechanism. | |
8483 | ||
8484 | 15.1.3 Encoding Sensitive Information in URI's | |
8485 | ||
8486 | Because the source of a link might be private information or might | |
8487 | reveal an otherwise private information source, it is strongly | |
8488 | recommended that the user be able to select whether or not the | |
8489 | Referer field is sent. For example, a browser client could have a | |
8490 | toggle switch for browsing openly/anonymously, which would | |
8491 | respectively enable/disable the sending of Referer and From | |
8492 | information. | |
8493 | ||
8494 | Clients SHOULD NOT include a Referer header field in a (non-secure) | |
8495 | HTTP request if the referring page was transferred with a secure | |
8496 | protocol. | |
8497 | ||
8498 | Authors of services which use the HTTP protocol SHOULD NOT use GET | |
8499 | based forms for the submission of sensitive data, because this will | |
8500 | cause this data to be encoded in the Request-URI. Many existing | |
8501 | servers, proxies, and user agents will log the request URI in some | |
8502 | place where it might be visible to third parties. Servers can use | |
8503 | POST-based form submission instead | |
8504 | ||
8505 | 15.1.4 Privacy Issues Connected to Accept Headers | |
8506 | ||
8507 | Accept request-headers can reveal information about the user to all | |
8508 | servers which are accessed. The Accept-Language header in particular | |
8509 | can reveal information the user would consider to be of a private | |
8510 | nature, because the understanding of particular languages is often | |
8511 | ||
8512 | ||
8513 | ||
8514 | Fielding, et al. Standards Track [Page 152] | |
8515 | \f | |
8516 | RFC 2616 HTTP/1.1 June 1999 | |
8517 | ||
8518 | ||
8519 | strongly correlated to the membership of a particular ethnic group. | |
8520 | User agents which offer the option to configure the contents of an | |
8521 | Accept-Language header to be sent in every request are strongly | |
8522 | encouraged to let the configuration process include a message which | |
8523 | makes the user aware of the loss of privacy involved. | |
8524 | ||
8525 | An approach that limits the loss of privacy would be for a user agent | |
8526 | to omit the sending of Accept-Language headers by default, and to ask | |
8527 | the user whether or not to start sending Accept-Language headers to a | |
8528 | server if it detects, by looking for any Vary response-header fields | |
8529 | generated by the server, that such sending could improve the quality | |
8530 | of service. | |
8531 | ||
8532 | Elaborate user-customized accept header fields sent in every request, | |
8533 | in particular if these include quality values, can be used by servers | |
8534 | as relatively reliable and long-lived user identifiers. Such user | |
8535 | identifiers would allow content providers to do click-trail tracking, | |
8536 | and would allow collaborating content providers to match cross-server | |
8537 | click-trails or form submissions of individual users. Note that for | |
8538 | many users not behind a proxy, the network address of the host | |
8539 | running the user agent will also serve as a long-lived user | |
8540 | identifier. In environments where proxies are used to enhance | |
8541 | privacy, user agents ought to be conservative in offering accept | |
8542 | header configuration options to end users. As an extreme privacy | |
8543 | measure, proxies could filter the accept headers in relayed requests. | |
8544 | General purpose user agents which provide a high degree of header | |
8545 | configurability SHOULD warn users about the loss of privacy which can | |
8546 | be involved. | |
8547 | ||
8548 | 15.2 Attacks Based On File and Path Names | |
8549 | ||
8550 | Implementations of HTTP origin servers SHOULD be careful to restrict | |
8551 | the documents returned by HTTP requests to be only those that were | |
8552 | intended by the server administrators. If an HTTP server translates | |
8553 | HTTP URIs directly into file system calls, the server MUST take | |
8554 | special care not to serve files that were not intended to be | |
8555 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | |
8556 | other operating systems use ".." as a path component to indicate a | |
8557 | directory level above the current one. On such a system, an HTTP | |
8558 | server MUST disallow any such construct in the Request-URI if it | |
8559 | would otherwise allow access to a resource outside those intended to | |
8560 | be accessible via the HTTP server. Similarly, files intended for | |
8561 | reference only internally to the server (such as access control | |
8562 | files, configuration files, and script code) MUST be protected from | |
8563 | inappropriate retrieval, since they might contain sensitive | |
8564 | information. Experience has shown that minor bugs in such HTTP server | |
8565 | implementations have turned into security risks. | |
8566 | ||
8567 | ||
8568 | ||
8569 | ||
8570 | Fielding, et al. Standards Track [Page 153] | |
8571 | \f | |
8572 | RFC 2616 HTTP/1.1 June 1999 | |
8573 | ||
8574 | ||
8575 | 15.3 DNS Spoofing | |
8576 | ||
8577 | Clients using HTTP rely heavily on the Domain Name Service, and are | |
8578 | thus generally prone to security attacks based on the deliberate | |
8579 | mis-association of IP addresses and DNS names. Clients need to be | |
8580 | cautious in assuming the continuing validity of an IP number/DNS name | |
8581 | association. | |
8582 | ||
8583 | In particular, HTTP clients SHOULD rely on their name resolver for | |
8584 | confirmation of an IP number/DNS name association, rather than | |
8585 | caching the result of previous host name lookups. Many platforms | |
8586 | already can cache host name lookups locally when appropriate, and | |
8587 | they SHOULD be configured to do so. It is proper for these lookups to | |
8588 | be cached, however, only when the TTL (Time To Live) information | |
8589 | reported by the name server makes it likely that the cached | |
8590 | information will remain useful. | |
8591 | ||
8592 | If HTTP clients cache the results of host name lookups in order to | |
8593 | achieve a performance improvement, they MUST observe the TTL | |
8594 | information reported by DNS. | |
8595 | ||
8596 | If HTTP clients do not observe this rule, they could be spoofed when | |
8597 | a previously-accessed server's IP address changes. As network | |
8598 | renumbering is expected to become increasingly common [24], the | |
8599 | possibility of this form of attack will grow. Observing this | |
8600 | requirement thus reduces this potential security vulnerability. | |
8601 | ||
8602 | This requirement also improves the load-balancing behavior of clients | |
8603 | for replicated servers using the same DNS name and reduces the | |
8604 | likelihood of a user's experiencing failure in accessing sites which | |
8605 | use that strategy. | |
8606 | ||
8607 | 15.4 Location Headers and Spoofing | |
8608 | ||
8609 | If a single server supports multiple organizations that do not trust | |
8610 | one another, then it MUST check the values of Location and Content- | |
8611 | Location headers in responses that are generated under control of | |
8612 | said organizations to make sure that they do not attempt to | |
8613 | invalidate resources over which they have no authority. | |
8614 | ||
8615 | 15.5 Content-Disposition Issues | |
8616 | ||
8617 | RFC 1806 [35], from which the often implemented Content-Disposition | |
8618 | (see section 19.5.1) header in HTTP is derived, has a number of very | |
8619 | serious security considerations. Content-Disposition is not part of | |
8620 | the HTTP standard, but since it is widely implemented, we are | |
8621 | documenting its use and risks for implementors. See RFC 2183 [49] | |
8622 | (which updates RFC 1806) for details. | |
8623 | ||
8624 | ||
8625 | ||
8626 | Fielding, et al. Standards Track [Page 154] | |
8627 | \f | |
8628 | RFC 2616 HTTP/1.1 June 1999 | |
8629 | ||
8630 | ||
8631 | 15.6 Authentication Credentials and Idle Clients | |
8632 | ||
8633 | Existing HTTP clients and user agents typically retain authentication | |
8634 | information indefinitely. HTTP/1.1. does not provide a method for a | |
8635 | server to direct clients to discard these cached credentials. This is | |
8636 | a significant defect that requires further extensions to HTTP. | |
8637 | Circumstances under which credential caching can interfere with the | |
8638 | application's security model include but are not limited to: | |
8639 | ||
8640 | - Clients which have been idle for an extended period following | |
8641 | which the server might wish to cause the client to reprompt the | |
8642 | user for credentials. | |
8643 | ||
8644 | - Applications which include a session termination indication | |
8645 | (such as a `logout' or `commit' button on a page) after which | |
8646 | the server side of the application `knows' that there is no | |
8647 | further reason for the client to retain the credentials. | |
8648 | ||
8649 | This is currently under separate study. There are a number of work- | |
8650 | arounds to parts of this problem, and we encourage the use of | |
8651 | password protection in screen savers, idle time-outs, and other | |
8652 | methods which mitigate the security problems inherent in this | |
8653 | problem. In particular, user agents which cache credentials are | |
8654 | encouraged to provide a readily accessible mechanism for discarding | |
8655 | cached credentials under user control. | |
8656 | ||
8657 | 15.7 Proxies and Caching | |
8658 | ||
8659 | By their very nature, HTTP proxies are men-in-the-middle, and | |
8660 | represent an opportunity for man-in-the-middle attacks. Compromise of | |
8661 | the systems on which the proxies run can result in serious security | |
8662 | and privacy problems. Proxies have access to security-related | |
8663 | information, personal information about individual users and | |
8664 | organizations, and proprietary information belonging to users and | |
8665 | content providers. A compromised proxy, or a proxy implemented or | |
8666 | configured without regard to security and privacy considerations, | |
8667 | might be used in the commission of a wide range of potential attacks. | |
8668 | ||
8669 | Proxy operators should protect the systems on which proxies run as | |
8670 | they would protect any system that contains or transports sensitive | |
8671 | information. In particular, log information gathered at proxies often | |
8672 | contains highly sensitive personal information, and/or information | |
8673 | about organizations. Log information should be carefully guarded, and | |
8674 | appropriate guidelines for use developed and followed. (Section | |
8675 | 15.1.1). | |
8676 | ||
8677 | ||
8678 | ||
8679 | ||
8680 | ||
8681 | ||
8682 | Fielding, et al. Standards Track [Page 155] | |
8683 | \f | |
8684 | RFC 2616 HTTP/1.1 June 1999 | |
8685 | ||
8686 | ||
8687 | Caching proxies provide additional potential vulnerabilities, since | |
8688 | the contents of the cache represent an attractive target for | |
8689 | malicious exploitation. Because cache contents persist after an HTTP | |
8690 | request is complete, an attack on the cache can reveal information | |
8691 | long after a user believes that the information has been removed from | |
8692 | the network. Therefore, cache contents should be protected as | |
8693 | sensitive information. | |
8694 | ||
8695 | Proxy implementors should consider the privacy and security | |
8696 | implications of their design and coding decisions, and of the | |
8697 | configuration options they provide to proxy operators (especially the | |
8698 | default configuration). | |
8699 | ||
8700 | Users of a proxy need to be aware that they are no trustworthier than | |
8701 | the people who run the proxy; HTTP itself cannot solve this problem. | |
8702 | ||
8703 | The judicious use of cryptography, when appropriate, may suffice to | |
8704 | protect against a broad range of security and privacy attacks. Such | |
8705 | cryptography is beyond the scope of the HTTP/1.1 specification. | |
8706 | ||
8707 | 15.7.1 Denial of Service Attacks on Proxies | |
8708 | ||
8709 | They exist. They are hard to defend against. Research continues. | |
8710 | Beware. | |
8711 | ||
8712 | 16 Acknowledgments | |
8713 | ||
8714 | This specification makes heavy use of the augmented BNF and generic | |
8715 | constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it | |
8716 | reuses many of the definitions provided by Nathaniel Borenstein and | |
8717 | Ned Freed for MIME [7]. We hope that their inclusion in this | |
8718 | specification will help reduce past confusion over the relationship | |
8719 | between HTTP and Internet mail message formats. | |
8720 | ||
8721 | The HTTP protocol has evolved considerably over the years. It has | |
8722 | benefited from a large and active developer community--the many | |
8723 | people who have participated on the www-talk mailing list--and it is | |
8724 | that community which has been most responsible for the success of | |
8725 | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | |
8726 | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | |
8727 | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | |
8728 | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | |
8729 | VanHeyningen deserve special recognition for their efforts in | |
8730 | defining early aspects of the protocol. | |
8731 | ||
8732 | This document has benefited greatly from the comments of all those | |
8733 | participating in the HTTP-WG. In addition to those already mentioned, | |
8734 | the following individuals have contributed to this specification: | |
8735 | ||
8736 | ||
8737 | ||
8738 | Fielding, et al. Standards Track [Page 156] | |
8739 | \f | |
8740 | RFC 2616 HTTP/1.1 June 1999 | |
8741 | ||
8742 | ||
8743 | Gary Adams Ross Patterson | |
8744 | Harald Tveit Alvestrand Albert Lunde | |
8745 | Keith Ball John C. Mallery | |
8746 | Brian Behlendorf Jean-Philippe Martin-Flatin | |
8747 | Paul Burchard Mitra | |
8748 | Maurizio Codogno David Morris | |
8749 | Mike Cowlishaw Gavin Nicol | |
8750 | Roman Czyborra Bill Perry | |
8751 | Michael A. Dolan Jeffrey Perry | |
8752 | David J. Fiander Scott Powers | |
8753 | Alan Freier Owen Rees | |
8754 | Marc Hedlund Luigi Rizzo | |
8755 | Greg Herlihy David Robinson | |
8756 | Koen Holtman Marc Salomon | |
8757 | Alex Hopmann Rich Salz | |
8758 | Bob Jernigan Allan M. Schiffman | |
8759 | Shel Kaphan Jim Seidman | |
8760 | Rohit Khare Chuck Shotton | |
8761 | John Klensin Eric W. Sink | |
8762 | Martijn Koster Simon E. Spero | |
8763 | Alexei Kosut Richard N. Taylor | |
8764 | David M. Kristol Robert S. Thau | |
8765 | Daniel LaLiberte Bill (BearHeart) Weinman | |
8766 | Ben Laurie Francois Yergeau | |
8767 | Paul J. Leach Mary Ellen Zurko | |
8768 | Daniel DuBois Josh Cohen | |
8769 | ||
8770 | ||
8771 | Much of the content and presentation of the caching design is due to | |
8772 | suggestions and comments from individuals including: Shel Kaphan, | |
8773 | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | |
8774 | ||
8775 | Most of the specification of ranges is based on work originally done | |
8776 | by Ari Luotonen and John Franks, with additional input from Steve | |
8777 | Zilles. | |
8778 | ||
8779 | Thanks to the "cave men" of Palo Alto. You know who you are. | |
8780 | ||
8781 | Jim Gettys (the current editor of this document) wishes particularly | |
8782 | to thank Roy Fielding, the previous editor of this document, along | |
8783 | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | |
8784 | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | |
8785 | Larry Masinter for their help. And thanks go particularly to Jeff | |
8786 | Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. | |
8787 | ||
8788 | ||
8789 | ||
8790 | ||
8791 | ||
8792 | ||
8793 | ||
8794 | Fielding, et al. Standards Track [Page 157] | |
8795 | \f | |
8796 | RFC 2616 HTTP/1.1 June 1999 | |
8797 | ||
8798 | ||
8799 | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik | |
8800 | Frystyk implemented RFC 2068 early, and we wish to thank them for the | |
8801 | discovery of many of the problems that this document attempts to | |
8802 | rectify. | |
8803 | ||
8804 | 17 References | |
8805 | ||
8806 | [1] Alvestrand, H., "Tags for the Identification of Languages", RFC | |
8807 | 1766, March 1995. | |
8808 | ||
8809 | [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | |
8810 | D. and B. Alberti, "The Internet Gopher Protocol (a distributed | |
8811 | document search and retrieval protocol)", RFC 1436, March 1993. | |
8812 | ||
8813 | [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC | |
8814 | 1630, June 1994. | |
8815 | ||
8816 | [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource | |
8817 | Locators (URL)", RFC 1738, December 1994. | |
8818 | ||
8819 | [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - | |
8820 | 2.0", RFC 1866, November 1995. | |
8821 | ||
8822 | [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer | |
8823 | Protocol -- HTTP/1.0", RFC 1945, May 1996. | |
8824 | ||
8825 | [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
8826 | Extensions (MIME) Part One: Format of Internet Message Bodies", | |
8827 | RFC 2045, November 1996. | |
8828 | ||
8829 | [8] Braden, R., "Requirements for Internet Hosts -- Communication | |
8830 | Layers", STD 3, RFC 1123, October 1989. | |
8831 | ||
8832 | [9] Crocker, D., "Standard for The Format of ARPA Internet Text | |
8833 | Messages", STD 11, RFC 822, August 1982. | |
8834 | ||
8835 | [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., | |
8836 | Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype | |
8837 | Functional Specification," (v1.5), Thinking Machines | |
8838 | Corporation, April 1990. | |
8839 | ||
8840 | [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, | |
8841 | June 1995. | |
8842 | ||
8843 | [12] Horton, M. and R. Adams, "Standard for Interchange of USENET | |
8844 | Messages", RFC 1036, December 1987. | |
8845 | ||
8846 | ||
8847 | ||
8848 | ||
8849 | ||
8850 | Fielding, et al. Standards Track [Page 158] | |
8851 | \f | |
8852 | RFC 2616 HTTP/1.1 June 1999 | |
8853 | ||
8854 | ||
8855 | [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC | |
8856 | 977, February 1986. | |
8857 | ||
8858 | [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | |
8859 | Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | |
8860 | November 1996. | |
8861 | ||
8862 | [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC | |
8863 | 1867, November 1995. | |
8864 | ||
8865 | [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | |
8866 | August 1982. | |
8867 | ||
8868 | [17] Postel, J., "Media Type Registration Procedure", RFC 1590, | |
8869 | November 1996. | |
8870 | ||
8871 | [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC | |
8872 | 959, October 1985. | |
8873 | ||
8874 | [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, | |
8875 | October 1994. | |
8876 | ||
8877 | [20] Sollins, K. and L. Masinter, "Functional Requirements for | |
8878 | Uniform Resource Names", RFC 1737, December 1994. | |
8879 | ||
8880 | [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for | |
8881 | Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. | |
8882 | ||
8883 | [22] ISO-8859. International Standard -- Information Processing -- | |
8884 | 8-bit Single-Byte Coded Graphic Character Sets -- | |
8885 | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. | |
8886 | Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. | |
8887 | Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. | |
8888 | Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. | |
8889 | Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. | |
8890 | Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. | |
8891 | Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. | |
8892 | Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | |
8893 | Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | |
8894 | ||
8895 | [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC | |
8896 | 1864, October 1995. | |
8897 | ||
8898 | [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC | |
8899 | 1900, February 1996. | |
8900 | ||
8901 | [25] Deutsch, P., "GZIP file format specification version 4.3", RFC | |
8902 | 1952, May 1996. | |
8903 | ||
8904 | ||
8905 | ||
8906 | Fielding, et al. Standards Track [Page 159] | |
8907 | \f | |
8908 | RFC 2616 HTTP/1.1 June 1999 | |
8909 | ||
8910 | ||
8911 | [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP | |
8912 | Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, | |
8913 | Dec. 1995. Slightly revised version of paper in Proc. 2nd | |
8914 | International WWW Conference '94: Mosaic and the Web, Oct. 1994, | |
8915 | which is available at | |
8916 | http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat | |
8917 | ency.html. | |
8918 | ||
8919 | [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP | |
8920 | Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, | |
8921 | ISI Research Report ISI/RR-98-463, (original report dated Aug. | |
8922 | 1996), USC/Information Sciences Institute, August 1998. | |
8923 | ||
8924 | [28] Mills, D., "Network Time Protocol (Version 3) Specification, | |
8925 | Implementation and Analysis", RFC 1305, March 1992. | |
8926 | ||
8927 | [29] Deutsch, P., "DEFLATE Compressed Data Format Specification | |
8928 | version 1.3", RFC 1951, May 1996. | |
8929 | ||
8930 | [30] S. Spero, "Analysis of HTTP Performance Problems," | |
8931 | http://sunsite.unc.edu/mdma-release/http-prob.html. | |
8932 | ||
8933 | [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format | |
8934 | Specification version 3.3", RFC 1950, May 1996. | |
8935 | ||
8936 | [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |
8937 | Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: | |
8938 | Digest Access Authentication", RFC 2069, January 1997. | |
8939 | ||
8940 | [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. | |
8941 | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC | |
8942 | 2068, January 1997. | |
8943 | ||
8944 | [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
8945 | Levels", BCP 14, RFC 2119, March 1997. | |
8946 | ||
8947 | [35] Troost, R. and Dorner, S., "Communicating Presentation | |
8948 | Information in Internet Messages: The Content-Disposition | |
8949 | Header", RFC 1806, June 1995. | |
8950 | ||
8951 | [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and | |
8952 | Interpretation of HTTP Version Numbers", RFC 2145, May 1997. | |
8953 | [jg639] | |
8954 | ||
8955 | [37] Palme, J., "Common Internet Message Headers", RFC 2076, February | |
8956 | 1997. [jg640] | |
8957 | ||
8958 | ||
8959 | ||
8960 | ||
8961 | ||
8962 | Fielding, et al. Standards Track [Page 160] | |
8963 | \f | |
8964 | RFC 2616 HTTP/1.1 June 1999 | |
8965 | ||
8966 | ||
8967 | [38] Yergeau, F., "UTF-8, a transformation format of Unicode and | |
8968 | ISO-10646", RFC 2279, January 1998. [jg641] | |
8969 | ||
8970 | [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., | |
8971 | Lie, H., and C. Lilley. "Network Performance Effects of | |
8972 | HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes | |
8973 | France, September 1997.[jg642] | |
8974 | ||
8975 | [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
8976 | Extensions (MIME) Part Two: Media Types", RFC 2046, November | |
8977 | 1996. [jg643] | |
8978 | ||
8979 | [41] Alvestrand, H., "IETF Policy on Character Sets and Languages", | |
8980 | BCP 18, RFC 2277, January 1998. [jg644] | |
8981 | ||
8982 | [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource | |
8983 | Identifiers (URI): Generic Syntax and Semantics", RFC 2396, | |
8984 | August 1998. [jg645] | |
8985 | ||
8986 | [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |
8987 | Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP | |
8988 | Authentication: Basic and Digest Access Authentication", RFC | |
8989 | 2617, June 1999. [jg646] | |
8990 | ||
8991 | [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy | |
8992 | servers," Work in Progress. [jg647] | |
8993 | ||
8994 | [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | |
8995 | Aggregate Documents, such as HTML (MHTML)", RFC 2110, March | |
8996 | 1997. | |
8997 | ||
8998 | [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | |
8999 | 9, RFC 2026, October 1996. | |
9000 | ||
9001 | [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |
9002 | (HTCPCP/1.0)", RFC 2324, 1 April 1998. | |
9003 | ||
9004 | [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
9005 | Extensions (MIME) Part Five: Conformance Criteria and Examples", | |
9006 | RFC 2049, November 1996. | |
9007 | ||
9008 | [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation | |
9009 | Information in Internet Messages: The Content-Disposition Header | |
9010 | Field", RFC 2183, August 1997. | |
9011 | ||
9012 | ||
9013 | ||
9014 | ||
9015 | ||
9016 | ||
9017 | ||
9018 | Fielding, et al. Standards Track [Page 161] | |
9019 | \f | |
9020 | RFC 2616 HTTP/1.1 June 1999 | |
9021 | ||
9022 | ||
9023 | 18 Authors' Addresses | |
9024 | ||
9025 | Roy T. Fielding | |
9026 | Information and Computer Science | |
9027 | University of California, Irvine | |
9028 | Irvine, CA 92697-3425, USA | |
9029 | ||
9030 | Fax: +1 (949) 824-1715 | |
9031 | EMail: fielding@ics.uci.edu | |
9032 | ||
9033 | ||
9034 | James Gettys | |
9035 | World Wide Web Consortium | |
9036 | MIT Laboratory for Computer Science | |
9037 | 545 Technology Square | |
9038 | Cambridge, MA 02139, USA | |
9039 | ||
9040 | Fax: +1 (617) 258 8682 | |
9041 | EMail: jg@w3.org | |
9042 | ||
9043 | ||
9044 | Jeffrey C. Mogul | |
9045 | Western Research Laboratory | |
9046 | Compaq Computer Corporation | |
9047 | 250 University Avenue | |
9048 | Palo Alto, California, 94305, USA | |
9049 | ||
9050 | EMail: mogul@wrl.dec.com | |
9051 | ||
9052 | ||
9053 | Henrik Frystyk Nielsen | |
9054 | World Wide Web Consortium | |
9055 | MIT Laboratory for Computer Science | |
9056 | 545 Technology Square | |
9057 | Cambridge, MA 02139, USA | |
9058 | ||
9059 | Fax: +1 (617) 258 8682 | |
9060 | EMail: frystyk@w3.org | |
9061 | ||
9062 | ||
9063 | Larry Masinter | |
9064 | Xerox Corporation | |
9065 | 3333 Coyote Hill Road | |
9066 | Palo Alto, CA 94034, USA | |
9067 | ||
9068 | EMail: masinter@parc.xerox.com | |
9069 | ||
9070 | ||
9071 | ||
9072 | ||
9073 | ||
9074 | Fielding, et al. Standards Track [Page 162] | |
9075 | \f | |
9076 | RFC 2616 HTTP/1.1 June 1999 | |
9077 | ||
9078 | ||
9079 | Paul J. Leach | |
9080 | Microsoft Corporation | |
9081 | 1 Microsoft Way | |
9082 | Redmond, WA 98052, USA | |
9083 | ||
9084 | EMail: paulle@microsoft.com | |
9085 | ||
9086 | ||
9087 | Tim Berners-Lee | |
9088 | Director, World Wide Web Consortium | |
9089 | MIT Laboratory for Computer Science | |
9090 | 545 Technology Square | |
9091 | Cambridge, MA 02139, USA | |
9092 | ||
9093 | Fax: +1 (617) 258 8682 | |
9094 | EMail: timbl@w3.org | |
9095 | ||
9096 | ||
9097 | ||
9098 | ||
9099 | ||
9100 | ||
9101 | ||
9102 | ||
9103 | ||
9104 | ||
9105 | ||
9106 | ||
9107 | ||
9108 | ||
9109 | ||
9110 | ||
9111 | ||
9112 | ||
9113 | ||
9114 | ||
9115 | ||
9116 | ||
9117 | ||
9118 | ||
9119 | ||
9120 | ||
9121 | ||
9122 | ||
9123 | ||
9124 | ||
9125 | ||
9126 | ||
9127 | ||
9128 | ||
9129 | ||
9130 | Fielding, et al. Standards Track [Page 163] | |
9131 | \f | |
9132 | RFC 2616 HTTP/1.1 June 1999 | |
9133 | ||
9134 | ||
9135 | 19 Appendices | |
9136 | ||
9137 | 19.1 Internet Media Type message/http and application/http | |
9138 | ||
9139 | In addition to defining the HTTP/1.1 protocol, this document serves | |
9140 | as the specification for the Internet media type "message/http" and | |
9141 | "application/http". The message/http type can be used to enclose a | |
9142 | single HTTP request or response message, provided that it obeys the | |
9143 | MIME restrictions for all "message" types regarding line length and | |
9144 | encodings. The application/http type can be used to enclose a | |
9145 | pipeline of one or more HTTP request or response messages (not | |
9146 | intermixed). The following is to be registered with IANA [17]. | |
9147 | ||
9148 | Media Type name: message | |
9149 | Media subtype name: http | |
9150 | Required parameters: none | |
9151 | Optional parameters: version, msgtype | |
9152 | version: The HTTP-Version number of the enclosed message | |
9153 | (e.g., "1.1"). If not present, the version can be | |
9154 | determined from the first line of the body. | |
9155 | msgtype: The message type -- "request" or "response". If not | |
9156 | present, the type can be determined from the first | |
9157 | line of the body. | |
9158 | Encoding considerations: only "7bit", "8bit", or "binary" are | |
9159 | permitted | |
9160 | Security considerations: none | |
9161 | ||
9162 | Media Type name: application | |
9163 | Media subtype name: http | |
9164 | Required parameters: none | |
9165 | Optional parameters: version, msgtype | |
9166 | version: The HTTP-Version number of the enclosed messages | |
9167 | (e.g., "1.1"). If not present, the version can be | |
9168 | determined from the first line of the body. | |
9169 | msgtype: The message type -- "request" or "response". If not | |
9170 | present, the type can be determined from the first | |
9171 | line of the body. | |
9172 | Encoding considerations: HTTP messages enclosed by this type | |
9173 | are in "binary" format; use of an appropriate | |
9174 | Content-Transfer-Encoding is required when | |
9175 | transmitted via E-mail. | |
9176 | Security considerations: none | |
9177 | ||
9178 | ||
9179 | ||
9180 | ||
9181 | ||
9182 | ||
9183 | ||
9184 | ||
9185 | ||
9186 | Fielding, et al. Standards Track [Page 164] | |
9187 | \f | |
9188 | RFC 2616 HTTP/1.1 June 1999 | |
9189 | ||
9190 | ||
9191 | 19.2 Internet Media Type multipart/byteranges | |
9192 | ||
9193 | When an HTTP 206 (Partial Content) response message includes the | |
9194 | content of multiple ranges (a response to a request for multiple | |
9195 | non-overlapping ranges), these are transmitted as a multipart | |
9196 | message-body. The media type for this purpose is called | |
9197 | "multipart/byteranges". | |
9198 | ||
9199 | The multipart/byteranges media type includes two or more parts, each | |
9200 | with its own Content-Type and Content-Range fields. The required | |
9201 | boundary parameter specifies the boundary string used to separate | |
9202 | each body-part. | |
9203 | ||
9204 | Media Type name: multipart | |
9205 | Media subtype name: byteranges | |
9206 | Required parameters: boundary | |
9207 | Optional parameters: none | |
9208 | Encoding considerations: only "7bit", "8bit", or "binary" are | |
9209 | permitted | |
9210 | Security considerations: none | |
9211 | ||
9212 | ||
9213 | For example: | |
9214 | ||
9215 | HTTP/1.1 206 Partial Content | |
9216 | Date: Wed, 15 Nov 1995 06:25:24 GMT | |
9217 | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |
9218 | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | |
9219 | ||
9220 | --THIS_STRING_SEPARATES | |
9221 | Content-type: application/pdf | |
9222 | Content-range: bytes 500-999/8000 | |
9223 | ||
9224 | ...the first range... | |
9225 | --THIS_STRING_SEPARATES | |
9226 | Content-type: application/pdf | |
9227 | Content-range: bytes 7000-7999/8000 | |
9228 | ||
9229 | ...the second range | |
9230 | --THIS_STRING_SEPARATES-- | |
9231 | ||
9232 | Notes: | |
9233 | ||
9234 | 1) Additional CRLFs may precede the first boundary string in the | |
9235 | entity. | |
9236 | ||
9237 | ||
9238 | ||
9239 | ||
9240 | ||
9241 | ||
9242 | Fielding, et al. Standards Track [Page 165] | |
9243 | \f | |
9244 | RFC 2616 HTTP/1.1 June 1999 | |
9245 | ||
9246 | ||
9247 | 2) Although RFC 2046 [40] permits the boundary string to be | |
9248 | quoted, some existing implementations handle a quoted boundary | |
9249 | string incorrectly. | |
9250 | ||
9251 | 3) A number of browsers and servers were coded to an early draft | |
9252 | of the byteranges specification to use a media type of | |
9253 | multipart/x-byteranges, which is almost, but not quite | |
9254 | compatible with the version documented in HTTP/1.1. | |
9255 | ||
9256 | 19.3 Tolerant Applications | |
9257 | ||
9258 | Although this document specifies the requirements for the generation | |
9259 | of HTTP/1.1 messages, not all applications will be correct in their | |
9260 | implementation. We therefore recommend that operational applications | |
9261 | be tolerant of deviations whenever those deviations can be | |
9262 | interpreted unambiguously. | |
9263 | ||
9264 | Clients SHOULD be tolerant in parsing the Status-Line and servers | |
9265 | tolerant when parsing the Request-Line. In particular, they SHOULD | |
9266 | accept any amount of SP or HT characters between fields, even though | |
9267 | only a single SP is required. | |
9268 | ||
9269 | The line terminator for message-header fields is the sequence CRLF. | |
9270 | However, we recommend that applications, when parsing such headers, | |
9271 | recognize a single LF as a line terminator and ignore the leading CR. | |
9272 | ||
9273 | The character set of an entity-body SHOULD be labeled as the lowest | |
9274 | common denominator of the character codes used within that body, with | |
9275 | the exception that not labeling the entity is preferred over labeling | |
9276 | the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 | |
9277 | and 3.4.1. | |
9278 | ||
9279 | Additional rules for requirements on parsing and encoding of dates | |
9280 | and other potential problems with date encodings include: | |
9281 | ||
9282 | - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | |
9283 | which appears to be more than 50 years in the future is in fact | |
9284 | in the past (this helps solve the "year 2000" problem). | |
9285 | ||
9286 | - An HTTP/1.1 implementation MAY internally represent a parsed | |
9287 | Expires date as earlier than the proper value, but MUST NOT | |
9288 | internally represent a parsed Expires date as later than the | |
9289 | proper value. | |
9290 | ||
9291 | - All expiration-related calculations MUST be done in GMT. The | |
9292 | local time zone MUST NOT influence the calculation or comparison | |
9293 | of an age or expiration time. | |
9294 | ||
9295 | ||
9296 | ||
9297 | ||
9298 | Fielding, et al. Standards Track [Page 166] | |
9299 | \f | |
9300 | RFC 2616 HTTP/1.1 June 1999 | |
9301 | ||
9302 | ||
9303 | - If an HTTP header incorrectly carries a date value with a time | |
9304 | zone other than GMT, it MUST be converted into GMT using the | |
9305 | most conservative possible conversion. | |
9306 | ||
9307 | 19.4 Differences Between HTTP Entities and RFC 2045 Entities | |
9308 | ||
9309 | HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | |
9310 | 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | |
9311 | allow entities to be transmitted in an open variety of | |
9312 | representations and with extensible mechanisms. However, RFC 2045 | |
9313 | discusses mail, and HTTP has a few features that are different from | |
9314 | those described in RFC 2045. These differences were carefully chosen | |
9315 | to optimize performance over binary connections, to allow greater | |
9316 | freedom in the use of new media types, to make date comparisons | |
9317 | easier, and to acknowledge the practice of some early HTTP servers | |
9318 | and clients. | |
9319 | ||
9320 | This appendix describes specific areas where HTTP differs from RFC | |
9321 | 2045. Proxies and gateways to strict MIME environments SHOULD be | |
9322 | aware of these differences and provide the appropriate conversions | |
9323 | where necessary. Proxies and gateways from MIME environments to HTTP | |
9324 | also need to be aware of the differences because some conversions | |
9325 | might be required. | |
9326 | ||
9327 | 19.4.1 MIME-Version | |
9328 | ||
9329 | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY | |
9330 | include a single MIME-Version general-header field to indicate what | |
9331 | version of the MIME protocol was used to construct the message. Use | |
9332 | of the MIME-Version header field indicates that the message is in | |
9333 | full compliance with the MIME protocol (as defined in RFC 2045[7]). | |
9334 | Proxies/gateways are responsible for ensuring full compliance (where | |
9335 | possible) when exporting HTTP messages to strict MIME environments. | |
9336 | ||
9337 | MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |
9338 | ||
9339 | MIME version "1.0" is the default for use in HTTP/1.1. However, | |
9340 | HTTP/1.1 message parsing and semantics are defined by this document | |
9341 | and not the MIME specification. | |
9342 | ||
9343 | 19.4.2 Conversion to Canonical Form | |
9344 | ||
9345 | RFC 2045 [7] requires that an Internet mail entity be converted to | |
9346 | canonical form prior to being transferred, as described in section 4 | |
9347 | of RFC 2049 [48]. Section 3.7.1 of this document describes the forms | |
9348 | allowed for subtypes of the "text" media type when transmitted over | |
9349 | HTTP. RFC 2046 requires that content with a type of "text" represent | |
9350 | line breaks as CRLF and forbids the use of CR or LF outside of line | |
9351 | ||
9352 | ||
9353 | ||
9354 | Fielding, et al. Standards Track [Page 167] | |
9355 | \f | |
9356 | RFC 2616 HTTP/1.1 June 1999 | |
9357 | ||
9358 | ||
9359 | break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a | |
9360 | line break within text content when a message is transmitted over | |
9361 | HTTP. | |
9362 | ||
9363 | Where it is possible, a proxy or gateway from HTTP to a strict MIME | |
9364 | environment SHOULD translate all line breaks within the text media | |
9365 | types described in section 3.7.1 of this document to the RFC 2049 | |
9366 | canonical form of CRLF. Note, however, that this might be complicated | |
9367 | by the presence of a Content-Encoding and by the fact that HTTP | |
9368 | allows the use of some character sets which do not use octets 13 and | |
9369 | 10 to represent CR and LF, as is the case for some multi-byte | |
9370 | character sets. | |
9371 | ||
9372 | Implementors should note that conversion will break any cryptographic | |
9373 | checksums applied to the original content unless the original content | |
9374 | is already in canonical form. Therefore, the canonical form is | |
9375 | recommended for any content that uses such checksums in HTTP. | |
9376 | ||
9377 | 19.4.3 Conversion of Date Formats | |
9378 | ||
9379 | HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to | |
9380 | simplify the process of date comparison. Proxies and gateways from | |
9381 | other protocols SHOULD ensure that any Date header field present in a | |
9382 | message conforms to one of the HTTP/1.1 formats and rewrite the date | |
9383 | if necessary. | |
9384 | ||
9385 | 19.4.4 Introduction of Content-Encoding | |
9386 | ||
9387 | RFC 2045 does not include any concept equivalent to HTTP/1.1's | |
9388 | Content-Encoding header field. Since this acts as a modifier on the | |
9389 | media type, proxies and gateways from HTTP to MIME-compliant | |
9390 | protocols MUST either change the value of the Content-Type header | |
9391 | field or decode the entity-body before forwarding the message. (Some | |
9392 | experimental applications of Content-Type for Internet mail have used | |
9393 | a media-type parameter of ";conversions=<content-coding>" to perform | |
9394 | a function equivalent to Content-Encoding. However, this parameter is | |
9395 | not part of RFC 2045.) | |
9396 | ||
9397 | 19.4.5 No Content-Transfer-Encoding | |
9398 | ||
9399 | HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC | |
9400 | 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST | |
9401 | remove any non-identity CTE ("quoted-printable" or "base64") encoding | |
9402 | prior to delivering the response message to an HTTP client. | |
9403 | ||
9404 | Proxies and gateways from HTTP to MIME-compliant protocols are | |
9405 | responsible for ensuring that the message is in the correct format | |
9406 | and encoding for safe transport on that protocol, where "safe | |
9407 | ||
9408 | ||
9409 | ||
9410 | Fielding, et al. Standards Track [Page 168] | |
9411 | \f | |
9412 | RFC 2616 HTTP/1.1 June 1999 | |
9413 | ||
9414 | ||
9415 | transport" is defined by the limitations of the protocol being used. | |
9416 | Such a proxy or gateway SHOULD label the data with an appropriate | |
9417 | Content-Transfer-Encoding if doing so will improve the likelihood of | |
9418 | safe transport over the destination protocol. | |
9419 | ||
9420 | 19.4.6 Introduction of Transfer-Encoding | |
9421 | ||
9422 | HTTP/1.1 introduces the Transfer-Encoding header field (section | |
9423 | 14.41). Proxies/gateways MUST remove any transfer-coding prior to | |
9424 | forwarding a message via a MIME-compliant protocol. | |
9425 | ||
9426 | A process for decoding the "chunked" transfer-coding (section 3.6) | |
9427 | can be represented in pseudo-code as: | |
9428 | ||
9429 | length := 0 | |
9430 | read chunk-size, chunk-extension (if any) and CRLF | |
9431 | while (chunk-size > 0) { | |
9432 | read chunk-data and CRLF | |
9433 | append chunk-data to entity-body | |
9434 | length := length + chunk-size | |
9435 | read chunk-size and CRLF | |
9436 | } | |
9437 | read entity-header | |
9438 | while (entity-header not empty) { | |
9439 | append entity-header to existing header fields | |
9440 | read entity-header | |
9441 | } | |
9442 | Content-Length := length | |
9443 | Remove "chunked" from Transfer-Encoding | |
9444 | ||
9445 | 19.4.7 MHTML and Line Length Limitations | |
9446 | ||
9447 | HTTP implementations which share code with MHTML [45] implementations | |
9448 | need to be aware of MIME line length limitations. Since HTTP does not | |
9449 | have this limitation, HTTP does not fold long lines. MHTML messages | |
9450 | being transported by HTTP follow all conventions of MHTML, including | |
9451 | line length limitations and folding, canonicalization, etc., since | |
9452 | HTTP transports all message-bodies as payload (see section 3.7.2) and | |
9453 | does not interpret the content or any MIME header lines that might be | |
9454 | contained therein. | |
9455 | ||
9456 | 19.5 Additional Features | |
9457 | ||
9458 | RFC 1945 and RFC 2068 document protocol elements used by some | |
9459 | existing HTTP implementations, but not consistently and correctly | |
9460 | across most HTTP/1.1 applications. Implementors are advised to be | |
9461 | aware of these features, but cannot rely upon their presence in, or | |
9462 | interoperability with, other HTTP/1.1 applications. Some of these | |
9463 | ||
9464 | ||
9465 | ||
9466 | Fielding, et al. Standards Track [Page 169] | |
9467 | \f | |
9468 | RFC 2616 HTTP/1.1 June 1999 | |
9469 | ||
9470 | ||
9471 | describe proposed experimental features, and some describe features | |
9472 | that experimental deployment found lacking that are now addressed in | |
9473 | the base HTTP/1.1 specification. | |
9474 | ||
9475 | A number of other headers, such as Content-Disposition and Title, | |
9476 | from SMTP and MIME are also often implemented (see RFC 2076 [37]). | |
9477 | ||
9478 | 19.5.1 Content-Disposition | |
9479 | ||
9480 | The Content-Disposition response-header field has been proposed as a | |
9481 | means for the origin server to suggest a default filename if the user | |
9482 | requests that the content is saved to a file. This usage is derived | |
9483 | from the definition of Content-Disposition in RFC 1806 [35]. | |
9484 | ||
9485 | content-disposition = "Content-Disposition" ":" | |
9486 | disposition-type *( ";" disposition-parm ) | |
9487 | disposition-type = "attachment" | disp-extension-token | |
9488 | disposition-parm = filename-parm | disp-extension-parm | |
9489 | filename-parm = "filename" "=" quoted-string | |
9490 | disp-extension-token = token | |
9491 | disp-extension-parm = token "=" ( token | quoted-string ) | |
9492 | ||
9493 | An example is | |
9494 | ||
9495 | Content-Disposition: attachment; filename="fname.ext" | |
9496 | ||
9497 | The receiving user agent SHOULD NOT respect any directory path | |
9498 | information present in the filename-parm parameter, which is the only | |
9499 | parameter believed to apply to HTTP implementations at this time. The | |
9500 | filename SHOULD be treated as a terminal component only. | |
9501 | ||
9502 | If this header is used in a response with the application/octet- | |
9503 | stream content-type, the implied suggestion is that the user agent | |
9504 | should not display the response, but directly enter a `save response | |
9505 | as...' dialog. | |
9506 | ||
9507 | See section 15.5 for Content-Disposition security issues. | |
9508 | ||
9509 | 19.6 Compatibility with Previous Versions | |
9510 | ||
9511 | It is beyond the scope of a protocol specification to mandate | |
9512 | compliance with previous versions. HTTP/1.1 was deliberately | |
9513 | designed, however, to make supporting previous versions easy. It is | |
9514 | worth noting that, at the time of composing this specification | |
9515 | (1996), we would expect commercial HTTP/1.1 servers to: | |
9516 | ||
9517 | - recognize the format of the Request-Line for HTTP/0.9, 1.0, and | |
9518 | 1.1 requests; | |
9519 | ||
9520 | ||
9521 | ||
9522 | Fielding, et al. Standards Track [Page 170] | |
9523 | \f | |
9524 | RFC 2616 HTTP/1.1 June 1999 | |
9525 | ||
9526 | ||
9527 | - understand any valid request in the format of HTTP/0.9, 1.0, or | |
9528 | 1.1; | |
9529 | ||
9530 | - respond appropriately with a message in the same major version | |
9531 | used by the client. | |
9532 | ||
9533 | And we would expect HTTP/1.1 clients to: | |
9534 | ||
9535 | - recognize the format of the Status-Line for HTTP/1.0 and 1.1 | |
9536 | responses; | |
9537 | ||
9538 | - understand any valid response in the format of HTTP/0.9, 1.0, or | |
9539 | 1.1. | |
9540 | ||
9541 | For most implementations of HTTP/1.0, each connection is established | |
9542 | by the client prior to the request and closed by the server after | |
9543 | sending the response. Some implementations implement the Keep-Alive | |
9544 | version of persistent connections described in section 19.7.1 of RFC | |
9545 | 2068 [33]. | |
9546 | ||
9547 | 19.6.1 Changes from HTTP/1.0 | |
9548 | ||
9549 | This section summarizes major differences between versions HTTP/1.0 | |
9550 | and HTTP/1.1. | |
9551 | ||
9552 | 19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP | |
9553 | Addresses | |
9554 | ||
9555 | The requirements that clients and servers support the Host request- | |
9556 | header, report an error if the Host request-header (section 14.23) is | |
9557 | missing from an HTTP/1.1 request, and accept absolute URIs (section | |
9558 | 5.1.2) are among the most important changes defined by this | |
9559 | specification. | |
9560 | ||
9561 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |
9562 | addresses and servers; there was no other established mechanism for | |
9563 | distinguishing the intended server of a request than the IP address | |
9564 | to which that request was directed. The changes outlined above will | |
9565 | allow the Internet, once older HTTP clients are no longer common, to | |
9566 | support multiple Web sites from a single IP address, greatly | |
9567 | simplifying large operational Web servers, where allocation of many | |
9568 | IP addresses to a single host has created serious problems. The | |
9569 | Internet will also be able to recover the IP addresses that have been | |
9570 | allocated for the sole purpose of allowing special-purpose domain | |
9571 | names to be used in root-level HTTP URLs. Given the rate of growth of | |
9572 | the Web, and the number of servers already deployed, it is extremely | |
9573 | ||
9574 | ||
9575 | ||
9576 | ||
9577 | ||
9578 | Fielding, et al. Standards Track [Page 171] | |
9579 | \f | |
9580 | RFC 2616 HTTP/1.1 June 1999 | |
9581 | ||
9582 | ||
9583 | important that all implementations of HTTP (including updates to | |
9584 | existing HTTP/1.0 applications) correctly implement these | |
9585 | requirements: | |
9586 | ||
9587 | - Both clients and servers MUST support the Host request-header. | |
9588 | ||
9589 | - A client that sends an HTTP/1.1 request MUST send a Host header. | |
9590 | ||
9591 | - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | |
9592 | request does not include a Host request-header. | |
9593 | ||
9594 | - Servers MUST accept absolute URIs. | |
9595 | ||
9596 | 19.6.2 Compatibility with HTTP/1.0 Persistent Connections | |
9597 | ||
9598 | Some clients and servers might wish to be compatible with some | |
9599 | previous implementations of persistent connections in HTTP/1.0 | |
9600 | clients and servers. Persistent connections in HTTP/1.0 are | |
9601 | explicitly negotiated as they are not the default behavior. HTTP/1.0 | |
9602 | experimental implementations of persistent connections are faulty, | |
9603 | and the new facilities in HTTP/1.1 are designed to rectify these | |
9604 | problems. The problem was that some existing 1.0 clients may be | |
9605 | sending Keep-Alive to a proxy server that doesn't understand | |
9606 | Connection, which would then erroneously forward it to the next | |
9607 | inbound server, which would establish the Keep-Alive connection and | |
9608 | result in a hung HTTP/1.0 proxy waiting for the close on the | |
9609 | response. The result is that HTTP/1.0 clients must be prevented from | |
9610 | using Keep-Alive when talking to proxies. | |
9611 | ||
9612 | However, talking to proxies is the most important use of persistent | |
9613 | connections, so that prohibition is clearly unacceptable. Therefore, | |
9614 | we need some other mechanism for indicating a persistent connection | |
9615 | is desired, which is safe to use even when talking to an old proxy | |
9616 | that ignores Connection. Persistent connections are the default for | |
9617 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | |
9618 | declaring non-persistence. See section 14.10. | |
9619 | ||
9620 | The original HTTP/1.0 form of persistent connections (the Connection: | |
9621 | Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] | |
9622 | ||
9623 | 19.6.3 Changes from RFC 2068 | |
9624 | ||
9625 | This specification has been carefully audited to correct and | |
9626 | disambiguate key word usage; RFC 2068 had many problems in respect to | |
9627 | the conventions laid out in RFC 2119 [34]. | |
9628 | ||
9629 | Clarified which error code should be used for inbound server failures | |
9630 | (e.g. DNS failures). (Section 10.5.5). | |
9631 | ||
9632 | ||
9633 | ||
9634 | Fielding, et al. Standards Track [Page 172] | |
9635 | \f | |
9636 | RFC 2616 HTTP/1.1 June 1999 | |
9637 | ||
9638 | ||
9639 | CREATE had a race that required an Etag be sent when a resource is | |
9640 | first created. (Section 10.2.2). | |
9641 | ||
9642 | Content-Base was deleted from the specification: it was not | |
9643 | implemented widely, and there is no simple, safe way to introduce it | |
9644 | without a robust extension mechanism. In addition, it is used in a | |
9645 | similar, but not identical fashion in MHTML [45]. | |
9646 | ||
9647 | Transfer-coding and message lengths all interact in ways that | |
9648 | required fixing exactly when chunked encoding is used (to allow for | |
9649 | transfer encoding that may not be self delimiting); it was important | |
9650 | to straighten out exactly how message lengths are computed. (Sections | |
9651 | 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | |
9652 | ||
9653 | A content-coding of "identity" was introduced, to solve problems | |
9654 | discovered in caching. (section 3.5) | |
9655 | ||
9656 | Quality Values of zero should indicate that "I don't want something" | |
9657 | to allow clients to refuse a representation. (Section 3.9) | |
9658 | ||
9659 | The use and interpretation of HTTP version numbers has been clarified | |
9660 | by RFC 2145. Require proxies to upgrade requests to highest protocol | |
9661 | version they support to deal with problems discovered in HTTP/1.0 | |
9662 | implementations (Section 3.1) | |
9663 | ||
9664 | Charset wildcarding is introduced to avoid explosion of character set | |
9665 | names in accept headers. (Section 14.2) | |
9666 | ||
9667 | A case was missed in the Cache-Control model of HTTP/1.1; s-maxage | |
9668 | was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, | |
9669 | 14.9.3) | |
9670 | ||
9671 | The Cache-Control: max-age directive was not properly defined for | |
9672 | responses. (Section 14.9.3) | |
9673 | ||
9674 | There are situations where a server (especially a proxy) does not | |
9675 | know the full length of a response but is capable of serving a | |
9676 | byterange request. We therefore need a mechanism to allow byteranges | |
9677 | with a content-range not indicating the full length of the message. | |
9678 | (Section 14.16) | |
9679 | ||
9680 | Range request responses would become very verbose if all meta-data | |
9681 | were always returned; by allowing the server to only send needed | |
9682 | headers in a 206 response, this problem can be avoided. (Section | |
9683 | 10.2.7, 13.5.3, and 14.27) | |
9684 | ||
9685 | ||
9686 | ||
9687 | ||
9688 | ||
9689 | ||
9690 | Fielding, et al. Standards Track [Page 173] | |
9691 | \f | |
9692 | RFC 2616 HTTP/1.1 June 1999 | |
9693 | ||
9694 | ||
9695 | Fix problem with unsatisfiable range requests; there are two cases: | |
9696 | syntactic problems, and range doesn't exist in the document. The 416 | |
9697 | status code was needed to resolve this ambiguity needed to indicate | |
9698 | an error for a byte range request that falls outside of the actual | |
9699 | contents of a document. (Section 10.4.17, 14.16) | |
9700 | ||
9701 | Rewrite of message transmission requirements to make it much harder | |
9702 | for implementors to get it wrong, as the consequences of errors here | |
9703 | can have significant impact on the Internet, and to deal with the | |
9704 | following problems: | |
9705 | ||
9706 | 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where | |
9707 | this was incorrectly placing a requirement on the behavior of | |
9708 | an implementation of a future version of HTTP/1.x | |
9709 | ||
9710 | 2. Made it clear that user-agents should retry requests, not | |
9711 | "clients" in general. | |
9712 | ||
9713 | 3. Converted requirements for clients to ignore unexpected 100 | |
9714 | (Continue) responses, and for proxies to forward 100 responses, | |
9715 | into a general requirement for 1xx responses. | |
9716 | ||
9717 | 4. Modified some TCP-specific language, to make it clearer that | |
9718 | non-TCP transports are possible for HTTP. | |
9719 | ||
9720 | 5. Require that the origin server MUST NOT wait for the request | |
9721 | body before it sends a required 100 (Continue) response. | |
9722 | ||
9723 | 6. Allow, rather than require, a server to omit 100 (Continue) if | |
9724 | it has already seen some of the request body. | |
9725 | ||
9726 | 7. Allow servers to defend against denial-of-service attacks and | |
9727 | broken clients. | |
9728 | ||
9729 | This change adds the Expect header and 417 status code. The message | |
9730 | transmission requirements fixes are in sections 8.2, 10.4.18, | |
9731 | 8.1.2.2, 13.11, and 14.20. | |
9732 | ||
9733 | Proxies should be able to add Content-Length when appropriate. | |
9734 | (Section 13.5.2) | |
9735 | ||
9736 | Clean up confusion between 403 and 404 responses. (Section 10.4.4, | |
9737 | 10.4.5, and 10.4.11) | |
9738 | ||
9739 | Warnings could be cached incorrectly, or not updated appropriately. | |
9740 | (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | |
9741 | also needed to be a general header, as PUT or other methods may have | |
9742 | need for it in requests. | |
9743 | ||
9744 | ||
9745 | ||
9746 | Fielding, et al. Standards Track [Page 174] | |
9747 | \f | |
9748 | RFC 2616 HTTP/1.1 June 1999 | |
9749 | ||
9750 | ||
9751 | Transfer-coding had significant problems, particularly with | |
9752 | interactions with chunked encoding. The solution is that transfer- | |
9753 | codings become as full fledged as content-codings. This involves | |
9754 | adding an IANA registry for transfer-codings (separate from content | |
9755 | codings), a new header field (TE) and enabling trailer headers in the | |
9756 | future. Transfer encoding is a major performance benefit, so it was | |
9757 | worth fixing [39]. TE also solves another, obscure, downward | |
9758 | interoperability problem that could have occurred due to interactions | |
9759 | between authentication trailers, chunked encoding and HTTP/1.0 | |
9760 | clients.(Section 3.6, 3.6.1, and 14.39) | |
9761 | ||
9762 | The PATCH, LINK, UNLINK methods were defined but not commonly | |
9763 | implemented in previous versions of this specification. See RFC 2068 | |
9764 | [33]. | |
9765 | ||
9766 | The Alternates, Content-Version, Derived-From, Link, URI, Public and | |
9767 | Content-Base header fields were defined in previous versions of this | |
9768 | specification, but not commonly implemented. See RFC 2068 [33]. | |
9769 | ||
9770 | 20 Index | |
9771 | ||
9772 | Please see the PostScript version of this RFC for the INDEX. | |
9773 | ||
9774 | ||
9775 | ||
9776 | ||
9777 | ||
9778 | ||
9779 | ||
9780 | ||
9781 | ||
9782 | ||
9783 | ||
9784 | ||
9785 | ||
9786 | ||
9787 | ||
9788 | ||
9789 | ||
9790 | ||
9791 | ||
9792 | ||
9793 | ||
9794 | ||
9795 | ||
9796 | ||
9797 | ||
9798 | ||
9799 | ||
9800 | ||
9801 | ||
9802 | Fielding, et al. Standards Track [Page 175] | |
9803 | \f | |
9804 | RFC 2616 HTTP/1.1 June 1999 | |
9805 | ||
9806 | ||
9807 | 21. Full Copyright Statement | |
9808 | ||
9809 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
9810 | ||
9811 | This document and translations of it may be copied and furnished to | |
9812 | others, and derivative works that comment on or otherwise explain it | |
9813 | or assist in its implementation may be prepared, copied, published | |
9814 | and distributed, in whole or in part, without restriction of any | |
9815 | kind, provided that the above copyright notice and this paragraph are | |
9816 | included on all such copies and derivative works. However, this | |
9817 | document itself may not be modified in any way, such as by removing | |
9818 | the copyright notice or references to the Internet Society or other | |
9819 | Internet organizations, except as needed for the purpose of | |
9820 | developing Internet standards in which case the procedures for | |
9821 | copyrights defined in the Internet Standards process must be | |
9822 | followed, or as required to translate it into languages other than | |
9823 | English. | |
9824 | ||
9825 | The limited permissions granted above are perpetual and will not be | |
9826 | revoked by the Internet Society or its successors or assigns. | |
9827 | ||
9828 | This document and the information contained herein is provided on an | |
9829 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
9830 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
9831 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
9832 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
9833 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
9834 | ||
9835 | Acknowledgement | |
9836 | ||
9837 | Funding for the RFC Editor function is currently provided by the | |
9838 | Internet Society. | |
9839 | ||
9840 | ||
9841 | ||
9842 | ||
9843 | ||
9844 | ||
9845 | ||
9846 | ||
9847 | ||
9848 | ||
9849 | ||
9850 | ||
9851 | ||
9852 | ||
9853 | ||
9854 | ||
9855 | ||
9856 | ||
9857 | ||
9858 | Fielding, et al. Standards Track [Page 176] | |
9859 | \f |