aboutsummaryrefslogtreecommitdiff
path: root/misc/rfc2616-http.txt
diff options
context:
space:
mode:
authorMike Buland <eichlan@xagasoft.com>2006-05-01 17:11:04 +0000
committerMike Buland <eichlan@xagasoft.com>2006-05-01 17:11:04 +0000
commitf7a9549bd6ad83f2e0bceec9cddacfa5e3f84a54 (patch)
tree53cec4864776e07950e3c72f2a990a1017d08045 /misc/rfc2616-http.txt
downloadlibbu++-f7a9549bd6ad83f2e0bceec9cddacfa5e3f84a54.tar.gz
libbu++-f7a9549bd6ad83f2e0bceec9cddacfa5e3f84a54.tar.bz2
libbu++-f7a9549bd6ad83f2e0bceec9cddacfa5e3f84a54.tar.xz
libbu++-f7a9549bd6ad83f2e0bceec9cddacfa5e3f84a54.zip
libbu++ is finally laid out the way it should be, trunk, branches, and tags.
Diffstat (limited to 'misc/rfc2616-http.txt')
-rw-r--r--misc/rfc2616-http.txt9859
1 files changed, 9859 insertions, 0 deletions
diff --git a/misc/rfc2616-http.txt b/misc/rfc2616-http.txt
new file mode 100644
index 0000000..45d7d08
--- /dev/null
+++ b/misc/rfc2616-http.txt
@@ -0,0 +1,9859 @@
1
2
3
4
5
6
7Network Working Group R. Fielding
8Request for Comments: 2616 UC Irvine
9Obsoletes: 2068 J. Gettys
10Category: 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
26Status 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
34Copyright Notice
35
36 Copyright (C) The Internet Society (1999). All Rights Reserved.
37
38Abstract
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
58Fielding, et al. Standards Track [Page 1]
59
60RFC 2616 HTTP/1.1 June 1999
61
62
63Table 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
114Fielding, et al. Standards Track [Page 2]
115
116RFC 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
170Fielding, et al. Standards Track [Page 3]
171
172RFC 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
226Fielding, et al. Standards Track [Page 4]
227
228RFC 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
282Fielding, et al. Standards Track [Page 5]
283
284RFC 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
338Fielding, et al. Standards Track [Page 6]
339
340RFC 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
3591 Introduction
360
3611.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
394Fielding, et al. Standards Track [Page 7]
395
396RFC 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
4091.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
4231.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
450Fielding, et al. Standards Track [Page 8]
451
452RFC 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
506Fielding, et al. Standards Track [Page 9]
507
508RFC 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
562Fielding, et al. Standards Track [Page 10]
563
564RFC 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
618Fielding, et al. Standards Track [Page 11]
619
620RFC 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
6281.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
674Fielding, et al. Standards Track [Page 12]
675
676RFC 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
730Fielding, et al. Standards Track [Page 13]
731
732RFC 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
7402 Notational Conventions and Generic Grammar
741
7422.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
786Fielding, et al. Standards Track [Page 14]
787
788RFC 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
8322.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
842Fielding, et al. Standards Track [Page 15]
843
844RFC 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
898Fielding, et al. Standards Track [Page 16]
899
900RFC 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
9343 Protocol Parameters
935
9363.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
954Fielding, et al. Standards Track [Page 17]
955
956RFC 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
9993.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
1010Fielding, et al. Standards Track [Page 18]
1011
1012RFC 2616 HTTP/1.1 June 1999
1013
1014
10153.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
10393.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
1066Fielding, et al. Standards Track [Page 19]
1067
1068RFC 2616 HTTP/1.1 June 1999
1069
1070
10713.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
10953.3 Date/Time Formats
1096
10973.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
1122Fielding, et al. Standards Track [Page 20]
1123
1124RFC 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
11613.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
11693.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
1178Fielding, et al. Standards Track [Page 21]
1179
1180RFC 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
12173.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
1234Fielding, et al. Standards Track [Page 22]
1235
1236RFC 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
12433.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
1290Fielding, et al. Standards Track [Page 23]
1291
1292RFC 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
13073.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
1346Fielding, et al. Standards Track [Page 24]
1347
1348RFC 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
13653.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
1402Fielding, et al. Standards Track [Page 25]
1403
1404RFC 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
14353.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
1458Fielding, et al. Standards Track [Page 26]
1459
1460RFC 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
14733.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
15063.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
1514Fielding, et al. Standards Track [Page 27]
1515
1516RFC 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
15493.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
1570Fielding, et al. Standards Track [Page 28]
1571
1572RFC 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
15823.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
16003.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
1626Fielding, et al. Standards Track [Page 29]
1627
1628RFC 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
16363.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
16653.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
1682Fielding, et al. Standards Track [Page 30]
1683
1684RFC 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
16904 HTTP Message
1691
16924.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
17224.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
1738Fielding, et al. Standards Track [Page 31]
1739
1740RFC 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
17774.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
1794Fielding, et al. Standards Track [Page 32]
1795
1796RFC 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
18244.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
1850Fielding, et al. Standards Track [Page 33]
1851
1852RFC 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
18984.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
1906Fielding, et al. Standards Track [Page 34]
1907
1908RFC 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
19305 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
19435.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
1962Fielding, et al. Standards Track [Page 35]
1963
1964RFC 2616 HTTP/1.1 June 1999
1965
1966
19675.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
19965.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
2018Fielding, et al. Standards Track [Page 36]
2019
2020RFC 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
2074Fielding, et al. Standards Track [Page 37]
2075
2076RFC 2616 HTTP/1.1 June 1999
2077
2078
20795.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
21105.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
2130Fielding, et al. Standards Track [Page 38]
2131
2132RFC 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
21536 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
21656.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
21746.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
2186Fielding, et al. Standards Track [Page 39]
2187
2188RFC 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
2242Fielding, et al. Standards Track [Page 40]
2243
2244RFC 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
22836.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
2298Fielding, et al. Standards Track [Page 41]
2299
2300RFC 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
23157 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
23257.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
2354Fielding, et al. Standards Track [Page 42]
2355
2356RFC 2616 HTTP/1.1 June 1999
2357
2358
23597.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
23717.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
23937.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
2410Fielding, et al. Standards Track [Page 43]
2411
2412RFC 2616 HTTP/1.1 June 1999
2413
2414
24158 Connections
2416
24178.1 Persistent Connections
2418
24198.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
2466Fielding, et al. Standards Track [Page 44]
2467
2468RFC 2616 HTTP/1.1 June 1999
2469
2470
24718.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
24858.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
2522Fielding, et al. Standards Track [Page 45]
2523
2524RFC 2616 HTTP/1.1 June 1999
2525
2526
25278.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
25498.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
25658.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
2578Fielding, et al. Standards Track [Page 46]
2579
2580RFC 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
26218.2 Message Transmission Requirements
2622
26238.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
2634Fielding, et al. Standards Track [Page 47]
2635
2636RFC 2616 HTTP/1.1 June 1999
2637
2638
26398.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
26508.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
2690Fielding, et al. Standards Track [Page 48]
2691
2692RFC 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
2746Fielding, et al. Standards Track [Page 49]
2747
2748RFC 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
27648.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
2802Fielding, et al. Standards Track [Page 50]
2803
2804RFC 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
28149 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
28239.1 Safe and Idempotent Methods
2824
28259.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
28459.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
2858Fielding, et al. Standards Track [Page 51]
2859
2860RFC 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
28759.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
2914Fielding, et al. Standards Track [Page 52]
2915
2916RFC 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
29369.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
2970Fielding, et al. Standards Track [Page 53]
2971
2972RFC 2616 HTTP/1.1 June 1999
2973
2974
29759.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
29949.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
3026Fielding, et al. Standards Track [Page 54]
3027
3028RFC 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
30469.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
3082Fielding, et al. Standards Track [Page 55]
3083
3084RFC 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
31079.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
31289.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
3138Fielding, et al. Standards Track [Page 56]
3139
3140RFC 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
31599.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
316510 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
317110.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
3194Fielding, et al. Standards Track [Page 57]
3195
3196RFC 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
320310.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
321410.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
322910.2 Successful 2xx
3230
3231 This class of status code indicates that the client's request was
3232 successfully received, understood, and accepted.
3233
323410.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
3250Fielding, et al. Standards Track [Page 58]
3251
3252RFC 2616 HTTP/1.1 June 1999
3253
3254
3255 TRACE an entity containing the request message as received by the
3256 end server.
3257
325810.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
327610.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
329310.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
3306Fielding, et al. Standards Track [Page 59]
3307
3308RFC 2616 HTTP/1.1 June 1999
3309
3310
331110.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
332910.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
333810.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
3362Fielding, et al. Standards Track [Page 60]
3363
3364RFC 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
338710.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
340110.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
3418Fielding, et al. Standards Track [Page 61]
3419
3420RFC 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
343210.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
345510.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
3474Fielding, et al. Standards Track [Page 62]
3475
3476RFC 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
349210.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
351210.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
3530Fielding, et al. Standards Track [Page 63]
3531
3532RFC 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
356110.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
357210.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
3586Fielding, et al. Standards Track [Page 64]
3587
3588RFC 2616 HTTP/1.1 June 1999
3589
3590
359110.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
361210.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
362910.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
3642Fielding, et al. Standards Track [Page 65]
3643
3644RFC 2616 HTTP/1.1 June 1999
3645
3646
364710.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
366310.4.3 402 Payment Required
3664
3665 This code is reserved for future use.
3666
366710.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
367710.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
368810.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
3698Fielding, et al. Standards Track [Page 66]
3699
3700RFC 2616 HTTP/1.1 June 1999
3701
3702
370310.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
372810.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
373910.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
374510.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
3754Fielding, et al. Standards Track [Page 67]
3755
3756RFC 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
377310.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
379310.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
380010.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
3810Fielding, et al. Standards Track [Page 68]
3811
3812RFC 2616 HTTP/1.1 June 1999
3813
3814
381510.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
382610.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
383810.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
384410.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
3866Fielding, et al. Standards Track [Page 69]
3867
3868RFC 2616 HTTP/1.1 June 1999
3869
3870
387110.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
387810.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
388810.5.1 500 Internal Server Error
3889
3890 The server encountered an unexpected condition which prevented it
3891 from fulfilling the request.
3892
389310.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
390010.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
390610.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
3922Fielding, et al. Standards Track [Page 70]
3923
3924RFC 2616 HTTP/1.1 June 1999
3925
3926
392710.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
393710.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
394711 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
395812 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
3978Fielding, et al. Standards Track [Page 71]
3979
3980RFC 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
399412.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
4034Fielding, et al. Standards Track [Page 72]
4035
4036RFC 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
405812.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
4090Fielding, et al. Standards Track [Page 73]
4091
4092RFC 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
410012.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
412013 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
4146Fielding, et al. Standards Track [Page 74]
4147
4148RFC 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
418513.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
4202Fielding, et al. Standards Track [Page 75]
4203
4204RFC 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
423913.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
4258Fielding, et al. Standards Track [Page 76]
4259
4260RFC 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
429713.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
4314Fielding, et al. Standards Track [Page 77]
4315
4316RFC 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
432513.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
435313.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
4370Fielding, et al. Standards Track [Page 78]
4371
4372RFC 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
438013.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
440313.2 Expiration Model
4404
440513.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
4426Fielding, et al. Standards Track [Page 79]
4427
4428RFC 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
445513.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
446713.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
4482Fielding, et al. Standards Track [Page 80]
4483
4484RFC 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
4538Fielding, et al. Standards Track [Page 81]
4539
4540RFC 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
4594Fielding, et al. Standards Track [Page 82]
4595
4596RFC 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
460313.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
4650Fielding, et al. Standards Track [Page 83]
4651
4652RFC 2616 HTTP/1.1 June 1999
4653
4654
465513.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
467413.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
4706Fielding, et al. Standards Track [Page 84]
4707
4708RFC 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
471713.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
4762Fielding, et al. Standards Track [Page 85]
4763
4764RFC 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
477313.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
477913.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
479113.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
4818Fielding, et al. Standards Track [Page 86]
4819
4820RFC 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
4874Fielding, et al. Standards Track [Page 87]
4875
4876RFC 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
4930Fielding, et al. Standards Track [Page 88]
4931
4932RFC 2616 HTTP/1.1 June 1999
4933
4934
4935 servers.
4936
493713.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
4986Fielding, et al. Standards Track [Page 89]
4987
4988RFC 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
502913.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
5042Fielding, et al. Standards Track [Page 90]
5043
5044RFC 2616 HTTP/1.1 June 1999
5045
5046
504713.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
5098Fielding, et al. Standards Track [Page 91]
5099
5100RFC 2616 HTTP/1.1 June 1999
5101
5102
510313.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
511213.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
514213.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
5154Fielding, et al. Standards Track [Page 92]
5155
5156RFC 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
5210Fielding, et al. Standards Track [Page 93]
5211
5212RFC 2616 HTTP/1.1 June 1999
5213
5214
521513.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
5266Fielding, et al. Standards Track [Page 94]
5267
5268RFC 2616 HTTP/1.1 June 1999
5269
5270
527113.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
529513.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
5322Fielding, et al. Standards Track [Page 95]
5323
5324RFC 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
536613.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
5378Fielding, et al. Standards Track [Page 96]
5379
5380RFC 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
538713.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
540613.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
542413.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
5434Fielding, et al. Standards Track [Page 97]
5435
5436RFC 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
546913.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
5490Fielding, et al. Standards Track [Page 98]
5491
5492RFC 2616 HTTP/1.1 June 1999
5493
5494
549513.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
550913.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
5546Fielding, et al. Standards Track [Page 99]
5547
5548RFC 2616 HTTP/1.1 June 1999
5549
5550
555114 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
555814.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
5602Fielding, et al. Standards Track [Page 100]
5603
5604RFC 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
5658Fielding, et al. Standards Track [Page 101]
5659
5660RFC 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
567214.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
570414.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
5714Fielding, et al. Standards Track [Page 102]
5715
5716RFC 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
5770Fielding, et al. Standards Track [Page 103]
5771
5772RFC 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
578414.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
5826Fielding, et al. Standards Track [Page 104]
5827
5828RFC 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
585514.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
5882Fielding, et al. Standards Track [Page 105]
5883
5884RFC 2616 HTTP/1.1 June 1999
5885
5886
588714.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
590914.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
5938Fielding, et al. Standards Track [Page 106]
5939
5940RFC 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
594714.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
5994Fielding, et al. Standards Track [Page 107]
5995
5996RFC 2616 HTTP/1.1 June 1999
5997
5998
599914.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
6050Fielding, et al. Standards Track [Page 108]
6051
6052RFC 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
608214.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
6106Fielding, et al. Standards Track [Page 109]
6107
6108RFC 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
613814.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
6162Fielding, et al. Standards Track [Page 110]
6163
6164RFC 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
617714.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
6218Fielding, et al. Standards Track [Page 111]
6219
6220RFC 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
6274Fielding, et al. Standards Track [Page 112]
6275
6276RFC 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
628814.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
6330Fielding, et al. Standards Track [Page 113]
6331
6332RFC 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
6386Fielding, et al. Standards Track [Page 114]
6387
6388RFC 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
642714.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
6442Fielding, et al. Standards Track [Page 115]
6443
6444RFC 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
645814.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
6498Fielding, et al. Standards Track [Page 116]
6499
6500RFC 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
650914.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
6554Fielding, et al. Standards Track [Page 117]
6555
6556RFC 2616 HTTP/1.1 June 1999
6557
6558
655914.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
659514.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
6610Fielding, et al. Standards Track [Page 118]
6611
6612RFC 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
664514.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
6666Fielding, et al. Standards Track [Page 119]
6667
6668RFC 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
668214.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
6722Fielding, et al. Standards Track [Page 120]
6723
6724RFC 2616 HTTP/1.1 June 1999
6725
6726
672714.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
6778Fielding, et al. Standards Track [Page 121]
6779
6780RFC 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
679514.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
6834Fielding, et al. Standards Track [Page 122]
6835
6836RFC 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
6890Fielding, et al. Standards Track [Page 123]
6891
6892RFC 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
691214.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
692714.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
6946Fielding, et al. Standards Track [Page 124]
6947
6948RFC 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
698614.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
7002Fielding, et al. Standards Track [Page 125]
7003
7004RFC 2616 HTTP/1.1 June 1999
7005
7006
700714.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
702314.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
7058Fielding, et al. Standards Track [Page 126]
7059
7060RFC 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
707414.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
7114Fielding, et al. Standards Track [Page 127]
7115
7116RFC 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
712914.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
716214.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
7170Fielding, et al. Standards Track [Page 128]
7171
7172RFC 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
720414.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
7226Fielding, et al. Standards Track [Page 129]
7227
7228RFC 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
727014.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
7282Fielding, et al. Standards Track [Page 130]
7283
7284RFC 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
7338Fielding, et al. Standards Track [Page 131]
7339
7340RFC 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
735314.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
7394Fielding, et al. Standards Track [Page 132]
7395
7396RFC 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
743014.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
7450Fielding, et al. Standards Track [Page 133]
7451
7452RFC 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
746914.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
749714.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
7506Fielding, et al. Standards Track [Page 134]
7507
7508RFC 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
753714.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
7562Fielding, et al. Standards Track [Page 135]
7563
7564RFC 2616 HTTP/1.1 June 1999
7565
7566
756714.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
759314.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
7618Fielding, et al. Standards Track [Page 136]
7619
7620RFC 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
763814.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
765614.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
7674Fielding, et al. Standards Track [Page 137]
7675
7676RFC 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
768514.35 Range
7686
768714.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
7730Fielding, et al. Standards Track [Page 138]
7731
7732RFC 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
777514.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
7786Fielding, et al. Standards Track [Page 139]
7787
7788RFC 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
782114.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
7842Fielding, et al. Standards Track [Page 140]
7843
7844RFC 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
785114.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
787014.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
7898Fielding, et al. Standards Track [Page 141]
7899
7900RFC 2616 HTTP/1.1 June 1999
7901
7902
790314.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
7954Fielding, et al. Standards Track [Page 142]
7955
7956RFC 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
796814.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
799414.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
8010Fielding, et al. Standards Track [Page 143]
8011
8012RFC 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
802314.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
8066Fielding, et al. Standards Track [Page 144]
8067
8068RFC 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
808214.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
810114.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
8122Fielding, et al. Standards Track [Page 145]
8123
8124RFC 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
815114.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
8178Fielding, et al. Standards Track [Page 146]
8179
8180RFC 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
8234Fielding, et al. Standards Track [Page 147]
8235
8236RFC 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
824414.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
8290Fielding, et al. Standards Track [Page 148]
8291
8292RFC 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
8346Fielding, et al. Standards Track [Page 149]
8347
8348RFC 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
837514.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
839215 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
8402Fielding, et al. Standards Track [Page 150]
8403
8404RFC 2616 HTTP/1.1 June 1999
8405
8406
840715.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
842015.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
843015.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
8458Fielding, et al. Standards Track [Page 151]
8459
8460RFC 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
848415.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
850515.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
8514Fielding, et al. Standards Track [Page 152]
8515
8516RFC 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
854815.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
8570Fielding, et al. Standards Track [Page 153]
8571
8572RFC 2616 HTTP/1.1 June 1999
8573
8574
857515.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
860715.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
861515.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
8626Fielding, et al. Standards Track [Page 154]
8627
8628RFC 2616 HTTP/1.1 June 1999
8629
8630
863115.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
865715.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
8682Fielding, et al. Standards Track [Page 155]
8683
8684RFC 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
870715.7.1 Denial of Service Attacks on Proxies
8708
8709 They exist. They are hard to defend against. Research continues.
8710 Beware.
8711
871216 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
8738Fielding, et al. Standards Track [Page 156]
8739
8740RFC 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
8794Fielding, et al. Standards Track [Page 157]
8795
8796RFC 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
880417 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
8850Fielding, et al. Standards Track [Page 158]
8851
8852RFC 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
8906Fielding, et al. Standards Track [Page 159]
8907
8908RFC 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
8962Fielding, et al. Standards Track [Page 160]
8963
8964RFC 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
9018Fielding, et al. Standards Track [Page 161]
9019
9020RFC 2616 HTTP/1.1 June 1999
9021
9022
902318 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
9074Fielding, et al. Standards Track [Page 162]
9075
9076RFC 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
9130Fielding, et al. Standards Track [Page 163]
9131
9132RFC 2616 HTTP/1.1 June 1999
9133
9134
913519 Appendices
9136
913719.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
9186Fielding, et al. Standards Track [Page 164]
9187
9188RFC 2616 HTTP/1.1 June 1999
9189
9190
919119.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
9242Fielding, et al. Standards Track [Page 165]
9243
9244RFC 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
925619.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
9298Fielding, et al. Standards Track [Page 166]
9299
9300RFC 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
930719.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
932719.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
934319.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
9354Fielding, et al. Standards Track [Page 167]
9355
9356RFC 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
937719.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
938519.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
939719.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
9410Fielding, et al. Standards Track [Page 168]
9411
9412RFC 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
942019.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
944519.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
945619.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
9466Fielding, et al. Standards Track [Page 169]
9467
9468RFC 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
947819.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
950919.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
9522Fielding, et al. Standards Track [Page 170]
9523
9524RFC 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
954719.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
955219.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
9578Fielding, et al. Standards Track [Page 171]
9579
9580RFC 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
959619.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
962319.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
9634Fielding, et al. Standards Track [Page 172]
9635
9636RFC 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
9690Fielding, et al. Standards Track [Page 173]
9691
9692RFC 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
9746Fielding, et al. Standards Track [Page 174]
9747
9748RFC 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
977020 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
9802Fielding, et al. Standards Track [Page 175]
9803
9804RFC 2616 HTTP/1.1 June 1999
9805
9806
980721. 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
9835Acknowledgement
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
9858Fielding, et al. Standards Track [Page 176]
9859
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-11 01:47:52 +0000