2 [[ Text in double brackets is from the unofficial errata at ]]
3 [[ http://skrb.org/ietf/http_errata.html ]]
6 Network Working Group R. Fielding
7 Request for Comments: 2616 UC Irvine
8 Obsoletes: 2068 J. Gettys
9 Category: Standards Track Compaq/W3C
23 Hypertext Transfer Protocol -- HTTP/1.1
27 This document specifies an Internet standards track protocol for the
28 Internet community, and requests discussion and suggestions for
29 improvements. Please refer to the current edition of the "Internet
30 Official Protocol Standards" (STD 1) for the standardization state
31 and status of this protocol. Distribution of this memo is unlimited.
35 Copyright (C) The Internet Society (1999). All Rights Reserved.
39 The Hypertext Transfer Protocol (HTTP) is an application-level
40 protocol for distributed, collaborative, hypermedia information
41 systems. It is a generic, stateless, protocol which can be used for
42 many tasks beyond its use for hypertext, such as name servers and
43 distributed object management systems, through extension of its
44 request methods, error codes and headers [47]. A feature of HTTP is
45 the typing and negotiation of data representation, allowing systems
46 to be built independently of the data being transferred.
48 HTTP has been in use by the World-Wide Web global information
49 initiative since 1990. This specification defines the protocol
50 referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
57 Fielding, et al. Standards Track [Page 1]
59 RFC 2616 HTTP/1.1 June 1999
64 1 Introduction ...................................................7
65 1.1 Purpose......................................................7
66 1.2 Requirements .................................................8
67 1.3 Terminology ..................................................8
68 1.4 Overall Operation ...........................................12
69 2 Notational Conventions and Generic Grammar ....................14
70 2.1 Augmented BNF ...............................................14
71 2.2 Basic Rules .................................................15
72 3 Protocol Parameters ...........................................17
73 3.1 HTTP Version ................................................17
74 3.2 Uniform Resource Identifiers ................................18
75 3.2.1 General Syntax ...........................................19
76 3.2.2 http URL .................................................19
77 3.2.3 URI Comparison ...........................................20
78 3.3 Date/Time Formats ...........................................20
79 3.3.1 Full Date ................................................20
80 3.3.2 Delta Seconds ............................................21
81 3.4 Character Sets ..............................................21
82 3.4.1 Missing Charset ..........................................22
83 3.5 Content Codings .............................................23
84 3.6 Transfer Codings ............................................24
85 3.6.1 Chunked Transfer Coding ..................................25
86 3.7 Media Types .................................................26
87 3.7.1 Canonicalization and Text Defaults .......................27
88 3.7.2 Multipart Types ..........................................27
89 3.8 Product Tokens ..............................................28
90 3.9 Quality Values ..............................................29
91 3.10 Language Tags ...............................................29
92 3.11 Entity Tags .................................................30
93 3.12 Range Units .................................................30
94 4 HTTP Message ..................................................31
95 4.1 Message Types ...............................................31
96 4.2 Message Headers .............................................31
97 4.3 Message Body ................................................32
98 4.4 Message Length ..............................................33
99 4.5 General Header Fields .......................................34
100 5 Request .......................................................35
101 5.1 Request-Line ................................................35
102 5.1.1 Method ...................................................36
103 5.1.2 Request-URI ..............................................36
104 5.2 The Resource Identified by a Request ........................38
105 5.3 Request Header Fields .......................................38
106 6 Response ......................................................39
107 6.1 Status-Line .................................................39
108 6.1.1 Status Code and Reason Phrase ............................39
109 6.2 Response Header Fields ......................................41
113 Fielding, et al. Standards Track [Page 2]
115 RFC 2616 HTTP/1.1 June 1999
118 7 Entity ........................................................42
119 7.1 Entity Header Fields ........................................42
120 7.2 Entity Body .................................................43
121 7.2.1 Type .....................................................43
122 7.2.2 Entity Length ............................................43
123 8 Connections ...................................................44
124 8.1 Persistent Connections ......................................44
125 8.1.1 Purpose ..................................................44
126 8.1.2 Overall Operation ........................................45
127 8.1.3 Proxy Servers ............................................46
128 8.1.4 Practical Considerations .................................46
129 8.2 Message Transmission Requirements ...........................47
130 8.2.1 Persistent Connections and Flow Control ..................47
131 8.2.2 Monitoring Connections for Error Status Messages .........48
132 8.2.3 Use of the 100 (Continue) Status .........................48
133 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
134 9 Method Definitions ............................................51
135 9.1 Safe and Idempotent Methods .................................51
136 9.1.1 Safe Methods .............................................51
137 9.1.2 Idempotent Methods .......................................51
138 9.2 OPTIONS .....................................................52
139 9.3 GET .........................................................53
140 9.4 HEAD ........................................................54
141 9.5 POST ........................................................54
142 9.6 PUT .........................................................55
143 9.7 DELETE ......................................................56
144 9.8 TRACE .......................................................56
145 9.9 CONNECT .....................................................57
146 10 Status Code Definitions ......................................57
147 10.1 Informational 1xx ...........................................57
148 10.1.1 100 Continue .............................................58
149 10.1.2 101 Switching Protocols ..................................58
150 10.2 Successful 2xx ..............................................58
151 10.2.1 200 OK ...................................................58
152 10.2.2 201 Created ..............................................59
153 10.2.3 202 Accepted .............................................59
154 10.2.4 203 Non-Authoritative Information ........................59
155 10.2.5 204 No Content ...........................................60
156 10.2.6 205 Reset Content ........................................60
157 10.2.7 206 Partial Content ......................................60
158 10.3 Redirection 3xx .............................................61
159 10.3.1 300 Multiple Choices .....................................61
160 10.3.2 301 Moved Permanently ....................................62
161 10.3.3 302 Found ................................................62
162 10.3.4 303 See Other ............................................63
163 10.3.5 304 Not Modified .........................................63
164 10.3.6 305 Use Proxy ............................................64
165 10.3.7 306 (Unused) .............................................64
169 Fielding, et al. Standards Track [Page 3]
171 RFC 2616 HTTP/1.1 June 1999
174 10.3.8 307 Temporary Redirect ...................................65
175 10.4 Client Error 4xx ............................................65
176 10.4.1 400 Bad Request .........................................65
177 10.4.2 401 Unauthorized ........................................66
178 10.4.3 402 Payment Required ....................................66
179 10.4.4 403 Forbidden ...........................................66
180 10.4.5 404 Not Found ...........................................66
181 10.4.6 405 Method Not Allowed ..................................66
182 10.4.7 406 Not Acceptable ......................................67
183 10.4.8 407 Proxy Authentication Required .......................67
184 10.4.9 408 Request Timeout .....................................67
185 10.4.10 409 Conflict ............................................67
186 10.4.11 410 Gone ................................................68
187 10.4.12 411 Length Required .....................................68
188 10.4.13 412 Precondition Failed .................................68
189 10.4.14 413 Request Entity Too Large ............................69
190 10.4.15 414 Request-URI Too Long ................................69
191 10.4.16 415 Unsupported Media Type ..............................69
192 10.4.17 416 Requested Range Not Satisfiable .....................69
193 10.4.18 417 Expectation Failed ..................................70
194 10.5 Server Error 5xx ............................................70
195 10.5.1 500 Internal Server Error ................................70
196 10.5.2 501 Not Implemented ......................................70
197 10.5.3 502 Bad Gateway ..........................................70
198 10.5.4 503 Service Unavailable ..................................70
199 10.5.5 504 Gateway Timeout ......................................71
200 10.5.6 505 HTTP Version Not Supported ...........................71
201 11 Access Authentication ........................................71
202 12 Content Negotiation ..........................................71
203 12.1 Server-driven Negotiation ...................................72
204 12.2 Agent-driven Negotiation ....................................73
205 12.3 Transparent Negotiation .....................................74
206 13 Caching in HTTP ..............................................74
207 13.1.1 Cache Correctness ........................................75
208 13.1.2 Warnings .................................................76
209 13.1.3 Cache-control Mechanisms .................................77
210 13.1.4 Explicit User Agent Warnings .............................78
211 13.1.5 Exceptions to the Rules and Warnings .....................78
212 13.1.6 Client-controlled Behavior ...............................79
213 13.2 Expiration Model ............................................79
214 13.2.1 Server-Specified Expiration ..............................79
215 13.2.2 Heuristic Expiration .....................................80
216 13.2.3 Age Calculations .........................................80
217 13.2.4 Expiration Calculations ..................................83
218 13.2.5 Disambiguating Expiration Values .........................84
219 13.2.6 Disambiguating Multiple Responses ........................84
220 13.3 Validation Model ............................................85
221 13.3.1 Last-Modified Dates ......................................86
225 Fielding, et al. Standards Track [Page 4]
227 RFC 2616 HTTP/1.1 June 1999
230 13.3.2 Entity Tag Cache Validators ..............................86
231 13.3.3 Weak and Strong Validators ...............................86
232 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
233 13.3.5 Non-validating Conditionals ..............................90
234 13.4 Response Cacheability .......................................91
235 13.5 Constructing Responses From Caches ..........................92
236 13.5.1 End-to-end and Hop-by-hop Headers ........................92
237 13.5.2 Non-modifiable Headers ...................................92
238 13.5.3 Combining Headers ........................................94
239 13.5.4 Combining Byte Ranges ....................................95
240 13.6 Caching Negotiated Responses ................................95
241 13.7 Shared and Non-Shared Caches ................................96
242 13.8 Errors or Incomplete Response Cache Behavior ................97
243 13.9 Side Effects of GET and HEAD ................................97
244 13.10 Invalidation After Updates or Deletions ...................97
245 13.11 Write-Through Mandatory ...................................98
246 13.12 Cache Replacement .........................................99
247 13.13 History Lists .............................................99
248 14 Header Field Definitions ....................................100
249 14.1 Accept .....................................................100
250 14.2 Accept-Charset .............................................102
251 14.3 Accept-Encoding ............................................102
252 14.4 Accept-Language ............................................104
253 14.5 Accept-Ranges ..............................................105
254 14.6 Age ........................................................106
255 14.7 Allow ......................................................106
256 14.8 Authorization ..............................................107
257 14.9 Cache-Control ..............................................108
258 14.9.1 What is Cacheable .......................................109
259 14.9.2 What May be Stored by Caches ............................110
260 14.9.3 Modifications of the Basic Expiration Mechanism .........111
261 14.9.4 Cache Revalidation and Reload Controls ..................113
262 14.9.5 No-Transform Directive ..................................115
263 14.9.6 Cache Control Extensions ................................116
264 14.10 Connection ...............................................117
265 14.11 Content-Encoding .........................................118
266 14.12 Content-Language .........................................118
267 14.13 Content-Length ...........................................119
268 14.14 Content-Location .........................................120
269 14.15 Content-MD5 ..............................................121
270 14.16 Content-Range ............................................122
271 14.17 Content-Type .............................................124
272 14.18 Date .....................................................124
273 14.18.1 Clockless Origin Server Operation ......................125
274 14.19 ETag .....................................................126
275 14.20 Expect ...................................................126
276 14.21 Expires ..................................................127
277 14.22 From .....................................................128
281 Fielding, et al. Standards Track [Page 5]
283 RFC 2616 HTTP/1.1 June 1999
286 14.23 Host .....................................................128
287 14.24 If-Match .................................................129
288 14.25 If-Modified-Since ........................................130
289 14.26 If-None-Match ............................................132
290 14.27 If-Range .................................................133
291 14.28 If-Unmodified-Since ......................................134
292 14.29 Last-Modified ............................................134
293 14.30 Location .................................................135
294 14.31 Max-Forwards .............................................136
295 14.32 Pragma ...................................................136
296 14.33 Proxy-Authenticate .......................................137
297 14.34 Proxy-Authorization ......................................137
298 14.35 Range ....................................................138
299 14.35.1 Byte Ranges ...........................................138
300 14.35.2 Range Retrieval Requests ..............................139
301 14.36 Referer ..................................................140
302 14.37 Retry-After ..............................................141
303 14.38 Server ...................................................141
304 14.39 TE .......................................................142
305 14.40 Trailer ..................................................143
306 14.41 Transfer-Encoding..........................................143
307 14.42 Upgrade ..................................................144
308 14.43 User-Agent ...............................................145
309 14.44 Vary .....................................................145
310 14.45 Via ......................................................146
311 14.46 Warning ..................................................148
312 14.47 WWW-Authenticate .........................................150
313 15 Security Considerations .......................................150
314 15.1 Personal Information....................................151
315 15.1.1 Abuse of Server Log Information .........................151
316 15.1.2 Transfer of Sensitive Information .......................151
317 15.1.3 Encoding Sensitive Information in URI's .................152
318 15.1.4 Privacy Issues Connected to Accept Headers ..............152
319 15.2 Attacks Based On File and Path Names .......................153
320 15.3 DNS Spoofing ...............................................154
321 15.4 Location Headers and Spoofing ..............................154
322 15.5 Content-Disposition Issues .................................154
323 15.6 Authentication Credentials and Idle Clients ................155
324 15.7 Proxies and Caching ........................................155
325 15.7.1 Denial of Service Attacks on Proxies....................156
326 16 Acknowledgments .............................................156
327 17 References ..................................................158
328 18 Authors' Addresses ..........................................162
329 19 Appendices ..................................................164
330 19.1 Internet Media Type message/http and application/http ......164
331 19.2 Internet Media Type multipart/byteranges ...................165
332 19.3 Tolerant Applications ......................................166
333 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
337 Fielding, et al. Standards Track [Page 6]
339 RFC 2616 HTTP/1.1 June 1999
342 19.4.1 MIME-Version ............................................167
343 19.4.2 Conversion to Canonical Form ............................167
344 19.4.3 Conversion of Date Formats ..............................168
345 19.4.4 Introduction of Content-Encoding ........................168
346 19.4.5 No Content-Transfer-Encoding ............................168
347 19.4.6 Introduction of Transfer-Encoding .......................169
348 19.4.7 MHTML and Line Length Limitations .......................169
349 19.5 Additional Features ........................................169
350 19.5.1 Content-Disposition .....................................170
351 19.6 Compatibility with Previous Versions .......................170
352 19.6.1 Changes from HTTP/1.0 ...................................171
353 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
354 19.6.3 Changes from RFC 2068 ...................................172
355 20 Index .......................................................175
356 21 Full Copyright Statement ....................................176
362 The Hypertext Transfer Protocol (HTTP) is an application-level
363 protocol for distributed, collaborative, hypermedia information
364 systems. HTTP has been in use by the World-Wide Web global
365 information initiative since 1990. The first version of HTTP,
366 referred to as HTTP/0.9, was a simple protocol for raw data transfer
367 across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
368 the protocol by allowing messages to be in the format of MIME-like
369 messages, containing metainformation about the data transferred and
370 modifiers on the request/response semantics. However, HTTP/1.0 does
371 not sufficiently take into consideration the effects of hierarchical
372 proxies, caching, the need for persistent connections, or virtual
373 hosts. In addition, the proliferation of incompletely-implemented
374 applications calling themselves "HTTP/1.0" has necessitated a
375 protocol version change in order for two communicating applications
376 to determine each other's true capabilities.
378 This specification defines the protocol referred to as "HTTP/1.1".
379 This protocol includes more stringent requirements than HTTP/1.0 in
380 order to ensure reliable implementation of its features.
382 Practical information systems require more functionality than simple
383 retrieval, including search, front-end update, and annotation. HTTP
384 allows an open-ended set of methods and headers that indicate the
385 purpose of a request [47]. It builds on the discipline of reference
386 provided by the Uniform Resource Identifier (URI) [3], as a location
387 (URL) [4] or name (URN) [20], for indicating the resource to which a
393 Fielding, et al. Standards Track [Page 7]
395 RFC 2616 HTTP/1.1 June 1999
398 method is to be applied. Messages are passed in a format similar to
399 that used by Internet mail [9] as defined by the Multipurpose
400 Internet Mail Extensions (MIME) [7].
402 HTTP is also used as a generic protocol for communication between
403 user agents and proxies/gateways to other Internet systems, including
404 those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
405 and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
406 access to resources available from diverse applications.
410 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
411 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
412 document are to be interpreted as described in RFC 2119 [34].
414 An implementation is not compliant if it fails to satisfy one or more
415 of the MUST or REQUIRED level requirements for the protocols it
416 implements. An implementation that satisfies all the MUST or REQUIRED
417 level and all the SHOULD level requirements for its protocols is said
418 to be "unconditionally compliant"; one that satisfies all the MUST
419 level requirements but not all the SHOULD level requirements for its
420 protocols is said to be "conditionally compliant."
424 This specification uses a number of terms to refer to the roles
425 played by participants in, and objects of, the HTTP communication.
428 A transport layer virtual circuit established between two programs
429 for the purpose of communication.
432 The basic unit of HTTP communication, consisting of a structured
433 sequence of octets matching the syntax defined in section 4 and
434 transmitted via the connection.
437 An HTTP request message, as defined in section 5.
440 An HTTP response message, as defined in section 6.
449 Fielding, et al. Standards Track [Page 8]
451 RFC 2616 HTTP/1.1 June 1999
455 A network data object or service that can be identified by a URI,
456 as defined in section 3.2. Resources may be available in multiple
457 representations (e.g. multiple languages, data formats, size, and
458 resolutions) or vary in other ways.
461 The information transferred as the payload of a request or
462 response. An entity consists of metainformation in the form of
463 entity-header fields and content in the form of an entity-body, as
464 described in section 7.
467 An entity included with a response that is subject to content
468 negotiation, as described in section 12. There may exist multiple
469 representations associated with a particular response status.
472 The mechanism for selecting the appropriate representation when
473 servicing a request, as described in section 12. The
474 representation of entities in any response can be negotiated
475 (including error responses).
478 A resource may have one, or more than one, representation(s)
479 associated with it at any given instant. Each of these
480 representations is termed a `varriant'. Use of the term `variant'
481 does not necessarily imply that the resource is subject to content
485 A program that establishes connections for the purpose of sending
489 The client which initiates a request. These are often browsers,
490 editors, spiders (web-traversing robots), or other end user tools.
493 An application program that accepts connections in order to
494 service requests by sending back responses. Any given program may
495 be capable of being both a client and a server; our use of these
496 terms refers only to the role being performed by the program for a
497 particular connection, rather than to the program's capabilities
498 in general. Likewise, any server may act as an origin server,
499 proxy, gateway, or tunnel, switching behavior based on the nature
505 Fielding, et al. Standards Track [Page 9]
507 RFC 2616 HTTP/1.1 June 1999
511 The server on which a given resource resides or is to be created.
514 An intermediary program which acts as both a server and a client
515 for the purpose of making requests on behalf of other clients.
516 Requests are serviced internally or by passing them on, with
517 possible translation, to other servers. A proxy MUST implement
518 both the client and server requirements of this specification. A
519 "transparent proxy" is a proxy that does not modify the request or
520 response beyond what is required for proxy authentication and
521 identification. A "non-transparent proxy" is a proxy that modifies
522 the request or response in order to provide some added service to
523 the user agent, such as group annotation services, media type
524 transformation, protocol reduction, or anonymity filtering. Except
525 where either transparent or non-transparent behavior is explicitly
526 stated, the HTTP proxy requirements apply to both types of
530 A server which acts as an intermediary for some other server.
531 Unlike a proxy, a gateway receives requests as if it were the
532 origin server for the requested resource; the requesting client
533 may not be aware that it is communicating with a gateway.
536 An intermediary program which is acting as a blind relay between
537 two connections. Once active, a tunnel is not considered a party
538 to the HTTP communication, though the tunnel may have been
539 initiated by an HTTP request. The tunnel ceases to exist when both
540 ends of the relayed connections are closed.
543 A program's local store of response messages and the subsystem
544 that controls its message storage, retrieval, and deletion. A
545 cache stores cacheable responses in order to reduce the response
546 time and network bandwidth consumption on future, equivalent
547 requests. Any client or server may include a cache, though a cache
548 cannot be used by a server that is acting as a tunnel.
551 A response is cacheable if a cache is allowed to store a copy of
552 the response message for use in answering subsequent requests. The
553 rules for determining the cacheability of HTTP responses are
554 defined in section 13. Even if a resource is cacheable, there may
555 be additional constraints on whether a cache can use the cached
556 copy for a particular request.
561 Fielding, et al. Standards Track [Page 10]
563 RFC 2616 HTTP/1.1 June 1999
567 A response is first-hand if it comes directly and without
568 unnecessary delay from the origin server, perhaps via one or more
569 proxies. A response is also first-hand if its validity has just
570 been checked directly with the origin server.
572 explicit expiration time
573 The time at which the origin server intends that an entity should
574 no longer be returned by a cache without further validation.
576 heuristic expiration time
577 An expiration time assigned by a cache when no explicit expiration
581 The age of a response is the time since it was sent by, or
582 successfully validated with, the origin server.
585 The length of time between the generation of a response and its
589 A response is fresh if its age has not yet exceeded its freshness
593 A response is stale if its age has passed its freshness lifetime.
595 semantically transparent
596 A cache behaves in a "semantically transparent" manner, with
597 respect to a particular response, when its use affects neither the
598 requesting client nor the origin server, except to improve
599 performance. When a cache is semantically transparent, the client
600 receives exactly the same response (except for hop-by-hop headers)
601 that it would have received had its request been handled directly
602 by the origin server.
605 A protocol element (e.g., an entity tag or a Last-Modified time)
606 that is used to find out whether a cache entry is an equivalent
610 Upstream and downstream describe the flow of a message: all
611 messages flow from upstream to downstream.
617 Fielding, et al. Standards Track [Page 11]
619 RFC 2616 HTTP/1.1 June 1999
623 Inbound and outbound refer to the request and response paths for
624 messages: "inbound" means "traveling toward the origin server",
625 and "outbound" means "traveling toward the user agent"
627 1.4 Overall Operation
629 The HTTP protocol is a request/response protocol. A client sends a
630 request to the server in the form of a request method, URI, and
631 protocol version, followed by a MIME-like message containing request
632 modifiers, client information, and possible body content over a
633 connection with a server. The server responds with a status line,
634 including the message's protocol version and a success or error code,
635 followed by a MIME-like message containing server information, entity
636 metainformation, and possible entity-body content. The relationship
637 between HTTP and MIME is described in appendix 19.4.
639 Most HTTP communication is initiated by a user agent and consists of
640 a request to be applied to a resource on some origin server. In the
641 simplest case, this may be accomplished via a single connection (v)
642 between the user agent (UA) and the origin server (O).
644 request chain ------------------------>
645 UA -------------------v------------------- O
646 <----------------------- response chain
648 A more complicated situation occurs when one or more intermediaries
649 are present in the request/response chain. There are three common
650 forms of intermediary: proxy, gateway, and tunnel. A proxy is a
651 forwarding agent, receiving requests for a URI in its absolute form,
652 rewriting all or part of the message, and forwarding the reformatted
653 request toward the server identified by the URI. A gateway is a
654 receiving agent, acting as a layer above some other server(s) and, if
655 necessary, translating the requests to the underlying server's
656 protocol. A tunnel acts as a relay point between two connections
657 without changing the messages; tunnels are used when the
658 communication needs to pass through an intermediary (such as a
659 firewall) even when the intermediary cannot understand the contents
662 request chain -------------------------------------->
663 UA -----v----- A -----v----- B -----v----- C -----v----- O
664 <------------------------------------- response chain
666 The figure above shows three intermediaries (A, B, and C) between the
667 user agent and origin server. A request or response message that
668 travels the whole chain will pass through four separate connections.
669 This distinction is important because some HTTP communication options
673 Fielding, et al. Standards Track [Page 12]
675 RFC 2616 HTTP/1.1 June 1999
678 may apply only to the connection with the nearest, non-tunnel
679 neighbor, only to the end-points of the chain, or to all connections
680 along the chain. Although the diagram is linear, each participant may
681 be engaged in multiple, simultaneous communications. For example, B
682 may be receiving requests from many clients other than A, and/or
683 forwarding requests to servers other than C, at the same time that it
684 is handling A's request.
686 Any party to the communication which is not acting as a tunnel may
687 employ an internal cache for handling requests. The effect of a cache
688 is that the request/response chain is shortened if one of the
689 participants along the chain has a cached response applicable to that
690 request. The following illustrates the resulting chain if B has a
691 cached copy of an earlier response from O (via C) for a request which
692 has not been cached by UA or A.
694 request chain ---------->
695 UA -----v----- A -----v----- B - - - - - - C - - - - - - O
696 <--------- response chain
698 Not all responses are usefully cacheable, and some requests may
699 contain modifiers which place special requirements on cache behavior.
700 HTTP requirements for cache behavior and cacheable responses are
701 defined in section 13.
703 In fact, there are a wide variety of architectures and configurations
704 of caches and proxies currently being experimented with or deployed
705 across the World Wide Web. These systems include national hierarchies
706 of proxy caches to save transoceanic bandwidth, systems that
707 broadcast or multicast cache entries, organizations that distribute
708 subsets of cached data via CD-ROM, and so on. HTTP systems are used
709 in corporate intranets over high-bandwidth links, and for access via
710 PDAs with low-power radio links and intermittent connectivity. The
711 goal of HTTP/1.1 is to support the wide diversity of configurations
712 already deployed while introducing protocol constructs that meet the
713 needs of those who build web applications that require high
714 reliability and, failing that, at least reliable indications of
717 HTTP communication usually takes place over TCP/IP connections. The
718 default port is TCP 80 [19], but other ports can be used. This does
719 not preclude HTTP from being implemented on top of any other protocol
720 on the Internet, or on other networks. HTTP only presumes a reliable
721 transport; any protocol that provides such guarantees can be used;
722 the mapping of the HTTP/1.1 request and response structures onto the
723 transport data units of the protocol in question is outside the scope
724 of this specification.
729 Fielding, et al. Standards Track [Page 13]
731 RFC 2616 HTTP/1.1 June 1999
734 In HTTP/1.0, most implementations used a new connection for each
735 request/response exchange. In HTTP/1.1, a connection may be used for
736 one or more request/response exchanges, although connections may be
737 closed for a variety of reasons (see section 8.1).
739 2 Notational Conventions and Generic Grammar
743 All of the mechanisms specified in this document are described in
744 both prose and an augmented Backus-Naur Form (BNF) similar to that
745 used by RFC 822 [9]. Implementors will need to be familiar with the
746 notation in order to understand this specification. The augmented BNF
747 includes the following constructs:
750 The name of a rule is simply the name itself (without any
751 enclosing "<" and ">") and is separated from its definition by the
752 equal "=" character. White space is only significant in that
753 indentation of continuation lines is used to indicate a rule
754 definition that spans more than one line. Certain basic rules are
755 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
756 brackets are used within definitions whenever their presence will
757 facilitate discerning the use of rule names.
760 Quotation marks surround literal text. Unless stated otherwise,
761 the text is case-insensitive.
764 Elements separated by a bar ("|") are alternatives, e.g., "yes |
765 no" will accept yes or no.
768 Elements enclosed in parentheses are treated as a single element.
769 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
770 foo elem" and "elem bar elem".
773 The character "*" preceding an element indicates repetition. The
774 full form is "<n>*<m>element" indicating at least <n> and at most
775 <m> occurrences of element. Default values are 0 and infinity so
776 that "*(element)" allows any number, including zero; "1*element"
777 requires at least one; and "1*2element" allows one or two.
780 Square brackets enclose optional elements; "[foo bar]" is
781 equivalent to "*1(foo bar)".
785 Fielding, et al. Standards Track [Page 14]
787 RFC 2616 HTTP/1.1 June 1999
791 Specific repetition: "<n>(element)" is equivalent to
792 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
793 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
794 alphabetic characters.
797 A construct "#" is defined, similar to "*", for defining lists of
798 elements. The full form is "<n>#<m>element" indicating at least
799 <n> and at most <m> elements, each separated by one or more commas
800 (",") and OPTIONAL linear white space (LWS). This makes the usual
801 form of lists very easy; a rule such as
802 ( *LWS element *( *LWS "," *LWS element ))
805 Wherever this construct is used, null elements are allowed, but do
806 not contribute to the count of elements present. That is,
807 "(element), , (element) " is permitted, but counts as only two
808 elements. Therefore, where at least one element is required, at
809 least one non-null element MUST be present. Default values are 0
810 and infinity so that "#element" allows any number, including zero;
811 "1#element" requires at least one; and "1#2element" allows one or
815 A semi-colon, set off some distance to the right of rule text,
816 starts a comment that continues to the end of line. This is a
817 simple way of including useful notes in parallel with the
821 The grammar described by this specification is word-based. Except
822 where noted otherwise, linear white space (LWS) can be included
823 between any two adjacent words (token or quoted-string), and
824 between adjacent words and separators, without changing the
825 interpretation of a field. At least one delimiter (LWS and/or
827 separators) MUST exist between any two tokens (for the definition
828 of "token" below), since they would otherwise be interpreted as a
833 The following rules are used throughout this specification to
834 describe basic parsing constructs. The US-ASCII coded character set
835 is defined by ANSI X3.4-1986 [21].
841 Fielding, et al. Standards Track [Page 15]
843 RFC 2616 HTTP/1.1 June 1999
846 OCTET = <any 8-bit sequence of data>
847 CHAR = <any US-ASCII character (octets 0 - 127)>
848 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
849 LOALPHA = <any US-ASCII lowercase letter "a".."z">
850 ALPHA = UPALPHA | LOALPHA
851 DIGIT = <any US-ASCII digit "0".."9">
852 CTL = <any US-ASCII control character
853 (octets 0 - 31) and DEL (127)>
854 CR = <US-ASCII CR, carriage return (13)>
855 LF = <US-ASCII LF, linefeed (10)>
856 SP = <US-ASCII SP, space (32)>
857 HT = <US-ASCII HT, horizontal-tab (9)>
858 <"> = <US-ASCII double-quote mark (34)>
860 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
861 protocol elements except the entity-body (see appendix 19.3 for
862 tolerant applications). The end-of-line marker within an entity-body
863 is defined by its associated media type, as described in section 3.7.
867 HTTP/1.1 header field values can be folded onto multiple lines if the
868 continuation line begins with a space or horizontal tab. All linear
869 white space, including folding, has the same semantics as SP. A
870 recipient MAY replace any linear white space with a single SP before
871 interpreting the field value or forwarding the message downstream.
873 LWS = [CRLF] 1*( SP | HT )
875 The TEXT rule is only used for descriptive field contents and values
876 that are not intended to be interpreted by the message parser. Words
877 of *TEXT MAY contain characters from character sets other than ISO-
878 8859-1 [22] only when encoded according to the rules of RFC 2047
881 TEXT = <any OCTET except CTLs,
884 A CRLF is allowed in the definition of TEXT only as part of a header
885 field continuation. It is expected that the folding LWS will be
886 replaced with a single SP before interpretation of the TEXT value.
888 Hexadecimal numeric characters are used in several protocol elements.
890 HEX = "A" | "B" | "C" | "D" | "E" | "F"
891 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
897 Fielding, et al. Standards Track [Page 16]
899 RFC 2616 HTTP/1.1 June 1999
902 Many HTTP/1.1 header field values consist of words separated by LWS
903 or special characters. These special characters MUST be in a quoted
904 string to be used within a parameter value (as defined in section
907 token = 1*<any CHAR except CTLs or separators>
908 separators = "(" | ")" | "<" | ">" | "@"
909 | "," | ";" | ":" | "\" | <">
910 | "/" | "[" | "]" | "?" | "="
911 | "{" | "}" | SP | HT
913 Comments can be included in some HTTP header fields by surrounding
914 the comment text with parentheses. Comments are only allowed in
915 fields containing "comment" as part of their field value definition.
916 In all other fields, parentheses are considered part of the field
919 comment = "(" *( ctext | quoted-pair | comment ) ")"
920 ctext = <any TEXT excluding "(" and ")">
922 A string of text is parsed as a single word if it is quoted using
925 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
926 qdtext = <any TEXT except <">>
928 The backslash character ("\") MAY be used as a single-character
929 quoting mechanism only within quoted-string and comment constructs.
931 quoted-pair = "\" CHAR
933 3 Protocol Parameters
937 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
938 of the protocol. The protocol versioning policy is intended to allow
939 the sender to indicate the format of a message and its capacity for
940 understanding further HTTP communication, rather than the features
941 obtained via that communication. No change is made to the version
942 number for the addition of message components which do not affect
943 communication behavior or which only add to extensible field values.
944 The <minor> number is incremented when the changes made to the
945 protocol add features which do not change the general message parsing
946 algorithm, but which may add to the message semantics and imply
947 additional capabilities of the sender. The <major> number is
948 incremented when the format of a message within the protocol is
949 changed. See RFC 2145 [36] for a fuller explanation.
953 Fielding, et al. Standards Track [Page 17]
955 RFC 2616 HTTP/1.1 June 1999
958 The version of an HTTP message is indicated by an HTTP-Version field
959 in the first line of the message. [[HTTP-Version is case-sensitive.]]
961 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
963 Note that the major and minor numbers MUST be treated as separate
964 integers and that each MAY be incremented higher than a single digit.
965 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
966 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
969 An application that sends a request or response message that includes
970 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
971 with this specification. Applications that are at least conditionally
972 compliant with this specification SHOULD use an HTTP-Version of
973 "HTTP/1.1" in their messages, and MUST do so for any message that is
974 not compatible with HTTP/1.0. For more details on when to send
975 specific HTTP-Version values, see RFC 2145 [36].
977 The HTTP version of an application is the highest HTTP version for
978 which the application is at least conditionally compliant.
980 Proxy and gateway applications need to be careful when forwarding
981 messages in protocol versions different from that of the application.
982 Since the protocol version indicates the protocol capability of the
983 sender, a proxy/gateway MUST NOT send a message with a version
984 indicator which is greater than its actual version. If a higher
985 version request is received, the proxy/gateway MUST either downgrade
986 the request version, or respond with an error, or switch to tunnel
989 Due to interoperability problems with HTTP/1.0 proxies discovered
990 since the publication of RFC 2068[33], caching proxies MUST, gateways
991 MAY, and tunnels MUST NOT upgrade the request to the highest version
992 they support. The proxy/gateway's response to that request MUST be in
993 the same major version as the request.
995 Note: Converting between versions of HTTP may involve modification
996 of header fields required or forbidden by the versions involved.
998 3.2 Uniform Resource Identifiers
1000 URIs have been known by many names: WWW addresses, Universal Document
1001 Identifiers, Universal Resource Identifiers [3], and finally the
1002 combination of Uniform Resource Locators (URL) [4] and Names (URN)
1003 [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
1004 simply formatted strings which identify--via name, location, or any
1005 other characteristic--a resource.
1009 Fielding, et al. Standards Track [Page 18]
1011 RFC 2616 HTTP/1.1 June 1999
1014 3.2.1 General Syntax
1016 URIs in HTTP can be represented in absolute form or relative to some
1017 known base URI [11], depending upon the context of their use. The two
1018 forms are differentiated by the fact that absolute URIs always begin
1019 with a scheme name followed by a colon. For definitive information on
1020 URL syntax and semantics, see "Uniform Resource Identifiers (URI):
1021 Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1022 1738 [4] and RFC 1808 [11]). This specification adopts the
1023 definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
1024 "host","abs_path", "rel_path", and "authority" from that
1027 The HTTP protocol does not place any a priori limit on the length of
1028 a URI. Servers MUST be able to handle the URI of any resource they
1029 serve, and SHOULD be able to handle URIs of unbounded length if they
1030 provide GET-based forms that could generate such URIs. A server
1031 SHOULD return 414 (Request-URI Too Long) status if a URI is longer
1032 than the server can handle (see section 10.4.15).
1034 Note: Servers ought to be cautious about depending on URI lengths
1035 above 255 bytes, because some older client or proxy
1036 implementations might not properly support these lengths.
1040 The "http" scheme is used to locate network resources via the HTTP
1041 protocol. This section defines the scheme-specific syntax and
1042 semantics for http URLs.
1044 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
1046 If the port is empty or not given, port 80 is assumed. The semantics
1047 are that the identified resource is located at the server listening
1048 for TCP connections on that port of that host, and the Request-URI
1049 for the resource is abs_path (section 5.1.2). The use of IP addresses
1050 in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
1051 the abs_path is not present in the URL, it MUST be given as "/" when
1052 used as a Request-URI for a resource (section 5.1.2). If a proxy
1053 receives a host name which is not a fully qualified domain name, it
1054 MAY add its domain to the host name it received. If a proxy receives
1055 a fully qualified domain name, the proxy MUST NOT change the host
1065 Fielding, et al. Standards Track [Page 19]
1067 RFC 2616 HTTP/1.1 June 1999
1070 3.2.3 URI Comparison
1072 When comparing two URIs to decide if they match or not, a client
1073 SHOULD use a case-sensitive octet-by-octet comparison of the entire
1074 URIs, with these exceptions:
1076 - A port that is empty or not given is equivalent to the default
1077 port for that URI-reference;
1079 - Comparisons of host names MUST be case-insensitive;
1081 - Comparisons of scheme names MUST be case-insensitive;
1083 - An empty abs_path is equivalent to an abs_path of "/".
1085 Characters other than those in the "reserved" and "unsafe" sets (see
1086 RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
1087 [[ Ignore reference to "unsafe" set. ]]
1089 For example, the following three URIs are equivalent:
1091 http://abc.com:80/~smith/home.html
1092 http://ABC.com/%7Esmith/home.html
1093 http://ABC.com:/%7esmith/home.html
1095 3.3 Date/Time Formats
1099 HTTP applications have historically allowed three different formats
1100 for the representation of date/time stamps:
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
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.
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.
1122 Fielding, et al. Standards Track [Page 20]
1124 RFC 2616 HTTP/1.1 June 1999
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
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"
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
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.
1167 delta-seconds = 1*DIGIT
1171 HTTP uses the same definition of the term "character set" as that
1178 Fielding, et al. Standards Track [Page 21]
1180 RFC 2616 HTTP/1.1 June 1999
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.
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
1202 HTTP character sets are identified by case-insensitive tokens. The
1203 complete set of tokens is defined by the IANA Character Set registry
1208 [[ HTTP uses charset in two contexts: within an Accept-Charset request ]]
1209 [[ header (in which the charset value is an unquoted token) and as the ]]
1210 [[ value of a parameter in a Content-type header (within a request or ]]
1211 [[ response), in which case the parameter value of the charset ]]
1212 [[ parameter may be quoted. ]]
1214 Although HTTP allows an arbitrary token to be used as a charset
1215 value, any token that has a predefined value within the IANA
1216 Character Set registry [19] MUST represent the character set defined
1217 by that registry. Applications SHOULD limit their use of character
1218 sets to those defined by the IANA registry.
1220 Implementors should be aware of IETF character set requirements [38]
1223 3.4.1 Missing Charset
1225 Some HTTP/1.0 software has interpreted a Content-Type header without
1226 charset parameter incorrectly to mean "recipient should guess."
1227 Senders wishing to defeat this behavior MAY include a charset
1228 parameter even when the charset is ISO-8859-1 and SHOULD do so when
1229 it is known that it will not confuse the recipient.
1231 Unfortunately, some older HTTP/1.0 clients did not deal properly with
1232 an explicit charset parameter. HTTP/1.1 recipients MUST respect the
1233 charset label provided by the sender; and those user agents that have
1234 a provision to "guess" a charset MUST use the charset from the
1240 Fielding, et al. Standards Track [Page 22]
1242 RFC 2616 HTTP/1.1 June 1999
1245 content-type field if they support that charset, rather than the
1246 recipient's preference, when initially displaying a document. See
1251 Content coding values indicate an encoding transformation that has
1252 been or can be applied to an entity. Content codings are primarily
1253 used to allow a document to be compressed or otherwise usefully
1254 transformed without losing the identity of its underlying media type
1255 and without loss of information. Frequently, the entity is stored in
1256 coded form, transmitted directly, and only decoded by the recipient.
1258 content-coding = token
1260 All content-coding values are case-insensitive. HTTP/1.1 uses
1261 content-coding values in the Accept-Encoding (section 14.3) and
1262 Content-Encoding (section 14.11) header fields. Although the value
1263 describes the content-coding, what is more important is that it
1264 indicates what decoding mechanism will be required to remove the
1267 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1268 content-coding value tokens. Initially, the registry contains the
1271 gzip An encoding format produced by the file compression program
1272 "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
1273 Lempel-Ziv coding (LZ77) with a 32 bit CRC.
1276 The encoding format produced by the common UNIX file compression
1277 program "compress". This format is an adaptive Lempel-Ziv-Welch
1280 Use of program names for the identification of encoding formats
1281 is not desirable and is discouraged for future encodings. Their
1282 use here is representative of historical practice, not good
1283 design. For compatibility with previous implementations of HTTP,
1284 applications SHOULD consider "x-gzip" and "x-compress" to be
1285 equivalent to "gzip" and "compress" respectively.
1288 The "zlib" format defined in RFC 1950 [31] in combination with
1289 the "deflate" compression mechanism described in RFC 1951 [29].
1296 Fielding, et al. Standards Track [Page 23]
1298 RFC 2616 HTTP/1.1 June 1999
1302 The default (identity) encoding; the use of no transformation
1303 whatsoever. This content-coding is used only in the Accept-
1304 Encoding header, and SHOULD NOT be used in the Content-Encoding
1307 New content-coding value tokens SHOULD be registered; to allow
1308 interoperability between clients and servers, specifications of the
1309 content coding algorithms needed to implement a new value SHOULD be
1310 publicly available and adequate for independent implementation, and
1311 conform to the purpose of content coding defined in this section.
1313 3.6 Transfer Codings
1315 Transfer-coding values are used to indicate an encoding
1316 transformation that has been, can be, or may need to be applied to an
1317 entity-body in order to ensure "safe transport" through the network.
1318 This differs from a content coding in that the transfer-coding is a
1319 property of the message, not of the original entity.
1321 transfer-coding = "chunked" | transfer-extension
1322 transfer-extension = token *( ";" parameter )
1324 Parameters are in the form of attribute/value pairs.
1326 parameter = attribute "=" value
1328 value = token | quoted-string
1330 All transfer-coding values are case-insensitive. HTTP/1.1 uses
1331 transfer-coding values in the TE header field (section 14.39) and in
1332 the Transfer-Encoding header field (section 14.41).
1334 Whenever a transfer-coding is applied to a message-body, the set of
1335 transfer-codings MUST include "chunked", unless the message is
1336 terminated by closing the connection. When the "chunked" transfer-
1337 coding is used, it MUST be the last transfer-coding applied to the
1338 message-body. The "chunked" transfer-coding MUST NOT be applied more
1339 than once to a message-body. These rules allow the recipient to
1340 determine the transfer-length of the message (section 4.4).
1342 Transfer-codings are analogous to the Content-Transfer-Encoding
1343 values of MIME [7], which were designed to enable safe transport of
1344 binary data over a 7-bit transport service. However, safe transport
1345 has a different focus for an 8bit-clean transfer protocol. In HTTP,
1346 the only unsafe characteristic of message-bodies is the difficulty in
1347 determining the exact body length (section 7.2.2), or the desire to
1348 encrypt data over a shared transport.
1352 Fielding, et al. Standards Track [Page 24]
1354 RFC 2616 HTTP/1.1 June 1999
1357 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1358 transfer-coding value tokens. Initially, the registry contains the
1359 following tokens: "chunked" (section 3.6.1), "identity" (section
1360 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
1363 [[ Remove reference to "identity" token ]]
1365 New transfer-coding value tokens SHOULD be registered in the same way
1366 as new content-coding value tokens (section 3.5).
1368 A server which receives an entity-body with a transfer-coding it does
1369 not understand SHOULD return 501 (Unimplemented), and close the
1370 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
1373 3.6.1 Chunked Transfer Coding
1375 The chunked encoding modifies the body of a message in order to
1376 transfer it as a series of chunks, each with its own size indicator,
1377 followed by an OPTIONAL trailer containing entity-header fields. This
1378 allows dynamically produced content to be transferred along with the
1379 information necessary for the recipient to verify that it has
1380 received the full message.
1382 Chunked-Body = *chunk
1387 chunk = chunk-size [ chunk-extension ] CRLF
1390 last-chunk = 1*("0") [ chunk-extension ] CRLF
1392 chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1393 chunk-ext-name = token
1394 chunk-ext-val = token | quoted-string
1395 chunk-data = chunk-size(OCTET)
1396 trailer = *(entity-header CRLF)
1398 The chunk-size field is a string of hex digits indicating the size of
1399 the chunk. The chunked encoding is ended by any chunk whose size is
1400 zero, followed by the trailer, which is terminated by an empty line.
1402 [[ "the size of the chunk" means "the size of the chunk-data in ]]
1405 The trailer allows the sender to include additional HTTP header
1406 fields at the end of the message. The Trailer header field can be
1407 used to indicate which header fields are included in a trailer (see
1413 Fielding, et al. Standards Track [Page 25]
1415 RFC 2616 HTTP/1.1 June 1999
1418 A server using chunked transfer-coding in a response MUST NOT use the
1419 trailer for any header fields unless at least one of the following is
1422 a)the request included a TE header field that indicates "trailers" is
1423 acceptable in the transfer-coding of the response, as described in
1426 b)the server is the origin server for the response, the trailer
1427 fields consist entirely of optional metadata, and the recipient
1428 could use the message (in a manner acceptable to the origin server)
1429 without receiving this metadata. In other words, the origin server
1430 is willing to accept the possibility that the trailer fields might
1431 be silently discarded along the path to the client.
1433 This requirement prevents an interoperability failure when the
1434 message is being received by an HTTP/1.1 (or later) proxy and
1435 forwarded to an HTTP/1.0 recipient. It avoids a situation where
1436 compliance with the protocol would have necessitated a possibly
1437 infinite buffer on the proxy.
1439 An example process for decoding a Chunked-Body is presented in
1442 All HTTP/1.1 applications MUST be able to receive and decode the
1443 "chunked" transfer-coding, and MUST ignore chunk-extension extensions
1444 they do not understand.
1448 HTTP uses Internet Media Types [17] in the Content-Type (section
1449 14.17) and Accept (section 14.1) header fields in order to provide
1450 open and extensible data typing and type negotiation.
1452 media-type = type "/" subtype *( ";" parameter )
1456 Parameters MAY follow the type/subtype in the form of attribute/value
1457 pairs (as defined in section 3.6).
1459 The type, subtype, and parameter attribute names are case-
1460 insensitive. Parameter values might or might not be case-sensitive,
1461 depending on the semantics of the parameter name. Linear white space
1462 (LWS) MUST NOT be used between the type and subtype, nor between an
1463 attribute and its value. The presence or absence of a parameter might
1464 be significant to the processing of a media-type, depending on its
1465 definition within the media type registry.
1469 Fielding, et al. Standards Track [Page 26]
1471 RFC 2616 HTTP/1.1 June 1999
1474 Note that some older HTTP applications do not recognize media type
1475 parameters. When sending data to older HTTP applications,
1476 implementations SHOULD only use media type parameters when they are
1477 required by that type/subtype definition.
1479 Media-type values are registered with the Internet Assigned Number
1480 Authority (IANA [19]). The media type registration process is
1481 outlined in RFC 1590 [17]. Use of non-registered media types is
1484 [[ "RFC 1590" should be "RFC 2048" ]]
1486 3.7.1 Canonicalization and Text Defaults
1488 Internet media types are registered with a canonical form. An
1489 entity-body transferred via HTTP messages MUST be represented in the
1490 appropriate canonical form prior to its transmission except for
1491 "text" types, as defined in the next paragraph.
1493 When in canonical form, media subtypes of the "text" type use CRLF as
1494 the text line break. HTTP relaxes this requirement and allows the
1495 transport of text media with plain CR or LF alone representing a line
1496 break when it is done consistently for an entire entity-body. HTTP
1497 applications MUST accept CRLF, bare CR, and bare LF as being
1498 representative of a line break in text media received via HTTP. In
1499 addition, if the text is represented in a character set that does not
1500 use octets 13 and 10 for CR and LF respectively, as is the case for
1501 some multi-byte character sets, HTTP allows the use of whatever octet
1502 sequences are defined by that character set to represent the
1503 equivalent of CR and LF for line breaks. This flexibility regarding
1504 line breaks applies only to text media in the entity-body; a bare CR
1505 or LF MUST NOT be substituted for CRLF within any of the HTTP control
1506 structures (such as header fields and multipart boundaries).
1508 If an entity-body is encoded with a content-coding, the underlying
1509 data MUST be in a form defined above prior to being encoded.
1511 The "charset" parameter is used with some media types to define the
1512 character set (section 3.4) of the data. When no explicit charset
1513 parameter is provided by the sender, media subtypes of the "text"
1514 type are defined to have a default charset value of "ISO-8859-1" when
1515 received via HTTP. Data in character sets other than "ISO-8859-1" or
1516 its subsets MUST be labeled with an appropriate charset value. See
1517 section 3.4.1 for compatibility problems.
1519 3.7.2 Multipart Types
1521 MIME provides for a number of "multipart" types -- encapsulations of
1522 one or more entities within a single message-body. All multipart
1523 types share a common syntax, as defined in section 5.1.1 of RFC 2046
1527 Fielding, et al. Standards Track [Page 27]
1529 RFC 2616 HTTP/1.1 June 1999
1532 [40], and MUST include a boundary parameter as part of the media type
1533 value. The message body is itself a protocol element and MUST
1534 therefore use only CRLF to represent line breaks between body-parts.
1535 Unlike in RFC 2046, the epilogue of any multipart message MUST be
1536 empty; HTTP applications MUST NOT transmit the epilogue (even if the
1537 original multipart contains an epilogue). These restrictions exist in
1538 order to preserve the self-delimiting nature of a multipart message-
1539 body, wherein the "end" of the message-body is indicated by the
1540 ending multipart boundary.
1542 In general, HTTP treats a multipart message-body no differently than
1543 any other media type: strictly as payload. The one exception is the
1544 "multipart/byteranges" type (appendix 19.2) when it appears in a 206
1545 (Partial Content) response, which will be interpreted by some HTTP
1546 caching mechanisms as described in sections 13.5.4 and 14.16. In all
1547 other cases, an HTTP user agent SHOULD follow the same or similar
1548 behavior as a MIME user agent would upon receipt of a multipart type.
1549 The MIME header fields within each body-part of a multipart message-
1550 body do not have any significance to HTTP beyond that defined by
1551 their MIME semantics.
1553 In general, an HTTP user agent SHOULD follow the same or similar
1554 behavior as a MIME user agent would upon receipt of a multipart type.
1555 If an application receives an unrecognized multipart subtype, the
1556 application MUST treat it as being equivalent to "multipart/mixed".
1558 Note: The "multipart/form-data" type has been specifically defined
1559 for carrying form data suitable for processing via the POST
1560 request method, as described in RFC 1867 [15].
1564 Product tokens are used to allow communicating applications to
1565 identify themselves by software name and version. Most fields using
1566 product tokens also allow sub-products which form a significant part
1567 of the application to be listed, separated by white space. By
1568 convention, the products are listed in order of their significance
1569 for identifying the application.
1571 product = token ["/" product-version]
1572 product-version = token
1576 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1577 Server: Apache/0.8.4
1583 Fielding, et al. Standards Track [Page 28]
1585 RFC 2616 HTTP/1.1 June 1999
1588 Product tokens SHOULD be short and to the point. They MUST NOT be
1589 used for advertising or other non-essential information. Although any
1590 token character MAY appear in a product-version, this token SHOULD
1591 only be used for a version identifier (i.e., successive versions of
1592 the same product SHOULD only differ in the product-version portion of
1597 HTTP content negotiation (section 12) uses short "floating point"
1598 numbers to indicate the relative importance ("weight") of various
1599 negotiable parameters. A weight is normalized to a real number in
1600 the range 0 through 1, where 0 is the minimum and 1 the maximum
1601 value. If a parameter has a quality value of 0, then content with
1602 this parameter is `not acceptable' for the client. HTTP/1.1
1603 applications MUST NOT generate more than three digits after the
1604 decimal point. User configuration of these values SHOULD also be
1605 limited in this fashion.
1607 qvalue = ( "0" [ "." 0*3DIGIT ] )
1608 | ( "1" [ "." 0*3("0") ] )
1610 "Quality values" is a misnomer, since these values merely represent
1611 relative degradation in desired quality.
1615 A language tag identifies a natural language spoken, written, or
1616 otherwise conveyed by human beings for communication of information
1617 to other human beings. Computer languages are explicitly excluded.
1618 HTTP uses language tags within the Accept-Language and Content-
1621 The syntax and registry of HTTP language tags is the same as that
1622 defined by RFC 1766 [1]. In summary, a language tag is composed of 1
1623 or more parts: A primary language tag and a possibly empty series of
1626 language-tag = primary-tag *( "-" subtag )
1627 primary-tag = 1*8ALPHA
1630 [[ Updated by RFC 3066: subtags may now contain digits ]]
1632 White space is not allowed within the tag and all tags are case-
1633 insensitive. The name space of language tags is administered by the
1634 IANA. Example tags include:
1636 en, en-US, en-cockney, i-cherokee, x-pig-latin
1641 Fielding, et al. Standards Track [Page 29]
1643 RFC 2616 HTTP/1.1 June 1999
1646 where any two-letter primary-tag is an ISO-639 language abbreviation
1647 and any two-letter initial subtag is an ISO-3166 country code. (The
1648 last three tags above are not registered tags; all but the last are
1649 examples of tags which could be registered in future.)
1653 Entity tags are used for comparing two or more entities from the same
1654 requested resource. HTTP/1.1 uses entity tags in the ETag (section
1655 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
1656 If-Range (section 14.27) header fields. The definition of how they
1657 are used and compared as cache validators is in section 13.3.3. An
1658 entity tag consists of an opaque quoted string, possibly prefixed by
1659 a weakness indicator.
1661 entity-tag = [ weak ] opaque-tag
1663 opaque-tag = quoted-string
1665 A "strong entity tag" MAY be shared by two entities of a resource
1666 only if they are equivalent by octet equality.
1668 A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
1669 two entities of a resource only if the entities are equivalent and
1670 could be substituted for each other with no significant change in
1671 semantics. A weak entity tag can only be used for weak comparison.
1673 An entity tag MUST be unique across all versions of all entities
1674 associated with a particular resource. A given entity tag value MAY
1675 be used for entities obtained by requests on different URIs. The use
1676 of the same entity tag value in conjunction with entities obtained by
1677 requests on different URIs does not imply the equivalence of those
1682 HTTP/1.1 allows a client to request that only part (a range of) the
1683 response entity be included within the response. HTTP/1.1 uses range
1684 units in the Range (section 14.35) and Content-Range (section 14.16)
1685 header fields. An entity can be broken down into subranges according
1686 to various structural units.
1688 range-unit = bytes-unit | other-range-unit
1689 bytes-unit = "bytes"
1690 other-range-unit = token
1692 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
1693 implementations MAY ignore ranges specified using other units.
1697 Fielding, et al. Standards Track [Page 30]
1699 RFC 2616 HTTP/1.1 June 1999
1702 HTTP/1.1 has been designed to allow implementations of applications
1703 that do not depend on knowledge of ranges.
1709 HTTP messages consist of requests from client to server and responses
1710 from server to client.
1712 HTTP-message = Request | Response ; HTTP/1.1 messages
1714 Request (section 5) and Response (section 6) messages use the generic
1715 message format of RFC 822 [9] for transferring entities (the payload
1716 of the message). Both types of message consist of a start-line, zero
1717 or more header fields (also known as "headers"), an empty line (i.e.,
1718 a line with nothing preceding the CRLF) indicating the end of the
1719 header fields, and possibly a message-body.
1721 generic-message = start-line
1722 *(message-header CRLF)
1725 start-line = Request-Line | Status-Line
1727 In the interest of robustness, servers SHOULD ignore any empty
1728 line(s) received where a Request-Line is expected. In other words, if
1729 the server is reading the protocol stream at the beginning of a
1730 message and receives a CRLF first, it should ignore the CRLF.
1732 Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1733 after a POST request. To restate what is explicitly forbidden by the
1734 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1739 HTTP header fields, which include general-header (section 4.5),
1740 request-header (section 5.3), response-header (section 6.2), and
1741 entity-header (section 7.1) fields, follow the same generic format as
1742 that given in Section 3.1 of RFC 822 [9]. Each header field consists
1743 of a name followed by a colon (":") and the field value. Field names
1744 are case-insensitive. The field value MAY be preceded by any amount
1745 of LWS, though a single SP is preferred. Header fields can be
1746 extended over multiple lines by preceding each extra line with at
1747 least one SP or HT. Applications ought to follow "common form", where
1748 one is known or indicated, when generating HTTP constructs, since
1749 there might exist some implementations that fail to accept anything
1753 Fielding, et al. Standards Track [Page 31]
1755 RFC 2616 HTTP/1.1 June 1999
1758 beyond the common forms.
1760 message-header = field-name ":" [ field-value ]
1762 field-value = *( field-content | LWS )
1763 field-content = <the OCTETs making up the field-value
1764 and consisting of either *TEXT or combinations
1765 of token, separators, and quoted-string>
1767 The field-content does not include any leading or trailing LWS:
1768 linear white space occurring before the first non-whitespace
1769 character of the field-value or after the last non-whitespace
1770 character of the field-value. Such leading or trailing LWS MAY be
1771 removed without changing the semantics of the field value. Any LWS
1772 that occurs between field-content MAY be replaced with a single SP
1773 before interpreting the field value or forwarding the message
1776 The order in which header fields with differing field names are
1777 received is not significant. However, it is "good practice" to send
1778 general-header fields first, followed by request-header or response-
1779 header fields, and ending with the entity-header fields.
1781 Multiple message-header fields with the same field-name MAY be
1782 present in a message if and only if the entire field-value for that
1783 header field is defined as a comma-separated list [i.e., #(values)].
1784 It MUST be possible to combine the multiple header fields into one
1785 "field-name: field-value" pair, without changing the semantics of the
1786 message, by appending each subsequent field-value to the first, each
1787 separated by a comma. The order in which header fields with the same
1788 field-name are received is therefore significant to the
1789 interpretation of the combined field value, and thus a proxy MUST NOT
1790 change the order of these field values when a message is forwarded.
1794 The message-body (if any) of an HTTP message is used to carry the
1795 entity-body associated with the request or response. The message-body
1796 differs from the entity-body only when a transfer-coding has been
1797 applied, as indicated by the Transfer-Encoding header field (section
1800 message-body = entity-body
1801 | <entity-body encoded as per Transfer-Encoding>
1803 Transfer-Encoding MUST be used to indicate any transfer-codings
1804 applied by an application to ensure safe and proper transfer of the
1805 message. Transfer-Encoding is a property of the message, not of the
1809 Fielding, et al. Standards Track [Page 32]
1811 RFC 2616 HTTP/1.1 June 1999
1814 entity, and thus MAY be added or removed by any application along the
1815 request/response chain. (However, section 3.6 places restrictions on
1816 when certain transfer-codings may be used.)
1818 The rules for when a message-body is allowed in a message differ for
1819 requests and responses.
1821 The presence of a message-body in a request is signaled by the
1822 inclusion of a Content-Length or Transfer-Encoding header field in
1823 the request's message-headers. A message-body MUST NOT be included in
1824 a request if the specification of the request method (section 5.1.1)
1825 does not allow sending an entity-body in requests. A server SHOULD
1826 read and forward a message-body on any request; if the request method
1827 does not include defined semantics for an entity-body, then the
1828 message-body SHOULD be ignored when handling the request.
1830 For response messages, whether or not a message-body is included with
1831 a message is dependent on both the request method and the response
1832 status code (section 6.1.1). All responses to the HEAD request method
1833 MUST NOT include a message-body, even though the presence of entity-
1834 header fields might lead one to believe they do. All 1xx
1835 (informational), 204 (no content), and 304 (not modified) responses
1836 MUST NOT include a message-body. All other responses do include a
1837 message-body, although it MAY be of zero length.
1841 The transfer-length of a message is the length of the message-body as
1842 it appears in the message; that is, after any transfer-codings have
1843 been applied. When a message-body is included with a message, the
1844 transfer-length of that body is determined by one of the following
1845 (in order of precedence):
1847 1.Any response message which "MUST NOT" include a message-body (such
1848 as the 1xx, 204, and 304 responses and any response to a HEAD
1849 request) is always terminated by the first empty line after the
1850 header fields, regardless of the entity-header fields present in
1853 2.If a Transfer-Encoding header field (section 14.41) is present and
1854 has any value other than "identity", then the transfer-length is
1855 defined by use of the "chunked" transfer-coding (section 3.6),
1856 unless the message is terminated by closing the connection.
1858 [[ Remove 'and has any value other than "identity"' ]]
1860 3.If a Content-Length header field (section 14.13) is present, its
1861 decimal value in OCTETs represents both the entity-length and the
1862 transfer-length. The Content-Length header field MUST NOT be sent
1863 if these two lengths are different (i.e., if a Transfer-Encoding
1867 Fielding, et al. Standards Track [Page 33]
1869 RFC 2616 HTTP/1.1 June 1999
1872 header field is present). If a message is received with both a
1873 Transfer-Encoding header field and a Content-Length header field,
1874 the latter MUST be ignored.
1876 4.If the message uses the media type "multipart/byteranges", and the
1877 ransfer-length is not otherwise specified, then this self-
1878 elimiting media type defines the transfer-length. This media type
1879 UST NOT be used unless the sender knows that the recipient can arse
1880 it; the presence in a request of a Range header with ultiple byte-
1881 range specifiers from a 1.1 client implies that the lient can parse
1882 multipart/byteranges responses.
1884 A range header might be forwarded by a 1.0 proxy that does not
1885 understand multipart/byteranges; in this case the server MUST
1886 delimit the message using methods defined in items 1,3 or 5 of
1889 5.By the server closing the connection. (Closing the connection
1890 cannot be used to indicate the end of a request body, since that
1891 would leave no possibility for the server to send back a response.)
1893 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1894 containing a message-body MUST include a valid Content-Length header
1895 field unless the server is known to be HTTP/1.1 compliant. If a
1896 request contains a message-body and a Content-Length is not given,
1897 the server SHOULD respond with 400 (bad request) if it cannot
1898 determine the length of the message, or with 411 (length required) if
1899 it wishes to insist on receiving a valid Content-Length.
1901 All HTTP/1.1 applications that receive entities MUST accept the
1902 "chunked" transfer-coding (section 3.6), thus allowing this mechanism
1903 to be used for messages when the message length cannot be determined
1906 Messages MUST NOT include both a Content-Length header field and a
1907 non-identity transfer-coding. If the message does include a non-
1908 identity transfer-coding, the Content-Length MUST be ignored.
1910 [[ Remove "non-identity" both times ]]
1912 When a Content-Length is given in a message where a message-body is
1913 allowed, its field value MUST exactly match the number of OCTETs in
1914 the message-body. HTTP/1.1 user agents MUST notify the user when an
1915 invalid length is received and detected.
1917 4.5 General Header Fields
1919 There are a few header fields which have general applicability for
1920 both request and response messages, but which do not apply to the
1921 entity being transferred. These header fields apply only to the
1925 Fielding, et al. Standards Track [Page 34]
1927 RFC 2616 HTTP/1.1 June 1999
1930 message being transmitted.
1932 general-header = Cache-Control ; Section 14.9
1933 | Connection ; Section 14.10
1934 | Date ; Section 14.18
1935 | Pragma ; Section 14.32
1936 | Trailer ; Section 14.40
1937 | Transfer-Encoding ; Section 14.41
1938 | Upgrade ; Section 14.42
1939 | Via ; Section 14.45
1940 | Warning ; Section 14.46
1942 General-header field names can be extended reliably only in
1943 combination with a change in the protocol version. However, new or
1944 experimental header fields may be given the semantics of general
1945 header fields if all parties in the communication recognize them to
1946 be general-header fields. Unrecognized header fields are treated as
1947 entity-header fields.
1951 A request message from a client to a server includes, within the
1952 first line of that message, the method to be applied to the resource,
1953 the identifier of the resource, and the protocol version in use.
1955 Request = Request-Line ; Section 5.1
1956 *(( general-header ; Section 4.5
1957 | request-header ; Section 5.3
1958 | entity-header ) CRLF) ; Section 7.1
1960 [ message-body ] ; Section 4.3
1964 The Request-Line begins with a method token, followed by the
1965 Request-URI and the protocol version, and ending with CRLF. The
1966 elements are separated by SP characters. No CR or LF is allowed
1967 except in the final CRLF sequence.
1969 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
1981 Fielding, et al. Standards Track [Page 35]
1983 RFC 2616 HTTP/1.1 June 1999
1988 The Method token indicates the method to be performed on the
1989 resource identified by the Request-URI. The method is case-sensitive.
1991 Method = "OPTIONS" ; Section 9.2
1992 | "GET" ; Section 9.3
1993 | "HEAD" ; Section 9.4
1994 | "POST" ; Section 9.5
1995 | "PUT" ; Section 9.6
1996 | "DELETE" ; Section 9.7
1997 | "TRACE" ; Section 9.8
1998 | "CONNECT" ; Section 9.9
2000 extension-method = token
2002 The list of methods allowed by a resource can be specified in an
2003 Allow header field (section 14.7). The return code of the response
2004 always notifies the client whether a method is currently allowed on a
2005 resource, since the set of allowed methods can change dynamically. An
2006 origin server SHOULD return the status code 405 (Method Not Allowed)
2007 if the method is known by the origin server but not allowed for the
2008 requested resource, and 501 (Not Implemented) if the method is
2009 unrecognized or not implemented by the origin server. The methods GET
2010 and HEAD MUST be supported by all general-purpose servers. All other
2011 methods are OPTIONAL; however, if the above methods are implemented,
2012 they MUST be implemented with the same semantics as those specified
2017 The Request-URI is a Uniform Resource Identifier (section 3.2) and
2018 identifies the resource upon which to apply the request.
2020 Request-URI = "*" | absoluteURI | abs_path | authority
2021 [[ Request-URI = "*" | absoluteURI | abs_path [ "?" query ] | authority ]]
2023 The four options for Request-URI are dependent on the nature of the
2024 request. The asterisk "*" means that the request does not apply to a
2025 particular resource, but to the server itself, and is only allowed
2026 when the method used does not necessarily apply to a resource. One
2031 The absoluteURI form is REQUIRED when the request is being made to a
2032 proxy. The proxy is requested to forward the request or service it
2033 from a valid cache, and return the response. Note that the proxy MAY
2034 forward the request on to another proxy or directly to the server
2038 Fielding, et al. Standards Track [Page 36]
2040 RFC 2616 HTTP/1.1 June 1999
2043 specified by the absoluteURI. In order to avoid request loops, a
2044 proxy MUST be able to recognize all of its server names, including
2045 any aliases, local variations, and the numeric IP address. An example
2046 Request-Line would be:
2048 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
2050 To allow for transition to absoluteURIs in all requests in future
2051 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
2052 form in requests, even though HTTP/1.1 clients will only generate
2053 them in requests to proxies.
2055 The authority form is only used by the CONNECT method (section 9.9).
2057 The most common form of Request-URI is that used to identify a
2058 resource on an origin server or gateway. In this case the absolute
2059 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
2060 the Request-URI, and the network location of the URI (authority) MUST
2061 be transmitted in a Host header field. For example, a client wishing
2062 to retrieve the resource above directly from the origin server would
2063 create a TCP connection to port 80 of the host "www.w3.org" and send
2066 GET /pub/WWW/TheProject.html HTTP/1.1
2069 followed by the remainder of the Request. Note that the absolute path
2070 cannot be empty; if none is present in the original URI, it MUST be
2071 given as "/" (the server root).
2073 The Request-URI is transmitted in the format specified in section
2074 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
2075 [42], the origin server MUST decode the Request-URI in order to
2076 properly interpret the request. Servers SHOULD respond to invalid
2077 Request-URIs with an appropriate status code.
2079 A transparent proxy MUST NOT rewrite the "abs_path" part of the
2080 received Request-URI when forwarding it to the next inbound server,
2081 except as noted above to replace a null abs_path with "/".
2083 Note: The "no rewrite" rule prevents the proxy from changing the
2084 meaning of the request when the origin server is improperly using
2085 a non-reserved URI character for a reserved purpose. Implementors
2086 should be aware that some pre-HTTP/1.1 proxies have been known to
2087 rewrite the Request-URI.
2094 Fielding, et al. Standards Track [Page 37]
2096 RFC 2616 HTTP/1.1 June 1999
2099 5.2 The Resource Identified by a Request
2101 The exact resource identified by an Internet request is determined by
2102 examining both the Request-URI and the Host header field.
2104 An origin server that does not allow resources to differ by the
2105 requested host MAY ignore the Host header field value when
2106 determining the resource identified by an HTTP/1.1 request. (But see
2107 section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
2109 An origin server that does differentiate resources based on the host
2110 requested (sometimes referred to as virtual hosts or vanity host
2111 names) MUST use the following rules for determining the requested
2112 resource on an HTTP/1.1 request:
2114 1. If Request-URI is an absoluteURI, the host is part of the
2115 Request-URI. Any Host header field value in the request MUST be
2118 2. If the Request-URI is not an absoluteURI, and the request includes
2119 a Host header field, the host is determined by the Host header
2122 3. If the host as determined by rule 1 or 2 is not a valid host on
2123 the server, the response MUST be a 400 (Bad Request) error message.
2125 Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2126 attempt to use heuristics (e.g., examination of the URI path for
2127 something unique to a particular host) in order to determine what
2128 exact resource is being requested.
2130 5.3 Request Header Fields
2132 The request-header fields allow the client to pass additional
2133 information about the request, and about the client itself, to the
2134 server. These fields act as request modifiers, with semantics
2135 equivalent to the parameters on a programming language method
2138 request-header = Accept ; Section 14.1
2139 | Accept-Charset ; Section 14.2
2140 | Accept-Encoding ; Section 14.3
2141 | Accept-Language ; Section 14.4
2142 | Authorization ; Section 14.8
2143 | Expect ; Section 14.20
2144 | From ; Section 14.22
2145 | Host ; Section 14.23
2146 | If-Match ; Section 14.24
2150 Fielding, et al. Standards Track [Page 38]
2152 RFC 2616 HTTP/1.1 June 1999
2155 | If-Modified-Since ; Section 14.25
2156 | If-None-Match ; Section 14.26
2157 | If-Range ; Section 14.27
2158 | If-Unmodified-Since ; Section 14.28
2159 | Max-Forwards ; Section 14.31
2160 | Proxy-Authorization ; Section 14.34
2161 | Range ; Section 14.35
2162 | Referer ; Section 14.36
2163 | TE ; Section 14.39
2164 | User-Agent ; Section 14.43
2166 Request-header field names can be extended reliably only in
2167 combination with a change in the protocol version. However, new or
2168 experimental header fields MAY be given the semantics of request-
2169 header fields if all parties in the communication recognize them to
2170 be request-header fields. Unrecognized header fields are treated as
2171 entity-header fields.
2175 After receiving and interpreting a request message, a server responds
2176 with an HTTP response message.
2178 Response = Status-Line ; Section 6.1
2179 *(( general-header ; Section 4.5
2180 | response-header ; Section 6.2
2181 | entity-header ) CRLF) ; Section 7.1
2183 [ message-body ] ; Section 7.2
2187 The first line of a Response message is the Status-Line, consisting
2188 of the protocol version followed by a numeric status code and its
2189 associated textual phrase, with each element separated by SP
2190 characters. No CR or LF is allowed except in the final CRLF sequence.
2192 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
2194 6.1.1 Status Code and Reason Phrase
2196 The Status-Code element is a 3-digit integer result code of the
2197 attempt to understand and satisfy the request. These codes are fully
2198 defined in section 10. The Reason-Phrase is intended to give a short
2199 textual description of the Status-Code. The Status-Code is intended
2200 for use by automata and the Reason-Phrase is intended for the human
2201 user. The client is not required to examine or display the Reason-
2206 Fielding, et al. Standards Track [Page 39]
2208 RFC 2616 HTTP/1.1 June 1999
2211 The first digit of the Status-Code defines the class of response. The
2212 last two digits do not have any categorization role. There are 5
2213 values for the first digit:
2215 - 1xx: Informational - Request received, continuing process
2217 - 2xx: Success - The action was successfully received,
2218 understood, and accepted
2220 - 3xx: Redirection - Further action must be taken in order to
2221 complete the request
2223 - 4xx: Client Error - The request contains bad syntax or cannot
2226 - 5xx: Server Error - The server failed to fulfill an apparently
2229 The individual values of the numeric status codes defined for
2230 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
2231 presented below. The reason phrases listed here are only
2232 recommendations -- they MAY be replaced by local equivalents without
2233 affecting the protocol.
2236 "100" ; Section 10.1.1: Continue
2237 | "101" ; Section 10.1.2: Switching Protocols
2238 | "200" ; Section 10.2.1: OK
2239 | "201" ; Section 10.2.2: Created
2240 | "202" ; Section 10.2.3: Accepted
2241 | "203" ; Section 10.2.4: Non-Authoritative Information
2242 | "204" ; Section 10.2.5: No Content
2243 | "205" ; Section 10.2.6: Reset Content
2244 | "206" ; Section 10.2.7: Partial Content
2245 | "300" ; Section 10.3.1: Multiple Choices
2246 | "301" ; Section 10.3.2: Moved Permanently
2247 | "302" ; Section 10.3.3: Found
2248 | "303" ; Section 10.3.4: See Other
2249 | "304" ; Section 10.3.5: Not Modified
2250 | "305" ; Section 10.3.6: Use Proxy
2251 | "307" ; Section 10.3.8: Temporary Redirect
2252 | "400" ; Section 10.4.1: Bad Request
2253 | "401" ; Section 10.4.2: Unauthorized
2254 | "402" ; Section 10.4.3: Payment Required
2255 | "403" ; Section 10.4.4: Forbidden
2256 | "404" ; Section 10.4.5: Not Found
2257 | "405" ; Section 10.4.6: Method Not Allowed
2258 | "406" ; Section 10.4.7: Not Acceptable
2262 Fielding, et al. Standards Track [Page 40]
2264 RFC 2616 HTTP/1.1 June 1999
2267 | "407" ; Section 10.4.8: Proxy Authentication Required
2268 | "408" ; Section 10.4.9: Request Time-out
2269 | "409" ; Section 10.4.10: Conflict
2270 | "410" ; Section 10.4.11: Gone
2271 | "411" ; Section 10.4.12: Length Required
2272 | "412" ; Section 10.4.13: Precondition Failed
2273 | "413" ; Section 10.4.14: Request Entity Too Large
2274 | "414" ; Section 10.4.15: Request-URI Too Large
2275 | "415" ; Section 10.4.16: Unsupported Media Type
2276 | "416" ; Section 10.4.17: Requested range not satisfiable
2277 | "417" ; Section 10.4.18: Expectation Failed
2278 | "500" ; Section 10.5.1: Internal Server Error
2279 | "501" ; Section 10.5.2: Not Implemented
2280 | "502" ; Section 10.5.3: Bad Gateway
2281 | "503" ; Section 10.5.4: Service Unavailable
2282 | "504" ; Section 10.5.5: Gateway Time-out
2283 | "505" ; Section 10.5.6: HTTP Version not supported
2286 extension-code = 3DIGIT
2287 Reason-Phrase = *<TEXT, excluding CR, LF>
2289 HTTP status codes are extensible. HTTP applications are not required
2290 to understand the meaning of all registered status codes, though such
2291 understanding is obviously desirable. However, applications MUST
2292 understand the class of any status code, as indicated by the first
2293 digit, and treat any unrecognized response as being equivalent to the
2294 x00 status code of that class, with the exception that an
2295 unrecognized response MUST NOT be cached. For example, if an
2296 unrecognized status code of 431 is received by the client, it can
2297 safely assume that there was something wrong with its request and
2298 treat the response as if it had received a 400 status code. In such
2299 cases, user agents SHOULD present to the user the entity returned
2300 with the response, since that entity is likely to include human-
2301 readable information which will explain the unusual status.
2303 6.2 Response Header Fields
2305 The response-header fields allow the server to pass additional
2306 information about the response which cannot be placed in the Status-
2307 Line. These header fields give information about the server and about
2308 further access to the resource identified by the Request-URI.
2310 response-header = Accept-Ranges ; Section 14.5
2311 | Age ; Section 14.6
2312 | ETag ; Section 14.19
2313 | Location ; Section 14.30
2314 | Proxy-Authenticate ; Section 14.33
2318 Fielding, et al. Standards Track [Page 41]
2320 RFC 2616 HTTP/1.1 June 1999
2323 | Retry-After ; Section 14.37
2324 | Server ; Section 14.38
2325 | Vary ; Section 14.44
2326 | WWW-Authenticate ; Section 14.47
2328 Response-header field names can be extended reliably only in
2329 combination with a change in the protocol version. However, new or
2330 experimental header fields MAY be given the semantics of response-
2331 header fields if all parties in the communication recognize them to
2332 be response-header fields. Unrecognized header fields are treated as
2333 entity-header fields.
2337 Request and Response messages MAY transfer an entity if not otherwise
2338 restricted by the request method or response status code. An entity
2339 consists of entity-header fields and an entity-body, although some
2340 responses will only include the entity-headers.
2342 In this section, both sender and recipient refer to either the client
2343 or the server, depending on who sends and who receives the entity.
2345 7.1 Entity Header Fields
2347 Entity-header fields define metainformation about the entity-body or,
2348 if no body is present, about the resource identified by the request.
2349 Some of this metainformation is OPTIONAL; some might be REQUIRED by
2350 portions of this specification.
2352 entity-header = Allow ; Section 14.7
2353 | Content-Encoding ; Section 14.11
2354 | Content-Language ; Section 14.12
2355 | Content-Length ; Section 14.13
2356 | Content-Location ; Section 14.14
2357 | Content-MD5 ; Section 14.15
2358 | Content-Range ; Section 14.16
2359 | Content-Type ; Section 14.17
2360 | Expires ; Section 14.21
2361 | Last-Modified ; Section 14.29
2364 extension-header = message-header
2366 The extension-header mechanism allows additional entity-header fields
2367 to be defined without changing the protocol, but these fields cannot
2368 be assumed to be recognizable by the recipient. Unrecognized header
2369 fields SHOULD be ignored by the recipient and MUST be forwarded by
2370 transparent proxies.
2374 Fielding, et al. Standards Track [Page 42]
2376 RFC 2616 HTTP/1.1 June 1999
2381 The entity-body (if any) sent with an HTTP request or response is in
2382 a format and encoding defined by the entity-header fields.
2384 entity-body = *OCTET
2386 An entity-body is only present in a message when a message-body is
2387 present, as described in section 4.3. The entity-body is obtained
2388 from the message-body by decoding any Transfer-Encoding that might
2389 have been applied to ensure safe and proper transfer of the message.
2393 When an entity-body is included with a message, the data type of that
2394 body is determined via the header fields Content-Type and Content-
2395 Encoding. These define a two-layer, ordered encoding model:
2397 entity-body := Content-Encoding( Content-Type( data ) )
2399 Content-Type specifies the media type of the underlying data.
2400 Content-Encoding may be used to indicate any additional content
2401 codings applied to the data, usually for the purpose of data
2402 compression, that are a property of the requested resource. There is
2403 no default encoding.
2405 Any HTTP/1.1 message containing an entity-body SHOULD include a
2406 Content-Type header field defining the media type of that body. If
2407 and only if the media type is not given by a Content-Type field, the
2408 recipient MAY attempt to guess the media type via inspection of its
2409 content and/or the name extension(s) of the URI used to identify the
2410 resource. If the media type remains unknown, the recipient SHOULD
2411 treat it as type "application/octet-stream".
2415 The entity-length of a message is the length of the message-body
2416 before any transfer-codings have been applied. Section 4.4 defines
2417 how the transfer-length of a message-body is determined.
2430 Fielding, et al. Standards Track [Page 43]
2432 RFC 2616 HTTP/1.1 June 1999
2437 8.1 Persistent Connections
2441 Prior to persistent connections, a separate TCP connection was
2442 established to fetch each URL, increasing the load on HTTP servers
2443 and causing congestion on the Internet. The use of inline images and
2444 other associated data often require a client to make multiple
2445 requests of the same server in a short amount of time. Analysis of
2446 these performance problems and results from a prototype
2447 implementation are available [26] [30]. Implementation experience and
2448 measurements of actual HTTP/1.1 (RFC 2068) implementations show good
2449 results [39]. Alternatives have also been explored, for example,
2452 Persistent HTTP connections have a number of advantages:
2454 - By opening and closing fewer TCP connections, CPU time is saved
2455 in routers and hosts (clients, servers, proxies, gateways,
2456 tunnels, or caches), and memory used for TCP protocol control
2457 blocks can be saved in hosts.
2459 - HTTP requests and responses can be pipelined on a connection.
2460 Pipelining allows a client to make multiple requests without
2461 waiting for each response, allowing a single TCP connection to
2462 be used much more efficiently, with much lower elapsed time.
2464 - Network congestion is reduced by reducing the number of packets
2465 caused by TCP opens, and by allowing TCP sufficient time to
2466 determine the congestion state of the network.
2468 - Latency on subsequent requests is reduced since there is no time
2469 spent in TCP's connection opening handshake.
2471 - HTTP can evolve more gracefully, since errors can be reported
2472 without the penalty of closing the TCP connection. Clients using
2473 future versions of HTTP might optimistically try a new feature,
2474 but if communicating with an older server, retry with old
2475 semantics after an error is reported.
2477 HTTP implementations SHOULD implement persistent connections.
2486 Fielding, et al. Standards Track [Page 44]
2488 RFC 2616 HTTP/1.1 June 1999
2491 8.1.2 Overall Operation
2493 A significant difference between HTTP/1.1 and earlier versions of
2494 HTTP is that persistent connections are the default behavior of any
2495 HTTP connection. That is, unless otherwise indicated, the client
2496 SHOULD assume that the server will maintain a persistent connection,
2497 even after error responses from the server.
2499 Persistent connections provide a mechanism by which a client and a
2500 server can signal the close of a TCP connection. This signaling takes
2501 place using the Connection header field (section 14.10). Once a close
2502 has been signaled, the client MUST NOT send any more requests on that
2507 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2508 maintain a persistent connection unless a Connection header including
2509 the connection-token "close" was sent in the request. If the server
2510 chooses to close the connection immediately after sending the
2511 response, it SHOULD send a Connection header including the
2512 connection-token close.
2514 An HTTP/1.1 client MAY expect a connection to remain open, but would
2515 decide to keep it open based on whether the response from a server
2516 contains a Connection header with the connection-token close. In case
2517 the client does not want to maintain a connection for more than that
2518 request, it SHOULD send a Connection header including the
2519 connection-token close.
2521 If either the client or the server sends the close token in the
2522 Connection header, that request becomes the last one for the
2525 Clients and servers SHOULD NOT assume that a persistent connection is
2526 maintained for HTTP versions less than 1.1 unless it is explicitly
2527 signaled. See section 19.6.2 for more information on backward
2528 compatibility with HTTP/1.0 clients.
2530 In order to remain persistent, all messages on the connection MUST
2531 have a self-defined message length (i.e., one not defined by closure
2532 of the connection), as described in section 4.4.
2542 Fielding, et al. Standards Track [Page 45]
2544 RFC 2616 HTTP/1.1 June 1999
2549 A client that supports persistent connections MAY "pipeline" its
2550 requests (i.e., send multiple requests without waiting for each
2551 response). A server MUST send its responses to those requests in the
2552 same order that the requests were received.
2554 Clients which assume persistent connections and pipeline immediately
2555 after connection establishment SHOULD be prepared to retry their
2556 connection if the first pipelined attempt fails. If a client does
2557 such a retry, it MUST NOT pipeline before it knows the connection is
2558 persistent. Clients MUST also be prepared to resend their requests if
2559 the server closes the connection before sending all of the
2560 corresponding responses.
2562 Clients SHOULD NOT pipeline requests using non-idempotent methods or
2563 non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
2564 premature termination of the transport connection could lead to
2565 indeterminate results. A client wishing to send a non-idempotent
2566 request SHOULD wait to send that request until it has received the
2567 response status for the previous request.
2571 It is especially important that proxies correctly implement the
2572 properties of the Connection header field as specified in section
2575 The proxy server MUST signal persistent connections separately with
2576 its clients and the origin servers (or other proxy servers) that it
2577 connects to. Each persistent connection applies to only one transport
2580 A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2581 with an HTTP/1.0 client (but see RFC 2068 [33] for information and
2582 discussion of the problems with the Keep-Alive header implemented by
2583 many HTTP/1.0 clients).
2585 8.1.4 Practical Considerations
2587 Servers will usually have some time-out value beyond which they will
2588 no longer maintain an inactive connection. Proxy servers might make
2589 this a higher value since it is likely that the client will be making
2590 more connections through the same server. The use of persistent
2591 connections places no requirements on the length (or existence) of
2592 this time-out for either the client or the server.
2598 Fielding, et al. Standards Track [Page 46]
2600 RFC 2616 HTTP/1.1 June 1999
2603 When a client or server wishes to time-out it SHOULD issue a graceful
2604 close on the transport connection. Clients and servers SHOULD both
2605 constantly watch for the other side of the transport close, and
2606 respond to it as appropriate. If a client or server does not detect
2607 the other side's close promptly it could cause unnecessary resource
2608 drain on the network.
2610 A client, server, or proxy MAY close the transport connection at any
2611 time. For example, a client might have started to send a new request
2612 at the same time that the server has decided to close the "idle"
2613 connection. From the server's point of view, the connection is being
2614 closed while it was idle, but from the client's point of view, a
2615 request is in progress.
2617 This means that clients, servers, and proxies MUST be able to recover
2618 from asynchronous close events. Client software SHOULD reopen the
2619 transport connection and retransmit the aborted sequence of requests
2620 without user interaction so long as the request sequence is
2621 idempotent (see section 9.1.2). Non-idempotent methods or sequences
2622 MUST NOT be automatically retried, although user agents MAY offer a
2623 human operator the choice of retrying the request(s). Confirmation by
2624 user-agent software with semantic understanding of the application
2625 MAY substitute for user confirmation. The automatic retry SHOULD NOT
2626 be repeated if the second sequence of requests fails.
2628 Servers SHOULD always respond to at least one request per connection,
2629 if at all possible. Servers SHOULD NOT close a connection in the
2630 middle of transmitting a response, unless a network or client failure
2633 Clients that use persistent connections SHOULD limit the number of
2634 simultaneous connections that they maintain to a given server. A
2635 single-user client SHOULD NOT maintain more than 2 connections with
2636 any server or proxy. A proxy SHOULD use up to 2*N connections to
2637 another server or proxy, where N is the number of simultaneously
2638 active users. These guidelines are intended to improve HTTP response
2639 times and avoid congestion.
2641 8.2 Message Transmission Requirements
2643 8.2.1 Persistent Connections and Flow Control
2645 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2646 flow control mechanisms to resolve temporary overloads, rather than
2647 terminating connections with the expectation that clients will retry.
2648 The latter technique can exacerbate network congestion.
2654 Fielding, et al. Standards Track [Page 47]
2656 RFC 2616 HTTP/1.1 June 1999
2659 8.2.2 Monitoring Connections for Error Status Messages
2661 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2662 the network connection for an error status while it is transmitting
2663 the request. If the client sees an error status, it SHOULD
2664 immediately cease transmitting the body. If the body is being sent
2665 using a "chunked" encoding (section 3.6), a zero length chunk and
2666 empty trailer MAY be used to prematurely mark the end of the message.
2667 If the body was preceded by a Content-Length header, the client MUST
2668 close the connection.
2670 8.2.3 Use of the 100 (Continue) Status
2672 The purpose of the 100 (Continue) status (see section 10.1.1) is to
2673 allow a client that is sending a request message with a request body
2674 to determine if the origin server is willing to accept the request
2675 (based on the request headers) before the client sends the request
2676 body. In some cases, it might either be inappropriate or highly
2677 inefficient for the client to send the body if the server will reject
2678 the message without looking at the body.
2680 Requirements for HTTP/1.1 clients:
2682 - If a client will wait for a 100 (Continue) response before
2683 sending the request body, it MUST send an Expect request-header
2684 field (section 14.20) with the "100-continue" expectation.
2686 - A client MUST NOT send an Expect request-header field (section
2687 14.20) with the "100-continue" expectation if it does not intend
2688 to send a request body.
2690 Because of the presence of older implementations, the protocol allows
2691 ambiguous situations in which a client may send "Expect: 100-
2692 continue" without receiving either a 417 (Expectation Failed) status
2693 or a 100 (Continue) status. Therefore, when a client sends this
2694 header field to an origin server (possibly via a proxy) from which it
2695 has never seen a 100 (Continue) status, the client SHOULD NOT wait
2696 for an indefinite period before sending the request body.
2698 Requirements for HTTP/1.1 origin servers:
2700 - Upon receiving a request which includes an Expect request-header
2701 field with the "100-continue" expectation, an origin server MUST
2702 either respond with 100 (Continue) status and continue to read
2703 from the input stream, or respond with a final status code. The
2704 origin server MUST NOT wait for the request body before sending
2705 the 100 (Continue) response. If it responds with a final status
2706 code, it MAY close the transport connection or it MAY continue
2710 Fielding, et al. Standards Track [Page 48]
2712 RFC 2616 HTTP/1.1 June 1999
2715 to read and discard the rest of the request. It MUST NOT
2716 perform the requested method if it returns a final status code.
2718 - An origin server SHOULD NOT send a 100 (Continue) response if
2719 the request message does not include an Expect request-header
2720 field with the "100-continue" expectation, and MUST NOT send a
2721 100 (Continue) response if such a request comes from an HTTP/1.0
2722 (or earlier) client. There is an exception to this rule: for
2723 compatibility with RFC 2068, a server MAY send a 100 (Continue)
2724 status in response to an HTTP/1.1 PUT or POST request that does
2725 not include an Expect request-header field with the "100-
2726 continue" expectation. This exception, the purpose of which is
2727 to minimize any client processing delays associated with an
2728 undeclared wait for 100 (Continue) status, applies only to
2729 HTTP/1.1 requests, and not to requests with any other HTTP-
2732 - An origin server MAY omit a 100 (Continue) response if it has
2733 already received some or all of the request body for the
2734 corresponding request.
2736 - An origin server that sends a 100 (Continue) response MUST
2737 ultimately send a final status code, once the request body is
2738 received and processed, unless it terminates the transport
2739 connection prematurely.
2741 - If an origin server receives a request that does not include an
2742 Expect request-header field with the "100-continue" expectation,
2743 the request includes a request body, and the server responds
2744 with a final status code before reading the entire request body
2745 from the transport connection, then the server SHOULD NOT close
2746 the transport connection until it has read the entire request,
2747 or until the client closes the connection. Otherwise, the client
2748 might not reliably receive the response message. However, this
2749 requirement is not be construed as preventing a server from
2750 defending itself against denial-of-service attacks, or from
2751 badly broken client implementations.
2753 Requirements for HTTP/1.1 proxies:
2755 - If a proxy receives a request that includes an Expect request-
2756 header field with the "100-continue" expectation, and the proxy
2757 either knows that the next-hop server complies with HTTP/1.1 or
2758 higher, or does not know the HTTP version of the next-hop
2759 server, it MUST forward the request, including the Expect header
2766 Fielding, et al. Standards Track [Page 49]
2768 RFC 2616 HTTP/1.1 June 1999
2771 - If the proxy knows that the version of the next-hop server is
2772 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2773 respond with a 417 (Expectation Failed) status.
2775 - Proxies SHOULD maintain a cache recording the HTTP version
2776 numbers received from recently-referenced next-hop servers.
2778 - A proxy MUST NOT forward a 100 (Continue) response if the
2779 request message was received from an HTTP/1.0 (or earlier)
2780 client and did not include an Expect request-header field with
2781 the "100-continue" expectation. This requirement overrides the
2782 general rule for forwarding of 1xx responses (see section 10.1).
2784 8.2.4 Client Behavior if Server Prematurely Closes Connection
2786 If an HTTP/1.1 client sends a request which includes a request body,
2787 but which does not include an Expect request-header field with the
2788 "100-continue" expectation, and if the client is not directly
2789 connected to an HTTP/1.1 origin server, and if the client sees the
2790 connection close before receiving any status from the server, the
2791 client SHOULD retry the request. If the client does retry this
2792 request, it MAY use the following "binary exponential backoff"
2793 algorithm to be assured of obtaining a reliable response:
2795 1. Initiate a new connection to the server
2797 2. Transmit the request-headers
2799 3. Initialize a variable R to the estimated round-trip time to the
2800 server (e.g., based on the time it took to establish the
2801 connection), or to a constant value of 5 seconds if the round-
2802 trip time is not available.
2804 4. Compute T = R * (2**N), where N is the number of previous
2805 retries of this request.
2807 5. Wait either for an error response from the server, or for T
2808 seconds (whichever comes first)
2810 6. If no error response is received, after T seconds transmit the
2811 body of the request.
2813 7. If client sees that the connection is closed prematurely,
2814 repeat from step 1 until the request is accepted, an error
2815 response is received, or the user becomes impatient and
2816 terminates the retry process.
2822 Fielding, et al. Standards Track [Page 50]
2824 RFC 2616 HTTP/1.1 June 1999
2827 If at any point an error status is received, the client
2829 - SHOULD NOT continue and
2831 - SHOULD close the connection if it has not completed sending the
2834 9 Method Definitions
2836 The set of common methods for HTTP/1.1 is defined below. Although
2837 this set can be expanded, additional methods cannot be assumed to
2838 share the same semantics for separately extended clients and servers.
2840 The Host request-header field (section 14.23) MUST accompany all
2843 9.1 Safe and Idempotent Methods
2847 Implementors should be aware that the software represents the user in
2848 their interactions over the Internet, and should be careful to allow
2849 the user to be aware of any actions they might take which may have an
2850 unexpected significance to themselves or others.
2852 In particular, the convention has been established that the GET and
2853 HEAD methods SHOULD NOT have the significance of taking an action
2854 other than retrieval. These methods ought to be considered "safe".
2855 This allows user agents to represent other methods, such as POST, PUT
2856 and DELETE, in a special way, so that the user is made aware of the
2857 fact that a possibly unsafe action is being requested.
2859 Naturally, it is not possible to ensure that the server does not
2860 generate side-effects as a result of performing a GET request; in
2861 fact, some dynamic resources consider that a feature. The important
2862 distinction here is that the user did not request the side-effects,
2863 so therefore cannot be held accountable for them.
2865 9.1.2 Idempotent Methods
2867 Methods can also have the property of "idempotence" in that (aside
2868 from error or expiration issues) the side-effects of N > 0 identical
2869 requests is the same as for a single request. The methods GET, HEAD,
2870 PUT and DELETE share this property. Also, the methods OPTIONS and
2871 TRACE SHOULD NOT have side effects, and so are inherently idempotent.
2878 Fielding, et al. Standards Track [Page 51]
2880 RFC 2616 HTTP/1.1 June 1999
2883 However, it is possible that a sequence of several requests is non-
2884 idempotent, even if all of the methods executed in that sequence are
2885 idempotent. (A sequence is idempotent if a single execution of the
2886 entire sequence always yields a result that is not changed by a
2887 reexecution of all, or part, of that sequence.) For example, a
2888 sequence is non-idempotent if its result depends on a value that is
2889 later modified in the same sequence.
2891 A sequence that never has side effects is idempotent, by definition
2892 (provided that no concurrent operations are being executed on the
2893 same set of resources).
2897 The OPTIONS method represents a request for information about the
2898 communication options available on the request/response chain
2899 identified by the Request-URI. This method allows the client to
2900 determine the options and/or requirements associated with a resource,
2901 or the capabilities of a server, without implying a resource action
2902 or initiating a resource retrieval.
2904 Responses to this method are not cacheable.
2906 If the OPTIONS request includes an entity-body (as indicated by the
2907 presence of Content-Length or Transfer-Encoding), then the media type
2908 MUST be indicated by a Content-Type field. Although this
2909 specification does not define any use for such a body, future
2910 extensions to HTTP might use the OPTIONS body to make more detailed
2911 queries on the server. A server that does not support such an
2912 extension MAY discard the request body.
2914 If the Request-URI is an asterisk ("*"), the OPTIONS request is
2915 intended to apply to the server in general rather than to a specific
2916 resource. Since a server's communication options typically depend on
2917 the resource, the "*" request is only useful as a "ping" or "no-op"
2918 type of method; it does nothing beyond allowing the client to test
2919 the capabilities of the server. For example, this can be used to test
2920 a proxy for HTTP/1.1 compliance (or lack thereof).
2922 If the Request-URI is not an asterisk, the OPTIONS request applies
2923 only to the options that are available when communicating with that
2926 A 200 response SHOULD include any header fields that indicate
2927 optional features implemented by the server and applicable to that
2928 resource (e.g., Allow), possibly including extensions not defined by
2929 this specification. The response body, if any, SHOULD also include
2930 information about the communication options. The format for such a
2934 Fielding, et al. Standards Track [Page 52]
2936 RFC 2616 HTTP/1.1 June 1999
2939 body is not defined by this specification, but might be defined by
2940 future extensions to HTTP. Content negotiation MAY be used to select
2941 the appropriate response format. If no response body is included, the
2942 response MUST include a Content-Length field with a field-value of
2945 The Max-Forwards request-header field MAY be used to target a
2946 specific proxy in the request chain. When a proxy receives an OPTIONS
2947 request on an absoluteURI for which request forwarding is permitted,
2948 the proxy MUST check for a Max-Forwards field. If the Max-Forwards
2949 field-value is zero ("0"), the proxy MUST NOT forward the message;
2950 instead, the proxy SHOULD respond with its own communication options.
2951 If the Max-Forwards field-value is an integer greater than zero, the
2952 proxy MUST decrement the field-value when it forwards the request. If
2953 no Max-Forwards field is present in the request, then the forwarded
2954 request MUST NOT include a Max-Forwards field.
2958 The GET method means retrieve whatever information (in the form of an
2959 entity) is identified by the Request-URI. If the Request-URI refers
2960 to a data-producing process, it is the produced data which shall be
2961 returned as the entity in the response and not the source text of the
2962 process, unless that text happens to be the output of the process.
2964 The semantics of the GET method change to a "conditional GET" if the
2965 request message includes an If-Modified-Since, If-Unmodified-Since,
2966 If-Match, If-None-Match, or If-Range header field. A conditional GET
2967 method requests that the entity be transferred only under the
2968 circumstances described by the conditional header field(s). The
2969 conditional GET method is intended to reduce unnecessary network
2970 usage by allowing cached entities to be refreshed without requiring
2971 multiple requests or transferring data already held by the client.
2973 The semantics of the GET method change to a "partial GET" if the
2974 request message includes a Range header field. A partial GET requests
2975 that only part of the entity be transferred, as described in section
2976 14.35. The partial GET method is intended to reduce unnecessary
2977 network usage by allowing partially-retrieved entities to be
2978 completed without transferring data already held by the client.
2980 The response to a GET request is cacheable if and only if it meets
2981 the requirements for HTTP caching described in section 13.
2983 See section 15.1.3 for security considerations when used for forms.
2990 Fielding, et al. Standards Track [Page 53]
2992 RFC 2616 HTTP/1.1 June 1999
2997 The HEAD method is identical to GET except that the server MUST NOT
2998 return a message-body in the response. The metainformation contained
2999 in the HTTP headers in response to a HEAD request SHOULD be identical
3000 to the information sent in response to a GET request. This method can
3001 be used for obtaining metainformation about the entity implied by the
3002 request without transferring the entity-body itself. This method is
3003 often used for testing hypertext links for validity, accessibility,
3004 and recent modification.
3006 The response to a HEAD request MAY be cacheable in the sense that the
3007 information contained in the response MAY be used to update a
3008 previously cached entity from that resource. If the new field values
3009 indicate that the cached entity differs from the current entity (as
3010 would be indicated by a change in Content-Length, Content-MD5, ETag
3011 or Last-Modified), then the cache MUST treat the cache entry as
3016 The POST method is used to request that the origin server accept the
3017 entity enclosed in the request as a new subordinate of the resource
3018 identified by the Request-URI in the Request-Line. POST is designed
3019 to allow a uniform method to cover the following functions:
3022 [[ The POST method is used to request that the origin server accept the ]]
3023 [[ entity enclosed in the request as data to be processed by the resource ]]
3024 [[ identified by the Request-URI in the Request-Line. POST is designed ]]
3025 [[ to allow a uniform method to cover the following functions: ]]
3027 - Annotation of existing resources;
3029 - Posting a message to a bulletin board, newsgroup, mailing list,
3030 or similar group of articles;
3032 - Providing a block of data, such as the result of submitting a
3033 form, to a data-handling process;
3035 - Extending a database through an append operation.
3037 The actual function performed by the POST method is determined by the
3038 server and is usually dependent on the Request-URI. The posted entity
3039 is subordinate to that URI in the same way that a file is subordinate
3040 to a directory containing it, a news article is subordinate to a
3041 newsgroup to which it is posted, or a record is subordinate to a
3044 [[ Remove second sentence ("The posted entity is subordinate") above ]]
3046 The action performed by the POST method might not result in a
3047 resource that can be identified by a URI. In this case, either 200
3048 (OK) or 204 (No Content) is the appropriate response status,
3049 depending on whether or not the response includes an entity that
3050 describes the result.
3054 Fielding, et al. Standards Track [Page 54]
3056 RFC 2616 HTTP/1.1 June 1999
3059 If a resource has been created on the origin server, the response
3060 SHOULD be 201 (Created) and contain an entity which describes the
3061 status of the request and refers to the new resource, and a Location
3062 header (see section 14.30).
3064 Responses to this method are not cacheable, unless the response
3065 includes appropriate Cache-Control or Expires header fields. However,
3066 the 303 (See Other) response can be used to direct the user agent to
3067 retrieve a cacheable resource.
3069 POST requests MUST obey the message transmission requirements set out
3072 See section 15.1.3 for security considerations.
3076 The PUT method requests that the enclosed entity be stored under the
3077 supplied Request-URI. If the Request-URI refers to an already
3078 existing resource, the enclosed entity SHOULD be considered as a
3079 modified version of the one residing on the origin server. If the
3080 Request-URI does not point to an existing resource, and that URI is
3081 capable of being defined as a new resource by the requesting user
3082 agent, the origin server can create the resource with that URI. If a
3083 new resource is created, the origin server MUST inform the user agent
3084 via the 201 (Created) response. If an existing resource is modified,
3085 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
3086 to indicate successful completion of the request. If the resource
3087 could not be created or modified with the Request-URI, an appropriate
3088 error response SHOULD be given that reflects the nature of the
3089 problem. The recipient of the entity MUST NOT ignore any Content-*
3090 (e.g. Content-Range) headers that it does not understand or implement
3091 and MUST return a 501 (Not Implemented) response in such cases.
3093 If the request passes through a cache and the Request-URI identifies
3094 one or more currently cached entities, those entries SHOULD be
3095 treated as stale. Responses to this method are not cacheable.
3097 The fundamental difference between the POST and PUT requests is
3098 reflected in the different meaning of the Request-URI. The URI in a
3099 POST request identifies the resource that will handle the enclosed
3100 entity. That resource might be a data-accepting process, a gateway to
3101 some other protocol, or a separate entity that accepts annotations.
3102 In contrast, the URI in a PUT request identifies the entity enclosed
3103 with the request -- the user agent knows what URI is intended and the
3104 server MUST NOT attempt to apply the request to some other resource.
3105 If the server desires that the request be applied to a different URI,
3110 Fielding, et al. Standards Track [Page 55]
3112 RFC 2616 HTTP/1.1 June 1999
3115 it MUST send a 301 (Moved Permanently) response; the user agent MAY
3116 then make its own decision regarding whether or not to redirect the
3119 A single resource MAY be identified by many different URIs. For
3120 example, an article might have a URI for identifying "the current
3121 version" which is separate from the URI identifying each particular
3122 version. In this case, a PUT request on a general URI might result in
3123 several other URIs being defined by the origin server.
3125 HTTP/1.1 does not define how a PUT method affects the state of an
3128 PUT requests MUST obey the message transmission requirements set out
3131 Unless otherwise specified for a particular entity-header, the
3132 entity-headers in the PUT request SHOULD be applied to the resource
3133 created or modified by the PUT.
3137 The DELETE method requests that the origin server delete the resource
3138 identified by the Request-URI. This method MAY be overridden by human
3139 intervention (or other means) on the origin server. The client cannot
3140 be guaranteed that the operation has been carried out, even if the
3141 status code returned from the origin server indicates that the action
3142 has been completed successfully. However, the server SHOULD NOT
3143 indicate success unless, at the time the response is given, it
3144 intends to delete the resource or move it to an inaccessible
3147 A successful response SHOULD be 200 (OK) if the response includes an
3148 entity describing the status, 202 (Accepted) if the action has not
3149 yet been enacted, or 204 (No Content) if the action has been enacted
3150 but the response does not include an entity.
3152 If the request passes through a cache and the Request-URI identifies
3153 one or more currently cached entities, those entries SHOULD be
3154 treated as stale. Responses to this method are not cacheable.
3158 The TRACE method is used to invoke a remote, application-layer loop-
3159 back of the request message. The final recipient of the request
3160 SHOULD reflect the message received back to the client as the
3161 entity-body of a 200 (OK) response. The final recipient is either the
3166 Fielding, et al. Standards Track [Page 56]
3168 RFC 2616 HTTP/1.1 June 1999
3171 origin server or the first proxy or gateway to receive a Max-Forwards
3172 value of zero (0) in the request (see section 14.31). A TRACE request
3173 MUST NOT include an entity.
3175 TRACE allows the client to see what is being received at the other
3176 end of the request chain and use that data for testing or diagnostic
3177 information. The value of the Via header field (section 14.45) is of
3178 particular interest, since it acts as a trace of the request chain.
3179 Use of the Max-Forwards header field allows the client to limit the
3180 length of the request chain, which is useful for testing a chain of
3181 proxies forwarding messages in an infinite loop.
3183 If the request is valid, the response SHOULD contain the entire
3184 request message in the entity-body, with a Content-Type of
3185 "message/http". Responses to this method MUST NOT be cached.
3189 This specification reserves the method name CONNECT for use with a
3190 proxy that can dynamically switch to being a tunnel (e.g. SSL
3193 10 Status Code Definitions
3195 Each Status-Code is described below, including a description of which
3196 method(s) it can follow and any metainformation required in the
3199 10.1 Informational 1xx
3201 This class of status code indicates a provisional response,
3202 consisting only of the Status-Line and optional headers, and is
3203 terminated by an empty line. There are no required headers for this
3204 class of status code. Since HTTP/1.0 did not define any 1xx status
3205 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
3206 except under experimental conditions.
3208 A client MUST be prepared to accept one or more 1xx status responses
3209 prior to a regular response, even if the client does not expect a 100
3210 (Continue) status message. Unexpected 1xx status responses MAY be
3211 ignored by a user agent.
3213 Proxies MUST forward 1xx responses, unless the connection between the
3214 proxy and its client has been closed, or unless the proxy itself
3215 requested the generation of the 1xx response. (For example, if a
3222 Fielding, et al. Standards Track [Page 57]
3224 RFC 2616 HTTP/1.1 June 1999
3227 proxy adds a "Expect: 100-continue" field when it forwards a request,
3228 then it need not forward the corresponding 100 (Continue)
3233 The client SHOULD continue with its request. This interim response is
3234 used to inform the client that the initial part of the request has
3235 been received and has not yet been rejected by the server. The client
3236 SHOULD continue by sending the remainder of the request or, if the
3237 request has already been completed, ignore this response. The server
3238 MUST send a final response after the request has been completed. See
3239 section 8.2.3 for detailed discussion of the use and handling of this
3242 10.1.2 101 Switching Protocols
3244 The server understands and is willing to comply with the client's
3245 request, via the Upgrade message header field (section 14.42), for a
3246 change in the application protocol being used on this connection. The
3247 server will switch protocols to those defined by the response's
3248 Upgrade header field immediately after the empty line which
3249 terminates the 101 response.
3251 The protocol SHOULD be switched only when it is advantageous to do
3252 so. For example, switching to a newer version of HTTP is advantageous
3253 over older versions, and switching to a real-time, synchronous
3254 protocol might be advantageous when delivering resources that use
3259 This class of status code indicates that the client's request was
3260 successfully received, understood, and accepted.
3264 The request has succeeded. The information returned with the response
3265 is dependent on the method used in the request, for example:
3267 GET an entity corresponding to the requested resource is sent in
3270 HEAD the entity-header fields corresponding to the requested
3271 resource are sent in the response without any message-body;
3273 POST an entity describing or containing the result of the action;
3278 Fielding, et al. Standards Track [Page 58]
3280 RFC 2616 HTTP/1.1 June 1999
3283 TRACE an entity containing the request message as received by the
3288 The request has been fulfilled and resulted in a new resource being
3289 created. The newly created resource can be referenced by the URI(s)
3290 returned in the entity of the response, with the most specific URI
3291 for the resource given by a Location header field. The response
3292 SHOULD include an entity containing a list of resource
3293 characteristics and location(s) from which the user or user agent can
3294 choose the one most appropriate. The entity format is specified by
3295 the media type given in the Content-Type header field. The origin
3296 server MUST create the resource before returning the 201 status code.
3297 If the action cannot be carried out immediately, the server SHOULD
3298 respond with 202 (Accepted) response instead.
3300 A 201 response MAY contain an ETag response header field indicating
3301 the current value of the entity tag for the requested variant just
3302 created, see section 14.19.
3306 The request has been accepted for processing, but the processing has
3307 not been completed. The request might or might not eventually be
3308 acted upon, as it might be disallowed when processing actually takes
3309 place. There is no facility for re-sending a status code from an
3310 asynchronous operation such as this.
3312 The 202 response is intentionally non-committal. Its purpose is to
3313 allow a server to accept a request for some other process (perhaps a
3314 batch-oriented process that is only run once per day) without
3315 requiring that the user agent's connection to the server persist
3316 until the process is completed. The entity returned with this
3317 response SHOULD include an indication of the request's current status
3318 and either a pointer to a status monitor or some estimate of when the
3319 user can expect the request to be fulfilled.
3321 10.2.4 203 Non-Authoritative Information
3323 The returned metainformation in the entity-header is not the
3324 definitive set as available from the origin server, but is gathered
3325 from a local or a third-party copy. The set presented MAY be a subset
3326 or superset of the original version. For example, including local
3327 annotation information about the resource might result in a superset
3328 of the metainformation known by the origin server. Use of this
3329 response code is not required and is only appropriate when the
3330 response would otherwise be 200 (OK).
3334 Fielding, et al. Standards Track [Page 59]
3336 RFC 2616 HTTP/1.1 June 1999
3339 10.2.5 204 No Content
3341 The server has fulfilled the request but does not need to return an
3342 entity-body, and might want to return updated metainformation. The
3343 response MAY include new or updated metainformation in the form of
3344 entity-headers, which if present SHOULD be associated with the
3347 If the client is a user agent, it SHOULD NOT change its document view
3348 from that which caused the request to be sent. This response is
3349 primarily intended to allow input for actions to take place without
3350 causing a change to the user agent's active document view, although
3351 any new or updated metainformation SHOULD be applied to the document
3352 currently in the user agent's active view.
3354 The 204 response MUST NOT include a message-body, and thus is always
3355 terminated by the first empty line after the header fields.
3357 10.2.6 205 Reset Content
3359 The server has fulfilled the request and the user agent SHOULD reset
3360 the document view which caused the request to be sent. This response
3361 is primarily intended to allow input for actions to take place via
3362 user input, followed by a clearing of the form in which the input is
3363 given so that the user can easily initiate another input action. The
3364 response MUST NOT include an entity.
3366 10.2.7 206 Partial Content
3368 The server has fulfilled the partial GET request for the resource.
3369 The request MUST have included a Range header field (section 14.35)
3370 indicating the desired range, and MAY have included an If-Range
3371 header field (section 14.27) to make the request conditional.
3373 The response MUST include the following header fields:
3375 - Either a Content-Range header field (section 14.16) indicating
3376 the range included with this response, or a multipart/byteranges
3377 Content-Type including Content-Range fields for each part. If a
3378 Content-Length header field is present in the response, its
3379 value MUST match the actual number of OCTETs transmitted in the
3384 - ETag and/or Content-Location, if the header would have been sent
3385 in a 200 response to the same request
3390 Fielding, et al. Standards Track [Page 60]
3392 RFC 2616 HTTP/1.1 June 1999
3395 - Expires, Cache-Control, and/or Vary, if the field-value might
3396 differ from that sent in any previous response for the same
3399 If the 206 response is the result of an If-Range request that used a
3400 strong cache validator (see section 13.3.3), the response SHOULD NOT
3401 include other entity-headers. If the response is the result of an
3402 If-Range request that used a weak validator, the response MUST NOT
3403 include other entity-headers; this prevents inconsistencies between
3404 cached entity-bodies and updated headers. Otherwise, the response
3405 MUST include all of the entity-headers that would have been returned
3406 with a 200 (OK) response to the same request.
3409 [[ If the 206 response is the result of an If-Range request, the ]]
3410 [[ response SHOULD NOT include other entity-headers. Otherwise, the ]]
3411 [[ response MUST include all of the entity-headers that would have ]]
3412 [[ been returned with a 200 (OK) response to the same request. ]]
3414 A cache MUST NOT combine a 206 response with other previously cached
3415 content if the ETag or Last-Modified headers do not match exactly,
3418 A cache that does not support the Range and Content-Range headers
3419 MUST NOT cache 206 (Partial) responses.
3421 10.3 Redirection 3xx
3423 This class of status code indicates that further action needs to be
3424 taken by the user agent in order to fulfill the request. The action
3425 required MAY be carried out by the user agent without interaction
3426 with the user if and only if the method used in the second request is
3427 GET or HEAD. A client SHOULD detect infinite redirection loops, since
3428 such loops generate network traffic for each redirection.
3430 Note: previous versions of this specification recommended a
3431 maximum of five redirections. Content developers should be aware
3432 that there might be clients that implement such a fixed
3435 10.3.1 300 Multiple Choices
3437 The requested resource corresponds to any one of a set of
3438 representations, each with its own specific location, and agent-
3439 driven negotiation information (section 12) is being provided so that
3440 the user (or user agent) can select a preferred representation and
3441 redirect its request to that location.
3443 Unless it was a HEAD request, the response SHOULD include an entity
3444 containing a list of resource characteristics and location(s) from
3445 which the user or user agent can choose the one most appropriate. The
3446 entity format is specified by the media type given in the Content-
3447 Type header field. Depending upon the format and the capabilities of
3452 Fielding, et al. Standards Track [Page 61]
3454 RFC 2616 HTTP/1.1 June 1999
3457 the user agent, selection of the most appropriate choice MAY be
3458 performed automatically. However, this specification does not define
3459 any standard for such automatic selection.
3461 If the server has a preferred choice of representation, it SHOULD
3462 include the specific URI for that representation in the Location
3463 field; user agents MAY use the Location field value for automatic
3464 redirection. This response is cacheable unless indicated otherwise.
3466 10.3.2 301 Moved Permanently
3468 The requested resource has been assigned a new permanent URI and any
3469 future references to this resource SHOULD use one of the returned
3470 URIs. Clients with link editing capabilities ought to automatically
3471 re-link references to the Request-URI to one or more of the new
3472 references returned by the server, where possible. This response is
3473 cacheable unless indicated otherwise.
3475 The new permanent URI SHOULD be given by the Location field in the
3476 response. Unless the request method was HEAD, the entity of the
3477 response SHOULD contain a short hypertext note with a hyperlink to
3480 If the 301 status code is received in response to a request other
3481 than GET or HEAD, the user agent MUST NOT automatically redirect the
3482 request unless it can be confirmed by the user, since this might
3483 change the conditions under which the request was issued.
3486 [[ If the 301 status code is received in response to a request method ]]
3487 [[ that is known to be "safe", as defined in section 9.1.1, then the ]]
3488 [[ request MAY be automatically redirected by the user agent without ]]
3489 [[ confirmation. Otherwise, the user agent MUST NOT automatically ]]
3490 [[ redirect the request unless it is confirmed by the user, since the ]]
3491 [[ new URI might change the conditions under which the request was ]]
3494 Note: When automatically redirecting a POST request after
3495 receiving a 301 status code, some existing HTTP/1.0 user agents
3496 will erroneously change it into a GET request.
3500 The requested resource resides temporarily under a different URI.
3501 Since the redirection might be altered on occasion, the client SHOULD
3502 continue to use the Request-URI for future requests. This response
3503 is only cacheable if indicated by a Cache-Control or Expires header
3506 The temporary URI SHOULD be given by the Location field in the
3507 response. Unless the request method was HEAD, the entity of the
3508 response SHOULD contain a short hypertext note with a hyperlink to
3517 Fielding, et al. Standards Track [Page 62]
3519 RFC 2616 HTTP/1.1 June 1999
3522 If the 302 status code is received in response to a request other
3523 than GET or HEAD, the user agent MUST NOT automatically redirect the
3524 request unless it can be confirmed by the user, since this might
3525 change the conditions under which the request was issued.
3527 [[ See errata to 10.3.3 ]]
3529 Note: RFC 1945 and RFC 2068 specify that the client is not allowed
3530 to change the method on the redirected request. However, most
3531 existing user agent implementations treat 302 as if it were a 303
3532 response, performing a GET on the Location field-value regardless
3533 of the original request method. The status codes 303 and 307 have
3534 been added for servers that wish to make unambiguously clear which
3535 kind of reaction is expected of the client.
3537 10.3.4 303 See Other
3539 The response to the request can be found under a different URI and
3540 SHOULD be retrieved using a GET method on that resource. This method
3541 exists primarily to allow the output of a POST-activated script to
3542 redirect the user agent to a selected resource. The new URI is not a
3543 substitute reference for the originally requested resource. The 303
3544 response MUST NOT be cached, but the response to the second
3545 (redirected) request might be cacheable.
3547 The different URI SHOULD be given by the Location field in the
3548 response. Unless the request method was HEAD, the entity of the
3549 response SHOULD contain a short hypertext note with a hyperlink to
3552 Note: Many pre-HTTP/1.1 user agents do not understand the 303
3553 status. When interoperability with such clients is a concern, the
3554 302 status code may be used instead, since most user agents react
3555 to a 302 response as described here for 303.
3557 10.3.5 304 Not Modified
3559 If the client has performed a conditional GET request and access is
3560 allowed, but the document has not been modified, the server SHOULD
3561 respond with this status code. The 304 response MUST NOT contain a
3562 message-body, and thus is always terminated by the first empty line
3563 after the header fields.
3565 The response MUST include the following header fields:
3567 - Date, unless its omission is required by section 14.18.1
3575 Fielding, et al. Standards Track [Page 63]
3577 RFC 2616 HTTP/1.1 June 1999
3580 If a clockless origin server obeys these rules, and proxies and
3581 clients add their own Date to any response received without one (as
3582 already specified by [RFC 2068], section 14.19), caches will operate
3585 - ETag and/or Content-Location, if the header would have been sent
3586 in a 200 response to the same request
3588 - Expires, Cache-Control, and/or Vary, if the field-value might
3589 differ from that sent in any previous response for the same
3592 If the conditional GET used a strong cache validator (see section
3593 13.3.3), the response SHOULD NOT include other entity-headers.
3594 Otherwise (i.e., the conditional GET used a weak validator), the
3595 response MUST NOT include other entity-headers; this prevents
3596 inconsistencies between cached entity-bodies and updated headers.
3598 If a 304 response indicates an entity not currently cached, then the
3599 cache MUST disregard the response and repeat the request without the
3602 If a cache uses a received 304 response to update a cache entry, the
3603 cache MUST update the entry to reflect any new field values given in
3606 10.3.6 305 Use Proxy
3608 The requested resource MUST be accessed through the proxy given by
3609 the Location field. The Location field gives the URI of the proxy.
3610 The recipient is expected to repeat this single request via the
3611 proxy. 305 responses MUST only be generated by origin servers.
3613 Note: RFC 2068 was not clear that 305 was intended to redirect a
3614 single request, and to be generated by origin servers only. Not
3615 observing these limitations has significant security consequences.
3619 The 306 status code was used in a previous version of the
3620 specification, is no longer used, and the code is reserved.
3631 Fielding, et al. Standards Track [Page 64]
3633 RFC 2616 HTTP/1.1 June 1999
3636 10.3.8 307 Temporary Redirect
3638 The requested resource resides temporarily under a different URI.
3639 Since the redirection MAY be altered on occasion, the client SHOULD
3640 continue to use the Request-URI for future requests. This response
3641 is only cacheable if indicated by a Cache-Control or Expires header
3644 The temporary URI SHOULD be given by the Location field in the
3645 response. Unless the request method was HEAD, the entity of the
3646 response SHOULD contain a short hypertext note with a hyperlink to
3647 the new URI(s) , since many pre-HTTP/1.1 user agents do not
3648 understand the 307 status. Therefore, the note SHOULD contain the
3649 information necessary for a user to repeat the original request on
3652 If the 307 status code is received in response to a request other
3653 than GET or HEAD, the user agent MUST NOT automatically redirect the
3654 request unless it can be confirmed by the user, since this might
3655 change the conditions under which the request was issued.
3657 [[ See errata to 10.3.3 ]]
3659 10.4 Client Error 4xx
3661 The 4xx class of status code is intended for cases in which the
3662 client seems to have erred. Except when responding to a HEAD request,
3663 the server SHOULD include an entity containing an explanation of the
3664 error situation, and whether it is a temporary or permanent
3665 condition. These status codes are applicable to any request method.
3666 User agents SHOULD display any included entity to the user.
3668 If the client is sending data, a server implementation using TCP
3669 SHOULD be careful to ensure that the client acknowledges receipt of
3670 the packet(s) containing the response, before the server closes the
3671 input connection. If the client continues sending data to the server
3672 after the close, the server's TCP stack will send a reset packet to
3673 the client, which may erase the client's unacknowledged input buffers
3674 before they can be read and interpreted by the HTTP application.
3676 10.4.1 400 Bad Request
3678 The request could not be understood by the server due to malformed
3679 syntax. The client SHOULD NOT repeat the request without
3689 Fielding, et al. Standards Track [Page 65]
3691 RFC 2616 HTTP/1.1 June 1999
3694 10.4.2 401 Unauthorized
3696 The request requires user authentication. The response MUST include a
3697 WWW-Authenticate header field (section 14.47) containing a challenge
3698 applicable to the requested resource. The client MAY repeat the
3699 request with a suitable Authorization header field (section 14.8). If
3700 the request already included Authorization credentials, then the 401
3701 response indicates that authorization has been refused for those
3702 credentials. If the 401 response contains the same challenge as the
3703 prior response, and the user agent has already attempted
3704 authentication at least once, then the user SHOULD be presented the
3705 entity that was given in the response, since that entity might
3706 include relevant diagnostic information. HTTP access authentication
3707 is explained in "HTTP Authentication: Basic and Digest Access
3708 Authentication" [43].
3710 10.4.3 402 Payment Required
3712 This code is reserved for future use.
3714 10.4.4 403 Forbidden
3716 The server understood the request, but is refusing to fulfill it.
3717 Authorization will not help and the request SHOULD NOT be repeated.
3718 If the request method was not HEAD and the server wishes to make
3719 public why the request has not been fulfilled, it SHOULD describe the
3720 reason for the refusal in the entity. If the server does not wish to
3721 make this information available to the client, the status code 404
3722 (Not Found) can be used instead.
3724 10.4.5 404 Not Found
3726 The server has not found anything matching the Request-URI. No
3727 indication is given of whether the condition is temporary or
3728 permanent. The 410 (Gone) status code SHOULD be used if the server
3729 knows, through some internally configurable mechanism, that an old
3730 resource is permanently unavailable and has no forwarding address.
3731 This status code is commonly used when the server does not wish to
3732 reveal exactly why the request has been refused, or when no other
3733 response is applicable.
3735 10.4.6 405 Method Not Allowed
3737 The method specified in the Request-Line is not allowed for the
3738 resource identified by the Request-URI. The response MUST include an
3739 Allow header containing a list of valid methods for the requested
3745 Fielding, et al. Standards Track [Page 66]
3747 RFC 2616 HTTP/1.1 June 1999
3750 10.4.7 406 Not Acceptable
3752 The resource identified by the request is only capable of generating
3753 response entities which have content characteristics not acceptable
3754 according to the accept headers sent in the request.
3756 Unless it was a HEAD request, the response SHOULD include an entity
3757 containing a list of available entity characteristics and location(s)
3758 from which the user or user agent can choose the one most
3759 appropriate. The entity format is specified by the media type given
3760 in the Content-Type header field. Depending upon the format and the
3761 capabilities of the user agent, selection of the most appropriate
3762 choice MAY be performed automatically. However, this specification
3763 does not define any standard for such automatic selection.
3765 Note: HTTP/1.1 servers are allowed to return responses which are
3766 not acceptable according to the accept headers sent in the
3767 request. In some cases, this may even be preferable to sending a
3768 406 response. User agents are encouraged to inspect the headers of
3769 an incoming response to determine if it is acceptable.
3771 If the response could be unacceptable, a user agent SHOULD
3772 temporarily stop receipt of more data and query the user for a
3773 decision on further actions.
3775 10.4.8 407 Proxy Authentication Required
3777 This code is similar to 401 (Unauthorized), but indicates that the
3778 client must first authenticate itself with the proxy. The proxy MUST
3779 return a Proxy-Authenticate header field (section 14.33) containing a
3780 challenge applicable to the proxy for the requested resource. The
3781 client MAY repeat the request with a suitable Proxy-Authorization
3782 header field (section 14.34). HTTP access authentication is explained
3783 in "HTTP Authentication: Basic and Digest Access Authentication"
3786 10.4.9 408 Request Timeout
3788 The client did not produce a request within the time that the server
3789 was prepared to wait. The client MAY repeat the request without
3790 modifications at any later time.
3792 10.4.10 409 Conflict
3794 The request could not be completed due to a conflict with the current
3795 state of the resource. This code is only allowed in situations where
3796 it is expected that the user might be able to resolve the conflict
3797 and resubmit the request. The response body SHOULD include enough
3801 Fielding, et al. Standards Track [Page 67]
3803 RFC 2616 HTTP/1.1 June 1999
3806 information for the user to recognize the source of the conflict.
3807 Ideally, the response entity would include enough information for the
3808 user or user agent to fix the problem; however, that might not be
3809 possible and is not required.
3811 Conflicts are most likely to occur in response to a PUT request. For
3812 example, if versioning were being used and the entity being PUT
3813 included changes to a resource which conflict with those made by an
3814 earlier (third-party) request, the server might use the 409 response
3815 to indicate that it can't complete the request. In this case, the
3816 response entity would likely contain a list of the differences
3817 between the two versions in a format defined by the response
3822 The requested resource is no longer available at the server and no
3823 forwarding address is known. This condition is expected to be
3824 considered permanent. Clients with link editing capabilities SHOULD
3825 delete references to the Request-URI after user approval. If the
3826 server does not know, or has no facility to determine, whether or not
3827 the condition is permanent, the status code 404 (Not Found) SHOULD be
3828 used instead. This response is cacheable unless indicated otherwise.
3830 The 410 response is primarily intended to assist the task of web
3831 maintenance by notifying the recipient that the resource is
3832 intentionally unavailable and that the server owners desire that
3833 remote links to that resource be removed. Such an event is common for
3834 limited-time, promotional services and for resources belonging to
3835 individuals no longer working at the server's site. It is not
3836 necessary to mark all permanently unavailable resources as "gone" or
3837 to keep the mark for any length of time -- that is left to the
3838 discretion of the server owner.
3840 10.4.12 411 Length Required
3842 The server refuses to accept the request without a defined Content-
3843 Length. The client MAY repeat the request if it adds a valid
3844 Content-Length header field containing the length of the message-body
3845 in the request message.
3847 10.4.13 412 Precondition Failed
3849 The precondition given in one or more of the request-header fields
3850 evaluated to false when it was tested on the server. This response
3851 code allows the client to place preconditions on the current resource
3852 metainformation (header field data) and thus prevent the requested
3853 method from being applied to a resource other than the one intended.
3857 Fielding, et al. Standards Track [Page 68]
3859 RFC 2616 HTTP/1.1 June 1999
3862 10.4.14 413 Request Entity Too Large
3864 The server is refusing to process a request because the request
3865 entity is larger than the server is willing or able to process. The
3866 server MAY close the connection to prevent the client from continuing
3869 If the condition is temporary, the server SHOULD include a Retry-
3870 After header field to indicate that it is temporary and after what
3871 time the client MAY try again.
3873 10.4.15 414 Request-URI Too Long
3875 The server is refusing to service the request because the Request-URI
3876 is longer than the server is willing to interpret. This rare
3877 condition is only likely to occur when a client has improperly
3878 converted a POST request to a GET request with long query
3879 information, when the client has descended into a URI "black hole" of
3880 redirection (e.g., a redirected URI prefix that points to a suffix of
3881 itself), or when the server is under attack by a client attempting to
3882 exploit security holes present in some servers using fixed-length
3883 buffers for reading or manipulating the Request-URI.
3885 10.4.16 415 Unsupported Media Type
3887 The server is refusing to service the request because the entity of
3888 the request is in a format not supported by the requested resource
3889 for the requested method.
3891 10.4.17 416 Requested Range Not Satisfiable
3893 A server SHOULD return a response with this status code if a request
3894 included a Range request-header field (section 14.35), and none of
3895 the range-specifier values in this field overlap the current extent
3896 of the selected resource, and the request did not include an If-Range
3897 request-header field. (For byte-ranges, this means that the first-
3898 byte-pos of all of the byte-range-spec values were greater than the
3899 current length of the selected resource.)
3901 When this status code is returned for a byte-range request, the
3902 response SHOULD include a Content-Range entity-header field
3903 specifying the current length of the selected resource (see section
3904 14.16). This response MUST NOT use the multipart/byteranges content-
3913 Fielding, et al. Standards Track [Page 69]
3915 RFC 2616 HTTP/1.1 June 1999
3918 10.4.18 417 Expectation Failed
3920 The expectation given in an Expect request-header field (see section
3921 14.20) could not be met by this server, or, if the server is a proxy,
3922 the server has unambiguous evidence that the request could not be met
3923 by the next-hop server.
3925 10.5 Server Error 5xx
3927 Response status codes beginning with the digit "5" indicate cases in
3928 which the server is aware that it has erred or is incapable of
3929 performing the request. Except when responding to a HEAD request, the
3930 server SHOULD include an entity containing an explanation of the
3931 error situation, and whether it is a temporary or permanent
3932 condition. User agents SHOULD display any included entity to the
3933 user. These response codes are applicable to any request method.
3935 10.5.1 500 Internal Server Error
3937 The server encountered an unexpected condition which prevented it
3938 from fulfilling the request.
3940 10.5.2 501 Not Implemented
3942 The server does not support the functionality required to fulfill the
3943 request. This is the appropriate response when the server does not
3944 recognize the request method and is not capable of supporting it for
3947 10.5.3 502 Bad Gateway
3949 The server, while acting as a gateway or proxy, received an invalid
3950 response from the upstream server it accessed in attempting to
3951 fulfill the request.
3953 10.5.4 503 Service Unavailable
3955 The server is currently unable to handle the request due to a
3956 temporary overloading or maintenance of the server. The implication
3957 is that this is a temporary condition which will be alleviated after
3958 some delay. If known, the length of the delay MAY be indicated in a
3959 Retry-After header. If no Retry-After is given, the client SHOULD
3960 handle the response as it would for a 500 response.
3962 Note: The existence of the 503 status code does not imply that a
3963 server must use it when becoming overloaded. Some servers may wish
3964 to simply refuse the connection.
3969 Fielding, et al. Standards Track [Page 70]
3971 RFC 2616 HTTP/1.1 June 1999
3974 10.5.5 504 Gateway Timeout
3976 The server, while acting as a gateway or proxy, did not receive a
3977 timely response from the upstream server specified by the URI (e.g.
3978 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
3979 to access in attempting to complete the request.
3981 Note: Note to implementors: some deployed proxies are known to
3982 return 400 or 500 when DNS lookups time out.
3984 10.5.6 505 HTTP Version Not Supported
3986 The server does not support, or refuses to support, the HTTP protocol
3987 version that was used in the request message. The server is
3988 indicating that it is unable or unwilling to complete the request
3989 using the same major version as the client, as described in section
3990 3.1, other than with this error message. The response SHOULD contain
3991 an entity describing why that version is not supported and what other
3992 protocols are supported by that server.
3994 11 Access Authentication
3996 HTTP provides several OPTIONAL challenge-response authentication
3997 mechanisms which can be used by a server to challenge a client
3998 request and by a client to provide authentication information. The
3999 general framework for access authentication, and the specification of
4000 "basic" and "digest" authentication, are specified in "HTTP
4001 Authentication: Basic and Digest Access Authentication" [43]. This
4002 specification adopts the definitions of "challenge" and "credentials"
4003 from that specification.
4005 12 Content Negotiation
4007 Most HTTP responses include an entity which contains information for
4008 interpretation by a human user. Naturally, it is desirable to supply
4009 the user with the "best available" entity corresponding to the
4010 request. Unfortunately for servers and caches, not all users have the
4011 same preferences for what is "best," and not all user agents are
4012 equally capable of rendering all entity types. For that reason, HTTP
4013 has provisions for several mechanisms for "content negotiation" --
4014 the process of selecting the best representation for a given response
4015 when there are multiple representations available.
4017 Note: This is not called "format negotiation" because the
4018 alternate representations may be of the same media type, but use
4019 different capabilities of that type, be in different languages,
4025 Fielding, et al. Standards Track [Page 71]
4027 RFC 2616 HTTP/1.1 June 1999
4030 Any response containing an entity-body MAY be subject to negotiation,
4031 including error responses.
4033 There are two kinds of content negotiation which are possible in
4034 HTTP: server-driven and agent-driven negotiation. These two kinds of
4035 negotiation are orthogonal and thus may be used separately or in
4036 combination. One method of combination, referred to as transparent
4037 negotiation, occurs when a cache uses the agent-driven negotiation
4038 information provided by the origin server in order to provide
4039 server-driven negotiation for subsequent requests.
4041 12.1 Server-driven Negotiation
4043 If the selection of the best representation for a response is made by
4044 an algorithm located at the server, it is called server-driven
4045 negotiation. Selection is based on the available representations of
4046 the response (the dimensions over which it can vary; e.g. language,
4047 content-coding, etc.) and the contents of particular header fields in
4048 the request message or on other information pertaining to the request
4049 (such as the network address of the client).
4051 Server-driven negotiation is advantageous when the algorithm for
4052 selecting from among the available representations is difficult to
4053 describe to the user agent, or when the server desires to send its
4054 "best guess" to the client along with the first response (hoping to
4055 avoid the round-trip delay of a subsequent request if the "best
4056 guess" is good enough for the user). In order to improve the server's
4057 guess, the user agent MAY include request header fields (Accept,
4058 Accept-Language, Accept-Encoding, etc.) which describe its
4059 preferences for such a response.
4061 Server-driven negotiation has disadvantages:
4063 1. It is impossible for the server to accurately determine what
4064 might be "best" for any given user, since that would require
4065 complete knowledge of both the capabilities of the user agent
4066 and the intended use for the response (e.g., does the user want
4067 to view it on screen or print it on paper?).
4069 2. Having the user agent describe its capabilities in every
4070 request can be both very inefficient (given that only a small
4071 percentage of responses have multiple representations) and a
4072 potential violation of the user's privacy.
4074 3. It complicates the implementation of an origin server and the
4075 algorithms for generating responses to a request.
4081 Fielding, et al. Standards Track [Page 72]
4083 RFC 2616 HTTP/1.1 June 1999
4086 4. It may limit a public cache's ability to use the same response
4087 for multiple user's requests.
4089 HTTP/1.1 includes the following request-header fields for enabling
4090 server-driven negotiation through description of user agent
4091 capabilities and user preferences: Accept (section 14.1), Accept-
4092 Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
4093 Language (section 14.4), and User-Agent (section 14.43). However, an
4094 origin server is not limited to these dimensions and MAY vary the
4095 response based on any aspect of the request, including information
4096 outside the request-header fields or within extension header fields
4097 not defined by this specification.
4099 The Vary header field can be used to express the parameters the
4100 server uses to select a representation that is subject to server-
4101 driven negotiation. See section 13.6 for use of the Vary header field
4102 by caches and section 14.44 for use of the Vary header field by
4105 12.2 Agent-driven Negotiation
4107 With agent-driven negotiation, selection of the best representation
4108 for a response is performed by the user agent after receiving an
4109 initial response from the origin server. Selection is based on a list
4110 of the available representations of the response included within the
4111 header fields or entity-body of the initial response, with each
4112 representation identified by its own URI. Selection from among the
4113 representations may be performed automatically (if the user agent is
4114 capable of doing so) or manually by the user selecting from a
4115 generated (possibly hypertext) menu.
4117 Agent-driven negotiation is advantageous when the response would vary
4118 over commonly-used dimensions (such as type, language, or encoding),
4119 when the origin server is unable to determine a user agent's
4120 capabilities from examining the request, and generally when public
4121 caches are used to distribute server load and reduce network usage.
4123 Agent-driven negotiation suffers from the disadvantage of needing a
4124 second request to obtain the best alternate representation. This
4125 second request is only efficient when caching is used. In addition,
4126 this specification does not define any mechanism for supporting
4127 automatic selection, though it also does not prevent any such
4128 mechanism from being developed as an extension and used within
4137 Fielding, et al. Standards Track [Page 73]
4139 RFC 2616 HTTP/1.1 June 1999
4142 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
4143 status codes for enabling agent-driven negotiation when the server is
4144 unwilling or unable to provide a varying response using server-driven
4147 12.3 Transparent Negotiation
4149 Transparent negotiation is a combination of both server-driven and
4150 agent-driven negotiation. When a cache is supplied with a form of the
4151 list of available representations of the response (as in agent-driven
4152 negotiation) and the dimensions of variance are completely understood
4153 by the cache, then the cache becomes capable of performing server-
4154 driven negotiation on behalf of the origin server for subsequent
4155 requests on that resource.
4157 Transparent negotiation has the advantage of distributing the
4158 negotiation work that would otherwise be required of the origin
4159 server and also removing the second request delay of agent-driven
4160 negotiation when the cache is able to correctly guess the right
4163 This specification does not define any mechanism for transparent
4164 negotiation, though it also does not prevent any such mechanism from
4165 being developed as an extension that could be used within HTTP/1.1.
4169 HTTP is typically used for distributed information systems, where
4170 performance can be improved by the use of response caches. The
4171 HTTP/1.1 protocol includes a number of elements intended to make
4172 caching work as well as possible. Because these elements are
4173 inextricable from other aspects of the protocol, and because they
4174 interact with each other, it is useful to describe the basic caching
4175 design of HTTP separately from the detailed descriptions of methods,
4176 headers, response codes, etc.
4178 Caching would be useless if it did not significantly improve
4179 performance. The goal of caching in HTTP/1.1 is to eliminate the need
4180 to send requests in many cases, and to eliminate the need to send
4181 full responses in many other cases. The former reduces the number of
4182 network round-trips required for many operations; we use an
4183 "expiration" mechanism for this purpose (see section 13.2). The
4184 latter reduces network bandwidth requirements; we use a "validation"
4185 mechanism for this purpose (see section 13.3).
4187 Requirements for performance, availability, and disconnected
4188 operation require us to be able to relax the goal of semantic
4189 transparency. The HTTP/1.1 protocol allows origin servers, caches,
4193 Fielding, et al. Standards Track [Page 74]
4195 RFC 2616 HTTP/1.1 June 1999
4198 and clients to explicitly reduce transparency when necessary.
4199 However, because non-transparent operation may confuse non-expert
4200 users, and might be incompatible with certain server applications
4201 (such as those for ordering merchandise), the protocol requires that
4202 transparency be relaxed
4204 - only by an explicit protocol-level request when relaxed by
4205 client or origin server
4207 - only with an explicit warning to the end user when relaxed by
4210 Therefore, the HTTP/1.1 protocol provides these important elements:
4212 1. Protocol features that provide full semantic transparency when
4213 this is required by all parties.
4215 2. Protocol features that allow an origin server or user agent to
4216 explicitly request and control non-transparent operation.
4218 3. Protocol features that allow a cache to attach warnings to
4219 responses that do not preserve the requested approximation of
4220 semantic transparency.
4222 A basic principle is that it must be possible for the clients to
4223 detect any potential relaxation of semantic transparency.
4225 Note: The server, cache, or client implementor might be faced with
4226 design decisions not explicitly discussed in this specification.
4227 If a decision might affect semantic transparency, the implementor
4228 ought to err on the side of maintaining transparency unless a
4229 careful and complete analysis shows significant benefits in
4230 breaking transparency.
4232 13.1.1 Cache Correctness
4234 A correct cache MUST respond to a request with the most up-to-date
4235 response held by the cache that is appropriate to the request (see
4236 sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
4239 1. It has been checked for equivalence with what the origin server
4240 would have returned by revalidating the response with the
4241 origin server (section 13.3);
4249 Fielding, et al. Standards Track [Page 75]
4251 RFC 2616 HTTP/1.1 June 1999
4254 2. It is "fresh enough" (see section 13.2). In the default case,
4255 this means it meets the least restrictive freshness requirement
4256 of the client, origin server, and cache (see section 14.9); if
4257 the origin server so specifies, it is the freshness requirement
4258 of the origin server alone.
4260 If a stored response is not "fresh enough" by the most
4261 restrictive freshness requirement of both the client and the
4262 origin server, in carefully considered circumstances the cache
4263 MAY still return the response with the appropriate Warning
4264 header (see section 13.1.5 and 14.46), unless such a response
4265 is prohibited (e.g., by a "no-store" cache-directive, or by a
4266 "no-cache" cache-request-directive; see section 14.9).
4268 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
4269 or error (4xx or 5xx) response message.
4271 If the cache can not communicate with the origin server, then a
4272 correct cache SHOULD respond as above if the response can be
4273 correctly served from the cache; if not it MUST return an error or
4274 warning indicating that there was a communication failure.
4276 If a cache receives a response (either an entire response, or a 304
4277 (Not Modified) response) that it would normally forward to the
4278 requesting client, and the received response is no longer fresh, the
4279 cache SHOULD forward it to the requesting client without adding a new
4280 Warning (but without removing any existing Warning headers). A cache
4281 SHOULD NOT attempt to revalidate a response simply because that
4282 response became stale in transit; this might lead to an infinite
4283 loop. A user agent that receives a stale response without a Warning
4284 MAY display a warning indication to the user.
4288 Whenever a cache returns a response that is neither first-hand nor
4289 "fresh enough" (in the sense of condition 2 in section 13.1.1), it
4290 MUST attach a warning to that effect, using a Warning general-header.
4291 The Warning header and the currently defined warnings are described
4292 in section 14.46. The warning allows clients to take appropriate
4295 Warnings MAY be used for other purposes, both cache-related and
4296 otherwise. The use of a warning, rather than an error status code,
4297 distinguish these responses from true failures.
4299 Warnings are assigned three digit warn-codes. The first digit
4300 indicates whether the Warning MUST or MUST NOT be deleted from a
4301 stored cache entry after a successful revalidation:
4305 Fielding, et al. Standards Track [Page 76]
4307 RFC 2616 HTTP/1.1 June 1999
4310 1xx Warnings that describe the freshness or revalidation status of
4311 the response, and so MUST be deleted after a successful
4312 revalidation. 1XX warn-codes MAY be generated by a cache only when
4313 validating a cached entry. It MUST NOT be generated by clients.
4315 2xx Warnings that describe some aspect of the entity body or entity
4316 headers that is not rectified by a revalidation (for example, a
4317 lossy compression of the entity bodies) and which MUST NOT be
4318 deleted after a successful revalidation.
4320 See section 14.46 for the definitions of the codes themselves.
4322 HTTP/1.0 caches will cache all Warnings in responses, without
4323 deleting the ones in the first category. Warnings in responses that
4324 are passed to HTTP/1.0 caches carry an extra warning-date field,
4325 which prevents a future HTTP/1.1 recipient from believing an
4326 erroneously cached Warning.
4328 Warnings also carry a warning text. The text MAY be in any
4329 appropriate natural language (perhaps based on the client's Accept
4330 headers), and include an OPTIONAL indication of what character set is
4333 Multiple warnings MAY be attached to a response (either by the origin
4334 server or by a cache), including multiple warnings with the same code
4335 number. For example, a server might provide the same warning with
4336 texts in both English and Basque.
4338 When multiple warnings are attached to a response, it might not be
4339 practical or reasonable to display all of them to the user. This
4340 version of HTTP does not specify strict priority rules for deciding
4341 which warnings to display and in what order, but does suggest some
4344 13.1.3 Cache-control Mechanisms
4346 The basic cache mechanisms in HTTP/1.1 (server-specified expiration
4347 times and validators) are implicit directives to caches. In some
4348 cases, a server or client might need to provide explicit directives
4349 to the HTTP caches. We use the Cache-Control header for this purpose.
4351 The Cache-Control header allows a client or server to transmit a
4352 variety of directives in either requests or responses. These
4353 directives typically override the default caching algorithms. As a
4354 general rule, if there is any apparent conflict between header
4355 values, the most restrictive interpretation is applied (that is, the
4356 one that is most likely to preserve semantic transparency). However,
4361 Fielding, et al. Standards Track [Page 77]
4363 RFC 2616 HTTP/1.1 June 1999
4366 in some cases, cache-control directives are explicitly specified as
4367 weakening the approximation of semantic transparency (for example,
4368 "max-stale" or "public").
4370 The cache-control directives are described in detail in section 14.9.
4372 13.1.4 Explicit User Agent Warnings
4374 Many user agents make it possible for users to override the basic
4375 caching mechanisms. For example, the user agent might allow the user
4376 to specify that cached entities (even explicitly stale ones) are
4377 never validated. Or the user agent might habitually add "Cache-
4378 Control: max-stale=3600" to every request. The user agent SHOULD NOT
4379 default to either non-transparent behavior, or behavior that results
4380 in abnormally ineffective caching, but MAY be explicitly configured
4381 to do so by an explicit action of the user.
4383 If the user has overridden the basic caching mechanisms, the user
4384 agent SHOULD explicitly indicate to the user whenever this results in
4385 the display of information that might not meet the server's
4386 transparency requirements (in particular, if the displayed entity is
4387 known to be stale). Since the protocol normally allows the user agent
4388 to determine if responses are stale or not, this indication need only
4389 be displayed when this actually happens. The indication need not be a
4390 dialog box; it could be an icon (for example, a picture of a rotting
4391 fish) or some other indicator.
4393 If the user has overridden the caching mechanisms in a way that would
4394 abnormally reduce the effectiveness of caches, the user agent SHOULD
4395 continually indicate this state to the user (for example, by a
4396 display of a picture of currency in flames) so that the user does not
4397 inadvertently consume excess resources or suffer from excessive
4400 13.1.5 Exceptions to the Rules and Warnings
4402 In some cases, the operator of a cache MAY choose to configure it to
4403 return stale responses even when not requested by clients. This
4404 decision ought not be made lightly, but may be necessary for reasons
4405 of availability or performance, especially when the cache is poorly
4406 connected to the origin server. Whenever a cache returns a stale
4407 response, it MUST mark it as such (using a Warning header) enabling
4408 the client software to alert the user that there might be a potential
4417 Fielding, et al. Standards Track [Page 78]
4419 RFC 2616 HTTP/1.1 June 1999
4422 It also allows the user agent to take steps to obtain a first-hand or
4423 fresh response. For this reason, a cache SHOULD NOT return a stale
4424 response if the client explicitly requests a first-hand or fresh one,
4425 unless it is impossible to comply for technical or policy reasons.
4427 13.1.6 Client-controlled Behavior
4429 While the origin server (and to a lesser extent, intermediate caches,
4430 by their contribution to the age of a response) are the primary
4431 source of expiration information, in some cases the client might need
4432 to control a cache's decision about whether to return a cached
4433 response without validating it. Clients do this using several
4434 directives of the Cache-Control header.
4436 A client's request MAY specify the maximum age it is willing to
4437 accept of an unvalidated response; specifying a value of zero forces
4438 the cache(s) to revalidate all responses. A client MAY also specify
4439 the minimum time remaining before a response expires. Both of these
4440 options increase constraints on the behavior of caches, and so cannot
4441 further relax the cache's approximation of semantic transparency.
4443 A client MAY also specify that it will accept stale responses, up to
4444 some maximum amount of staleness. This loosens the constraints on the
4445 caches, and so might violate the origin server's specified
4446 constraints on semantic transparency, but might be necessary to
4447 support disconnected operation, or high availability in the face of
4450 13.2 Expiration Model
4452 13.2.1 Server-Specified Expiration
4454 HTTP caching works best when caches can entirely avoid making
4455 requests to the origin server. The primary mechanism for avoiding
4456 requests is for an origin server to provide an explicit expiration
4457 time in the future, indicating that a response MAY be used to satisfy
4458 subsequent requests. In other words, a cache can return a fresh
4459 response without first contacting the server.
4461 Our expectation is that servers will assign future explicit
4462 expiration times to responses in the belief that the entity is not
4463 likely to change, in a semantically significant way, before the
4464 expiration time is reached. This normally preserves semantic
4465 transparency, as long as the server's expiration times are carefully
4473 Fielding, et al. Standards Track [Page 79]
4475 RFC 2616 HTTP/1.1 June 1999
4478 The expiration mechanism applies only to responses taken from a cache
4479 and not to first-hand responses forwarded immediately to the
4482 If an origin server wishes to force a semantically transparent cache
4483 to validate every request, it MAY assign an explicit expiration time
4484 in the past. This means that the response is always stale, and so the
4485 cache SHOULD validate it before using it for subsequent requests. See
4486 section 14.9.4 for a more restrictive way to force revalidation.
4488 If an origin server wishes to force any HTTP/1.1 cache, no matter how
4489 it is configured, to validate every request, it SHOULD use the "must-
4490 revalidate" cache-control directive (see section 14.9).
4492 Servers specify explicit expiration times using either the Expires
4493 header, or the max-age directive of the Cache-Control header.
4495 An expiration time cannot be used to force a user agent to refresh
4496 its display or reload a resource; its semantics apply only to caching
4497 mechanisms, and such mechanisms need only check a resource's
4498 expiration status when a new request for that resource is initiated.
4499 See section 13.13 for an explanation of the difference between caches
4500 and history mechanisms.
4502 13.2.2 Heuristic Expiration
4504 Since origin servers do not always provide explicit expiration times,
4505 HTTP caches typically assign heuristic expiration times, employing
4506 algorithms that use other header values (such as the Last-Modified
4507 time) to estimate a plausible expiration time. The HTTP/1.1
4508 specification does not provide specific algorithms, but does impose
4509 worst-case constraints on their results. Since heuristic expiration
4510 times might compromise semantic transparency, they ought to used
4511 cautiously, and we encourage origin servers to provide explicit
4512 expiration times as much as possible.
4514 13.2.3 Age Calculations
4516 In order to know if a cached entry is fresh, a cache needs to know if
4517 its age exceeds its freshness lifetime. We discuss how to calculate
4518 the latter in section 13.2.4; this section describes how to calculate
4519 the age of a response or cache entry.
4521 In this discussion, we use the term "now" to mean "the current value
4522 of the clock at the host performing the calculation." Hosts that use
4523 HTTP, but especially hosts running origin servers and caches, SHOULD
4524 use NTP [28] or some similar protocol to synchronize their clocks to
4525 a globally accurate time standard.
4529 Fielding, et al. Standards Track [Page 80]
4531 RFC 2616 HTTP/1.1 June 1999
4534 HTTP/1.1 requires origin servers to send a Date header, if possible,
4535 with every response, giving the time at which the response was
4536 generated (see section 14.18). We use the term "date_value" to denote
4537 the value of the Date header, in a form appropriate for arithmetic
4540 HTTP/1.1 uses the Age response-header to convey the estimated age of
4541 the response message when obtained from a cache. The Age field value
4542 is the cache's estimate of the amount of time since the response was
4543 generated or revalidated by the origin server.
4545 In essence, the Age value is the sum of the time that the response
4546 has been resident in each of the caches along the path from the
4547 origin server, plus the amount of time it has been in transit along
4550 We use the term "age_value" to denote the value of the Age header, in
4551 a form appropriate for arithmetic operations.
4553 A response's age can be calculated in two entirely independent ways:
4555 1. now minus date_value, if the local clock is reasonably well
4556 synchronized to the origin server's clock. If the result is
4557 negative, the result is replaced by zero.
4559 2. age_value, if all of the caches along the response path
4562 Given that we have two independent ways to compute the age of a
4563 response when it is received, we can combine these as
4565 corrected_received_age = max(now - date_value, age_value)
4567 and as long as we have either nearly synchronized clocks or all-
4568 HTTP/1.1 paths, one gets a reliable (conservative) result.
4570 Because of network-imposed delays, some significant interval might
4571 pass between the time that a server generates a response and the time
4572 it is received at the next outbound cache or client. If uncorrected,
4573 this delay could result in improperly low ages.
4575 Because the request that resulted in the returned Age value must have
4576 been initiated prior to that Age value's generation, we can correct
4577 for delays imposed by the network by recording the time at which the
4578 request was initiated. Then, when an Age value is received, it MUST
4579 be interpreted relative to the time the request was initiated, not
4585 Fielding, et al. Standards Track [Page 81]
4587 RFC 2616 HTTP/1.1 June 1999
4590 the time that the response was received. This algorithm results in
4591 conservative behavior no matter how much delay is experienced. So, we
4594 corrected_initial_age = corrected_received_age
4595 + (now - request_time)
4597 where "request_time" is the time (according to the local clock) when
4598 the request that elicited this response was sent.
4600 Summary of age calculation algorithm, when a cache receives a
4605 * is the value of Age: header received by the cache with
4608 * is the value of the origin server's Date: header
4610 * is the (local) time when the cache made the request
4611 * that resulted in this cached response
4613 * is the (local) time when the cache received the
4616 * is the current (local) time
4619 apparent_age = max(0, response_time - date_value);
4620 corrected_received_age = max(apparent_age, age_value);
4621 response_delay = response_time - request_time;
4622 corrected_initial_age = corrected_received_age + response_delay;
4623 resident_time = now - response_time;
4624 current_age = corrected_initial_age + resident_time;
4626 The current_age of a cache entry is calculated by adding the amount
4627 of time (in seconds) since the cache entry was last validated by the
4628 origin server to the corrected_initial_age. When a response is
4629 generated from a cache entry, the cache MUST include a single Age
4630 header field in the response with a value equal to the cache entry's
4633 The presence of an Age header field in a response implies that a
4634 response is not first-hand. However, the converse is not true, since
4635 the lack of an Age header field in a response does not imply that the
4641 Fielding, et al. Standards Track [Page 82]
4643 RFC 2616 HTTP/1.1 June 1999
4646 response is first-hand unless all caches along the request path are
4647 compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
4648 the Age header field).
4650 13.2.4 Expiration Calculations
4652 In order to decide whether a response is fresh or stale, we need to
4653 compare its freshness lifetime to its age. The age is calculated as
4654 described in section 13.2.3; this section describes how to calculate
4655 the freshness lifetime, and to determine if a response has expired.
4656 In the discussion below, the values can be represented in any form
4657 appropriate for arithmetic operations.
4659 We use the term "expires_value" to denote the value of the Expires
4660 header. We use the term "max_age_value" to denote an appropriate
4661 value of the number of seconds carried by the "max-age" directive of
4662 the Cache-Control header in a response (see section 14.9.3).
4664 The max-age directive takes priority over Expires, so if max-age is
4665 present in a response, the calculation is simply:
4667 freshness_lifetime = max_age_value
4669 Otherwise, if Expires is present in the response, the calculation is:
4671 freshness_lifetime = expires_value - date_value
4673 Note that neither of these calculations is vulnerable to clock skew,
4674 since all of the information comes from the origin server.
4676 If none of Expires, Cache-Control: max-age, or Cache-Control: s-
4677 maxage (see section 14.9.3) appears in the response, and the response
4678 does not include other restrictions on caching, the cache MAY compute
4679 a freshness lifetime using a heuristic. The cache MUST attach Warning
4680 113 to any response whose age is more than 24 hours if such warning
4681 has not already been added.
4683 Also, if the response does have a Last-Modified time, the heuristic
4684 expiration value SHOULD be no more than some fraction of the interval
4685 since that time. A typical setting of this fraction might be 10%.
4687 The calculation to determine if a response has expired is quite
4690 response_is_fresh = (freshness_lifetime > current_age)
4697 Fielding, et al. Standards Track [Page 83]
4699 RFC 2616 HTTP/1.1 June 1999
4702 13.2.5 Disambiguating Expiration Values
4704 Because expiration values are assigned optimistically, it is possible
4705 for two caches to contain fresh values for the same resource that are
4708 If a client performing a retrieval receives a non-first-hand response
4709 for a request that was already fresh in its own cache, and the Date
4710 header in its existing cache entry is newer than the Date on the new
4711 response, then the client MAY ignore the response. If so, it MAY
4712 retry the request with a "Cache-Control: max-age=0" directive (see
4713 section 14.9), to force a check with the origin server.
4715 If a cache has two fresh responses for the same representation with
4716 different validators, it MUST use the one with the more recent Date
4717 header. This situation might arise because the cache is pooling
4718 responses from other caches, or because a client has asked for a
4719 reload or a revalidation of an apparently fresh cache entry.
4721 13.2.6 Disambiguating Multiple Responses
4723 Because a client might be receiving responses via multiple paths, so
4724 that some responses flow through one set of caches and other
4725 responses flow through a different set of caches, a client might
4726 receive responses in an order different from that in which the origin
4727 server sent them. We would like the client to use the most recently
4728 generated response, even if older responses are still apparently
4731 Neither the entity tag nor the expiration value can impose an
4732 ordering on responses, since it is possible that a later response
4733 intentionally carries an earlier expiration time. The Date values are
4734 ordered to a granularity of one second.
4736 When a client tries to revalidate a cache entry, and the response it
4737 receives contains a Date header that appears to be older than the one
4738 for the existing entry, then the client SHOULD repeat the request
4739 unconditionally, and include
4741 Cache-Control: max-age=0
4743 to force any intermediate caches to validate their copies directly
4744 with the origin server, or
4746 Cache-Control: no-cache
4748 to force any intermediate caches to obtain a new copy from the origin
4753 Fielding, et al. Standards Track [Page 84]
4755 RFC 2616 HTTP/1.1 June 1999
4758 If the Date values are equal, then the client MAY use either response
4759 (or MAY, if it is being extremely prudent, request a new response).
4760 Servers MUST NOT depend on clients being able to choose
4761 deterministically between responses generated during the same second,
4762 if their expiration times overlap.
4764 13.3 Validation Model
4766 When a cache has a stale entry that it would like to use as a
4767 response to a client's request, it first has to check with the origin
4768 server (or possibly an intermediate cache with a fresh response) to
4769 see if its cached entry is still usable. We call this "validating"
4770 the cache entry. Since we do not want to have to pay the overhead of
4771 retransmitting the full response if the cached entry is good, and we
4772 do not want to pay the overhead of an extra round trip if the cached
4773 entry is invalid, the HTTP/1.1 protocol supports the use of
4774 conditional methods.
4776 The key protocol features for supporting conditional methods are
4777 those concerned with "cache validators." When an origin server
4778 generates a full response, it attaches some sort of validator to it,
4779 which is kept with the cache entry. When a client (user agent or
4780 proxy cache) makes a conditional request for a resource for which it
4781 has a cache entry, it includes the associated validator in the
4784 The server then checks that validator against the current validator
4785 for the entity, and, if they match (see section 13.3.3), it responds
4786 with a special status code (usually, 304 (Not Modified)) and no
4787 entity-body. Otherwise, it returns a full response (including
4788 entity-body). Thus, we avoid transmitting the full response if the
4789 validator matches, and we avoid an extra round trip if it does not
4792 In HTTP/1.1, a conditional request looks exactly the same as a normal
4793 request for the same resource, except that it carries a special
4794 header (which includes the validator) that implicitly turns the
4795 method (usually, GET) into a conditional.
4797 The protocol includes both positive and negative senses of cache-
4798 validating conditions. That is, it is possible to request either that
4799 a method be performed if and only if a validator matches or if and
4800 only if no validators match.
4809 Fielding, et al. Standards Track [Page 85]
4811 RFC 2616 HTTP/1.1 June 1999
4814 Note: a response that lacks a validator may still be cached, and
4815 served from cache until it expires, unless this is explicitly
4816 prohibited by a cache-control directive. However, a cache cannot
4817 do a conditional retrieval if it does not have a validator for the
4818 entity, which means it will not be refreshable after it expires.
4820 13.3.1 Last-Modified Dates
4822 The Last-Modified entity-header field value is often used as a cache
4823 validator. In simple terms, a cache entry is considered to be valid
4824 if the entity has not been modified since the Last-Modified value.
4826 13.3.2 Entity Tag Cache Validators
4828 The ETag response-header field value, an entity tag, provides for an
4829 "opaque" cache validator. This might allow more reliable validation
4830 in situations where it is inconvenient to store modification dates,
4831 where the one-second resolution of HTTP date values is not
4832 sufficient, or where the origin server wishes to avoid certain
4833 paradoxes that might arise from the use of modification dates.
4835 Entity Tags are described in section 3.11. The headers used with
4836 entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
4838 13.3.3 Weak and Strong Validators
4840 Since both origin servers and caches will compare two validators to
4841 decide if they represent the same or different entities, one normally
4842 would expect that if the entity (the entity-body or any entity-
4843 headers) changes in any way, then the associated validator would
4844 change as well. If this is true, then we call this validator a
4847 However, there might be cases when a server prefers to change the
4848 validator only on semantically significant changes, and not when
4849 insignificant aspects of the entity change. A validator that does not
4850 always change when the resource changes is a "weak validator."
4852 Entity tags are normally "strong validators," but the protocol
4853 provides a mechanism to tag an entity tag as "weak." One can think of
4854 a strong validator as one that changes whenever the bits of an entity
4855 changes, while a weak value changes whenever the meaning of an entity
4856 changes. Alternatively, one can think of a strong validator as part
4857 of an identifier for a specific entity, while a weak validator is
4858 part of an identifier for a set of semantically equivalent entities.
4860 Note: One example of a strong validator is an integer that is
4861 incremented in stable storage every time an entity is changed.
4865 Fielding, et al. Standards Track [Page 86]
4867 RFC 2616 HTTP/1.1 June 1999
4870 An entity's modification time, if represented with one-second
4871 resolution, could be a weak validator, since it is possible that
4872 the resource might be modified twice during a single second.
4874 Support for weak validators is optional. However, weak validators
4875 allow for more efficient caching of equivalent objects; for
4876 example, a hit counter on a site is probably good enough if it is
4877 updated every few days or weeks, and any value during that period
4878 is likely "good enough" to be equivalent.
4880 A "use" of a validator is either when a client generates a request
4881 and includes the validator in a validating header field, or when a
4882 server compares two validators.
4884 Strong validators are usable in any context. Weak validators are only
4885 usable in contexts that do not depend on exact equality of an entity.
4886 For example, either kind is usable for a conditional GET of a full
4887 entity. However, only a strong validator is usable for a sub-range
4888 retrieval, since otherwise the client might end up with an internally
4889 inconsistent entity.
4891 Clients MAY issue simple (non-subrange) GET requests with either weak
4892 validators or strong validators. Clients MUST NOT use weak validators
4893 in other forms of request.
4895 The only function that the HTTP/1.1 protocol defines on validators is
4896 comparison. There are two validator comparison functions, depending
4897 on whether the comparison context allows the use of weak validators
4900 - The strong comparison function: in order to be considered equal,
4901 both validators MUST be identical in every way, and both MUST
4904 - The weak comparison function: in order to be considered equal,
4905 both validators MUST be identical in every way, but either or
4906 both of them MAY be tagged as "weak" without affecting the
4909 An entity tag is strong unless it is explicitly tagged as weak.
4910 Section 3.11 gives the syntax for entity tags.
4912 A Last-Modified time, when used as a validator in a request, is
4913 implicitly weak unless it is possible to deduce that it is strong,
4914 using the following rules:
4916 - The validator is being compared by an origin server to the
4917 actual current validator for the entity and,
4921 Fielding, et al. Standards Track [Page 87]
4923 RFC 2616 HTTP/1.1 June 1999
4926 - That origin server reliably knows that the associated entity did
4927 not change twice during the second covered by the presented
4932 - The validator is about to be used by a client in an If-
4933 Modified-Since or If-Unmodified-Since header, because the client
4934 has a cache entry for the associated entity, and
4936 - That cache entry includes a Date value, which gives the time
4937 when the origin server sent the original response, and
4939 - The presented Last-Modified time is at least 60 seconds before
4944 - The validator is being compared by an intermediate cache to the
4945 validator stored in its cache entry for the entity, and
4947 - That cache entry includes a Date value, which gives the time
4948 when the origin server sent the original response, and
4950 - The presented Last-Modified time is at least 60 seconds before
4953 This method relies on the fact that if two different responses were
4954 sent by the origin server during the same second, but both had the
4955 same Last-Modified time, then at least one of those responses would
4956 have a Date value equal to its Last-Modified time. The arbitrary 60-
4957 second limit guards against the possibility that the Date and Last-
4958 Modified values are generated from different clocks, or at somewhat
4959 different times during the preparation of the response. An
4960 implementation MAY use a value larger than 60 seconds, if it is
4961 believed that 60 seconds is too short.
4963 If a client wishes to perform a sub-range retrieval on a value for
4964 which it has only a Last-Modified time and no opaque validator, it
4965 MAY do this only if the Last-Modified time is strong in the sense
4968 A cache or origin server receiving a conditional request, other than
4969 a full-body GET request, MUST use the strong comparison function to
4970 evaluate the condition.
4972 These rules allow HTTP/1.1 caches and clients to safely perform sub-
4973 range retrievals on values that have been obtained from HTTP/1.0
4977 Fielding, et al. Standards Track [Page 88]
4979 RFC 2616 HTTP/1.1 June 1999
4984 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
4986 We adopt a set of rules and recommendations for origin servers,
4987 clients, and caches regarding when various validator types ought to
4988 be used, and for what purposes.
4990 HTTP/1.1 origin servers:
4992 - SHOULD send an entity tag validator unless it is not feasible to
4995 - MAY send a weak entity tag instead of a strong entity tag, if
4996 performance considerations support the use of weak entity tags,
4997 or if it is unfeasible to send a strong entity tag.
4999 - SHOULD send a Last-Modified value if it is feasible to send one,
5000 unless the risk of a breakdown in semantic transparency that
5001 could result from using this date in an If-Modified-Since header
5002 would lead to serious problems.
5004 In other words, the preferred behavior for an HTTP/1.1 origin server
5005 is to send both a strong entity tag and a Last-Modified value.
5007 In order to be legal, a strong entity tag MUST change whenever the
5008 associated entity value changes in any way. A weak entity tag SHOULD
5009 change whenever the associated entity changes in a semantically
5012 Note: in order to provide semantically transparent caching, an
5013 origin server must avoid reusing a specific strong entity tag
5014 value for two different entities, or reusing a specific weak
5015 entity tag value for two semantically different entities. Cache
5016 entries might persist for arbitrarily long periods, regardless of
5017 expiration times, so it might be inappropriate to expect that a
5018 cache will never again attempt to validate an entry using a
5019 validator that it obtained at some point in the past.
5023 - If an entity tag has been provided by the origin server, MUST
5024 use that entity tag in any cache-conditional request (using If-
5025 Match or If-None-Match).
5027 - If only a Last-Modified value has been provided by the origin
5028 server, SHOULD use that value in non-subrange cache-conditional
5029 requests (using If-Modified-Since).
5033 Fielding, et al. Standards Track [Page 89]
5035 RFC 2616 HTTP/1.1 June 1999
5038 - If only a Last-Modified value has been provided by an HTTP/1.0
5039 origin server, MAY use that value in subrange cache-conditional
5040 requests (using If-Unmodified-Since:). The user agent SHOULD
5041 provide a way to disable this, in case of difficulty.
5043 - If both an entity tag and a Last-Modified value have been
5044 provided by the origin server, SHOULD use both validators in
5045 cache-conditional requests. This allows both HTTP/1.0 and
5046 HTTP/1.1 caches to respond appropriately.
5048 An HTTP/1.1 origin server, upon receiving a conditional request that
5049 includes both a Last-Modified date (e.g., in an If-Modified-Since or
5050 If-Unmodified-Since header field) and one or more entity tags (e.g.,
5051 in an If-Match, If-None-Match, or If-Range header field) as cache
5052 validators, MUST NOT return a response status of 304 (Not Modified)
5053 unless doing so is consistent with all of the conditional header
5054 fields in the request.
5056 An HTTP/1.1 caching proxy, upon receiving a conditional request that
5057 includes both a Last-Modified date and one or more entity tags as
5058 cache validators, MUST NOT return a locally cached response to the
5059 client unless that cached response is consistent with all of the
5060 conditional header fields in the request.
5062 Note: The general principle behind these rules is that HTTP/1.1
5063 servers and clients should transmit as much non-redundant
5064 information as is available in their responses and requests.
5065 HTTP/1.1 systems receiving this information will make the most
5066 conservative assumptions about the validators they receive.
5068 HTTP/1.0 clients and caches will ignore entity tags. Generally,
5069 last-modified values received or used by these systems will
5070 support transparent and efficient caching, and so HTTP/1.1 origin
5071 servers should provide Last-Modified values. In those rare cases
5072 where the use of a Last-Modified value as a validator by an
5073 HTTP/1.0 system could result in a serious problem, then HTTP/1.1
5074 origin servers should not provide one.
5076 13.3.5 Non-validating Conditionals
5078 The principle behind entity tags is that only the service author
5079 knows the semantics of a resource well enough to select an
5080 appropriate cache validation mechanism, and the specification of any
5081 validator comparison function more complex than byte-equality would
5082 open up a can of worms. Thus, comparisons of any other headers
5083 (except Last-Modified, for compatibility with HTTP/1.0) are never
5084 used for purposes of validating a cache entry.
5089 Fielding, et al. Standards Track [Page 90]
5091 RFC 2616 HTTP/1.1 June 1999
5094 13.4 Response Cacheability
5096 Unless specifically constrained by a cache-control (section 14.9)
5097 directive, a caching system MAY always store a successful response
5098 (see section 13.8) as a cache entry, MAY return it without validation
5099 if it is fresh, and MAY return it after successful validation. If
5100 there is neither a cache validator nor an explicit expiration time
5101 associated with a response, we do not expect it to be cached, but
5102 certain caches MAY violate this expectation (for example, when little
5103 or no network connectivity is available). A client can usually detect
5104 that such a response was taken from a cache by comparing the Date
5105 header to the current time.
5107 Note: some HTTP/1.0 caches are known to violate this expectation
5108 without providing any Warning.
5110 However, in some cases it might be inappropriate for a cache to
5111 retain an entity, or to return it in response to a subsequent
5112 request. This might be because absolute semantic transparency is
5113 deemed necessary by the service author, or because of security or
5114 privacy considerations. Certain cache-control directives are
5115 therefore provided so that the server can indicate that certain
5116 resource entities, or portions thereof, are not to be cached
5117 regardless of other considerations.
5119 Note that section 14.8 normally prevents a shared cache from saving
5120 and returning a response to a previous request if that request
5121 included an Authorization header.
5123 A response received with a status code of 200, 203, 206, 300, 301 or
5124 410 MAY be stored by a cache and used in reply to a subsequent
5125 request, subject to the expiration mechanism, unless a cache-control
5126 directive prohibits caching. However, a cache that does not support
5127 the Range and Content-Range headers MUST NOT cache 206 (Partial
5130 A response received with any other status code (e.g. status codes 302
5131 and 307) MUST NOT be returned in a reply to a subsequent request
5132 unless there are cache-control directives or another header(s) that
5133 explicitly allow it. For example, these include the following: an
5134 Expires header (section 14.21); a "max-age", "s-maxage", "must-
5135 revalidate", "proxy-revalidate", "public" or "private" cache-control
5136 directive (section 14.9).
5145 Fielding, et al. Standards Track [Page 91]
5147 RFC 2616 HTTP/1.1 June 1999
5150 13.5 Constructing Responses From Caches
5152 The purpose of an HTTP cache is to store information received in
5153 response to requests for use in responding to future requests. In
5154 many cases, a cache simply returns the appropriate parts of a
5155 response to the requester. However, if the cache holds a cache entry
5156 based on a previous response, it might have to combine parts of a new
5157 response with what is held in the cache entry.
5159 13.5.1 End-to-end and Hop-by-hop Headers
5161 For the purpose of defining the behavior of caches and non-caching
5162 proxies, we divide HTTP headers into two categories:
5164 - End-to-end headers, which are transmitted to the ultimate
5165 recipient of a request or response. End-to-end headers in
5166 responses MUST be stored as part of a cache entry and MUST be
5167 transmitted in any response formed from a cache entry.
5169 - Hop-by-hop headers, which are meaningful only for a single
5170 transport-level connection, and are not stored by caches or
5171 forwarded by proxies.
5173 The following HTTP/1.1 headers are hop-by-hop headers:
5177 - Proxy-Authenticate
5178 - Proxy-Authorization
5180 - Trailers [[should be "Trailer"]]
5184 All other headers defined by HTTP/1.1 are end-to-end headers.
5186 Other hop-by-hop headers MUST be listed in a Connection header,
5187 (section 14.10) to be introduced into HTTP/1.1 (or later).
5189 13.5.2 Non-modifiable Headers
5191 Some features of the HTTP/1.1 protocol, such as Digest
5192 Authentication, depend on the value of certain end-to-end headers. A
5193 transparent proxy SHOULD NOT modify an end-to-end header unless the
5194 definition of that header requires or specifically allows that.
5201 Fielding, et al. Standards Track [Page 92]
5203 RFC 2616 HTTP/1.1 June 1999
5206 A transparent proxy MUST NOT modify any of the following fields in a
5207 request or response, and it MUST NOT add any of these fields if not
5218 A transparent proxy MUST NOT modify any of the following fields in a
5223 but it MAY add any of these fields if not already present. If an
5224 Expires header is added, it MUST be given a field-value identical to
5225 that of the Date header in that response.
5227 A proxy MUST NOT modify or add any of the following fields in a
5228 message that contains the no-transform cache-control directive, or in
5237 A non-transparent proxy MAY modify or add these fields to a message
5238 that does not include no-transform, but if it does so, it MUST add a
5239 Warning 214 (Transformation applied) if one does not already appear
5240 in the message (see section 14.46).
5242 Warning: unnecessary modification of end-to-end headers might
5243 cause authentication failures if stronger authentication
5244 mechanisms are introduced in later versions of HTTP. Such
5245 authentication mechanisms MAY rely on the values of header fields
5248 The Content-Length field of a request or response is added or deleted
5249 according to the rules in section 4.4. A transparent proxy MUST
5250 preserve the entity-length (section 7.2.2) of the entity-body,
5251 although it MAY change the transfer-length (section 4.4).
5257 Fielding, et al. Standards Track [Page 93]
5259 RFC 2616 HTTP/1.1 June 1999
5262 13.5.3 Combining Headers
5264 When a cache makes a validating request to a server, and the server
5265 provides a 304 (Not Modified) response or a 206 (Partial Content)
5266 response, the cache then constructs a response to send to the
5269 If the status code is 304 (Not Modified), the cache uses the entity-
5270 body stored in the cache entry as the entity-body of this outgoing
5271 response. If the status code is 206 (Partial Content) and the ETag or
5272 Last-Modified headers match exactly, the cache MAY combine the
5273 contents stored in the cache entry with the new contents received in
5274 the response and use the result as the entity-body of this outgoing
5275 response, (see 13.5.4).
5277 The end-to-end headers stored in the cache entry are used for the
5278 constructed response, except that
5280 - any stored Warning headers with warn-code 1xx (see section
5281 14.46) MUST be deleted from the cache entry and the forwarded
5284 - any stored Warning headers with warn-code 2xx MUST be retained
5285 in the cache entry and the forwarded response.
5287 - any end-to-end headers provided in the 304 or 206 response MUST
5288 replace the corresponding headers from the cache entry.
5290 Unless the cache decides to remove the cache entry, it MUST also
5291 replace the end-to-end headers stored with the cache entry with
5292 corresponding headers received in the incoming response, except for
5293 Warning headers as described immediately above. If a header field-
5294 name in the incoming response matches more than one header in the
5295 cache entry, all such old headers MUST be replaced.
5297 In other words, the set of end-to-end headers received in the
5298 incoming response overrides all corresponding end-to-end headers
5299 stored with the cache entry (except for stored Warning headers with
5300 warn-code 1xx, which are deleted even if not overridden).
5302 Note: this rule allows an origin server to use a 304 (Not
5303 Modified) or a 206 (Partial Content) response to update any header
5304 associated with a previous response for the same entity or sub-
5305 ranges thereof, although it might not always be meaningful or
5306 correct to do so. This rule does not allow an origin server to use
5307 a 304 (Not Modified) or a 206 (Partial Content) response to
5308 entirely delete a header that it had provided with a previous
5313 Fielding, et al. Standards Track [Page 94]
5315 RFC 2616 HTTP/1.1 June 1999
5318 13.5.4 Combining Byte Ranges
5320 A response might transfer only a subrange of the bytes of an entity-
5321 body, either because the request included one or more Range
5322 specifications, or because a connection was broken prematurely. After
5323 several such transfers, a cache might have received several ranges of
5324 the same entity-body.
5326 If a cache has a stored non-empty set of subranges for an entity, and
5327 an incoming response transfers another subrange, the cache MAY
5328 combine the new subrange with the existing set if both the following
5331 - Both the incoming response and the cache entry have a cache
5334 - The two cache validators match using the strong comparison
5335 function (see section 13.3.3).
5337 If either requirement is not met, the cache MUST use only the most
5338 recent partial response (based on the Date values transmitted with
5339 every response, and using the incoming response if these values are
5340 equal or missing), and MUST discard the other partial information.
5342 13.6 Caching Negotiated Responses
5344 Use of server-driven content negotiation (section 12.1), as indicated
5345 by the presence of a Vary header field in a response, alters the
5346 conditions and procedure by which a cache can use the response for
5347 subsequent requests. See section 14.44 for use of the Vary header
5350 A server SHOULD use the Vary header field to inform a cache of what
5351 request-header fields were used to select among multiple
5352 representations of a cacheable response subject to server-driven
5353 negotiation. The set of header fields named by the Vary field value
5354 is known as the "selecting" request-headers.
5356 When the cache receives a subsequent request whose Request-URI
5357 specifies one or more cache entries including a Vary header field,
5358 the cache MUST NOT use such a cache entry to construct a response to
5359 the new request unless all of the selecting request-headers present
5360 in the new request match the corresponding stored request-headers in
5361 the original request.
5363 The selecting request-headers from two requests are defined to match
5364 if and only if the selecting request-headers in the first request can
5365 be transformed to the selecting request-headers in the second request
5369 Fielding, et al. Standards Track [Page 95]
5371 RFC 2616 HTTP/1.1 June 1999
5374 by adding or removing linear white space (LWS) at places where this
5375 is allowed by the corresponding BNF, and/or combining multiple
5376 message-header fields with the same field name following the rules
5377 about message headers in section 4.2.
5379 A Vary header field-value of "*" always fails to match and subsequent
5380 requests on that resource can only be properly interpreted by the
5383 If the selecting request header fields for the cached entry do not
5384 match the selecting request header fields of the new request, then
5385 the cache MUST NOT use a cached entry to satisfy the request unless
5386 it first relays the new request to the origin server in a conditional
5387 request and the server responds with 304 (Not Modified), including an
5388 entity tag or Content-Location that indicates the entity to be used.
5390 If an entity tag was assigned to a cached representation, the
5391 forwarded request SHOULD be conditional and include the entity tags
5392 in an If-None-Match header field from all its cache entries for the
5393 resource. This conveys to the server the set of entities currently
5394 held by the cache, so that if any one of these entities matches the
5395 requested entity, the server can use the ETag header field in its 304
5396 (Not Modified) response to tell the cache which entry is appropriate.
5397 If the entity-tag of the new response matches that of an existing
5398 entry, the new response SHOULD be used to update the header fields of
5399 the existing entry, and the result MUST be returned to the client.
5401 If any of the existing cache entries contains only partial content
5402 for the associated entity, its entity-tag SHOULD NOT be included in
5403 the If-None-Match header field unless the request is for a range that
5404 would be fully satisfied by that entry.
5406 If a cache receives a successful response whose Content-Location
5407 field matches that of an existing cache entry for the same Request-
5408 ]URI, whose entity-tag differs from that of the existing entry, and
5409 whose Date is more recent than that of the existing entry, the
5410 existing entry SHOULD NOT be returned in response to future requests
5411 and SHOULD be deleted from the cache.
5413 13.7 Shared and Non-Shared Caches
5415 For reasons of security and privacy, it is necessary to make a
5416 distinction between "shared" and "non-shared" caches. A non-shared
5417 cache is one that is accessible only to a single user. Accessibility
5418 in this case SHOULD be enforced by appropriate security mechanisms.
5419 All other caches are considered to be "shared." Other sections of
5425 Fielding, et al. Standards Track [Page 96]
5427 RFC 2616 HTTP/1.1 June 1999
5430 this specification place certain constraints on the operation of
5431 shared caches in order to prevent loss of privacy or failure of
5434 13.8 Errors or Incomplete Response Cache Behavior
5436 A cache that receives an incomplete response (for example, with fewer
5437 bytes of data than specified in a Content-Length header) MAY store
5438 the response. However, the cache MUST treat this as a partial
5439 response. Partial responses MAY be combined as described in section
5440 13.5.4; the result might be a full response or might still be
5441 partial. A cache MUST NOT return a partial response to a client
5442 without explicitly marking it as such, using the 206 (Partial
5443 Content) status code. A cache MUST NOT return a partial response
5444 using a status code of 200 (OK).
5446 If a cache receives a 5xx response while attempting to revalidate an
5447 entry, it MAY either forward this response to the requesting client,
5448 or act as if the server failed to respond. In the latter case, it MAY
5449 return a previously received response unless the cached entry
5450 includes the "must-revalidate" cache-control directive (see section
5453 13.9 Side Effects of GET and HEAD
5455 Unless the origin server explicitly prohibits the caching of their
5456 responses, the application of GET and HEAD methods to any resources
5457 SHOULD NOT have side effects that would lead to erroneous behavior if
5458 these responses are taken from a cache. They MAY still have side
5459 effects, but a cache is not required to consider such side effects in
5460 its caching decisions. Caches are always expected to observe an
5461 origin server's explicit restrictions on caching.
5463 We note one exception to this rule: since some applications have
5464 traditionally used GETs and HEADs with query URLs (those containing a
5465 "?" in the rel_path part) to perform operations with significant side
5466 effects, caches MUST NOT treat responses to such URIs as fresh unless
5467 the server provides an explicit expiration time. This specifically
5468 means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
5469 be taken from a cache. See section 9.1.1 for related information.
5471 13.10 Invalidation After Updates or Deletions
5473 The effect of certain methods performed on a resource at the origin
5474 server might cause one or more existing cache entries to become non-
5475 transparently invalid. That is, although they might continue to be
5476 "fresh," they do not accurately reflect what the origin server would
5477 return for a new request on that resource.
5481 Fielding, et al. Standards Track [Page 97]
5483 RFC 2616 HTTP/1.1 June 1999
5486 There is no way for the HTTP protocol to guarantee that all such
5487 cache entries are marked invalid. For example, the request that
5488 caused the change at the origin server might not have gone through
5489 the proxy where a cache entry is stored. However, several rules help
5490 reduce the likelihood of erroneous behavior.
5492 In this section, the phrase "invalidate an entity" means that the
5493 cache will either remove all instances of that entity from its
5494 storage, or will mark these as "invalid" and in need of a mandatory
5495 revalidation before they can be returned in response to a subsequent
5498 Some HTTP methods MUST cause a cache to invalidate an entity. This is
5499 either the entity referred to by the Request-URI, or by the Location
5500 or Content-Location headers (if present). These methods are:
5508 In order to prevent denial of service attacks, an invalidation based
5509 on the URI in a Location or Content-Location header MUST only be
5510 performed if the host part is the same as in the Request-URI.
5513 [[ An invalidation based on the URI in a Location or Content-Location ]]
5514 [[ header MUST NOT be performed if the host part of that URI differs ]]
5515 [[ from the host part in the Request-URI. This helps prevent denial of ]]
5516 [[ service attacks. ]]
5518 A cache that passes through requests for methods it does not
5519 understand SHOULD invalidate any entities referred to by the
5522 13.11 Write-Through Mandatory
5524 All methods that might be expected to cause modifications to the
5525 origin server's resources MUST be written through to the origin
5526 server. This currently includes all methods except for GET and HEAD.
5527 A cache MUST NOT reply to such a request from a client before having
5528 transmitted the request to the inbound server, and having received a
5529 corresponding response from the inbound server. This does not prevent
5530 a proxy cache from sending a 100 (Continue) response before the
5531 inbound server has sent its final reply.
5533 The alternative (known as "write-back" or "copy-back" caching) is not
5534 allowed in HTTP/1.1, due to the difficulty of providing consistent
5535 updates and the problems arising from server, cache, or network
5536 failure prior to write-back.
5543 Fielding, et al. Standards Track [Page 98]
5545 RFC 2616 HTTP/1.1 June 1999
5548 13.12 Cache Replacement
5550 If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
5551 response is received from a resource while any existing responses for
5552 the same resource are cached, the cache SHOULD use the new response
5553 to reply to the current request. It MAY insert it into cache storage
5554 and MAY, if it meets all other requirements, use it to respond to any
5555 future requests that would previously have caused the old response to
5556 be returned. If it inserts the new response into cache storage the
5557 rules in section 13.5.3 apply.
5559 Note: a new response that has an older Date header value than
5560 existing cached responses is not cacheable.
5564 User agents often have history mechanisms, such as "Back" buttons and
5565 history lists, which can be used to redisplay an entity retrieved
5566 earlier in a session.
5568 History mechanisms and caches are different. In particular history
5569 mechanisms SHOULD NOT try to show a semantically transparent view of
5570 the current state of a resource. Rather, a history mechanism is meant
5571 to show exactly what the user saw at the time when the resource was
5574 By default, an expiration time does not apply to history mechanisms.
5575 If the entity is still in storage, a history mechanism SHOULD display
5576 it even if the entity has expired, unless the user has specifically
5577 configured the agent to refresh expired history documents.
5579 This is not to be construed to prohibit the history mechanism from
5580 telling the user that a view might be stale.
5582 Note: if history list mechanisms unnecessarily prevent users from
5583 viewing stale resources, this will tend to force service authors
5584 to avoid using HTTP expiration controls and cache controls when
5585 they would otherwise like to. Service authors may consider it
5586 important that users not be presented with error messages or
5587 warning messages when they use navigation controls (such as BACK)
5588 to view previously fetched resources. Even though sometimes such
5589 resources ought not to cached, or ought to expire quickly, user
5590 interface considerations may force service authors to resort to
5591 other means of preventing caching (e.g. "once-only" URLs) in order
5592 not to suffer the effects of improperly functioning history
5599 Fielding, et al. Standards Track [Page 99]
5601 RFC 2616 HTTP/1.1 June 1999
5604 14 Header Field Definitions
5606 This section defines the syntax and semantics of all standard
5607 HTTP/1.1 header fields. For entity-header fields, both sender and
5608 recipient refer to either the client or the server, depending on who
5609 sends and who receives the entity.
5613 The Accept request-header field can be used to specify certain media
5614 types which are acceptable for the response. Accept headers can be
5615 used to indicate that the request is specifically limited to a small
5616 set of desired types, as in the case of a request for an in-line
5619 Accept = "Accept" ":"
5620 #( media-range [ accept-params ] )
5622 media-range = ( "*/*"
5624 | ( type "/" subtype )
5625 ) *( ";" parameter )
5626 accept-params = ";" "q" "=" qvalue *( accept-extension )
5627 accept-extension = ";" token [ "=" ( token | quoted-string ) ]
5629 The asterisk "*" character is used to group media types into ranges,
5630 with "*/*" indicating all media types and "type/*" indicating all
5631 subtypes of that type. The media-range MAY include media type
5632 parameters that are applicable to that range.
5634 Each media-range MAY be followed by one or more accept-params,
5635 beginning with the "q" parameter for indicating a relative quality
5636 factor. The first "q" parameter (if any) separates the media-range
5637 parameter(s) from the accept-params. Quality factors allow the user
5638 or user agent to indicate the relative degree of preference for that
5639 media-range, using the qvalue scale from 0 to 1 (section 3.9). The
5640 default value is q=1.
5642 Note: Use of the "q" parameter name to separate media type
5643 parameters from Accept extension parameters is due to historical
5644 practice. Although this prevents any media type parameter named
5645 "q" from being used with a media range, such an event is believed
5646 to be unlikely given the lack of any "q" parameters in the IANA
5647 media type registry and the rare usage of any media type
5648 parameters in Accept. Future media types are discouraged from
5649 registering any parameter named "q".
5655 Fielding, et al. Standards Track [Page 100]
5657 RFC 2616 HTTP/1.1 June 1999
5662 Accept: audio/*; q=0.2, audio/basic
5664 SHOULD be interpreted as "I prefer audio/basic, but send me any audio
5665 type if it is the best available after an 80% mark-down in quality."
5667 If no Accept header field is present, then it is assumed that the
5668 client accepts all media types. If an Accept header field is present,
5669 and if the server cannot send a response which is acceptable
5670 according to the combined Accept field value, then the server SHOULD
5671 send a 406 (not acceptable) response.
5673 A more elaborate example is
5675 Accept: text/plain; q=0.5, text/html,
5676 text/x-dvi; q=0.8, text/x-c
5678 Verbally, this would be interpreted as "text/html and text/x-c are
5679 the preferred media types, but if they do not exist, then send the
5680 text/x-dvi entity, and if that does not exist, send the text/plain
5683 Media ranges can be overridden by more specific media ranges or
5684 specific media types. If more than one media range applies to a given
5685 type, the most specific reference has precedence. For example,
5687 Accept: text/*, text/html, text/html;level=1, */*
5689 have the following precedence:
5691 1) text/html;level=1
5696 The media type quality factor associated with a given type is
5697 determined by finding the media range with the highest precedence
5698 which matches that type. For example,
5700 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
5701 text/html;level=2;q=0.4, */*;q=0.5
5703 would cause the following values to be associated:
5705 text/html;level=1 = 1
5711 Fielding, et al. Standards Track [Page 101]
5713 RFC 2616 HTTP/1.1 June 1999
5717 text/html;level=2 = 0.4
5718 text/html;level=3 = 0.7
5720 Note: A user agent might be provided with a default set of quality
5721 values for certain media ranges. However, unless the user agent is
5722 a closed system which cannot interact with other rendering agents,
5723 this default set ought to be configurable by the user.
5727 The Accept-Charset request-header field can be used to indicate what
5728 character sets are acceptable for the response. This field allows
5729 clients capable of understanding more comprehensive or special-
5730 purpose character sets to signal that capability to a server which is
5731 capable of representing documents in those character sets.
5733 Accept-Charset = "Accept-Charset" ":"
5734 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
5737 Character set values are described in section 3.4. Each charset MAY
5738 be given an associated quality value which represents the user's
5739 preference for that charset. The default value is q=1. An example is
5741 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
5743 The special value "*", if present in the Accept-Charset field,
5744 matches every character set (including ISO-8859-1) which is not
5745 mentioned elsewhere in the Accept-Charset field. If no "*" is present
5746 in an Accept-Charset field, then all character sets not explicitly
5747 mentioned get a quality value of 0, except for ISO-8859-1, which gets
5748 a quality value of 1 if not explicitly mentioned.
5750 If no Accept-Charset header is present, the default is that any
5751 character set is acceptable. If an Accept-Charset header is present,
5752 and if the server cannot send a response which is acceptable
5753 according to the Accept-Charset header, then the server SHOULD send
5754 an error response with the 406 (not acceptable) status code, though
5755 the sending of an unacceptable response is also allowed.
5757 14.3 Accept-Encoding
5759 The Accept-Encoding request-header field is similar to Accept, but
5760 restricts the content-codings (section 3.5) that are acceptable in
5763 Accept-Encoding = "Accept-Encoding" ":"
5767 Fielding, et al. Standards Track [Page 102]
5769 RFC 2616 HTTP/1.1 June 1999
5772 1#( codings [ ";" "q" "=" qvalue ] )
5773 codings = ( content-coding | "*" )
5775 [[ http://lists.w3.org/Archives/Public/ietf-http-wg/2005AprJun/0029.html ]]
5776 [[ points out that the "1#" must be "#" to make the examples below and ]]
5777 [[ the text of rule 4 correct. ]]
5779 Examples of its use are:
5781 Accept-Encoding: compress, gzip
5784 Accept-Encoding: compress;q=0.5, gzip;q=1.0
5785 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
5787 A server tests whether a content-coding is acceptable, according to
5788 an Accept-Encoding field, using these rules:
5790 1. If the content-coding is one of the content-codings listed in
5791 the Accept-Encoding field, then it is acceptable, unless it is
5792 accompanied by a qvalue of 0. (As defined in section 3.9, a
5793 qvalue of 0 means "not acceptable.")
5795 2. The special "*" symbol in an Accept-Encoding field matches any
5796 available content-coding not explicitly listed in the header
5799 3. If multiple content-codings are acceptable, then the acceptable
5800 content-coding with the highest non-zero qvalue is preferred.
5802 4. The "identity" content-coding is always acceptable, unless
5803 specifically refused because the Accept-Encoding field includes
5804 "identity;q=0", or because the field includes "*;q=0" and does
5805 not explicitly include the "identity" content-coding. If the
5806 Accept-Encoding field-value is empty, then only the "identity"
5807 encoding is acceptable.
5809 If an Accept-Encoding field is present in a request, and if the
5810 server cannot send a response which is acceptable according to the
5811 Accept-Encoding header, then the server SHOULD send an error response
5812 with the 406 (Not Acceptable) status code.
5814 If no Accept-Encoding field is present in a request, the server MAY
5815 assume that the client will accept any content coding. In this case,
5816 if "identity" is one of the available content-codings, then the
5817 server SHOULD use the "identity" content-coding, unless it has
5818 additional information that a different content-coding is meaningful
5821 Note: If the request does not include an Accept-Encoding field,
5822 and if the "identity" content-coding is unavailable, then
5823 content-codings commonly understood by HTTP/1.0 clients (i.e.,
5827 Fielding, et al. Standards Track [Page 103]
5829 RFC 2616 HTTP/1.1 June 1999
5832 "gzip" and "compress") are preferred; some older clients
5833 improperly display messages sent with other content-codings. The
5834 server might also make this decision based on information about
5835 the particular user-agent or client.
5837 Note: Most HTTP/1.0 applications do not recognize or obey qvalues
5838 associated with content-codings. This means that qvalues will not
5839 work and are not permitted with x-gzip or x-compress.
5841 14.4 Accept-Language
5843 The Accept-Language request-header field is similar to Accept, but
5844 restricts the set of natural languages that are preferred as a
5845 response to the request. Language tags are defined in section 3.10.
5847 Accept-Language = "Accept-Language" ":"
5848 1#( language-range [ ";" "q" "=" qvalue ] )
5849 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
5851 Each language-range MAY be given an associated quality value which
5852 represents an estimate of the user's preference for the languages
5853 specified by that range. The quality value defaults to "q=1". For
5856 Accept-Language: da, en-gb;q=0.8, en;q=0.7
5858 would mean: "I prefer Danish, but will accept British English and
5859 other types of English." A language-range matches a language-tag if
5860 it exactly equals the tag, or if it exactly equals a prefix of the
5861 tag such that the first tag character following the prefix is "-".
5862 The special range "*", if present in the Accept-Language field,
5863 matches every tag not matched by any other range present in the
5864 Accept-Language field.
5866 Note: This use of a prefix matching rule does not imply that
5867 language tags are assigned to languages in such a way that it is
5868 always true that if a user understands a language with a certain
5869 tag, then this user will also understand all languages with tags
5870 for which this tag is a prefix. The prefix rule simply allows the
5871 use of prefix tags if this is the case.
5873 The language quality factor assigned to a language-tag by the
5874 Accept-Language field is the quality value of the longest language-
5875 range in the field that matches the language-tag. If no language-
5876 range in the field matches the tag, the language quality factor
5877 assigned is 0. If no Accept-Language header is present in the
5883 Fielding, et al. Standards Track [Page 104]
5885 RFC 2616 HTTP/1.1 June 1999
5888 SHOULD assume that all languages are equally acceptable. If an
5889 Accept-Language header is present, then all languages which are
5890 assigned a quality factor greater than 0 are acceptable.
5892 It might be contrary to the privacy expectations of the user to send
5893 an Accept-Language header with the complete linguistic preferences of
5894 the user in every request. For a discussion of this issue, see
5897 As intelligibility is highly dependent on the individual user, it is
5898 recommended that client applications make the choice of linguistic
5899 preference available to the user. If the choice is not made
5900 available, then the Accept-Language header field MUST NOT be given in
5903 Note: When making the choice of linguistic preference available to
5904 the user, we remind implementors of the fact that users are not
5905 familiar with the details of language matching as described above,
5906 and should provide appropriate guidance. As an example, users
5907 might assume that on selecting "en-gb", they will be served any
5908 kind of English document if British English is not available. A
5909 user agent might suggest in such a case to add "en" to get the
5910 best matching behavior.
5914 The Accept-Ranges response-header field allows the server to
5915 indicate its acceptance of range requests for a resource:
5917 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
5918 acceptable-ranges = 1#range-unit | "none"
5920 Origin servers that accept byte-range requests MAY send
5922 Accept-Ranges: bytes
5924 but are not required to do so. Clients MAY generate byte-range
5925 requests without having received this header for the resource
5926 involved. Range units are defined in section 3.12.
5928 Servers that do not accept any kind of range request for a
5933 to advise the client not to attempt a range request.
5939 Fielding, et al. Standards Track [Page 105]
5941 RFC 2616 HTTP/1.1 June 1999
5946 The Age response-header field conveys the sender's estimate of the
5947 amount of time since the response (or its revalidation) was
5948 generated at the origin server. A cached response is "fresh" if
5949 its age does not exceed its freshness lifetime. Age values are
5950 calculated as specified in section 13.2.3.
5952 Age = "Age" ":" age-value
5953 age-value = delta-seconds
5955 Age values are non-negative decimal integers, representing time in
5958 If a cache receives a value larger than the largest positive
5959 integer it can represent, or if any of its age calculations
5960 overflows, it MUST transmit an Age header with a value of
5961 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
5962 include an Age header field in every response generated from its
5963 own cache. Caches SHOULD use an arithmetic type of at least 31
5968 The Allow entity-header field lists the set of methods supported
5969 by the resource identified by the Request-URI. The purpose of this
5970 field is strictly to inform the recipient of valid methods
5971 associated with the resource. An Allow header field MUST be
5972 present in a 405 (Method Not Allowed) response.
5974 Allow = "Allow" ":" #Method
5978 Allow: GET, HEAD, PUT
5980 This field cannot prevent a client from trying other methods.
5981 However, the indications given by the Allow header field value
5982 SHOULD be followed. The actual set of allowed methods is defined
5983 by the origin server at the time of each request.
5985 The Allow header field MAY be provided with a PUT request to
5986 recommend the methods to be supported by the new or modified
5987 resource. The server is not required to support these methods and
5988 SHOULD include an Allow header in the response giving the actual
5995 Fielding, et al. Standards Track [Page 106]
5997 RFC 2616 HTTP/1.1 June 1999
6000 A proxy MUST NOT modify the Allow header field even if it does not
6001 understand all the methods specified, since the user agent might
6002 have other means of communicating with the origin server.
6006 A user agent that wishes to authenticate itself with a server--
6007 usually, but not necessarily, after receiving a 401 response--does
6008 so by including an Authorization request-header field with the
6009 request. The Authorization field value consists of credentials
6010 containing the authentication information of the user agent for
6011 the realm of the resource being requested.
6013 Authorization = "Authorization" ":" credentials
6015 HTTP access authentication is described in "HTTP Authentication:
6016 Basic and Digest Access Authentication" [43]. If a request is
6017 authenticated and a realm specified, the same credentials SHOULD
6018 be valid for all other requests within this realm (assuming that
6019 the authentication scheme itself does not require otherwise, such
6020 as credentials that vary according to a challenge value or using
6021 synchronized clocks).
6023 When a shared cache (see section 13.7) receives a request
6024 containing an Authorization field, it MUST NOT return the
6025 corresponding response as a reply to any other request, unless one
6026 of the following specific exceptions holds:
6028 1. If the response includes the "s-maxage" cache-control
6029 directive, the cache MAY use that response in replying to a
6030 subsequent request. But (if the specified maximum age has
6031 passed) a proxy cache MUST first revalidate it with the origin
6032 server, using the request-headers from the new request to allow
6033 the origin server to authenticate the new request. (This is the
6034 defined behavior for s-maxage.) If the response includes "s-
6035 maxage=0", the proxy MUST always revalidate it before re-using
6038 2. If the response includes the "must-revalidate" cache-control
6039 directive, the cache MAY use that response in replying to a
6040 subsequent request. But if the response is stale, all caches
6041 MUST first revalidate it with the origin server, using the
6042 request-headers from the new request to allow the origin server
6043 to authenticate the new request.
6045 3. If the response includes the "public" cache-control directive,
6046 it MAY be returned in reply to any subsequent request.
6051 Fielding, et al. Standards Track [Page 107]
6053 RFC 2616 HTTP/1.1 June 1999
6058 The Cache-Control general-header field is used to specify directives
6059 that MUST be obeyed by all caching mechanisms along the
6060 request/response chain. The directives specify behavior intended to
6061 prevent caches from adversely interfering with the request or
6062 response. These directives typically override the default caching
6063 algorithms. Cache directives are unidirectional in that the presence
6064 of a directive in a request does not imply that the same directive is
6065 to be given in the response.
6067 Note that HTTP/1.0 caches might not implement Cache-Control and
6068 might only implement Pragma: no-cache (see section 14.32).
6070 Cache directives MUST be passed through by a proxy or gateway
6071 application, regardless of their significance to that application,
6072 since the directives might be applicable to all recipients along the
6073 request/response chain. It is not possible to specify a cache-
6074 directive for a specific cache.
6076 Cache-Control = "Cache-Control" ":" 1#cache-directive
6078 cache-directive = cache-request-directive
6079 | cache-response-directive
6081 cache-request-directive =
6082 "no-cache" ; Section 14.9.1
6083 | "no-store" ; Section 14.9.2
6084 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
6085 | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
6086 | "min-fresh" "=" delta-seconds ; Section 14.9.3
6087 | "no-transform" ; Section 14.9.5
6088 | "only-if-cached" ; Section 14.9.4
6089 | cache-extension ; Section 14.9.6
6091 cache-response-directive =
6092 "public" ; Section 14.9.1
6093 | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
6094 | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
6095 | "no-store" ; Section 14.9.2
6096 | "no-transform" ; Section 14.9.5
6097 | "must-revalidate" ; Section 14.9.4
6098 | "proxy-revalidate" ; Section 14.9.4
6099 | "max-age" "=" delta-seconds ; Section 14.9.3
6100 | "s-maxage" "=" delta-seconds ; Section 14.9.3
6101 | cache-extension ; Section 14.9.6
6103 cache-extension = token [ "=" ( token | quoted-string ) ]
6107 Fielding, et al. Standards Track [Page 108]
6109 RFC 2616 HTTP/1.1 June 1999
6112 When a directive appears without any 1#field-name parameter, the
6113 directive applies to the entire request or response. When such a
6114 directive appears with a 1#field-name parameter, it applies only to
6115 the named field or fields, and not to the rest of the request or
6116 response. This mechanism supports extensibility; implementations of
6117 future versions of the HTTP protocol might apply these directives to
6118 header fields not defined in HTTP/1.1.
6120 The cache-control directives can be broken down into these general
6123 - Restrictions on what are cacheable; these may only be imposed by
6126 - Restrictions on what may be stored by a cache; these may be
6127 imposed by either the origin server or the user agent.
6129 - Modifications of the basic expiration mechanism; these may be
6130 imposed by either the origin server or the user agent.
6132 - Controls over cache revalidation and reload; these may only be
6133 imposed by a user agent.
6135 - Control over transformation of entities.
6137 - Extensions to the caching system.
6139 14.9.1 What is Cacheable
6141 By default, a response is cacheable if the requirements of the
6142 request method, request header fields, and the response status
6143 indicate that it is cacheable. Section 13.4 summarizes these defaults
6144 for cacheability. The following Cache-Control response directives
6145 allow an origin server to override the default cacheability of a
6149 Indicates that the response MAY be cached by any cache, even if it
6150 would normally be non-cacheable or cacheable only within a non-
6151 shared cache. (See also Authorization, section 14.8, for
6152 additional details.)
6155 Indicates that all or part of the response message is intended for
6156 a single user and MUST NOT be cached by a shared cache. This
6157 allows an origin server to state that the specified parts of the
6163 Fielding, et al. Standards Track [Page 109]
6165 RFC 2616 HTTP/1.1 June 1999
6168 response are intended for only one user and are not a valid
6169 response for requests by other users. A private (non-shared) cache
6170 MAY cache the response.
6172 Note: This usage of the word private only controls where the
6173 response may be cached, and cannot ensure the privacy of the
6177 If the no-cache directive does not specify a field-name, then a
6178 cache MUST NOT use the response to satisfy a subsequent request
6179 without successful revalidation with the origin server. This
6180 allows an origin server to prevent caching even by caches that
6181 have been configured to return stale responses to client requests.
6183 If the no-cache directive does specify one or more field-names,
6184 then a cache MAY use the response to satisfy a subsequent request,
6185 subject to any other restrictions on caching. However, the
6186 specified field-name(s) MUST NOT be sent in the response to a
6187 subsequent request without successful revalidation with the origin
6188 server. This allows an origin server to prevent the re-use of
6189 certain header fields in a response, while still allowing caching
6190 of the rest of the response.
6192 Note: Most HTTP/1.0 caches will not recognize or obey this
6195 14.9.2 What May be Stored by Caches
6198 The purpose of the no-store directive is to prevent the
6199 inadvertent release or retention of sensitive information (for
6200 example, on backup tapes). The no-store directive applies to the
6201 entire message, and MAY be sent either in a response or in a
6202 request. If sent in a request, a cache MUST NOT store any part of
6203 either this request or any response to it. If sent in a response,
6204 a cache MUST NOT store any part of either this response or the
6205 request that elicited it. This directive applies to both non-
6206 shared and shared caches. "MUST NOT store" in this context means
6207 that the cache MUST NOT intentionally store the information in
6208 non-volatile storage, and MUST make a best-effort attempt to
6209 remove the information from volatile storage as promptly as
6210 possible after forwarding it.
6212 Even when this directive is associated with a response, users
6213 might explicitly store such a response outside of the caching
6214 system (e.g., with a "Save As" dialog). History buffers MAY store
6215 such responses as part of their normal operation.
6219 Fielding, et al. Standards Track [Page 110]
6221 RFC 2616 HTTP/1.1 June 1999
6224 The purpose of this directive is to meet the stated requirements
6225 of certain users and service authors who are concerned about
6226 accidental releases of information via unanticipated accesses to
6227 cache data structures. While the use of this directive might
6228 improve privacy in some cases, we caution that it is NOT in any
6229 way a reliable or sufficient mechanism for ensuring privacy. In
6230 particular, malicious or compromised caches might not recognize or
6231 obey this directive, and communications networks might be
6232 vulnerable to eavesdropping.
6234 14.9.3 Modifications of the Basic Expiration Mechanism
6236 The expiration time of an entity MAY be specified by the origin
6237 server using the Expires header (see section 14.21). Alternatively,
6238 it MAY be specified using the max-age directive in a response. When
6239 the max-age cache-control directive is present in a cached response,
6240 the response is stale if its current age is greater than the age
6241 value given (in seconds) at the time of a new request for that
6242 resource. The max-age directive on a response implies that the
6243 response is cacheable (i.e., "public") unless some other, more
6244 restrictive cache directive is also present.
6246 If a response includes both an Expires header and a max-age
6247 directive, the max-age directive overrides the Expires header, even
6248 if the Expires header is more restrictive. This rule allows an origin
6249 server to provide, for a given response, a longer expiration time to
6250 an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
6251 useful if certain HTTP/1.0 caches improperly calculate ages or
6252 expiration times, perhaps due to desynchronized clocks.
6254 Many HTTP/1.0 cache implementations will treat an Expires value that
6255 is less than or equal to the response Date value as being equivalent
6256 to the Cache-Control response directive "no-cache". If an HTTP/1.1
6257 cache receives such a response, and the response does not include a
6258 Cache-Control header field, it SHOULD consider the response to be
6259 non-cacheable in order to retain compatibility with HTTP/1.0 servers.
6261 Note: An origin server might wish to use a relatively new HTTP
6262 cache control feature, such as the "private" directive, on a
6263 network including older caches that do not understand that
6264 feature. The origin server will need to combine the new feature
6265 with an Expires field whose value is less than or equal to the
6266 Date value. This will prevent older caches from improperly
6267 caching the response.
6275 Fielding, et al. Standards Track [Page 111]
6277 RFC 2616 HTTP/1.1 June 1999
6281 If a response includes an s-maxage directive, then for a shared
6282 cache (but not for a private cache), the maximum age specified by
6283 this directive overrides the maximum age specified by either the
6284 max-age directive or the Expires header. The s-maxage directive
6285 also implies the semantics of the proxy-revalidate directive (see
6286 section 14.9.4), i.e., that the shared cache must not use the
6287 entry after it becomes stale to respond to a subsequent request
6288 without first revalidating it with the origin server. The s-
6289 maxage directive is always ignored by a private cache.
6291 Note that most older caches, not compliant with this specification,
6292 do not implement any cache-control directives. An origin server
6293 wishing to use a cache-control directive that restricts, but does not
6294 prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
6295 requirement that the max-age directive overrides the Expires header,
6296 and the fact that pre-HTTP/1.1-compliant caches do not observe the
6299 Other directives allow a user agent to modify the basic expiration
6300 mechanism. These directives MAY be specified on a request:
6303 Indicates that the client is willing to accept a response whose
6304 age is no greater than the specified time in seconds. Unless max-
6305 stale directive is also included, the client is not willing to
6306 accept a stale response.
6309 Indicates that the client is willing to accept a response whose
6310 freshness lifetime is no less than its current age plus the
6311 specified time in seconds. That is, the client wants a response
6312 that will still be fresh for at least the specified number of
6316 Indicates that the client is willing to accept a response that has
6317 exceeded its expiration time. If max-stale is assigned a value,
6318 then the client is willing to accept a response that has exceeded
6319 its expiration time by no more than the specified number of
6320 seconds. If no value is assigned to max-stale, then the client is
6321 willing to accept a stale response of any age.
6323 If a cache returns a stale response, either because of a max-stale
6324 directive on a request, or because the cache is configured to
6325 override the expiration time of a response, the cache MUST attach a
6326 Warning header to the stale response, using Warning 110 (Response is
6331 Fielding, et al. Standards Track [Page 112]
6333 RFC 2616 HTTP/1.1 June 1999
6336 A cache MAY be configured to return stale responses without
6337 validation, but only if this does not conflict with any "MUST"-level
6338 requirements concerning cache validation (e.g., a "must-revalidate"
6339 cache-control directive).
6341 If both the new request and the cached entry include "max-age"
6342 directives, then the lesser of the two values is used for determining
6343 the freshness of the cached entry for that request.
6345 14.9.4 Cache Revalidation and Reload Controls
6347 Sometimes a user agent might want or need to insist that a cache
6348 revalidate its cache entry with the origin server (and not just with
6349 the next cache along the path to the origin server), or to reload its
6350 cache entry from the origin server. End-to-end revalidation might be
6351 necessary if either the cache or the origin server has overestimated
6352 the expiration time of the cached response. End-to-end reload may be
6353 necessary if the cache entry has become corrupted for some reason.
6355 End-to-end revalidation may be requested either when the client does
6356 not have its own local cached copy, in which case we call it
6357 "unspecified end-to-end revalidation", or when the client does have a
6358 local cached copy, in which case we call it "specific end-to-end
6361 The client can specify these three kinds of action using Cache-
6362 Control request directives:
6365 The request includes a "no-cache" cache-control directive or, for
6366 compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
6367 names MUST NOT be included with the no-cache directive in a
6368 request. The server MUST NOT use a cached copy when responding to
6371 Specific end-to-end revalidation
6372 The request includes a "max-age=0" cache-control directive, which
6373 forces each cache along the path to the origin server to
6374 revalidate its own entry, if any, with the next cache or server.
6375 The initial request includes a cache-validating conditional with
6376 the client's current validator.
6378 Unspecified end-to-end revalidation
6379 The request includes "max-age=0" cache-control directive, which
6380 forces each cache along the path to the origin server to
6381 revalidate its own entry, if any, with the next cache or server.
6382 The initial request does not include a cache-validating
6387 Fielding, et al. Standards Track [Page 113]
6389 RFC 2616 HTTP/1.1 June 1999
6392 conditional; the first cache along the path (if any) that holds a
6393 cache entry for this resource includes a cache-validating
6394 conditional with its current validator.
6397 When an intermediate cache is forced, by means of a max-age=0
6398 directive, to revalidate its own cache entry, and the client has
6399 supplied its own validator in the request, the supplied validator
6400 might differ from the validator currently stored with the cache
6401 entry. In this case, the cache MAY use either validator in making
6402 its own request without affecting semantic transparency.
6404 However, the choice of validator might affect performance. The
6405 best approach is for the intermediate cache to use its own
6406 validator when making its request. If the server replies with 304
6407 (Not Modified), then the cache can return its now validated copy
6408 to the client with a 200 (OK) response. If the server replies with
6409 a new entity and cache validator, however, the intermediate cache
6410 can compare the returned validator with the one provided in the
6411 client's request, using the strong comparison function. If the
6412 client's validator is equal to the origin server's, then the
6413 intermediate cache simply returns 304 (Not Modified). Otherwise,
6414 it returns the new entity with a 200 (OK) response.
6416 If a request includes the no-cache directive, it SHOULD NOT
6417 include min-fresh, max-stale, or max-age.
6420 In some cases, such as times of extremely poor network
6421 connectivity, a client may want a cache to return only those
6422 responses that it currently has stored, and not to reload or
6423 revalidate with the origin server. To do this, the client may
6424 include the only-if-cached directive in a request. If it receives
6425 this directive, a cache SHOULD either respond using a cached entry
6426 that is consistent with the other constraints of the request, or
6427 respond with a 504 (Gateway Timeout) status. However, if a group
6428 of caches is being operated as a unified system with good internal
6429 connectivity, such a request MAY be forwarded within that group of
6433 Because a cache MAY be configured to ignore a server's specified
6434 expiration time, and because a client request MAY include a max-
6435 stale directive (which has a similar effect), the protocol also
6436 includes a mechanism for the origin server to require revalidation
6437 of a cache entry on any subsequent use. When the must-revalidate
6438 directive is present in a response received by a cache, that cache
6439 MUST NOT use the entry after it becomes stale to respond to a
6443 Fielding, et al. Standards Track [Page 114]
6445 RFC 2616 HTTP/1.1 June 1999
6448 subsequent request without first revalidating it with the origin
6449 server. (I.e., the cache MUST do an end-to-end revalidation every
6450 time, if, based solely on the origin server's Expires or max-age
6451 value, the cached response is stale.)
6453 The must-revalidate directive is necessary to support reliable
6454 operation for certain protocol features. In all circumstances an
6455 HTTP/1.1 cache MUST obey the must-revalidate directive; in
6456 particular, if the cache cannot reach the origin server for any
6457 reason, it MUST generate a 504 (Gateway Timeout) response.
6459 Servers SHOULD send the must-revalidate directive if and only if
6460 failure to revalidate a request on the entity could result in
6461 incorrect operation, such as a silently unexecuted financial
6462 transaction. Recipients MUST NOT take any automated action that
6463 violates this directive, and MUST NOT automatically provide an
6464 unvalidated copy of the entity if revalidation fails.
6466 Although this is not recommended, user agents operating under
6467 severe connectivity constraints MAY violate this directive but, if
6468 so, MUST explicitly warn the user that an unvalidated response has
6469 been provided. The warning MUST be provided on each unvalidated
6470 access, and SHOULD require explicit user confirmation.
6473 The proxy-revalidate directive has the same meaning as the must-
6474 revalidate directive, except that it does not apply to non-shared
6475 user agent caches. It can be used on a response to an
6476 authenticated request to permit the user's cache to store and
6477 later return the response without needing to revalidate it (since
6478 it has already been authenticated once by that user), while still
6479 requiring proxies that service many users to revalidate each time
6480 (in order to make sure that each user has been authenticated).
6481 Note that such authenticated responses also need the public cache
6482 control directive in order to allow them to be cached at all.
6484 14.9.5 No-Transform Directive
6487 Implementors of intermediate caches (proxies) have found it useful
6488 to convert the media type of certain entity bodies. A non-
6489 transparent proxy might, for example, convert between image
6490 formats in order to save cache space or to reduce the amount of
6491 traffic on a slow link.
6493 Serious operational problems occur, however, when these
6494 transformations are applied to entity bodies intended for certain
6495 kinds of applications. For example, applications for medical
6499 Fielding, et al. Standards Track [Page 115]
6501 RFC 2616 HTTP/1.1 June 1999
6504 imaging, scientific data analysis and those using end-to-end
6505 authentication, all depend on receiving an entity body that is bit
6506 for bit identical to the original entity-body.
6508 Therefore, if a message includes the no-transform directive, an
6509 intermediate cache or proxy MUST NOT change those headers that are
6510 listed in section 13.5.2 as being subject to the no-transform
6511 directive. This implies that the cache or proxy MUST NOT change
6512 any aspect of the entity-body that is specified by these headers,
6513 including the value of the entity-body itself.
6515 14.9.6 Cache Control Extensions
6517 The Cache-Control header field can be extended through the use of one
6518 or more cache-extension tokens, each with an optional assigned value.
6519 Informational extensions (those which do not require a change in
6520 cache behavior) MAY be added without changing the semantics of other
6521 directives. Behavioral extensions are designed to work by acting as
6522 modifiers to the existing base of cache directives. Both the new
6523 directive and the standard directive are supplied, such that
6524 applications which do not understand the new directive will default
6525 to the behavior specified by the standard directive, and those that
6526 understand the new directive will recognize it as modifying the
6527 requirements associated with the standard directive. In this way,
6528 extensions to the cache-control directives can be made without
6529 requiring changes to the base protocol.
6531 This extension mechanism depends on an HTTP cache obeying all of the
6532 cache-control directives defined for its native HTTP-version, obeying
6533 certain extensions, and ignoring all directives that it does not
6536 For example, consider a hypothetical new response directive called
6537 community which acts as a modifier to the private directive. We
6538 define this new directive to mean that, in addition to any non-shared
6539 cache, any cache which is shared only by members of the community
6540 named within its value may cache the response. An origin server
6541 wishing to allow the UCI community to use an otherwise private
6542 response in their shared cache(s) could do so by including
6544 Cache-Control: private, community="UCI"
6546 A cache seeing this header field will act correctly even if the cache
6547 does not understand the community cache-extension, since it will also
6548 see and understand the private directive and thus default to the safe
6555 Fielding, et al. Standards Track [Page 116]
6557 RFC 2616 HTTP/1.1 June 1999
6560 Unrecognized cache-directives MUST be ignored; it is assumed that any
6561 cache-directive likely to be unrecognized by an HTTP/1.1 cache will
6562 be combined with standard directives (or the response's default
6563 cacheability) such that the cache behavior will remain minimally
6564 correct even if the cache does not understand the extension(s).
6568 The Connection general-header field allows the sender to specify
6569 options that are desired for that particular connection and MUST NOT
6570 be communicated by proxies over further connections.
6572 The Connection header has the following grammar:
6574 Connection = "Connection" ":" 1#(connection-token)
6575 connection-token = token
6577 HTTP/1.1 proxies MUST parse the Connection header field before a
6578 message is forwarded and, for each connection-token in this field,
6579 remove any header field(s) from the message with the same name as the
6580 connection-token. Connection options are signaled by the presence of
6581 a connection-token in the Connection header field, not by any
6582 corresponding additional header field(s), since the additional header
6583 field may not be sent if there are no parameters associated with that
6586 Message headers listed in the Connection header MUST NOT include
6587 end-to-end headers, such as Cache-Control.
6589 HTTP/1.1 defines the "close" connection option for the sender to
6590 signal that the connection will be closed after completion of the
6591 response. For example,
6595 in either the request or the response header fields indicates that
6596 the connection SHOULD NOT be considered `persistent' (section 8.1)
6597 after the current request/response is complete.
6599 HTTP/1.1 applications that do not support persistent connections MUST
6600 include the "close" connection option in every message.
6603 [[ An HTTP/1.1 client that does not support persistent connections ]]
6604 [[ MUST include the "close" connection option in every request message. ]]
6606 [[ An HTTP/1.1 server that does not support persistent connections ]]
6607 [[ MUST include the "close" connection option in every response ]]
6608 [[ message that does not have a 1xx (informational) status code. ]]
6610 A system receiving an HTTP/1.0 (or lower-version) message that
6611 includes a Connection header MUST, for each connection-token in this
6612 field, remove and ignore any header field(s) from the message with
6613 the same name as the connection-token. This protects against mistaken
6614 forwarding of such header fields by pre-HTTP/1.1 proxies. See section
6619 Fielding, et al. Standards Track [Page 117]
6621 RFC 2616 HTTP/1.1 June 1999
6624 14.11 Content-Encoding
6626 The Content-Encoding entity-header field is used as a modifier to the
6627 media-type. When present, its value indicates what additional content
6628 codings have been applied to the entity-body, and thus what decoding
6629 mechanisms must be applied in order to obtain the media-type
6630 referenced by the Content-Type header field. Content-Encoding is
6631 primarily used to allow a document to be compressed without losing
6632 the identity of its underlying media type.
6634 Content-Encoding = "Content-Encoding" ":" 1#content-coding
6636 Content codings are defined in section 3.5. An example of its use is
6638 Content-Encoding: gzip
6640 The content-coding is a characteristic of the entity identified by
6641 the Request-URI. Typically, the entity-body is stored with this
6642 encoding and is only decoded before rendering or analogous usage.
6643 However, a non-transparent proxy MAY modify the content-coding if the
6644 new coding is known to be acceptable to the recipient, unless the
6645 "no-transform" cache-control directive is present in the message.
6647 If the content-coding of an entity is not "identity", then the
6648 response MUST include a Content-Encoding entity-header (section
6649 14.11) that lists the non-identity content-coding(s) used.
6651 If the content-coding of an entity in a request message is not
6652 acceptable to the origin server, the server SHOULD respond with a
6653 status code of 415 (Unsupported Media Type).
6655 If multiple encodings have been applied to an entity, the content
6656 codings MUST be listed in the order in which they were applied.
6657 Additional information about the encoding parameters MAY be provided
6658 by other entity-header fields not defined by this specification.
6660 14.12 Content-Language
6662 The Content-Language entity-header field describes the natural
6663 language(s) of the intended audience for the enclosed entity. Note
6664 that this might not be equivalent to all the languages used within
6667 Content-Language = "Content-Language" ":" 1#language-tag
6675 Fielding, et al. Standards Track [Page 118]
6677 RFC 2616 HTTP/1.1 June 1999
6680 Language tags are defined in section 3.10. The primary purpose of
6681 Content-Language is to allow a user to identify and differentiate
6682 entities according to the user's own preferred language. Thus, if the
6683 body content is intended only for a Danish-literate audience, the
6684 appropriate field is
6686 Content-Language: da
6688 If no Content-Language is specified, the default is that the content
6689 is intended for all language audiences. This might mean that the
6690 sender does not consider it to be specific to any natural language,
6691 or that the sender does not know for which language it is intended.
6693 Multiple languages MAY be listed for content that is intended for
6694 multiple audiences. For example, a rendition of the "Treaty of
6695 Waitangi," presented simultaneously in the original Maori and English
6696 versions, would call for
6698 Content-Language: mi, en
6700 However, just because multiple languages are present within an entity
6701 does not mean that it is intended for multiple linguistic audiences.
6702 An example would be a beginner's language primer, such as "A First
6703 Lesson in Latin," which is clearly intended to be used by an
6704 English-literate audience. In this case, the Content-Language would
6705 properly only include "en".
6707 Content-Language MAY be applied to any media type -- it is not
6708 limited to textual documents.
6710 14.13 Content-Length
6712 The Content-Length entity-header field indicates the size of the
6713 entity-body, in decimal number of OCTETs, sent to the recipient or,
6714 in the case of the HEAD method, the size of the entity-body that
6715 would have been sent had the request been a GET.
6717 Content-Length = "Content-Length" ":" 1*DIGIT
6721 Content-Length: 3495
6723 Applications SHOULD use this field to indicate the transfer-length of
6724 the message-body, unless this is prohibited by the rules in section
6731 Fielding, et al. Standards Track [Page 119]
6733 RFC 2616 HTTP/1.1 June 1999
6736 Any Content-Length greater than or equal to zero is a valid value.
6737 Section 4.4 describes how to determine the length of a message-body
6738 if a Content-Length is not given.
6740 Note that the meaning of this field is significantly different from
6741 the corresponding definition in MIME, where it is an optional field
6742 used within the "message/external-body" content-type. In HTTP, it
6743 SHOULD be sent whenever the message's length can be determined prior
6744 to being transferred, unless this is prohibited by the rules in
6747 14.14 Content-Location
6749 The Content-Location entity-header field MAY be used to supply the
6750 resource location for the entity enclosed in the message when that
6751 entity is accessible from a location separate from the requested
6752 resource's URI. A server SHOULD provide a Content-Location for the
6753 variant corresponding to the response entity; especially in the case
6754 where a resource has multiple entities associated with it, and those
6755 entities actually have separate locations by which they might be
6756 individually accessed, the server SHOULD provide a Content-Location
6757 for the particular variant which is returned.
6759 Content-Location = "Content-Location" ":"
6760 ( absoluteURI | relativeURI )
6762 The value of Content-Location also defines the base URI for the
6765 The Content-Location value is not a replacement for the original
6766 requested URI; it is only a statement of the location of the resource
6767 corresponding to this particular entity at the time of the request.
6768 Future requests MAY specify the Content-Location URI as the request-
6769 URI if the desire is to identify the source of that particular
6772 A cache cannot assume that an entity with a Content-Location
6773 different from the URI used to retrieve it can be used to respond to
6774 later requests on that Content-Location URI. However, the Content-
6775 Location can be used to differentiate between multiple entities
6776 retrieved from a single requested resource, as described in section
6779 If the Content-Location is a relative URI, the relative URI is
6780 interpreted relative to the Request-URI.
6782 The meaning of the Content-Location header in PUT or POST requests is
6783 undefined; servers are free to ignore it in those cases.
6787 Fielding, et al. Standards Track [Page 120]
6789 RFC 2616 HTTP/1.1 June 1999
6794 The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
6795 an MD5 digest of the entity-body for the purpose of providing an
6796 end-to-end message integrity check (MIC) of the entity-body. (Note: a
6797 MIC is good for detecting accidental modification of the entity-body
6798 in transit, but is not proof against malicious attacks.)
6800 Content-MD5 = "Content-MD5" ":" md5-digest
6801 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
6803 The Content-MD5 header field MAY be generated by an origin server or
6804 client to function as an integrity check of the entity-body. Only
6805 origin servers or clients MAY generate the Content-MD5 header field;
6806 proxies and gateways MUST NOT generate it, as this would defeat its
6807 value as an end-to-end integrity check. Any recipient of the entity-
6808 body, including gateways and proxies, MAY check that the digest value
6809 in this header field matches that of the entity-body as received.
6811 The MD5 digest is computed based on the content of the entity-body,
6812 including any content-coding that has been applied, but not including
6813 any transfer-encoding applied to the message-body. If the message is
6814 received with a transfer-encoding, that encoding MUST be removed
6815 prior to checking the Content-MD5 value against the received entity.
6817 This has the result that the digest is computed on the octets of the
6818 entity-body exactly as, and in the order that, they would be sent if
6819 no transfer-encoding were being applied.
6821 HTTP extends RFC 1864 to permit the digest to be computed for MIME
6822 composite media-types (e.g., multipart/* and message/rfc822), but
6823 this does not change how the digest is computed as defined in the
6824 preceding paragraph.
6826 There are several consequences of this. The entity-body for composite
6827 types MAY contain many body-parts, each with its own MIME and HTTP
6828 headers (including Content-MD5, Content-Transfer-Encoding, and
6829 Content-Encoding headers). If a body-part has a Content-Transfer-
6830 Encoding or Content-Encoding header, it is assumed that the content
6831 of the body-part has had the encoding applied, and the body-part is
6832 included in the Content-MD5 digest as is -- i.e., after the
6833 application. The Transfer-Encoding header field is not allowed within
6836 Conversion of all line breaks to CRLF MUST NOT be done before
6837 computing or checking the digest: the line break convention used in
6838 the text actually transmitted MUST be left unaltered when computing
6843 Fielding, et al. Standards Track [Page 121]
6845 RFC 2616 HTTP/1.1 June 1999
6848 Note: while the definition of Content-MD5 is exactly the same for
6849 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
6850 in which the application of Content-MD5 to HTTP entity-bodies
6851 differs from its application to MIME entity-bodies. One is that
6852 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
6853 does use Transfer-Encoding and Content-Encoding. Another is that
6854 HTTP more frequently uses binary content types than MIME, so it is
6855 worth noting that, in such cases, the byte order used to compute
6856 the digest is the transmission byte order defined for the type.
6857 Lastly, HTTP allows transmission of text types with any of several
6858 line break conventions and not just the canonical form using CRLF.
6862 The Content-Range entity-header is sent with a partial entity-body to
6863 specify where in the full entity-body the partial body should be
6864 applied. Range units are defined in section 3.12.
6866 Content-Range = "Content-Range" ":" content-range-spec
6868 content-range-spec = byte-content-range-spec
6869 byte-content-range-spec = bytes-unit SP
6870 byte-range-resp-spec "/"
6871 ( instance-length | "*" )
6873 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
6875 instance-length = 1*DIGIT
6877 The header SHOULD indicate the total length of the full entity-body,
6878 unless this length is unknown or difficult to determine. The asterisk
6879 "*" character means that the instance-length is unknown at the time
6880 when the response was generated.
6882 Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
6883 range-resp-spec MUST only specify one range, and MUST contain
6884 absolute byte positions for both the first and last byte of the
6887 A byte-content-range-spec with a byte-range-resp-spec whose last-
6888 byte-pos value is less than its first-byte-pos value, or whose
6889 instance-length value is less than or equal to its last-byte-pos
6890 value, is invalid. The recipient of an invalid byte-content-range-
6891 spec MUST ignore it and any content transferred along with it.
6893 A server sending a response with status code 416 (Requested range not
6894 satisfiable) SHOULD include a Content-Range field with a byte-range-
6895 resp-spec of "*". The instance-length specifies the current length of
6899 Fielding, et al. Standards Track [Page 122]
6901 RFC 2616 HTTP/1.1 June 1999
6904 the selected resource. A response with status code 206 (Partial
6905 Content) MUST NOT include a Content-Range field with a byte-range-
6908 Examples of byte-content-range-spec values, assuming that the entity
6909 contains a total of 1234 bytes:
6911 . The first 500 bytes:
6914 . The second 500 bytes:
6917 . All except for the first 500 bytes:
6920 . The last 500 bytes:
6923 When an HTTP message includes the content of a single range (for
6924 example, a response to a request for a single range, or to a request
6925 for a set of ranges that overlap without any holes), this content is
6926 transmitted with a Content-Range header, and a Content-Length header
6927 showing the number of bytes actually transferred. For example,
6929 HTTP/1.1 206 Partial content
6930 Date: Wed, 15 Nov 1995 06:25:24 GMT
6931 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
6932 Content-Range: bytes 21010-47021/47022
6933 Content-Length: 26012
6934 Content-Type: image/gif
6936 When an HTTP message includes the content of multiple ranges (for
6937 example, a response to a request for multiple non-overlapping
6938 ranges), these are transmitted as a multipart message. The multipart
6939 media type used for this purpose is "multipart/byteranges" as defined
6940 in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
6942 A response to a request for a single range MUST NOT be sent using the
6943 multipart/byteranges media type. A response to a request for
6944 multiple ranges, whose result is a single range, MAY be sent as a
6945 multipart/byteranges media type with one part. A client that cannot
6946 decode a multipart/byteranges message MUST NOT ask for multiple
6947 byte-ranges in a single request.
6949 When a client requests multiple byte-ranges in one request, the
6950 server SHOULD return them in the order that they appeared in the
6955 Fielding, et al. Standards Track [Page 123]
6957 RFC 2616 HTTP/1.1 June 1999
6960 If the server ignores a byte-range-spec because it is syntactically
6961 invalid, the server SHOULD treat the request as if the invalid Range
6962 header field did not exist. (Normally, this means return a 200
6963 response containing the full entity).
6965 If the server receives a request (other than one including an If-
6966 Range request-header field) with an unsatisfiable Range request-
6967 header field (that is, all of whose byte-range-spec values have a
6968 first-byte-pos value greater than the current length of the selected
6969 resource), it SHOULD return a response code of 416 (Requested range
6970 not satisfiable) (section 10.4.17).
6972 Note: clients cannot depend on servers to send a 416 (Requested
6973 range not satisfiable) response instead of a 200 (OK) response for
6974 an unsatisfiable Range request-header, since not all servers
6975 implement this request-header.
6979 The Content-Type entity-header field indicates the media type of the
6980 entity-body sent to the recipient or, in the case of the HEAD method,
6981 the media type that would have been sent had the request been a GET.
6983 Content-Type = "Content-Type" ":" media-type
6985 Media types are defined in section 3.7. An example of the field is
6987 Content-Type: text/html; charset=ISO-8859-4
6989 Further discussion of methods for identifying the media type of an
6990 entity is provided in section 7.2.1.
6994 The Date general-header field represents the date and time at which
6995 the message was originated, having the same semantics as orig-date in
6996 RFC 822. The field value is an HTTP-date, as described in section
6997 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
6999 Date = "Date" ":" HTTP-date
7003 Date: Tue, 15 Nov 1994 08:12:31 GMT
7005 Origin servers MUST include a Date header field in all responses,
7006 except in these cases:
7011 Fielding, et al. Standards Track [Page 124]
7013 RFC 2616 HTTP/1.1 June 1999
7016 1. If the response status code is 100 (Continue) or 101 (Switching
7017 Protocols), the response MAY include a Date header field, at
7018 the server's option.
7020 2. If the response status code conveys a server error, e.g. 500
7021 (Internal Server Error) or 503 (Service Unavailable), and it is
7022 inconvenient or impossible to generate a valid Date.
7024 3. If the server does not have a clock that can provide a
7025 reasonable approximation of the current time, its responses
7026 MUST NOT include a Date header field. In this case, the rules
7027 in section 14.18.1 MUST be followed.
7029 A received message that does not have a Date header field MUST be
7030 assigned one by the recipient if the message will be cached by that
7031 recipient or gatewayed via a protocol which requires a Date. An HTTP
7032 implementation without a clock MUST NOT cache responses without
7033 revalidating them on every use. An HTTP cache, especially a shared
7034 cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
7035 clock with a reliable external standard.
7037 Clients SHOULD only send a Date header field in messages that include
7038 an entity-body, as in the case of the PUT and POST requests, and even
7039 then it is optional. A client without a clock MUST NOT send a Date
7040 header field in a request.
7042 The HTTP-date sent in a Date header SHOULD NOT represent a date and
7043 time subsequent to the generation of the message. It SHOULD represent
7044 the best available approximation of the date and time of message
7045 generation, unless the implementation has no means of generating a
7046 reasonably accurate date and time. In theory, the date ought to
7047 represent the moment just before the entity is generated. In
7048 practice, the date can be generated at any time during the message
7049 origination without affecting its semantic value.
7051 14.18.1 Clockless Origin Server Operation
7053 Some origin server implementations might not have a clock available.
7054 An origin server without a clock MUST NOT assign Expires or Last-
7055 Modified values to a response, unless these values were associated
7056 with the resource by a system or user with a reliable clock. It MAY
7057 assign an Expires value that is known, at or before server
7058 configuration time, to be in the past (this allows "pre-expiration"
7059 of responses without storing separate Expires values for each
7067 Fielding, et al. Standards Track [Page 125]
7069 RFC 2616 HTTP/1.1 June 1999
7074 The ETag response-header field provides the current value of the
7075 entity tag for the requested variant. The headers used with entity
7076 tags are described in sections 14.24, 14.26 and 14.44. The entity tag
7077 MAY be used for comparison with other entities from the same resource
7078 (see section 13.3.3).
7080 ETag = "ETag" ":" entity-tag
7090 The Expect request-header field is used to indicate that particular
7091 server behaviors are required by the client.
7093 Expect = "Expect" ":" 1#expectation
7095 expectation = "100-continue" | expectation-extension
7096 expectation-extension = token [ "=" ( token | quoted-string )
7098 expect-params = ";" token [ "=" ( token | quoted-string ) ]
7101 A server that does not understand or is unable to comply with any of
7102 the expectation values in the Expect field of a request MUST respond
7103 with appropriate error status. The server MUST respond with a 417
7104 (Expectation Failed) status if any of the expectations cannot be met
7105 or, if there are other problems with the request, some other 4xx
7108 This header field is defined with extensible syntax to allow for
7109 future extensions. If a server receives a request containing an
7110 Expect field that includes an expectation-extension that it does not
7111 support, it MUST respond with a 417 (Expectation Failed) status.
7113 Comparison of expectation values is case-insensitive for unquoted
7114 tokens (including the 100-continue token), and is case-sensitive for
7115 quoted-string expectation-extensions.
7123 Fielding, et al. Standards Track [Page 126]
7125 RFC 2616 HTTP/1.1 June 1999
7128 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
7129 return a 417 (Expectation Failed) status if it receives a request
7130 with an expectation that it cannot meet. However, the Expect
7131 request-header itself is end-to-end; it MUST be forwarded if the
7132 request is forwarded.
7134 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
7137 See section 8.2.3 for the use of the 100 (continue) status.
7141 The Expires entity-header field gives the date/time after which the
7142 response is considered stale. A stale cache entry may not normally be
7143 returned by a cache (either a proxy cache or a user agent cache)
7144 unless it is first validated with the origin server (or with an
7145 intermediate cache that has a fresh copy of the entity). See section
7146 13.2 for further discussion of the expiration model.
7148 The presence of an Expires field does not imply that the original
7149 resource will change or cease to exist at, before, or after that
7152 The format is an absolute date and time as defined by HTTP-date in
7153 section 3.3.1; it MUST be in RFC 1123 date format:
7155 Expires = "Expires" ":" HTTP-date
7157 An example of its use is
7159 Expires: Thu, 01 Dec 1994 16:00:00 GMT
7161 Note: if a response includes a Cache-Control field with the max-
7162 age directive (see section 14.9.3), that directive overrides the
7165 HTTP/1.1 clients and caches MUST treat other invalid date formats,
7166 especially including the value "0", as in the past (i.e., "already
7169 To mark a response as "already expired," an origin server sends an
7170 Expires date that is equal to the Date header value. (See the rules
7171 for expiration calculations in section 13.2.4.)
7179 Fielding, et al. Standards Track [Page 127]
7181 RFC 2616 HTTP/1.1 June 1999
7184 To mark a response as "never expires," an origin server sends an
7185 Expires date approximately one year from the time the response is
7186 sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
7189 The presence of an Expires header field with a date value of some
7190 time in the future on a response that otherwise would by default be
7191 non-cacheable indicates that the response is cacheable, unless
7192 indicated otherwise by a Cache-Control header field (section 14.9).
7196 The From request-header field, if given, SHOULD contain an Internet
7197 e-mail address for the human user who controls the requesting user
7198 agent. The address SHOULD be machine-usable, as defined by "mailbox"
7199 in RFC 822 [9] as updated by RFC 1123 [8]:
7201 From = "From" ":" mailbox
7205 From: webmaster@w3.org
7207 This header field MAY be used for logging purposes and as a means for
7208 identifying the source of invalid or unwanted requests. It SHOULD NOT
7209 be used as an insecure form of access protection. The interpretation
7210 of this field is that the request is being performed on behalf of the
7211 person given, who accepts responsibility for the method performed. In
7212 particular, robot agents SHOULD include this header so that the
7213 person responsible for running the robot can be contacted if problems
7214 occur on the receiving end.
7216 The Internet e-mail address in this field MAY be separate from the
7217 Internet host which issued the request. For example, when a request
7218 is passed through a proxy the original issuer's address SHOULD be
7221 The client SHOULD NOT send the From header field without the user's
7222 approval, as it might conflict with the user's privacy interests or
7223 their site's security policy. It is strongly recommended that the
7224 user be able to disable, enable, and modify the value of this field
7225 at any time prior to a request.
7229 The Host request-header field specifies the Internet host and port
7230 number of the resource being requested, as obtained from the original
7231 URI given by the user or referring resource (generally an HTTP URL,
7235 Fielding, et al. Standards Track [Page 128]
7237 RFC 2616 HTTP/1.1 June 1999
7240 as described in section 3.2.2). The Host field value MUST represent
7241 the naming authority of the origin server or gateway given by the
7242 original URL. This allows the origin server or gateway to
7243 differentiate between internally-ambiguous URLs, such as the root "/"
7244 URL of a server for multiple host names on a single IP address.
7246 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
7248 A "host" without any trailing port information implies the default
7249 port for the service requested (e.g., "80" for an HTTP URL). For
7250 example, a request on the origin server for
7251 <http://www.w3.org/pub/WWW/> would properly include:
7253 GET /pub/WWW/ HTTP/1.1
7256 A client MUST include a Host header field in all HTTP/1.1 request
7257 messages . If the requested URI does not include an Internet host
7258 name for the service being requested, then the Host header field MUST
7259 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
7260 request message it forwards does contain an appropriate Host header
7261 field that identifies the service being requested by the proxy. All
7262 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
7263 status code to any HTTP/1.1 request message which lacks a Host header
7266 See sections 5.2 and 19.6.1.1 for other requirements relating to
7271 The If-Match request-header field is used with a method to make it
7272 conditional. A client that has one or more entities previously
7273 obtained from the resource can verify that one of those entities is
7274 current by including a list of their associated entity tags in the
7275 If-Match header field. Entity tags are defined in section 3.11. The
7276 purpose of this feature is to allow efficient updates of cached
7277 information with a minimum amount of transaction overhead. It is also
7278 used, on updating requests, to prevent inadvertent modification of
7279 the wrong version of a resource. As a special case, the value "*"
7280 matches any current entity of the resource.
7282 If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
7284 If any of the entity tags match the entity tag of the entity that
7285 would have been returned in the response to a similar GET request
7286 (without the If-Match header) on that resource, or if "*" is given
7291 Fielding, et al. Standards Track [Page 129]
7293 RFC 2616 HTTP/1.1 June 1999
7296 and any current entity exists for that resource, then the server MAY
7297 perform the requested method as if the If-Match header field did not
7300 A server MUST use the strong comparison function (see section 13.3.3)
7301 to compare the entity tags in If-Match.
7303 If none of the entity tags match, or if "*" is given and no current
7304 entity exists, the server MUST NOT perform the requested method, and
7305 MUST return a 412 (Precondition Failed) response. This behavior is
7306 most useful when the client wants to prevent an updating method, such
7307 as PUT, from modifying a resource that has changed since the client
7310 If the request would, without the If-Match header field, result in
7311 anything other than a 2xx or 412 status, then the If-Match header
7314 The meaning of "If-Match: *" is that the method SHOULD be performed
7315 if the representation selected by the origin server (or by a cache,
7316 possibly using the Vary mechanism, see section 14.44) exists, and
7317 MUST NOT be performed if the representation does not exist.
7319 A request intended to update a resource (e.g., a PUT) MAY include an
7320 If-Match header field to signal that the request method MUST NOT be
7321 applied if the entity corresponding to the If-Match value (a single
7322 entity tag) is no longer a representation of that resource. This
7323 allows the user to indicate that they do not wish the request to be
7324 successful if the resource has been changed without their knowledge.
7328 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
7331 The result of a request having both an If-Match header field and
7332 either an If-None-Match or an If-Modified-Since header fields is
7333 undefined by this specification.
7335 14.25 If-Modified-Since
7337 The If-Modified-Since request-header field is used with a method to
7338 make it conditional: if the requested variant has not been modified
7339 since the time specified in this field, an entity will not be
7340 returned from the server; instead, a 304 (not modified) response will
7341 be returned without any message-body.
7343 If-Modified-Since = "If-Modified-Since" ":" HTTP-date
7347 Fielding, et al. Standards Track [Page 130]
7349 RFC 2616 HTTP/1.1 June 1999
7352 An example of the field is:
7354 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
7356 A GET method with an If-Modified-Since header and no Range header
7357 requests that the identified entity be transferred only if it has
7358 been modified since the date given by the If-Modified-Since header.
7359 The algorithm for determining this includes the following cases:
7361 a) If the request would normally result in anything other than a
7362 200 (OK) status, or if the passed If-Modified-Since date is
7363 invalid, the response is exactly the same as for a normal GET.
7364 A date which is later than the server's current time is
7367 b) If the variant has been modified since the If-Modified-Since
7368 date, the response is exactly the same as for a normal GET.
7370 c) If the variant has not been modified since a valid If-
7371 Modified-Since date, the server SHOULD return a 304 (Not
7374 The purpose of this feature is to allow efficient updates of cached
7375 information with a minimum amount of transaction overhead.
7377 Note: The Range request-header field modifies the meaning of If-
7378 Modified-Since; see section 14.35 for full details.
7380 Note: If-Modified-Since times are interpreted by the server, whose
7381 clock might not be synchronized with the client.
7383 Note: When handling an If-Modified-Since header field, some
7384 servers will use an exact date comparison function, rather than a
7385 less-than function, for deciding whether to send a 304 (Not
7386 Modified) response. To get best results when sending an If-
7387 Modified-Since header field for cache validation, clients are
7388 advised to use the exact date string received in a previous Last-
7389 Modified header field whenever possible.
7391 Note: If a client uses an arbitrary date in the If-Modified-Since
7392 header instead of a date taken from the Last-Modified header for
7393 the same request, the client should be aware of the fact that this
7394 date is interpreted in the server's understanding of time. The
7395 client should consider unsynchronized clocks and rounding problems
7396 due to the different encodings of time between the client and
7397 server. This includes the possibility of race conditions if the
7398 document has changed between the time it was first requested and
7399 the If-Modified-Since date of a subsequent request, and the
7403 Fielding, et al. Standards Track [Page 131]
7405 RFC 2616 HTTP/1.1 June 1999
7408 possibility of clock-skew-related problems if the If-Modified-
7409 Since date is derived from the client's clock without correction
7410 to the server's clock. Corrections for different time bases
7411 between client and server are at best approximate due to network
7414 The result of a request having both an If-Modified-Since header field
7415 and either an If-Match or an If-Unmodified-Since header fields is
7416 undefined by this specification.
7420 The If-None-Match request-header field is used with a method to make
7421 it conditional. A client that has one or more entities previously
7422 obtained from the resource can verify that none of those entities is
7423 current by including a list of their associated entity tags in the
7424 If-None-Match header field. The purpose of this feature is to allow
7425 efficient updates of cached information with a minimum amount of
7426 transaction overhead. It is also used to prevent a method (e.g. PUT)
7427 from inadvertently modifying an existing resource when the client
7428 believes that the resource does not exist.
7430 As a special case, the value "*" matches any current entity of the
7433 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
7435 If any of the entity tags match the entity tag of the entity that
7436 would have been returned in the response to a similar GET request
7437 (without the If-None-Match header) on that resource, or if "*" is
7438 given and any current entity exists for that resource, then the
7439 server MUST NOT perform the requested method, unless required to do
7440 so because the resource's modification date fails to match that
7441 supplied in an If-Modified-Since header field in the request.
7442 Instead, if the request method was GET or HEAD, the server SHOULD
7443 respond with a 304 (Not Modified) response, including the cache-
7444 related header fields (particularly ETag) of one of the entities that
7445 matched. For all other request methods, the server MUST respond with
7446 a status of 412 (Precondition Failed).
7448 See section 13.3.3 for rules on how to determine if two entities tags
7449 match. The weak comparison function can only be used with GET or HEAD
7459 Fielding, et al. Standards Track [Page 132]
7461 RFC 2616 HTTP/1.1 June 1999
7464 If none of the entity tags match, then the server MAY perform the
7465 requested method as if the If-None-Match header field did not exist,
7466 but MUST also ignore any If-Modified-Since header field(s) in the
7467 request. That is, if no entity tags match, then the server MUST NOT
7468 return a 304 (Not Modified) response.
7470 If the request would, without the If-None-Match header field, result
7471 in anything other than a 2xx or 304 status, then the If-None-Match
7472 header MUST be ignored. (See section 13.3.4 for a discussion of
7473 server behavior when both If-Modified-Since and If-None-Match appear
7474 in the same request.)
7476 The meaning of "If-None-Match: *" is that the method MUST NOT be
7477 performed if the representation selected by the origin server (or by
7478 a cache, possibly using the Vary mechanism, see section 14.44)
7479 exists, and SHOULD be performed if the representation does not exist.
7480 This feature is intended to be useful in preventing races between PUT
7485 If-None-Match: "xyzzy"
7486 If-None-Match: W/"xyzzy"
7487 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
7488 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
7491 The result of a request having both an If-None-Match header field and
7492 either an If-Match or an If-Unmodified-Since header fields is
7493 undefined by this specification.
7497 If a client has a partial copy of an entity in its cache, and wishes
7498 to have an up-to-date copy of the entire entity in its cache, it
7499 could use the Range request-header with a conditional GET (using
7500 either or both of If-Unmodified-Since and If-Match.) However, if the
7501 condition fails because the entity has been modified, the client
7502 would then have to make a second request to obtain the entire current
7505 The If-Range header allows a client to "short-circuit" the second
7506 request. Informally, its meaning is `if the entity is unchanged, send
7507 me the part(s) that I am missing; otherwise, send me the entire new
7510 If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
7515 Fielding, et al. Standards Track [Page 133]
7517 RFC 2616 HTTP/1.1 June 1999
7520 If the client has no entity tag for an entity, but does have a Last-
7521 Modified date, it MAY use that date in an If-Range header. (The
7522 server can distinguish between a valid HTTP-date and any form of
7523 entity-tag by examining no more than two characters.) The If-Range
7524 header SHOULD only be used together with a Range header, and MUST be
7525 ignored if the request does not include a Range header, or if the
7526 server does not support the sub-range operation.
7528 If the entity tag given in the If-Range header matches the current
7529 entity tag for the entity, then the server SHOULD provide the
7530 specified sub-range of the entity using a 206 (Partial content)
7531 response. If the entity tag does not match, then the server SHOULD
7532 return the entire entity using a 200 (OK) response.
7534 14.28 If-Unmodified-Since
7536 The If-Unmodified-Since request-header field is used with a method to
7537 make it conditional. If the requested resource has not been modified
7538 since the time specified in this field, the server SHOULD perform the
7539 requested operation as if the If-Unmodified-Since header were not
7542 If the requested variant has been modified since the specified time,
7543 the server MUST NOT perform the requested operation, and MUST return
7544 a 412 (Precondition Failed).
7546 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
7548 An example of the field is:
7550 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
7552 If the request normally (i.e., without the If-Unmodified-Since
7553 header) would result in anything other than a 2xx or 412 status, the
7554 If-Unmodified-Since header SHOULD be ignored.
7556 If the specified date is invalid, the header is ignored.
7558 The result of a request having both an If-Unmodified-Since header
7559 field and either an If-None-Match or an If-Modified-Since header
7560 fields is undefined by this specification.
7564 The Last-Modified entity-header field indicates the date and time at
7565 which the origin server believes the variant was last modified.
7567 Last-Modified = "Last-Modified" ":" HTTP-date
7571 Fielding, et al. Standards Track [Page 134]
7573 RFC 2616 HTTP/1.1 June 1999
7576 An example of its use is
7578 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
7580 The exact meaning of this header field depends on the implementation
7581 of the origin server and the nature of the original resource. For
7582 files, it may be just the file system last-modified time. For
7583 entities with dynamically included parts, it may be the most recent
7584 of the set of last-modify times for its component parts. For database
7585 gateways, it may be the last-update time stamp of the record. For
7586 virtual objects, it may be the last time the internal state changed.
7588 An origin server MUST NOT send a Last-Modified date which is later
7589 than the server's time of message origination. In such cases, where
7590 the resource's last modification would indicate some time in the
7591 future, the server MUST replace that date with the message
7594 An origin server SHOULD obtain the Last-Modified value of the entity
7595 as close as possible to the time that it generates the Date value of
7596 its response. This allows a recipient to make an accurate assessment
7597 of the entity's modification time, especially if the entity changes
7598 near the time that the response is generated.
7600 HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
7604 The Location response-header field is used to redirect the recipient
7605 to a location other than the Request-URI for completion of the
7606 request or identification of a new resource. For 201 (Created)
7607 responses, the Location is that of the new resource which was created
7608 by the request. For 3xx responses, the location SHOULD indicate the
7609 server's preferred URI for automatic redirection to the resource. The
7610 field value consists of a single absolute URI.
7612 Location = "Location" ":" absoluteURI
7613 [[ [ "#" fragment ] ]]
7617 Location: http://www.w3.org/pub/WWW/People.html
7619 Note: The Content-Location header field (section 14.14) differs
7620 from Location in that the Content-Location identifies the original
7621 location of the entity enclosed in the request. It is therefore
7622 possible for a response to contain header fields for both Location
7623 and Content-Location. Also see section 13.10 for cache
7624 requirements of some methods.
7628 Fielding, et al. Standards Track [Page 135]
7630 RFC 2616 HTTP/1.1 June 1999
7635 The Max-Forwards request-header field provides a mechanism with the
7636 TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
7637 number of proxies or gateways that can forward the request to the
7638 next inbound server. This can be useful when the client is attempting
7639 to trace a request chain which appears to be failing or looping in
7642 Max-Forwards = "Max-Forwards" ":" 1*DIGIT
7644 The Max-Forwards value is a decimal integer indicating the remaining
7645 number of times this request message may be forwarded.
7647 Each proxy or gateway recipient of a TRACE or OPTIONS request
7648 containing a Max-Forwards header field MUST check and update its
7649 value prior to forwarding the request. If the received value is zero
7650 (0), the recipient MUST NOT forward the request; instead, it MUST
7651 respond as the final recipient. If the received Max-Forwards value is
7652 greater than zero, then the forwarded message MUST contain an updated
7653 Max-Forwards field with a value decremented by one (1).
7655 The Max-Forwards header field MAY be ignored for all other methods
7656 defined by this specification and for any extension methods for which
7657 it is not explicitly referred to as part of that method definition.
7661 The Pragma general-header field is used to include implementation-
7662 specific directives that might apply to any recipient along the
7663 request/response chain. All pragma directives specify optional
7664 behavior from the viewpoint of the protocol; however, some systems
7665 MAY require that behavior be consistent with the directives.
7667 Pragma = "Pragma" ":" 1#pragma-directive
7668 pragma-directive = "no-cache" | extension-pragma
7669 extension-pragma = token [ "=" ( token | quoted-string ) ]
7671 When the no-cache directive is present in a request message, an
7672 application SHOULD forward the request toward the origin server even
7673 if it has a cached copy of what is being requested. This pragma
7674 directive has the same semantics as the no-cache cache-directive (see
7675 section 14.9) and is defined here for backward compatibility with
7676 HTTP/1.0. Clients SHOULD include both header fields when a no-cache
7677 request is sent to a server not known to be HTTP/1.1 compliant.
7684 Fielding, et al. Standards Track [Page 136]
7686 RFC 2616 HTTP/1.1 June 1999
7689 Pragma directives MUST be passed through by a proxy or gateway
7690 application, regardless of their significance to that application,
7691 since the directives might be applicable to all recipients along the
7692 request/response chain. It is not possible to specify a pragma for a
7693 specific recipient; however, any pragma directive not relevant to a
7694 recipient SHOULD be ignored by that recipient.
7696 HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
7697 sent "Cache-Control: no-cache". No new Pragma directives will be
7700 Note: because the meaning of "Pragma: no-cache as a response
7701 header field is not actually specified, it does not provide a
7702 reliable replacement for "Cache-Control: no-cache" in a response
7704 14.33 Proxy-Authenticate
7706 The Proxy-Authenticate response-header field MUST be included as part
7707 of a 407 (Proxy Authentication Required) response. The field value
7708 consists of a challenge that indicates the authentication scheme and
7709 parameters applicable to the proxy for this Request-URI.
7711 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
7713 The HTTP access authentication process is described in "HTTP
7714 Authentication: Basic and Digest Access Authentication" [43]. Unlike
7715 WWW-Authenticate, the Proxy-Authenticate header field applies only to
7716 the current connection and SHOULD NOT be passed on to downstream
7717 clients. However, an intermediate proxy might need to obtain its own
7718 credentials by requesting them from the downstream client, which in
7719 some circumstances will appear as if the proxy is forwarding the
7720 Proxy-Authenticate header field.
7722 14.34 Proxy-Authorization
7724 The Proxy-Authorization request-header field allows the client to
7725 identify itself (or its user) to a proxy which requires
7726 authentication. The Proxy-Authorization field value consists of
7727 credentials containing the authentication information of the user
7728 agent for the proxy and/or realm of the resource being requested.
7730 Proxy-Authorization = "Proxy-Authorization" ":" credentials
7732 The HTTP access authentication process is described in "HTTP
7733 Authentication: Basic and Digest Access Authentication" [43] . Unlike
7734 Authorization, the Proxy-Authorization header field applies only to
7735 the next outbound proxy that demanded authentication using the Proxy-
7736 Authenticate field. When multiple proxies are used in a chain, the
7740 Fielding, et al. Standards Track [Page 137]
7742 RFC 2616 HTTP/1.1 June 1999
7745 Proxy-Authorization header field is consumed by the first outbound
7746 proxy that was expecting to receive credentials. A proxy MAY relay
7747 the credentials from the client request to the next proxy if that is
7748 the mechanism by which the proxies cooperatively authenticate a given
7755 Since all HTTP entities are represented in HTTP messages as sequences
7756 of bytes, the concept of a byte range is meaningful for any HTTP
7757 entity. (However, not all clients and servers need to support byte-
7760 Byte range specifications in HTTP apply to the sequence of bytes in
7761 the entity-body (not necessarily the same as the message-body).
7763 A byte range operation MAY specify a single range of bytes, or a set
7764 of ranges within a single entity.
7766 ranges-specifier = byte-ranges-specifier
7767 byte-ranges-specifier = bytes-unit "=" byte-range-set
7768 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
7769 byte-range-spec = first-byte-pos "-" [last-byte-pos]
7770 first-byte-pos = 1*DIGIT
7771 last-byte-pos = 1*DIGIT
7773 The first-byte-pos value in a byte-range-spec gives the byte-offset
7774 of the first byte in a range. The last-byte-pos value gives the
7775 byte-offset of the last byte in the range; that is, the byte
7776 positions specified are inclusive. Byte offsets start at zero.
7778 If the last-byte-pos value is present, it MUST be greater than or
7779 equal to the first-byte-pos in that byte-range-spec, or the byte-
7780 range-spec is syntactically invalid. The recipient of a byte-range-
7781 set that includes one or more syntactically invalid byte-range-spec
7782 values MUST ignore the header field that includes that byte-range-
7785 If the last-byte-pos value is absent, or if the value is greater than
7786 or equal to the current length of the entity-body, last-byte-pos is
7787 taken to be equal to one less than the current length of the entity-
7790 By its choice of last-byte-pos, a client can limit the number of
7791 bytes retrieved without knowing the size of the entity.
7796 Fielding, et al. Standards Track [Page 138]
7798 RFC 2616 HTTP/1.1 June 1999
7801 suffix-byte-range-spec = "-" suffix-length
7802 suffix-length = 1*DIGIT
7804 A suffix-byte-range-spec is used to specify the suffix of the
7805 entity-body, of a length given by the suffix-length value. (That is,
7806 this form specifies the last N bytes of an entity-body.) If the
7807 entity is shorter than the specified suffix-length, the entire
7808 entity-body is used.
7810 If a syntactically valid byte-range-set includes at least one byte-
7811 range-spec whose first-byte-pos is less than the current length of
7812 the entity-body, or at least one suffix-byte-range-spec with a non-
7813 zero suffix-length, then the byte-range-set is satisfiable.
7814 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
7815 is unsatisfiable, the server SHOULD return a response with a status
7816 of 416 (Requested range not satisfiable). Otherwise, the server
7817 SHOULD return a response with a status of 206 (Partial Content)
7818 containing the satisfiable ranges of the entity-body.
7820 Examples of byte-ranges-specifier values (assuming an entity-body of
7823 - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
7826 - The second 500 bytes (byte offsets 500-999, inclusive):
7829 - The final 500 bytes (byte offsets 9500-9999, inclusive):
7834 - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
7836 - Several legal but not canonical specifications of the second 500
7837 bytes (byte offsets 500-999, inclusive):
7838 bytes=500-600,601-999
7839 bytes=500-700,601-999
7841 14.35.2 Range Retrieval Requests
7843 HTTP retrieval requests using conditional or unconditional GET
7844 methods MAY request one or more sub-ranges of the entity, instead of
7845 the entire entity, using the Range request header, which applies to
7846 the entity returned as the result of the request:
7848 Range = "Range" ":" ranges-specifier
7852 Fielding, et al. Standards Track [Page 139]
7854 RFC 2616 HTTP/1.1 June 1999
7857 A server MAY ignore the Range header. However, HTTP/1.1 origin
7858 servers and intermediate caches ought to support byte ranges when
7859 possible, since Range supports efficient recovery from partially
7860 failed transfers, and supports efficient partial retrieval of large
7863 If the server supports the Range header and the specified range or
7864 ranges are appropriate for the entity:
7866 - The presence of a Range header in an unconditional GET modifies
7867 what is returned if the GET is otherwise successful. In other
7868 words, the response carries a status code of 206 (Partial
7869 Content) instead of 200 (OK).
7871 - The presence of a Range header in a conditional GET (a request
7872 using one or both of If-Modified-Since and If-None-Match, or
7873 one or both of If-Unmodified-Since and If-Match) modifies what
7874 is returned if the GET is otherwise successful and the
7875 condition is true. It does not affect the 304 (Not Modified)
7876 response returned if the conditional is false.
7878 In some cases, it might be more appropriate to use the If-Range
7879 header (see section 14.27) in addition to the Range header.
7881 If a proxy that supports ranges receives a Range request, forwards
7882 the request to an inbound server, and receives an entire entity in
7883 reply, it SHOULD only return the requested range to its client. It
7884 SHOULD store the entire received response in its cache if that is
7885 consistent with its cache allocation policies.
7889 The Referer[sic] request-header field allows the client to specify,
7890 for the server's benefit, the address (URI) of the resource from
7891 which the Request-URI was obtained (the "referrer", although the
7892 header field is misspelled.) The Referer request-header allows a
7893 server to generate lists of back-links to resources for interest,
7894 logging, optimized caching, etc. It also allows obsolete or mistyped
7895 links to be traced for maintenance. The Referer field MUST NOT be
7896 sent if the Request-URI was obtained from a source that does not have
7897 its own URI, such as input from the user keyboard.
7899 Referer = "Referer" ":" ( absoluteURI | relativeURI )
7903 Referer: http://www.w3.org/hypertext/DataSources/Overview.html
7908 Fielding, et al. Standards Track [Page 140]
7910 RFC 2616 HTTP/1.1 June 1999
7913 If the field value is a relative URI, it SHOULD be interpreted
7914 relative to the Request-URI. The URI MUST NOT include a fragment. See
7915 section 15.1.3 for security considerations.
7919 The Retry-After response-header field can be used with a 503 (Service
7920 Unavailable) response to indicate how long the service is expected to
7921 be unavailable to the requesting client. This field MAY also be used
7922 with any 3xx (Redirection) response to indicate the minimum time the
7923 user-agent is asked wait before issuing the redirected request. The
7924 value of this field can be either an HTTP-date or an integer number
7925 of seconds (in decimal) after the time of the response.
7927 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
7929 Two examples of its use are
7931 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
7934 In the latter example, the delay is 2 minutes.
7938 The Server response-header field contains information about the
7939 software used by the origin server to handle the request. The field
7940 can contain multiple product tokens (section 3.8) and comments
7941 identifying the server and any significant subproducts. The product
7942 tokens are listed in order of their significance for identifying the
7945 Server = "Server" ":" 1*( product | comment )
7949 Server: CERN/3.0 libwww/2.17
7951 If the response is being forwarded through a proxy, the proxy
7952 application MUST NOT modify the Server response-header. Instead, it
7953 SHOULD include a Via field (as described in section 14.45).
7954 [[ Actually, it MUST ]]
7956 Note: Revealing the specific software version of the server might
7957 allow the server machine to become more vulnerable to attacks
7958 against software that is known to contain security holes. Server
7959 implementors are encouraged to make this field a configurable
7965 Fielding, et al. Standards Track [Page 141]
7967 RFC 2616 HTTP/1.1 June 1999
7972 The TE request-header field indicates what extension transfer-codings
7973 it is willing to accept in the response and whether or not it is
7974 willing to accept trailer fields in a chunked transfer-coding. Its
7975 value may consist of the keyword "trailers" and/or a comma-separated
7976 list of extension transfer-coding names with optional accept
7977 parameters (as described in section 3.6).
7979 TE = "TE" ":" #( t-codings )
7980 t-codings = "trailers" | ( transfer-extension [ accept-params ] )
7982 The presence of the keyword "trailers" indicates that the client is
7983 willing to accept trailer fields in a chunked transfer-coding, as
7984 defined in section 3.6.1. This keyword is reserved for use with
7985 transfer-coding values even though it does not itself represent a
7988 Examples of its use are:
7992 TE: trailers, deflate;q=0.5
7994 The TE header field only applies to the immediate connection.
7995 Therefore, the keyword MUST be supplied within a Connection header
7996 field (section 14.10) whenever TE is present in an HTTP/1.1 message.
7998 A server tests whether a transfer-coding is acceptable, according to
7999 a TE field, using these rules:
8001 1. The "chunked" transfer-coding is always acceptable. If the
8002 keyword "trailers" is listed, the client indicates that it is
8003 willing to accept trailer fields in the chunked response on
8004 behalf of itself and any downstream clients. The implication is
8005 that, if given, the client is stating that either all
8006 downstream clients are willing to accept trailer fields in the
8007 forwarded response, or that it will attempt to buffer the
8008 response on behalf of downstream recipients.
8010 Note: HTTP/1.1 does not define any means to limit the size of a
8011 chunked response such that a client can be assured of buffering
8012 the entire response.
8014 2. If the transfer-coding being tested is one of the transfer-
8015 codings listed in the TE field, then it is acceptable unless it
8016 is accompanied by a qvalue of 0. (As defined in section 3.9, a
8017 qvalue of 0 means "not acceptable.")
8021 Fielding, et al. Standards Track [Page 142]
8023 RFC 2616 HTTP/1.1 June 1999
8026 3. If multiple transfer-codings are acceptable, then the
8027 acceptable transfer-coding with the highest non-zero qvalue is
8028 preferred. The "chunked" transfer-coding always has a qvalue
8031 If the TE field-value is empty or if no TE field is present, the only
8032 transfer-coding is "chunked". A message with no transfer-coding is
8037 The Trailer general field value indicates that the given set of
8038 header fields is present in the trailer of a message encoded with
8039 chunked transfer-coding.
8041 Trailer = "Trailer" ":" 1#field-name
8043 An HTTP/1.1 message SHOULD include a Trailer header field in a
8044 message using chunked transfer-coding with a non-empty trailer. Doing
8045 so allows the recipient to know which header fields to expect in the
8048 If no Trailer header field is present, the trailer SHOULD NOT include
8049 any header fields. See section 3.6.1 for restrictions on the use of
8050 trailer fields in a "chunked" transfer-coding.
8052 Message header fields listed in the Trailer header field MUST NOT
8053 include the following header fields:
8061 14.41 Transfer-Encoding
8063 The Transfer-Encoding general-header field indicates what (if any)
8064 type of transformation has been applied to the message body in order
8065 to safely transfer it between the sender and the recipient. This
8066 differs from the content-coding in that the transfer-coding is a
8067 property of the message, not of the entity.
8069 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
8071 Transfer-codings are defined in section 3.6. An example is:
8073 Transfer-Encoding: chunked
8077 Fielding, et al. Standards Track [Page 143]
8079 RFC 2616 HTTP/1.1 June 1999
8082 If multiple encodings have been applied to an entity, the transfer-
8083 codings MUST be listed in the order in which they were applied.
8084 Additional information about the encoding parameters MAY be provided
8085 by other entity-header fields not defined by this specification.
8087 Many older HTTP/1.0 applications do not understand the Transfer-
8092 The Upgrade general-header allows the client to specify what
8093 additional communication protocols it supports and would like to use
8094 if the server finds it appropriate to switch protocols. The server
8095 MUST use the Upgrade header field within a 101 (Switching Protocols)
8096 response to indicate which protocol(s) are being switched.
8098 Upgrade = "Upgrade" ":" 1#product
8102 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
8104 The Upgrade header field is intended to provide a simple mechanism
8105 for transition from HTTP/1.1 to some other, incompatible protocol. It
8106 does so by allowing the client to advertise its desire to use another
8107 protocol, such as a later version of HTTP with a higher major version
8108 number, even though the current request has been made using HTTP/1.1.
8109 This eases the difficult transition between incompatible protocols by
8110 allowing the client to initiate a request in the more commonly
8111 supported protocol while indicating to the server that it would like
8112 to use a "better" protocol if available (where "better" is determined
8113 by the server, possibly according to the nature of the method and/or
8114 resource being requested).
8116 The Upgrade header field only applies to switching application-layer
8117 protocols upon the existing transport-layer connection. Upgrade
8118 cannot be used to insist on a protocol change; its acceptance and use
8119 by the server is optional. The capabilities and nature of the
8120 application-layer communication after the protocol change is entirely
8121 dependent upon the new protocol chosen, although the first action
8122 after changing the protocol MUST be a response to the initial HTTP
8123 request containing the Upgrade header field.
8125 The Upgrade header field only applies to the immediate connection.
8126 Therefore, the upgrade keyword MUST be supplied within a Connection
8127 header field (section 14.10) whenever Upgrade is present in an
8133 Fielding, et al. Standards Track [Page 144]
8135 RFC 2616 HTTP/1.1 June 1999
8138 The Upgrade header field cannot be used to indicate a switch to a
8139 protocol on a different connection. For that purpose, it is more
8140 appropriate to use a 301, 302, 303, or 305 redirection response.
8142 This specification only defines the protocol name "HTTP" for use by
8143 the family of Hypertext Transfer Protocols, as defined by the HTTP
8144 version rules of section 3.1 and future updates to this
8145 specification. Any token can be used as a protocol name; however, it
8146 will only be useful if both the client and server associate the name
8147 with the same protocol.
8151 The User-Agent request-header field contains information about the
8152 user agent originating the request. This is for statistical purposes,
8153 the tracing of protocol violations, and automated recognition of user
8154 agents for the sake of tailoring responses to avoid particular user
8155 agent limitations. User agents SHOULD include this field with
8156 requests. The field can contain multiple product tokens (section 3.8)
8157 and comments identifying the agent and any subproducts which form a
8158 significant part of the user agent. By convention, the product tokens
8159 are listed in order of their significance for identifying the
8162 User-Agent = "User-Agent" ":" 1*( product | comment )
8166 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
8170 The Vary field value indicates the set of request-header fields that
8171 fully determines, while the response is fresh, whether a cache is
8172 permitted to use the response to reply to a subsequent request
8173 without revalidation. For uncacheable or stale responses, the Vary
8174 field value advises the user agent about the criteria that were used
8175 to select the representation. A Vary field value of "*" implies that
8176 a cache cannot determine from the request headers of a subsequent
8177 request whether this response is the appropriate representation. See
8178 section 13.6 for use of the Vary header field by caches.
8180 Vary = "Vary" ":" ( "*" | 1#field-name )
8182 An HTTP/1.1 server SHOULD include a Vary header field with any
8183 cacheable response that is subject to server-driven negotiation.
8184 Doing so allows a cache to properly interpret future requests on that
8185 resource and informs the user agent about the presence of negotiation
8189 Fielding, et al. Standards Track [Page 145]
8191 RFC 2616 HTTP/1.1 June 1999
8194 on that resource. A server MAY include a Vary header field with a
8195 non-cacheable response that is subject to server-driven negotiation,
8196 since this might provide the user agent with useful information about
8197 the dimensions over which the response varies at the time of the
8200 A Vary field value consisting of a list of field-names signals that
8201 the representation selected for the response is based on a selection
8202 algorithm which considers ONLY the listed request-header field values
8203 in selecting the most appropriate representation. A cache MAY assume
8204 that the same selection will be made for future requests with the
8205 same values for the listed field names, for the duration of time for
8206 which the response is fresh.
8208 The field-names given are not limited to the set of standard
8209 request-header fields defined by this specification. Field names are
8212 A Vary field value of "*" signals that unspecified parameters not
8213 limited to the request-headers (e.g., the network address of the
8214 client), play a role in the selection of the response representation.
8215 The "*" value MUST NOT be generated by a proxy server; it may only be
8216 generated by an origin server.
8220 The Via general-header field MUST be used by gateways and proxies to
8221 indicate the intermediate protocols and recipients between the user
8222 agent and the server on requests, and between the origin server and
8223 the client on responses. It is analogous to the "Received" field of
8224 RFC 822 [9] and is intended to be used for tracking message forwards,
8225 avoiding request loops, and identifying the protocol capabilities of
8226 all senders along the request/response chain.
8228 Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
8229 received-protocol = [ protocol-name "/" ] protocol-version
8230 protocol-name = token
8231 protocol-version = token
8232 received-by = ( host [ ":" port ] ) | pseudonym
8235 The received-protocol indicates the protocol version of the message
8236 received by the server or client along each segment of the
8237 request/response chain. The received-protocol version is appended to
8238 the Via field value when the message is forwarded so that information
8239 about the protocol capabilities of upstream applications remains
8240 visible to all recipients.
8245 Fielding, et al. Standards Track [Page 146]
8247 RFC 2616 HTTP/1.1 June 1999
8250 The protocol-name is optional if and only if it would be "HTTP". The
8251 received-by field is normally the host and optional port number of a
8252 recipient server or client that subsequently forwarded the message.
8253 However, if the real host is considered to be sensitive information,
8254 it MAY be replaced by a pseudonym. If the port is not given, it MAY
8255 be assumed to be the default port of the received-protocol.
8257 Multiple Via field values represents each proxy or gateway that has
8258 forwarded the message. Each recipient MUST append its information
8259 such that the end result is ordered according to the sequence of
8260 forwarding applications.
8262 Comments MAY be used in the Via header field to identify the software
8263 of the recipient proxy or gateway, analogous to the User-Agent and
8264 Server header fields. However, all comments in the Via field are
8265 optional and MAY be removed by any recipient prior to forwarding the
8268 For example, a request message could be sent from an HTTP/1.0 user
8269 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
8270 forward the request to a public proxy at nowhere.com, which completes
8271 the request by forwarding it to the origin server at www.ics.uci.edu.
8272 The request received by www.ics.uci.edu would then have the following
8275 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
8277 Proxies and gateways used as a portal through a network firewall
8278 SHOULD NOT, by default, forward the names and ports of hosts within
8279 the firewall region. This information SHOULD only be propagated if
8280 explicitly enabled. If not enabled, the received-by host of any host
8281 behind the firewall SHOULD be replaced by an appropriate pseudonym
8284 For organizations that have strong privacy requirements for hiding
8285 internal structures, a proxy MAY combine an ordered subsequence of
8286 Via header field entries with identical received-protocol values into
8287 a single such entry. For example,
8289 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
8291 could be collapsed to
8293 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
8301 Fielding, et al. Standards Track [Page 147]
8303 RFC 2616 HTTP/1.1 June 1999
8306 Applications SHOULD NOT combine multiple entries unless they are all
8307 under the same organizational control and the hosts have already been
8308 replaced by pseudonyms. Applications MUST NOT combine entries which
8309 have different received-protocol values.
8313 The Warning general-header field is used to carry additional
8314 information about the status or transformation of a message which
8315 might not be reflected in the message. This information is typically
8316 used to warn about a possible lack of semantic transparency from
8317 caching operations or transformations applied to the entity body of
8320 Warning headers are sent with responses using:
8322 Warning = "Warning" ":" 1#warning-value
8324 warning-value = warn-code SP warn-agent SP warn-text
8328 warn-agent = ( host [ ":" port ] ) | pseudonym
8329 ; the name or pseudonym of the server adding
8330 ; the Warning header, for use in debugging
8331 warn-text = quoted-string
8332 warn-date = <"> HTTP-date <">
8334 A response MAY carry more than one Warning header.
8336 The warn-text SHOULD be in a natural language and character set that
8337 is most likely to be intelligible to the human user receiving the
8338 response. This decision MAY be based on any available knowledge, such
8339 as the location of the cache or user, the Accept-Language field in a
8340 request, the Content-Language field in a response, etc. The default
8341 language is English and the default character set is ISO-8859-1.
8343 If a character set other than ISO-8859-1 is used, it MUST be encoded
8344 in the warn-text using the method described in RFC 2047 [14].
8346 Warning headers can in general be applied to any message, however
8347 some specific warn-codes are specific to caches and can only be
8348 applied to response messages. New Warning headers SHOULD be added
8349 after any existing Warning headers. A cache MUST NOT delete any
8350 Warning header that it received with a message. However, if a cache
8351 successfully validates a cache entry, it SHOULD remove any Warning
8352 headers previously attached to that entry except as specified for
8357 Fielding, et al. Standards Track [Page 148]
8359 RFC 2616 HTTP/1.1 June 1999
8362 specific Warning codes. It MUST then add any Warning headers received
8363 in the validating response. In other words, Warning headers are those
8364 that would be attached to the most recent relevant response.
8366 When multiple Warning headers are attached to a response, the user
8367 agent ought to inform the user of as many of them as possible, in the
8368 order that they appear in the response. If it is not possible to
8369 inform the user of all of the warnings, the user agent SHOULD follow
8372 - Warnings that appear early in the response take priority over
8373 those appearing later in the response.
8375 - Warnings in the user's preferred character set take priority
8376 over warnings in other character sets but with identical warn-
8377 codes and warn-agents.
8379 Systems that generate multiple Warning headers SHOULD order them with
8380 this user agent behavior in mind.
8382 Requirements for the behavior of caches with respect to Warnings are
8383 stated in section 13.1.2.
8385 This is a list of the currently-defined warn-codes, each with a
8386 recommended warn-text in English, and a description of its meaning.
8388 110 Response is stale
8389 MUST be included whenever the returned response is stale.
8391 111 Revalidation failed
8392 MUST be included if a cache returns a stale response because an
8393 attempt to revalidate the response failed, due to an inability to
8396 112 Disconnected operation
8397 SHOULD be included if the cache is intentionally disconnected from
8398 the rest of the network for a period of time.
8400 113 Heuristic expiration
8401 MUST be included if the cache heuristically chose a freshness
8402 lifetime greater than 24 hours and the response's age is greater
8405 199 Miscellaneous warning
8406 The warning text MAY include arbitrary information to be presented
8407 to a human user, or logged. A system receiving this warning MUST
8408 NOT take any automated action, besides presenting the warning to
8413 Fielding, et al. Standards Track [Page 149]
8415 RFC 2616 HTTP/1.1 June 1999
8418 214 Transformation applied
8419 MUST be added by an intermediate cache or proxy if it applies any
8420 transformation changing the content-coding (as specified in the
8421 Content-Encoding header) or media-type (as specified in the
8422 Content-Type header) of the response, or the entity-body of the
8423 response, unless this Warning code already appears in the response.
8425 299 Miscellaneous persistent warning
8426 The warning text MAY include arbitrary information to be presented
8427 to a human user, or logged. A system receiving this warning MUST
8428 NOT take any automated action.
8430 If an implementation sends a message with one or more Warning headers
8431 whose version is HTTP/1.0 or lower, then the sender MUST include in
8432 each warning-value a warn-date that matches the date in the response.
8434 If an implementation receives a message with a warning-value that
8435 includes a warn-date, and that warn-date is different from the Date
8436 value in the response, then that warning-value MUST be deleted from
8437 the message before storing, forwarding, or using it. (This prevents
8438 bad consequences of naive caching of Warning header fields.) If all
8439 of the warning-values are deleted for this reason, the Warning header
8440 MUST be deleted as well.
8442 14.47 WWW-Authenticate
8444 The WWW-Authenticate response-header field MUST be included in 401
8445 (Unauthorized) response messages. The field value consists of at
8446 least one challenge that indicates the authentication scheme(s) and
8447 parameters applicable to the Request-URI.
8449 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
8451 The HTTP access authentication process is described in "HTTP
8452 Authentication: Basic and Digest Access Authentication" [43]. User
8453 agents are advised to take special care in parsing the WWW-
8454 Authenticate field value as it might contain more than one challenge,
8455 or if more than one WWW-Authenticate header field is provided, the
8456 contents of a challenge itself can contain a comma-separated list of
8457 authentication parameters.
8459 15 Security Considerations
8461 This section is meant to inform application developers, information
8462 providers, and users of the security limitations in HTTP/1.1 as
8463 described by this document. The discussion does not include
8464 definitive solutions to the problems revealed, though it does make
8465 some suggestions for reducing security risks.
8469 Fielding, et al. Standards Track [Page 150]
8471 RFC 2616 HTTP/1.1 June 1999
8474 15.1 Personal Information
8476 HTTP clients are often privy to large amounts of personal information
8477 (e.g. the user's name, location, mail address, passwords, encryption
8478 keys, etc.), and SHOULD be very careful to prevent unintentional
8479 leakage of this information via the HTTP protocol to other sources.
8480 We very strongly recommend that a convenient interface be provided
8481 for the user to control dissemination of such information, and that
8482 designers and implementors be particularly careful in this area.
8483 History shows that errors in this area often create serious security
8484 and/or privacy problems and generate highly adverse publicity for the
8485 implementor's company.
8487 15.1.1 Abuse of Server Log Information
8489 A server is in the position to save personal data about a user's
8490 requests which might identify their reading patterns or subjects of
8491 interest. This information is clearly confidential in nature and its
8492 handling can be constrained by law in certain countries. People using
8493 the HTTP protocol to provide data are responsible for ensuring that
8494 such material is not distributed without the permission of any
8495 individuals that are identifiable by the published results.
8497 15.1.2 Transfer of Sensitive Information
8499 Like any generic data transfer protocol, HTTP cannot regulate the
8500 content of the data that is transferred, nor is there any a priori
8501 method of determining the sensitivity of any particular piece of
8502 information within the context of any given request. Therefore,
8503 applications SHOULD supply as much control over this information as
8504 possible to the provider of that information. Four header fields are
8505 worth special mention in this context: Server, Via, Referer and From.
8507 Revealing the specific software version of the server might allow the
8508 server machine to become more vulnerable to attacks against software
8509 that is known to contain security holes. Implementors SHOULD make the
8510 Server header field a configurable option.
8512 Proxies which serve as a portal through a network firewall SHOULD
8513 take special precautions regarding the transfer of header information
8514 that identifies the hosts behind the firewall. In particular, they
8515 SHOULD remove, or replace with sanitized versions, any Via fields
8516 generated behind the firewall.
8518 The Referer header allows reading patterns to be studied and reverse
8519 links drawn. Although it can be very useful, its power can be abused
8520 if user details are not separated from the information contained in
8525 Fielding, et al. Standards Track [Page 151]
8527 RFC 2616 HTTP/1.1 June 1999
8530 the Referer. Even when the personal information has been removed, the
8531 Referer header might indicate a private document's URI whose
8532 publication would be inappropriate.
8534 The information sent in the From field might conflict with the user's
8535 privacy interests or their site's security policy, and hence it
8536 SHOULD NOT be transmitted without the user being able to disable,
8537 enable, and modify the contents of the field. The user MUST be able
8538 to set the contents of this field within a user preference or
8539 application defaults configuration.
8541 We suggest, though do not require, that a convenient toggle interface
8542 be provided for the user to enable or disable the sending of From and
8543 Referer information.
8545 The User-Agent (section 14.43) or Server (section 14.38) header
8546 fields can sometimes be used to determine that a specific client or
8547 server have a particular security hole which might be exploited.
8548 Unfortunately, this same information is often used for other valuable
8549 purposes for which HTTP currently has no better mechanism.
8551 15.1.3 Encoding Sensitive Information in URI's
8553 Because the source of a link might be private information or might
8554 reveal an otherwise private information source, it is strongly
8555 recommended that the user be able to select whether or not the
8556 Referer field is sent. For example, a browser client could have a
8557 toggle switch for browsing openly/anonymously, which would
8558 respectively enable/disable the sending of Referer and From
8561 Clients SHOULD NOT include a Referer header field in a (non-secure)
8562 HTTP request if the referring page was transferred with a secure
8565 Authors of services which use the HTTP protocol SHOULD NOT use GET
8566 based forms for the submission of sensitive data, because this will
8567 cause this data to be encoded in the Request-URI. Many existing
8568 servers, proxies, and user agents will log the request URI in some
8569 place where it might be visible to third parties. Servers can use
8570 POST-based form submission instead
8572 15.1.4 Privacy Issues Connected to Accept Headers
8574 Accept request-headers can reveal information about the user to all
8575 servers which are accessed. The Accept-Language header in particular
8576 can reveal information the user would consider to be of a private
8577 nature, because the understanding of particular languages is often
8581 Fielding, et al. Standards Track [Page 152]
8583 RFC 2616 HTTP/1.1 June 1999
8586 strongly correlated to the membership of a particular ethnic group.
8587 User agents which offer the option to configure the contents of an
8588 Accept-Language header to be sent in every request are strongly
8589 encouraged to let the configuration process include a message which
8590 makes the user aware of the loss of privacy involved.
8592 An approach that limits the loss of privacy would be for a user agent
8593 to omit the sending of Accept-Language headers by default, and to ask
8594 the user whether or not to start sending Accept-Language headers to a
8595 server if it detects, by looking for any Vary response-header fields
8596 generated by the server, that such sending could improve the quality
8599 Elaborate user-customized accept header fields sent in every request,
8600 in particular if these include quality values, can be used by servers
8601 as relatively reliable and long-lived user identifiers. Such user
8602 identifiers would allow content providers to do click-trail tracking,
8603 and would allow collaborating content providers to match cross-server
8604 click-trails or form submissions of individual users. Note that for
8605 many users not behind a proxy, the network address of the host
8606 running the user agent will also serve as a long-lived user
8607 identifier. In environments where proxies are used to enhance
8608 privacy, user agents ought to be conservative in offering accept
8609 header configuration options to end users. As an extreme privacy
8610 measure, proxies could filter the accept headers in relayed requests.
8611 General purpose user agents which provide a high degree of header
8612 configurability SHOULD warn users about the loss of privacy which can
8615 15.2 Attacks Based On File and Path Names
8617 Implementations of HTTP origin servers SHOULD be careful to restrict
8618 the documents returned by HTTP requests to be only those that were
8619 intended by the server administrators. If an HTTP server translates
8620 HTTP URIs directly into file system calls, the server MUST take
8621 special care not to serve files that were not intended to be
8622 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
8623 other operating systems use ".." as a path component to indicate a
8624 directory level above the current one. On such a system, an HTTP
8625 server MUST disallow any such construct in the Request-URI if it
8626 would otherwise allow access to a resource outside those intended to
8627 be accessible via the HTTP server. Similarly, files intended for
8628 reference only internally to the server (such as access control
8629 files, configuration files, and script code) MUST be protected from
8630 inappropriate retrieval, since they might contain sensitive
8631 information. Experience has shown that minor bugs in such HTTP server
8632 implementations have turned into security risks.
8637 Fielding, et al. Standards Track [Page 153]
8639 RFC 2616 HTTP/1.1 June 1999
8644 Clients using HTTP rely heavily on the Domain Name Service, and are
8645 thus generally prone to security attacks based on the deliberate
8646 mis-association of IP addresses and DNS names. Clients need to be
8647 cautious in assuming the continuing validity of an IP number/DNS name
8650 In particular, HTTP clients SHOULD rely on their name resolver for
8651 confirmation of an IP number/DNS name association, rather than
8652 caching the result of previous host name lookups. Many platforms
8653 already can cache host name lookups locally when appropriate, and
8654 they SHOULD be configured to do so. It is proper for these lookups to
8655 be cached, however, only when the TTL (Time To Live) information
8656 reported by the name server makes it likely that the cached
8657 information will remain useful.
8659 If HTTP clients cache the results of host name lookups in order to
8660 achieve a performance improvement, they MUST observe the TTL
8661 information reported by DNS.
8663 If HTTP clients do not observe this rule, they could be spoofed when
8664 a previously-accessed server's IP address changes. As network
8665 renumbering is expected to become increasingly common [24], the
8666 possibility of this form of attack will grow. Observing this
8667 requirement thus reduces this potential security vulnerability.
8669 This requirement also improves the load-balancing behavior of clients
8670 for replicated servers using the same DNS name and reduces the
8671 likelihood of a user's experiencing failure in accessing sites which
8674 15.4 Location Headers and Spoofing
8676 If a single server supports multiple organizations that do not trust
8677 one another, then it MUST check the values of Location and Content-
8678 Location headers in responses that are generated under control of
8679 said organizations to make sure that they do not attempt to
8680 invalidate resources over which they have no authority.
8682 15.5 Content-Disposition Issues
8684 RFC 1806 [35], from which the often implemented Content-Disposition
8685 (see section 19.5.1) header in HTTP is derived, has a number of very
8686 serious security considerations. Content-Disposition is not part of
8687 the HTTP standard, but since it is widely implemented, we are
8688 documenting its use and risks for implementors. See RFC 2183 [49]
8689 (which updates RFC 1806) for details.
8693 Fielding, et al. Standards Track [Page 154]
8695 RFC 2616 HTTP/1.1 June 1999
8698 15.6 Authentication Credentials and Idle Clients
8700 Existing HTTP clients and user agents typically retain authentication
8701 information indefinitely. HTTP/1.1. does not provide a method for a
8702 server to direct clients to discard these cached credentials. This is
8703 a significant defect that requires further extensions to HTTP.
8704 Circumstances under which credential caching can interfere with the
8705 application's security model include but are not limited to:
8707 - Clients which have been idle for an extended period following
8708 which the server might wish to cause the client to reprompt the
8709 user for credentials.
8711 - Applications which include a session termination indication
8712 (such as a `logout' or `commit' button on a page) after which
8713 the server side of the application `knows' that there is no
8714 further reason for the client to retain the credentials.
8716 This is currently under separate study. There are a number of work-
8717 arounds to parts of this problem, and we encourage the use of
8718 password protection in screen savers, idle time-outs, and other
8719 methods which mitigate the security problems inherent in this
8720 problem. In particular, user agents which cache credentials are
8721 encouraged to provide a readily accessible mechanism for discarding
8722 cached credentials under user control.
8724 15.7 Proxies and Caching
8726 By their very nature, HTTP proxies are men-in-the-middle, and
8727 represent an opportunity for man-in-the-middle attacks. Compromise of
8728 the systems on which the proxies run can result in serious security
8729 and privacy problems. Proxies have access to security-related
8730 information, personal information about individual users and
8731 organizations, and proprietary information belonging to users and
8732 content providers. A compromised proxy, or a proxy implemented or
8733 configured without regard to security and privacy considerations,
8734 might be used in the commission of a wide range of potential attacks.
8736 Proxy operators should protect the systems on which proxies run as
8737 they would protect any system that contains or transports sensitive
8738 information. In particular, log information gathered at proxies often
8739 contains highly sensitive personal information, and/or information
8740 about organizations. Log information should be carefully guarded, and
8741 appropriate guidelines for use developed and followed. (Section
8749 Fielding, et al. Standards Track [Page 155]
8751 RFC 2616 HTTP/1.1 June 1999
8754 Caching proxies provide additional potential vulnerabilities, since
8755 the contents of the cache represent an attractive target for
8756 malicious exploitation. Because cache contents persist after an HTTP
8757 request is complete, an attack on the cache can reveal information
8758 long after a user believes that the information has been removed from
8759 the network. Therefore, cache contents should be protected as
8760 sensitive information.
8762 Proxy implementors should consider the privacy and security
8763 implications of their design and coding decisions, and of the
8764 configuration options they provide to proxy operators (especially the
8765 default configuration).
8767 Users of a proxy need to be aware that they are no trustworthier than
8768 the people who run the proxy; HTTP itself cannot solve this problem.
8770 The judicious use of cryptography, when appropriate, may suffice to
8771 protect against a broad range of security and privacy attacks. Such
8772 cryptography is beyond the scope of the HTTP/1.1 specification.
8774 15.7.1 Denial of Service Attacks on Proxies
8776 They exist. They are hard to defend against. Research continues.
8781 This specification makes heavy use of the augmented BNF and generic
8782 constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
8783 reuses many of the definitions provided by Nathaniel Borenstein and
8784 Ned Freed for MIME [7]. We hope that their inclusion in this
8785 specification will help reduce past confusion over the relationship
8786 between HTTP and Internet mail message formats.
8788 The HTTP protocol has evolved considerably over the years. It has
8789 benefited from a large and active developer community--the many
8790 people who have participated on the www-talk mailing list--and it is
8791 that community which has been most responsible for the success of
8792 HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
8793 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
8794 Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
8795 McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
8796 VanHeyningen deserve special recognition for their efforts in
8797 defining early aspects of the protocol.
8799 This document has benefited greatly from the comments of all those
8800 participating in the HTTP-WG. In addition to those already mentioned,
8801 the following individuals have contributed to this specification:
8805 Fielding, et al. Standards Track [Page 156]
8807 RFC 2616 HTTP/1.1 June 1999
8810 Gary Adams Ross Patterson
8811 Harald Tveit Alvestrand Albert Lunde
8812 Keith Ball John C. Mallery
8813 Brian Behlendorf Jean-Philippe Martin-Flatin
8815 Maurizio Codogno David Morris
8816 Mike Cowlishaw Gavin Nicol
8817 Roman Czyborra Bill Perry
8818 Michael A. Dolan Jeffrey Perry
8819 David J. Fiander Scott Powers
8820 Alan Freier Owen Rees
8821 Marc Hedlund Luigi Rizzo
8822 Greg Herlihy David Robinson
8823 Koen Holtman Marc Salomon
8824 Alex Hopmann Rich Salz
8825 Bob Jernigan Allan M. Schiffman
8826 Shel Kaphan Jim Seidman
8827 Rohit Khare Chuck Shotton
8828 John Klensin Eric W. Sink
8829 Martijn Koster Simon E. Spero
8830 Alexei Kosut Richard N. Taylor
8831 David M. Kristol Robert S. Thau
8832 Daniel LaLiberte Bill (BearHeart) Weinman
8833 Ben Laurie Francois Yergeau
8834 Paul J. Leach Mary Ellen Zurko
8835 Daniel DuBois Josh Cohen
8838 Much of the content and presentation of the caching design is due to
8839 suggestions and comments from individuals including: Shel Kaphan,
8840 Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
8842 Most of the specification of ranges is based on work originally done
8843 by Ari Luotonen and John Franks, with additional input from Steve
8846 Thanks to the "cave men" of Palo Alto. You know who you are.
8848 Jim Gettys (the current editor of this document) wishes particularly
8849 to thank Roy Fielding, the previous editor of this document, along
8850 with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
8851 Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
8852 Larry Masinter for their help. And thanks go particularly to Jeff
8853 Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
8861 Fielding, et al. Standards Track [Page 157]
8863 RFC 2616 HTTP/1.1 June 1999
8866 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
8867 Frystyk implemented RFC 2068 early, and we wish to thank them for the
8868 discovery of many of the problems that this document attempts to
8873 [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
8876 [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
8877 D. and B. Alberti, "The Internet Gopher Protocol (a distributed
8878 document search and retrieval protocol)", RFC 1436, March 1993.
8880 [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
8883 [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
8884 Locators (URL)", RFC 1738, December 1994.
8886 [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
8887 2.0", RFC 1866, November 1995.
8889 [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
8890 Protocol -- HTTP/1.0", RFC 1945, May 1996.
8892 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
8893 Extensions (MIME) Part One: Format of Internet Message Bodies",
8894 RFC 2045, November 1996.
8896 [8] Braden, R., "Requirements for Internet Hosts -- Communication
8897 Layers", STD 3, RFC 1123, October 1989.
8899 [9] Crocker, D., "Standard for The Format of ARPA Internet Text
8900 Messages", STD 11, RFC 822, August 1982.
8902 [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
8903 Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
8904 Functional Specification," (v1.5), Thinking Machines
8905 Corporation, April 1990.
8907 [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
8910 [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
8911 Messages", RFC 1036, December 1987.
8917 Fielding, et al. Standards Track [Page 158]
8919 RFC 2616 HTTP/1.1 June 1999
8922 [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
8925 [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
8926 Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
8929 [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
8930 1867, November 1995.
8932 [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
8935 [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
8939 [[ [17] Freed, N., Klensin, J., and Postel, J., "Multipurpose Internet ]]
8940 [[ Mail Extensions (MIME) Part Four: "Registration Procedure", ]]
8941 [[ RFC 2048, November 1996. ]]
8943 [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
8946 [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
8949 [20] Sollins, K. and L. Masinter, "Functional Requirements for
8950 Uniform Resource Names", RFC 1737, December 1994.
8952 [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
8953 Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
8955 [22] ISO-8859. International Standard -- Information Processing --
8956 8-bit Single-Byte Coded Graphic Character Sets --
8957 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
8958 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
8959 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
8960 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
8961 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
8962 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
8963 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
8964 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
8965 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
8967 [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
8970 [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
8971 1900, February 1996.
8973 [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
8978 Fielding, et al. Standards Track [Page 159]
8980 RFC 2616 HTTP/1.1 June 1999
8983 [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
8984 Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
8985 Dec. 1995. Slightly revised version of paper in Proc. 2nd
8986 International WWW Conference '94: Mosaic and the Web, Oct. 1994,
8987 which is available at
8988 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
8991 [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
8992 Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
8993 ISI Research Report ISI/RR-98-463, (original report dated Aug.
8994 1996), USC/Information Sciences Institute, August 1998.
8996 [28] Mills, D., "Network Time Protocol (Version 3) Specification,
8997 Implementation and Analysis", RFC 1305, March 1992.
8999 [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
9000 version 1.3", RFC 1951, May 1996.
9002 [30] S. Spero, "Analysis of HTTP Performance Problems,"
9003 http://sunsite.unc.edu/mdma-release/http-prob.html.
9005 [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
9006 Specification version 3.3", RFC 1950, May 1996.
9008 [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
9009 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
9010 Digest Access Authentication", RFC 2069, January 1997.
9012 [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
9013 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
9016 [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
9017 Levels", BCP 14, RFC 2119, March 1997.
9019 [35] Troost, R. and Dorner, S., "Communicating Presentation
9020 Information in Internet Messages: The Content-Disposition
9021 Header", RFC 1806, June 1995.
9023 [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
9024 Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
9027 [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
9034 Fielding, et al. Standards Track [Page 160]
9036 RFC 2616 HTTP/1.1 June 1999
9039 [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
9040 ISO-10646", RFC 2279, January 1998. [jg641]
9042 [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
9043 Lie, H., and C. Lilley. "Network Performance Effects of
9044 HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
9045 France, September 1997.[jg642]
9047 [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
9048 Extensions (MIME) Part Two: Media Types", RFC 2046, November
9051 [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
9052 BCP 18, RFC 2277, January 1998. [jg644]
9054 [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
9055 Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
9056 August 1998. [jg645]
9058 [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
9059 Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
9060 Authentication: Basic and Digest Access Authentication", RFC
9061 2617, June 1999. [jg646]
9063 [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
9064 servers," Work in Progress. [jg647]
9066 [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
9067 Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
9070 [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9071 9, RFC 2026, October 1996.
9073 [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
9074 (HTCPCP/1.0)", RFC 2324, 1 April 1998.
9076 [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
9077 Extensions (MIME) Part Five: Conformance Criteria and Examples",
9078 RFC 2049, November 1996.
9080 [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
9081 Information in Internet Messages: The Content-Disposition Header
9082 Field", RFC 2183, August 1997.
9090 Fielding, et al. Standards Track [Page 161]
9092 RFC 2616 HTTP/1.1 June 1999
9095 18 Authors' Addresses
9098 Information and Computer Science
9099 University of California, Irvine
9100 Irvine, CA 92697-3425, USA
9102 Fax: +1 (949) 824-1715
9103 EMail: fielding@ics.uci.edu
9107 World Wide Web Consortium
9108 MIT Laboratory for Computer Science
9109 545 Technology Square
9110 Cambridge, MA 02139, USA
9112 Fax: +1 (617) 258 8682
9117 Western Research Laboratory
9118 Compaq Computer Corporation
9119 250 University Avenue
9120 Palo Alto, California, 94305, USA
9122 EMail: mogul@wrl.dec.com
9125 Henrik Frystyk Nielsen
9126 World Wide Web Consortium
9127 MIT Laboratory for Computer Science
9128 545 Technology Square
9129 Cambridge, MA 02139, USA
9131 Fax: +1 (617) 258 8682
9132 EMail: frystyk@w3.org
9137 3333 Coyote Hill Road
9138 Palo Alto, CA 94034, USA
9140 EMail: masinter@parc.xerox.com
9146 Fielding, et al. Standards Track [Page 162]
9148 RFC 2616 HTTP/1.1 June 1999
9152 Microsoft Corporation
9154 Redmond, WA 98052, USA
9156 EMail: paulle@microsoft.com
9160 Director, World Wide Web Consortium
9161 MIT Laboratory for Computer Science
9162 545 Technology Square
9163 Cambridge, MA 02139, USA
9165 Fax: +1 (617) 258 8682
9202 Fielding, et al. Standards Track [Page 163]
9204 RFC 2616 HTTP/1.1 June 1999
9209 19.1 Internet Media Type message/http and application/http
9211 In addition to defining the HTTP/1.1 protocol, this document serves
9212 as the specification for the Internet media type "message/http" and
9213 "application/http". The message/http type can be used to enclose a
9214 single HTTP request or response message, provided that it obeys the
9215 MIME restrictions for all "message" types regarding line length and
9216 encodings. The application/http type can be used to enclose a
9217 pipeline of one or more HTTP request or response messages (not
9218 intermixed). The following is to be registered with IANA [17].
9220 Media Type name: message
9221 Media subtype name: http
9222 Required parameters: none
9223 Optional parameters: version, msgtype
9224 version: The HTTP-Version number of the enclosed message
9225 (e.g., "1.1"). If not present, the version can be
9226 determined from the first line of the body.
9227 msgtype: The message type -- "request" or "response". If not
9228 present, the type can be determined from the first
9230 Encoding considerations: only "7bit", "8bit", or "binary" are
9232 Security considerations: none
9234 Media Type name: application
9235 Media subtype name: http
9236 Required parameters: none
9237 Optional parameters: version, msgtype
9238 version: The HTTP-Version number of the enclosed messages
9239 (e.g., "1.1"). If not present, the version can be
9240 determined from the first line of the body.
9241 msgtype: The message type -- "request" or "response". If not
9242 present, the type can be determined from the first
9244 Encoding considerations: HTTP messages enclosed by this type
9245 are in "binary" format; use of an appropriate
9246 Content-Transfer-Encoding is required when
9247 transmitted via E-mail.
9248 Security considerations: none
9258 Fielding, et al. Standards Track [Page 164]
9260 RFC 2616 HTTP/1.1 June 1999
9263 19.2 Internet Media Type multipart/byteranges
9265 When an HTTP 206 (Partial Content) response message includes the
9266 content of multiple ranges (a response to a request for multiple
9267 non-overlapping ranges), these are transmitted as a multipart
9268 message-body. The media type for this purpose is called
9269 "multipart/byteranges".
9271 The multipart/byteranges media type includes two or more parts, each
9272 with its own Content-Type and Content-Range fields. The required
9273 boundary parameter specifies the boundary string used to separate
9276 Media Type name: multipart
9277 Media subtype name: byteranges
9278 Required parameters: boundary
9279 Optional parameters: none
9280 Encoding considerations: only "7bit", "8bit", or "binary" are
9282 Security considerations: none
9287 HTTP/1.1 206 Partial Content
9288 Date: Wed, 15 Nov 1995 06:25:24 GMT
9289 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
9290 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
9292 --THIS_STRING_SEPARATES
9293 Content-type: application/pdf
9294 Content-range: bytes 500-999/8000
9296 ...the first range...
9297 --THIS_STRING_SEPARATES
9298 Content-type: application/pdf
9299 Content-range: bytes 7000-7999/8000
9302 --THIS_STRING_SEPARATES--
9306 1) Additional CRLFs may precede the first boundary string in the
9314 Fielding, et al. Standards Track [Page 165]
9316 RFC 2616 HTTP/1.1 June 1999
9319 2) Although RFC 2046 [40] permits the boundary string to be
9320 quoted, some existing implementations handle a quoted boundary
9323 3) A number of browsers and servers were coded to an early draft
9324 of the byteranges specification to use a media type of
9325 multipart/x-byteranges, which is almost, but not quite
9326 compatible with the version documented in HTTP/1.1.
9328 19.3 Tolerant Applications
9330 Although this document specifies the requirements for the generation
9331 of HTTP/1.1 messages, not all applications will be correct in their
9332 implementation. We therefore recommend that operational applications
9333 be tolerant of deviations whenever those deviations can be
9334 interpreted unambiguously.
9336 Clients SHOULD be tolerant in parsing the Status-Line and servers
9337 tolerant when parsing the Request-Line. In particular, they SHOULD
9338 accept any amount of SP or HT characters between fields, even though
9339 only a single SP is required.
9341 The line terminator for message-header fields is the sequence CRLF.
9342 However, we recommend that applications, when parsing such headers,
9343 recognize a single LF as a line terminator and ignore the leading CR.
9345 The character set of an entity-body SHOULD be labeled as the lowest
9346 common denominator of the character codes used within that body, with
9347 the exception that not labeling the entity is preferred over labeling
9348 the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
9351 Additional rules for requirements on parsing and encoding of dates
9352 and other potential problems with date encodings include:
9354 - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
9355 which appears to be more than 50 years in the future is in fact
9356 in the past (this helps solve the "year 2000" problem).
9358 - An HTTP/1.1 implementation MAY internally represent a parsed
9359 Expires date as earlier than the proper value, but MUST NOT
9360 internally represent a parsed Expires date as later than the
9363 - All expiration-related calculations MUST be done in GMT. The
9364 local time zone MUST NOT influence the calculation or comparison
9365 of an age or expiration time.
9370 Fielding, et al. Standards Track [Page 166]
9372 RFC 2616 HTTP/1.1 June 1999
9375 - If an HTTP header incorrectly carries a date value with a time
9376 zone other than GMT, it MUST be converted into GMT using the
9377 most conservative possible conversion.
9379 19.4 Differences Between HTTP Entities and RFC 2045 Entities
9381 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
9382 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
9383 allow entities to be transmitted in an open variety of
9384 representations and with extensible mechanisms. However, RFC 2045
9385 discusses mail, and HTTP has a few features that are different from
9386 those described in RFC 2045. These differences were carefully chosen
9387 to optimize performance over binary connections, to allow greater
9388 freedom in the use of new media types, to make date comparisons
9389 easier, and to acknowledge the practice of some early HTTP servers
9392 This appendix describes specific areas where HTTP differs from RFC
9393 2045. Proxies and gateways to strict MIME environments SHOULD be
9394 aware of these differences and provide the appropriate conversions
9395 where necessary. Proxies and gateways from MIME environments to HTTP
9396 also need to be aware of the differences because some conversions
9401 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
9402 include a single MIME-Version general-header field to indicate what
9403 version of the MIME protocol was used to construct the message. Use
9404 of the MIME-Version header field indicates that the message is in
9405 full compliance with the MIME protocol (as defined in RFC 2045[7]).
9406 Proxies/gateways are responsible for ensuring full compliance (where
9407 possible) when exporting HTTP messages to strict MIME environments.
9409 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
9411 MIME version "1.0" is the default for use in HTTP/1.1. However,
9412 HTTP/1.1 message parsing and semantics are defined by this document
9413 and not the MIME specification.
9415 19.4.2 Conversion to Canonical Form
9417 RFC 2045 [7] requires that an Internet mail entity be converted to
9418 canonical form prior to being transferred, as described in section 4
9419 of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
9420 allowed for subtypes of the "text" media type when transmitted over
9421 HTTP. RFC 2046 requires that content with a type of "text" represent
9422 line breaks as CRLF and forbids the use of CR or LF outside of line
9426 Fielding, et al. Standards Track [Page 167]
9428 RFC 2616 HTTP/1.1 June 1999
9431 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
9432 line break within text content when a message is transmitted over
9435 Where it is possible, a proxy or gateway from HTTP to a strict MIME
9436 environment SHOULD translate all line breaks within the text media
9437 types described in section 3.7.1 of this document to the RFC 2049
9438 canonical form of CRLF. Note, however, that this might be complicated
9439 by the presence of a Content-Encoding and by the fact that HTTP
9440 allows the use of some character sets which do not use octets 13 and
9441 10 to represent CR and LF, as is the case for some multi-byte
9444 Implementors should note that conversion will break any cryptographic
9445 checksums applied to the original content unless the original content
9446 is already in canonical form. Therefore, the canonical form is
9447 recommended for any content that uses such checksums in HTTP.
9449 19.4.3 Conversion of Date Formats
9451 HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
9452 simplify the process of date comparison. Proxies and gateways from
9453 other protocols SHOULD ensure that any Date header field present in a
9454 message conforms to one of the HTTP/1.1 formats and rewrite the date
9457 19.4.4 Introduction of Content-Encoding
9459 RFC 2045 does not include any concept equivalent to HTTP/1.1's
9460 Content-Encoding header field. Since this acts as a modifier on the
9461 media type, proxies and gateways from HTTP to MIME-compliant
9462 protocols MUST either change the value of the Content-Type header
9463 field or decode the entity-body before forwarding the message. (Some
9464 experimental applications of Content-Type for Internet mail have used
9465 a media-type parameter of ";conversions=<content-coding>" to perform
9466 a function equivalent to Content-Encoding. However, this parameter is
9467 not part of RFC 2045.)
9469 19.4.5 No Content-Transfer-Encoding
9471 HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
9472 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
9473 remove any non-identity CTE ("quoted-printable" or "base64") encoding
9474 prior to delivering the response message to an HTTP client.
9476 [[ "MUST remove any CTE encoding prior to delivering the response ]]
9477 [[ message to an HTTP client." ]]
9479 Proxies and gateways from HTTP to MIME-compliant protocols are
9480 responsible for ensuring that the message is in the correct format
9481 and encoding for safe transport on that protocol, where "safe
9485 Fielding, et al. Standards Track [Page 168]
9487 RFC 2616 HTTP/1.1 June 1999
9490 transport" is defined by the limitations of the protocol being used.
9491 Such a proxy or gateway SHOULD label the data with an appropriate
9492 Content-Transfer-Encoding if doing so will improve the likelihood of
9493 safe transport over the destination protocol.
9495 19.4.6 Introduction of Transfer-Encoding
9497 HTTP/1.1 introduces the Transfer-Encoding header field (section
9498 14.41). Proxies/gateways MUST remove any transfer-coding prior to
9499 forwarding a message via a MIME-compliant protocol.
9501 A process for decoding the "chunked" transfer-coding (section 3.6)
9502 can be represented in pseudo-code as:
9505 read chunk-size, chunk-extension (if any) and CRLF
9506 while (chunk-size > 0) {
9507 read chunk-data and CRLF
9508 append chunk-data to entity-body
9509 length := length + chunk-size
9510 read chunk-size and CRLF
9513 while (entity-header not empty) {
9514 append entity-header to existing header fields
9517 Content-Length := length
9518 Remove "chunked" from Transfer-Encoding
9520 19.4.7 MHTML and Line Length Limitations
9522 HTTP implementations which share code with MHTML [45] implementations
9523 need to be aware of MIME line length limitations. Since HTTP does not
9524 have this limitation, HTTP does not fold long lines. MHTML messages
9525 being transported by HTTP follow all conventions of MHTML, including
9526 line length limitations and folding, canonicalization, etc., since
9527 HTTP transports all message-bodies as payload (see section 3.7.2) and
9528 does not interpret the content or any MIME header lines that might be
9531 19.5 Additional Features
9533 RFC 1945 and RFC 2068 document protocol elements used by some
9534 existing HTTP implementations, but not consistently and correctly
9535 across most HTTP/1.1 applications. Implementors are advised to be
9536 aware of these features, but cannot rely upon their presence in, or
9537 interoperability with, other HTTP/1.1 applications. Some of these
9541 Fielding, et al. Standards Track [Page 169]
9543 RFC 2616 HTTP/1.1 June 1999
9546 describe proposed experimental features, and some describe features
9547 that experimental deployment found lacking that are now addressed in
9548 the base HTTP/1.1 specification.
9550 A number of other headers, such as Content-Disposition and Title,
9551 from SMTP and MIME are also often implemented (see RFC 2076 [37]).
9553 19.5.1 Content-Disposition
9555 The Content-Disposition response-header field has been proposed as a
9556 means for the origin server to suggest a default filename if the user
9557 requests that the content is saved to a file. This usage is derived
9558 from the definition of Content-Disposition in RFC 1806 [35].
9560 content-disposition = "Content-Disposition" ":"
9561 disposition-type *( ";" disposition-parm )
9562 disposition-type = "attachment" | disp-extension-token
9563 disposition-parm = filename-parm | disp-extension-parm
9564 filename-parm = "filename" "=" quoted-string
9565 disp-extension-token = token
9566 disp-extension-parm = token "=" ( token | quoted-string )
9570 Content-Disposition: attachment; filename="fname.ext"
9572 The receiving user agent SHOULD NOT respect any directory path
9573 information present in the filename-parm parameter, which is the only
9574 parameter believed to apply to HTTP implementations at this time. The
9575 filename SHOULD be treated as a terminal component only.
9577 If this header is used in a response with the application/octet-
9578 stream content-type, the implied suggestion is that the user agent
9579 should not display the response, but directly enter a `save response
9582 See section 15.5 for Content-Disposition security issues.
9584 19.6 Compatibility with Previous Versions
9586 It is beyond the scope of a protocol specification to mandate
9587 compliance with previous versions. HTTP/1.1 was deliberately
9588 designed, however, to make supporting previous versions easy. It is
9589 worth noting that, at the time of composing this specification
9590 (1996), we would expect commercial HTTP/1.1 servers to:
9592 - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
9597 Fielding, et al. Standards Track [Page 170]
9599 RFC 2616 HTTP/1.1 June 1999
9602 - understand any valid request in the format of HTTP/0.9, 1.0, or
9605 - respond appropriately with a message in the same major version
9608 And we would expect HTTP/1.1 clients to:
9610 - recognize the format of the Status-Line for HTTP/1.0 and 1.1
9613 - understand any valid response in the format of HTTP/0.9, 1.0, or
9616 For most implementations of HTTP/1.0, each connection is established
9617 by the client prior to the request and closed by the server after
9618 sending the response. Some implementations implement the Keep-Alive
9619 version of persistent connections described in section 19.7.1 of RFC
9622 19.6.1 Changes from HTTP/1.0
9624 This section summarizes major differences between versions HTTP/1.0
9627 19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
9630 The requirements that clients and servers support the Host request-
9631 header, report an error if the Host request-header (section 14.23) is
9632 missing from an HTTP/1.1 request, and accept absolute URIs (section
9633 5.1.2) are among the most important changes defined by this
9636 Older HTTP/1.0 clients assumed a one-to-one relationship of IP
9637 addresses and servers; there was no other established mechanism for
9638 distinguishing the intended server of a request than the IP address
9639 to which that request was directed. The changes outlined above will
9640 allow the Internet, once older HTTP clients are no longer common, to
9641 support multiple Web sites from a single IP address, greatly
9642 simplifying large operational Web servers, where allocation of many
9643 IP addresses to a single host has created serious problems. The
9644 Internet will also be able to recover the IP addresses that have been
9645 allocated for the sole purpose of allowing special-purpose domain
9646 names to be used in root-level HTTP URLs. Given the rate of growth of
9647 the Web, and the number of servers already deployed, it is extremely
9653 Fielding, et al. Standards Track [Page 171]
9655 RFC 2616 HTTP/1.1 June 1999
9658 important that all implementations of HTTP (including updates to
9659 existing HTTP/1.0 applications) correctly implement these
9662 - Both clients and servers MUST support the Host request-header.
9664 - A client that sends an HTTP/1.1 request MUST send a Host header.
9666 - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
9667 request does not include a Host request-header.
9669 - Servers MUST accept absolute URIs.
9671 19.6.2 Compatibility with HTTP/1.0 Persistent Connections
9673 Some clients and servers might wish to be compatible with some
9674 previous implementations of persistent connections in HTTP/1.0
9675 clients and servers. Persistent connections in HTTP/1.0 are
9676 explicitly negotiated as they are not the default behavior. HTTP/1.0
9677 experimental implementations of persistent connections are faulty,
9678 and the new facilities in HTTP/1.1 are designed to rectify these
9679 problems. The problem was that some existing 1.0 clients may be
9680 sending Keep-Alive to a proxy server that doesn't understand
9681 Connection, which would then erroneously forward it to the next
9682 inbound server, which would establish the Keep-Alive connection and
9683 result in a hung HTTP/1.0 proxy waiting for the close on the
9684 response. The result is that HTTP/1.0 clients must be prevented from
9685 using Keep-Alive when talking to proxies.
9687 However, talking to proxies is the most important use of persistent
9688 connections, so that prohibition is clearly unacceptable. Therefore,
9689 we need some other mechanism for indicating a persistent connection
9690 is desired, which is safe to use even when talking to an old proxy
9691 that ignores Connection. Persistent connections are the default for
9692 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
9693 declaring non-persistence. See section 14.10.
9695 The original HTTP/1.0 form of persistent connections (the Connection:
9696 Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
9698 19.6.3 Changes from RFC 2068
9700 This specification has been carefully audited to correct and
9701 disambiguate key word usage; RFC 2068 had many problems in respect to
9702 the conventions laid out in RFC 2119 [34].
9704 Clarified which error code should be used for inbound server failures
9705 (e.g. DNS failures). (Section 10.5.5).
9709 Fielding, et al. Standards Track [Page 172]
9711 RFC 2616 HTTP/1.1 June 1999
9714 CREATE had a race that required an Etag be sent when a resource is
9715 first created. (Section 10.2.2).
9717 Content-Base was deleted from the specification: it was not
9718 implemented widely, and there is no simple, safe way to introduce it
9719 without a robust extension mechanism. In addition, it is used in a
9720 similar, but not identical fashion in MHTML [45].
9722 Transfer-coding and message lengths all interact in ways that
9723 required fixing exactly when chunked encoding is used (to allow for
9724 transfer encoding that may not be self delimiting); it was important
9725 to straighten out exactly how message lengths are computed. (Sections
9726 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
9728 A content-coding of "identity" was introduced, to solve problems
9729 discovered in caching. (section 3.5)
9731 Quality Values of zero should indicate that "I don't want something"
9732 to allow clients to refuse a representation. (Section 3.9)
9734 The use and interpretation of HTTP version numbers has been clarified
9735 by RFC 2145. Require proxies to upgrade requests to highest protocol
9736 version they support to deal with problems discovered in HTTP/1.0
9737 implementations (Section 3.1)
9739 Charset wildcarding is introduced to avoid explosion of character set
9740 names in accept headers. (Section 14.2)
9742 A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
9743 was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
9746 The Cache-Control: max-age directive was not properly defined for
9747 responses. (Section 14.9.3)
9749 There are situations where a server (especially a proxy) does not
9750 know the full length of a response but is capable of serving a
9751 byterange request. We therefore need a mechanism to allow byteranges
9752 with a content-range not indicating the full length of the message.
9755 Range request responses would become very verbose if all meta-data
9756 were always returned; by allowing the server to only send needed
9757 headers in a 206 response, this problem can be avoided. (Section
9758 10.2.7, 13.5.3, and 14.27)
9765 Fielding, et al. Standards Track [Page 173]
9767 RFC 2616 HTTP/1.1 June 1999
9770 Fix problem with unsatisfiable range requests; there are two cases:
9771 syntactic problems, and range doesn't exist in the document. The 416
9772 status code was needed to resolve this ambiguity needed to indicate
9773 an error for a byte range request that falls outside of the actual
9774 contents of a document. (Section 10.4.17, 14.16)
9776 Rewrite of message transmission requirements to make it much harder
9777 for implementors to get it wrong, as the consequences of errors here
9778 can have significant impact on the Internet, and to deal with the
9781 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
9782 this was incorrectly placing a requirement on the behavior of
9783 an implementation of a future version of HTTP/1.x
9785 2. Made it clear that user-agents should retry requests, not
9786 "clients" in general.
9788 3. Converted requirements for clients to ignore unexpected 100
9789 (Continue) responses, and for proxies to forward 100 responses,
9790 into a general requirement for 1xx responses.
9792 4. Modified some TCP-specific language, to make it clearer that
9793 non-TCP transports are possible for HTTP.
9795 5. Require that the origin server MUST NOT wait for the request
9796 body before it sends a required 100 (Continue) response.
9798 6. Allow, rather than require, a server to omit 100 (Continue) if
9799 it has already seen some of the request body.
9801 7. Allow servers to defend against denial-of-service attacks and
9804 This change adds the Expect header and 417 status code. The message
9805 transmission requirements fixes are in sections 8.2, 10.4.18,
9806 8.1.2.2, 13.11, and 14.20.
9808 Proxies should be able to add Content-Length when appropriate.
9811 Clean up confusion between 403 and 404 responses. (Section 10.4.4,
9812 10.4.5, and 10.4.11)
9814 Warnings could be cached incorrectly, or not updated appropriately.
9815 (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
9816 also needed to be a general header, as PUT or other methods may have
9817 need for it in requests.
9821 Fielding, et al. Standards Track [Page 174]
9823 RFC 2616 HTTP/1.1 June 1999
9826 Transfer-coding had significant problems, particularly with
9827 interactions with chunked encoding. The solution is that transfer-
9828 codings become as full fledged as content-codings. This involves
9829 adding an IANA registry for transfer-codings (separate from content
9830 codings), a new header field (TE) and enabling trailer headers in the
9831 future. Transfer encoding is a major performance benefit, so it was
9832 worth fixing [39]. TE also solves another, obscure, downward
9833 interoperability problem that could have occurred due to interactions
9834 between authentication trailers, chunked encoding and HTTP/1.0
9835 clients.(Section 3.6, 3.6.1, and 14.39)
9837 The PATCH, LINK, UNLINK methods were defined but not commonly
9838 implemented in previous versions of this specification. See RFC 2068
9841 The Alternates, Content-Version, Derived-From, Link, URI, Public and
9842 Content-Base header fields were defined in previous versions of this
9843 specification, but not commonly implemented. See RFC 2068 [33].
9847 Please see the PostScript version of this RFC for the INDEX.
9877 Fielding, et al. Standards Track [Page 175]
9879 RFC 2616 HTTP/1.1 June 1999
9882 21. Full Copyright Statement
9884 Copyright (C) The Internet Society (1999). All Rights Reserved.
9886 This document and translations of it may be copied and furnished to
9887 others, and derivative works that comment on or otherwise explain it
9888 or assist in its implementation may be prepared, copied, published
9889 and distributed, in whole or in part, without restriction of any
9890 kind, provided that the above copyright notice and this paragraph are
9891 included on all such copies and derivative works. However, this
9892 document itself may not be modified in any way, such as by removing
9893 the copyright notice or references to the Internet Society or other
9894 Internet organizations, except as needed for the purpose of
9895 developing Internet standards in which case the procedures for
9896 copyrights defined in the Internet Standards process must be
9897 followed, or as required to translate it into languages other than
9900 The limited permissions granted above are perpetual and will not be
9901 revoked by the Internet Society or its successors or assigns.
9903 This document and the information contained herein is provided on an
9904 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
9905 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
9906 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
9907 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
9908 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9912 Funding for the RFC Editor function is currently provided by the
9933 Fielding, et al. Standards Track [Page 176]
projects / profile / ivi / libsoup2.4.git / blob