7Network Working Group R. Fielding
8Request for Comments: 2616 UC Irvine
9Obsoletes: 2068 J. Gettys
10Category: Standards Track Compaq/W3C
24 Hypertext Transfer Protocol -- HTTP/1.1
28 This document specifies an Internet standards track protocol for the
29 Internet community, and requests discussion and suggestions for
30 improvements. Please refer to the current edition of the "Internet
31 Official Protocol Standards" (STD 1) for the standardization state
32 and status of this protocol. Distribution of this memo is unlimited.
36 Copyright (C) The Internet Society (1999). All Rights Reserved.
40 The Hypertext Transfer Protocol (HTTP) is an application-level
41 protocol for distributed, collaborative, hypermedia information
42 systems. It is a generic, stateless, protocol which can be used for
43 many tasks beyond its use for hypertext, such as name servers and
44 distributed object management systems, through extension of its
45 request methods, error codes and headers [47]. A feature of HTTP is
46 the typing and negotiation of data representation, allowing systems
47 to be built independently of the data being transferred.
49 HTTP has been in use by the World-Wide Web global information
50 initiative since 1990. This specification defines the protocol
51 referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
58Fielding, et al. Standards Track [Page 1]
60RFC 2616 HTTP/1.1 June 1999
65 1 Introduction ...................................................7
66 1.1 Purpose......................................................7
67 1.2 Requirements .................................................8
68 1.3 Terminology ..................................................8
69 1.4 Overall Operation ...........................................12
70 2 Notational Conventions and Generic Grammar ....................14
71 2.1 Augmented BNF ...............................................14
72 2.2 Basic Rules .................................................15
73 3 Protocol Parameters ...........................................17
74 3.1 HTTP Version ................................................17
75 3.2 Uniform Resource Identifiers ................................18
76 3.2.1 General Syntax ...........................................19
77 3.2.2 http URL .................................................19
78 3.2.3 URI Comparison ...........................................20
79 3.3 Date/Time Formats ...........................................20
80 3.3.1 Full Date ................................................20
81 3.3.2 Delta Seconds ............................................21
82 3.4 Character Sets ..............................................21
83 3.4.1 Missing Charset ..........................................22
84 3.5 Content Codings .............................................23
85 3.6 Transfer Codings ............................................24
86 3.6.1 Chunked Transfer Coding ..................................25
87 3.7 Media Types .................................................26
88 3.7.1 Canonicalization and Text Defaults .......................27
89 3.7.2 Multipart Types ..........................................27
90 3.8 Product Tokens ..............................................28
91 3.9 Quality Values ..............................................29
92 3.10 Language Tags ...............................................29
93 3.11 Entity Tags .................................................30
94 3.12 Range Units .................................................30
95 4 HTTP Message ..................................................31
96 4.1 Message Types ...............................................31
97 4.2 Message Headers .............................................31
98 4.3 Message Body ................................................32
99 4.4 Message Length ..............................................33
100 4.5 General Header Fields .......................................34
101 5 Request .......................................................35
102 5.1 Request-Line ................................................35
103 5.1.1 Method ...................................................36
104 5.1.2 Request-URI ..............................................36
105 5.2 The Resource Identified by a Request ........................38
106 5.3 Request Header Fields .......................................38
107 6 Response ......................................................39
108 6.1 Status-Line .................................................39
109 6.1.1 Status Code and Reason Phrase ............................39
110 6.2 Response Header Fields ......................................41
114Fielding, et al. Standards Track [Page 2]
116RFC 2616 HTTP/1.1 June 1999
119 7 Entity ........................................................42
120 7.1 Entity Header Fields ........................................42
121 7.2 Entity Body .................................................43
122 7.2.1 Type .....................................................43
123 7.2.2 Entity Length ............................................43
124 8 Connections ...................................................44
125 8.1 Persistent Connections ......................................44
126 8.1.1 Purpose ..................................................44
127 8.1.2 Overall Operation ........................................45
128 8.1.3 Proxy Servers ............................................46
129 8.1.4 Practical Considerations .................................46
130 8.2 Message Transmission Requirements ...........................47
131 8.2.1 Persistent Connections and Flow Control ..................47
132 8.2.2 Monitoring Connections for Error Status Messages .........48
133 8.2.3 Use of the 100 (Continue) Status .........................48
134 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
135 9 Method Definitions ............................................51
136 9.1 Safe and Idempotent Methods .................................51
137 9.1.1 Safe Methods .............................................51
138 9.1.2 Idempotent Methods .......................................51
139 9.2 OPTIONS .....................................................52
140 9.3 GET .........................................................53
141 9.4 HEAD ........................................................54
142 9.5 POST ........................................................54
143 9.6 PUT .........................................................55
144 9.7 DELETE ......................................................56
145 9.8 TRACE .......................................................56
146 9.9 CONNECT .....................................................57
147 10 Status Code Definitions ......................................57
148 10.1 Informational 1xx ...........................................57
149 10.1.1 100 Continue .............................................58
150 10.1.2 101 Switching Protocols ..................................58
151 10.2 Successful 2xx ..............................................58
152 10.2.1 200 OK ...................................................58
153 10.2.2 201 Created ..............................................59
154 10.2.3 202 Accepted .............................................59
155 10.2.4 203 Non-Authoritative Information ........................59
156 10.2.5 204 No Content ...........................................60
157 10.2.6 205 Reset Content ........................................60
158 10.2.7 206 Partial Content ......................................60
159 10.3 Redirection 3xx .............................................61
160 10.3.1 300 Multiple Choices .....................................61
161 10.3.2 301 Moved Permanently ....................................62
162 10.3.3 302 Found ................................................62
163 10.3.4 303 See Other ............................................63
164 10.3.5 304 Not Modified .........................................63
165 10.3.6 305 Use Proxy ............................................64
166 10.3.7 306 (Unused) .............................................64
170Fielding, et al. Standards Track [Page 3]
172RFC 2616 HTTP/1.1 June 1999
175 10.3.8 307 Temporary Redirect ...................................65
176 10.4 Client Error 4xx ............................................65
177 10.4.1 400 Bad Request .........................................65
178 10.4.2 401 Unauthorized ........................................66
179 10.4.3 402 Payment Required ....................................66
180 10.4.4 403 Forbidden ...........................................66
181 10.4.5 404 Not Found ...........................................66
182 10.4.6 405 Method Not Allowed ..................................66
183 10.4.7 406 Not Acceptable ......................................67
184 10.4.8 407 Proxy Authentication Required .......................67
185 10.4.9 408 Request Timeout .....................................67
186 10.4.10 409 Conflict ............................................67
187 10.4.11 410 Gone ................................................68
188 10.4.12 411 Length Required .....................................68
189 10.4.13 412 Precondition Failed .................................68
190 10.4.14 413 Request Entity Too Large ............................69
191 10.4.15 414 Request-URI Too Long ................................69
192 10.4.16 415 Unsupported Media Type ..............................69
193 10.4.17 416 Requested Range Not Satisfiable .....................69
194 10.4.18 417 Expectation Failed ..................................70
195 10.5 Server Error 5xx ............................................70
196 10.5.1 500 Internal Server Error ................................70
197 10.5.2 501 Not Implemented ......................................70
198 10.5.3 502 Bad Gateway ..........................................70
199 10.5.4 503 Service Unavailable ..................................70
200 10.5.5 504 Gateway Timeout ......................................71
201 10.5.6 505 HTTP Version Not Supported ...........................71
202 11 Access Authentication ........................................71
203 12 Content Negotiation ..........................................71
204 12.1 Server-driven Negotiation ...................................72
205 12.2 Agent-driven Negotiation ....................................73
206 12.3 Transparent Negotiation .....................................74
207 13 Caching in HTTP ..............................................74
208 13.1.1 Cache Correctness ........................................75
209 13.1.2 Warnings .................................................76
210 13.1.3 Cache-control Mechanisms .................................77
211 13.1.4 Explicit User Agent Warnings .............................78
212 13.1.5 Exceptions to the Rules and Warnings .....................78
213 13.1.6 Client-controlled Behavior ...............................79
214 13.2 Expiration Model ............................................79
215 13.2.1 Server-Specified Expiration ..............................79
216 13.2.2 Heuristic Expiration .....................................80
217 13.2.3 Age Calculations .........................................80
218 13.2.4 Expiration Calculations ..................................83
219 13.2.5 Disambiguating Expiration Values .........................84
220 13.2.6 Disambiguating Multiple Responses ........................84
221 13.3 Validation Model ............................................85
222 13.3.1 Last-Modified Dates ......................................86
226Fielding, et al. Standards Track [Page 4]
228RFC 2616 HTTP/1.1 June 1999
231 13.3.2 Entity Tag Cache Validators ..............................86
232 13.3.3 Weak and Strong Validators ...............................86
233 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
234 13.3.5 Non-validating Conditionals ..............................90
235 13.4 Response Cacheability .......................................91
236 13.5 Constructing Responses From Caches ..........................92
237 13.5.1 End-to-end and Hop-by-hop Headers ........................92
238 13.5.2 Non-modifiable Headers ...................................92
239 13.5.3 Combining Headers ........................................94
240 13.5.4 Combining Byte Ranges ....................................95
241 13.6 Caching Negotiated Responses ................................95
242 13.7 Shared and Non-Shared Caches ................................96
243 13.8 Errors or Incomplete Response Cache Behavior ................97
244 13.9 Side Effects of GET and HEAD ................................97
245 13.10 Invalidation After Updates or Deletions ...................97
246 13.11 Write-Through Mandatory ...................................98
247 13.12 Cache Replacement .........................................99
248 13.13 History Lists .............................................99
249 14 Header Field Definitions ....................................100
250 14.1 Accept .....................................................100
251 14.2 Accept-Charset .............................................102
252 14.3 Accept-Encoding ............................................102
253 14.4 Accept-Language ............................................104
254 14.5 Accept-Ranges ..............................................105
255 14.6 Age ........................................................106
256 14.7 Allow ......................................................106
257 14.8 Authorization ..............................................107
258 14.9 Cache-Control ..............................................108
259 14.9.1 What is Cacheable .......................................109
260 14.9.2 What May be Stored by Caches ............................110
261 14.9.3 Modifications of the Basic Expiration Mechanism .........111
262 14.9.4 Cache Revalidation and Reload Controls ..................113
263 14.9.5 No-Transform Directive ..................................115
264 14.9.6 Cache Control Extensions ................................116
265 14.10 Connection ...............................................117
266 14.11 Content-Encoding .........................................118
267 14.12 Content-Language .........................................118
268 14.13 Content-Length ...........................................119
269 14.14 Content-Location .........................................120
270 14.15 Content-MD5 ..............................................121
271 14.16 Content-Range ............................................122
272 14.17 Content-Type .............................................124
273 14.18 Date .....................................................124
274 14.18.1 Clockless Origin Server Operation ......................125
275 14.19 ETag .....................................................126
276 14.20 Expect ...................................................126
277 14.21 Expires ..................................................127
278 14.22 From .....................................................128
282Fielding, et al. Standards Track [Page 5]
284RFC 2616 HTTP/1.1 June 1999
287 14.23 Host .....................................................128
288 14.24 If-Match .................................................129
289 14.25 If-Modified-Since ........................................130
290 14.26 If-None-Match ............................................132
291 14.27 If-Range .................................................133
292 14.28 If-Unmodified-Since ......................................134
293 14.29 Last-Modified ............................................134
294 14.30 Location .................................................135
295 14.31 Max-Forwards .............................................136
296 14.32 Pragma ...................................................136
297 14.33 Proxy-Authenticate .......................................137
298 14.34 Proxy-Authorization ......................................137
299 14.35 Range ....................................................138
300 14.35.1 Byte Ranges ...........................................138
301 14.35.2 Range Retrieval Requests ..............................139
302 14.36 Referer ..................................................140
303 14.37 Retry-After ..............................................141
304 14.38 Server ...................................................141
305 14.39 TE .......................................................142
306 14.40 Trailer ..................................................143
307 14.41 Transfer-Encoding..........................................143
308 14.42 Upgrade ..................................................144
309 14.43 User-Agent ...............................................145
310 14.44 Vary .....................................................145
311 14.45 Via ......................................................146
312 14.46 Warning ..................................................148
313 14.47 WWW-Authenticate .........................................150
314 15 Security Considerations .......................................150
315 15.1 Personal Information....................................151
316 15.1.1 Abuse of Server Log Information .........................151
317 15.1.2 Transfer of Sensitive Information .......................151
318 15.1.3 Encoding Sensitive Information in URI's .................152
319 15.1.4 Privacy Issues Connected to Accept Headers ..............152
320 15.2 Attacks Based On File and Path Names .......................153
321 15.3 DNS Spoofing ...............................................154
322 15.4 Location Headers and Spoofing ..............................154
323 15.5 Content-Disposition Issues .................................154
324 15.6 Authentication Credentials and Idle Clients ................155
325 15.7 Proxies and Caching ........................................155
326 15.7.1 Denial of Service Attacks on Proxies....................156
327 16 Acknowledgments .............................................156
328 17 References ..................................................158
329 18 Authors' Addresses ..........................................162
330 19 Appendices ..................................................164
331 19.1 Internet Media Type message/http and application/http ......164
332 19.2 Internet Media Type multipart/byteranges ...................165
333 19.3 Tolerant Applications ......................................166
334 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
338Fielding, et al. Standards Track [Page 6]
340RFC 2616 HTTP/1.1 June 1999
343 19.4.1 MIME-Version ............................................167
344 19.4.2 Conversion to Canonical Form ............................167
345 19.4.3 Conversion of Date Formats ..............................168
346 19.4.4 Introduction of Content-Encoding ........................168
347 19.4.5 No Content-Transfer-Encoding ............................168
348 19.4.6 Introduction of Transfer-Encoding .......................169
349 19.4.7 MHTML and Line Length Limitations .......................169
350 19.5 Additional Features ........................................169
351 19.5.1 Content-Disposition .....................................170
352 19.6 Compatibility with Previous Versions .......................170
353 19.6.1 Changes from HTTP/1.0 ...................................171
354 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
355 19.6.3 Changes from RFC 2068 ...................................172
356 20 Index .......................................................175
357 21 Full Copyright Statement ....................................176
363 The Hypertext Transfer Protocol (HTTP) is an application-level
364 protocol for distributed, collaborative, hypermedia information
365 systems. HTTP has been in use by the World-Wide Web global
366 information initiative since 1990. The first version of HTTP,
367 referred to as HTTP/0.9, was a simple protocol for raw data transfer
368 across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
369 the protocol by allowing messages to be in the format of MIME-like
370 messages, containing metainformation about the data transferred and
371 modifiers on the request/response semantics. However, HTTP/1.0 does
372 not sufficiently take into consideration the effects of hierarchical
373 proxies, caching, the need for persistent connections, or virtual
374 hosts. In addition, the proliferation of incompletely-implemented
375 applications calling themselves "HTTP/1.0" has necessitated a
376 protocol version change in order for two communicating applications
377 to determine each other's true capabilities.
379 This specification defines the protocol referred to as "HTTP/1.1".
380 This protocol includes more stringent requirements than HTTP/1.0 in
381 order to ensure reliable implementation of its features.
383 Practical information systems require more functionality than simple
384 retrieval, including search, front-end update, and annotation. HTTP
385 allows an open-ended set of methods and headers that indicate the
386 purpose of a request [47]. It builds on the discipline of reference
387 provided by the Uniform Resource Identifier (URI) [3], as a location
388 (URL) [4] or name (URN) [20], for indicating the resource to which a
394Fielding, et al. Standards Track [Page 7]
396RFC 2616 HTTP/1.1 June 1999
399 method is to be applied. Messages are passed in a format similar to
400 that used by Internet mail [9] as defined by the Multipurpose
401 Internet Mail Extensions (MIME) [7].
403 HTTP is also used as a generic protocol for communication between
404 user agents and proxies/gateways to other Internet systems, including
405 those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
406 and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
407 access to resources available from diverse applications.
411 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
412 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
413 document are to be interpreted as described in RFC 2119 [34].
415 An implementation is not compliant if it fails to satisfy one or more
416 of the MUST or REQUIRED level requirements for the protocols it
417 implements. An implementation that satisfies all the MUST or REQUIRED
418 level and all the SHOULD level requirements for its protocols is said
419 to be "unconditionally compliant"; one that satisfies all the MUST
420 level requirements but not all the SHOULD level requirements for its
421 protocols is said to be "conditionally compliant."
425 This specification uses a number of terms to refer to the roles
426 played by participants in, and objects of, the HTTP communication.
429 A transport layer virtual circuit established between two programs
430 for the purpose of communication.
433 The basic unit of HTTP communication, consisting of a structured
434 sequence of octets matching the syntax defined in section 4 and
435 transmitted via the connection.
438 An HTTP request message, as defined in section 5.
441 An HTTP response message, as defined in section 6.
450Fielding, et al. Standards Track [Page 8]
452RFC 2616 HTTP/1.1 June 1999
456 A network data object or service that can be identified by a URI,
457 as defined in section 3.2. Resources may be available in multiple
458 representations (e.g. multiple languages, data formats, size, and
459 resolutions) or vary in other ways.
462 The information transferred as the payload of a request or
463 response. An entity consists of metainformation in the form of
464 entity-header fields and content in the form of an entity-body, as
465 described in section 7.
468 An entity included with a response that is subject to content
469 negotiation, as described in section 12. There may exist multiple
470 representations associated with a particular response status.
473 The mechanism for selecting the appropriate representation when
474 servicing a request, as described in section 12. The
475 representation of entities in any response can be negotiated
476 (including error responses).
479 A resource may have one, or more than one, representation(s)
480 associated with it at any given instant. Each of these
481 representations is termed a `varriant'. Use of the term `variant'
482 does not necessarily imply that the resource is subject to content
486 A program that establishes connections for the purpose of sending
490 The client which initiates a request. These are often browsers,
491 editors, spiders (web-traversing robots), or other end user tools.
494 An application program that accepts connections in order to
495 service requests by sending back responses. Any given program may
496 be capable of being both a client and a server; our use of these
497 terms refers only to the role being performed by the program for a
498 particular connection, rather than to the program's capabilities
499 in general. Likewise, any server may act as an origin server,
500 proxy, gateway, or tunnel, switching behavior based on the nature
506Fielding, et al. Standards Track [Page 9]
508RFC 2616 HTTP/1.1 June 1999
512 The server on which a given resource resides or is to be created.
515 An intermediary program which acts as both a server and a client
516 for the purpose of making requests on behalf of other clients.
517 Requests are serviced internally or by passing them on, with
518 possible translation, to other servers. A proxy MUST implement
519 both the client and server requirements of this specification. A
520 "transparent proxy" is a proxy that does not modify the request or
521 response beyond what is required for proxy authentication and
522 identification. A "non-transparent proxy" is a proxy that modifies
523 the request or response in order to provide some added service to
524 the user agent, such as group annotation services, media type
525 transformation, protocol reduction, or anonymity filtering. Except
526 where either transparent or non-transparent behavior is explicitly
527 stated, the HTTP proxy requirements apply to both types of
531 A server which acts as an intermediary for some other server.
532 Unlike a proxy, a gateway receives requests as if it were the
533 origin server for the requested resource; the requesting client
534 may not be aware that it is communicating with a gateway.
537 An intermediary program which is acting as a blind relay between
538 two connections. Once active, a tunnel is not considered a party
539 to the HTTP communication, though the tunnel may have been
540 initiated by an HTTP request. The tunnel ceases to exist when both
541 ends of the relayed connections are closed.
544 A program's local store of response messages and the subsystem
545 that controls its message storage, retrieval, and deletion. A
546 cache stores cacheable responses in order to reduce the response
547 time and network bandwidth consumption on future, equivalent
548 requests. Any client or server may include a cache, though a cache
549 cannot be used by a server that is acting as a tunnel.
552 A response is cacheable if a cache is allowed to store a copy of
553 the response message for use in answering subsequent requests. The
554 rules for determining the cacheability of HTTP responses are
555 defined in section 13. Even if a resource is cacheable, there may
556 be additional constraints on whether a cache can use the cached
557 copy for a particular request.
562Fielding, et al. Standards Track [Page 10]
564RFC 2616 HTTP/1.1 June 1999
568 A response is first-hand if it comes directly and without
569 unnecessary delay from the origin server, perhaps via one or more
570 proxies. A response is also first-hand if its validity has just
571 been checked directly with the origin server.
573 explicit expiration time
574 The time at which the origin server intends that an entity should
575 no longer be returned by a cache without further validation.
577 heuristic expiration time
578 An expiration time assigned by a cache when no explicit expiration
582 The age of a response is the time since it was sent by, or
583 successfully validated with, the origin server.
586 The length of time between the generation of a response and its
590 A response is fresh if its age has not yet exceeded its freshness
594 A response is stale if its age has passed its freshness lifetime.
596 semantically transparent
597 A cache behaves in a "semantically transparent" manner, with
598 respect to a particular response, when its use affects neither the
599 requesting client nor the origin server, except to improve
600 performance. When a cache is semantically transparent, the client
601 receives exactly the same response (except for hop-by-hop headers)
602 that it would have received had its request been handled directly
603 by the origin server.
606 A protocol element (e.g., an entity tag or a Last-Modified time)
607 that is used to find out whether a cache entry is an equivalent
611 Upstream and downstream describe the flow of a message: all
612 messages flow from upstream to downstream.
618Fielding, et al. Standards Track [Page 11]
620RFC 2616 HTTP/1.1 June 1999
624 Inbound and outbound refer to the request and response paths for
625 messages: "inbound" means "traveling toward the origin server",
626 and "outbound" means "traveling toward the user agent"
630 The HTTP protocol is a request/response protocol. A client sends a
631 request to the server in the form of a request method, URI, and
632 protocol version, followed by a MIME-like message containing request
633 modifiers, client information, and possible body content over a
634 connection with a server. The server responds with a status line,
635 including the message's protocol version and a success or error code,
636 followed by a MIME-like message containing server information, entity
637 metainformation, and possible entity-body content. The relationship
638 between HTTP and MIME is described in appendix 19.4.
640 Most HTTP communication is initiated by a user agent and consists of
641 a request to be applied to a resource on some origin server. In the
642 simplest case, this may be accomplished via a single connection (v)
643 between the user agent (UA) and the origin server (O).
645 request chain ------------------------>
646 UA -------------------v------------------- O
647 <----------------------- response chain
649 A more complicated situation occurs when one or more intermediaries
650 are present in the request/response chain. There are three common
651 forms of intermediary: proxy, gateway, and tunnel. A proxy is a
652 forwarding agent, receiving requests for a URI in its absolute form,
653 rewriting all or part of the message, and forwarding the reformatted
654 request toward the server identified by the URI. A gateway is a
655 receiving agent, acting as a layer above some other server(s) and, if
656 necessary, translating the requests to the underlying server's
657 protocol. A tunnel acts as a relay point between two connections
658 without changing the messages; tunnels are used when the
659 communication needs to pass through an intermediary (such as a
660 firewall) even when the intermediary cannot understand the contents
663 request chain -------------------------------------->
664 UA -----v----- A -----v----- B -----v----- C -----v----- O
665 <------------------------------------- response chain
667 The figure above shows three intermediaries (A, B, and C) between the
668 user agent and origin server. A request or response message that
669 travels the whole chain will pass through four separate connections.
670 This distinction is important because some HTTP communication options
674Fielding, et al. Standards Track [Page 12]
676RFC 2616 HTTP/1.1 June 1999
679 may apply only to the connection with the nearest, non-tunnel
680 neighbor, only to the end-points of the chain, or to all connections
681 along the chain. Although the diagram is linear, each participant may
682 be engaged in multiple, simultaneous communications. For example, B
683 may be receiving requests from many clients other than A, and/or
684 forwarding requests to servers other than C, at the same time that it
685 is handling A's request.
687 Any party to the communication which is not acting as a tunnel may
688 employ an internal cache for handling requests. The effect of a cache
689 is that the request/response chain is shortened if one of the
690 participants along the chain has a cached response applicable to that
691 request. The following illustrates the resulting chain if B has a
692 cached copy of an earlier response from O (via C) for a request which
693 has not been cached by UA or A.
695 request chain ---------->
696 UA -----v----- A -----v----- B - - - - - - C - - - - - - O
697 <--------- response chain
699 Not all responses are usefully cacheable, and some requests may
700 contain modifiers which place special requirements on cache behavior.
701 HTTP requirements for cache behavior and cacheable responses are
702 defined in section 13.
704 In fact, there are a wide variety of architectures and configurations
705 of caches and proxies currently being experimented with or deployed
706 across the World Wide Web. These systems include national hierarchies
707 of proxy caches to save transoceanic bandwidth, systems that
708 broadcast or multicast cache entries, organizations that distribute
709 subsets of cached data via CD-ROM, and so on. HTTP systems are used
710 in corporate intranets over high-bandwidth links, and for access via
711 PDAs with low-power radio links and intermittent connectivity. The
712 goal of HTTP/1.1 is to support the wide diversity of configurations
713 already deployed while introducing protocol constructs that meet the
714 needs of those who build web applications that require high
715 reliability and, failing that, at least reliable indications of
718 HTTP communication usually takes place over TCP/IP connections. The
719 default port is TCP 80 [19], but other ports can be used. This does
720 not preclude HTTP from being implemented on top of any other protocol
721 on the Internet, or on other networks. HTTP only presumes a reliable
722 transport; any protocol that provides such guarantees can be used;
723 the mapping of the HTTP/1.1 request and response structures onto the
724 transport data units of the protocol in question is outside the scope
725 of this specification.
730Fielding, et al. Standards Track [Page 13]
732RFC 2616 HTTP/1.1 June 1999
735 In HTTP/1.0, most implementations used a new connection for each
736 request/response exchange. In HTTP/1.1, a connection may be used for
737 one or more request/response exchanges, although connections may be
738 closed for a variety of reasons (see section 8.1).
7402 Notational Conventions and Generic Grammar
744 All of the mechanisms specified in this document are described in
745 both prose and an augmented Backus-Naur Form (BNF) similar to that
746 used by RFC 822 [9]. Implementors will need to be familiar with the
747 notation in order to understand this specification. The augmented BNF
748 includes the following constructs:
751 The name of a rule is simply the name itself (without any
752 enclosing "<" and ">") and is separated from its definition by the
753 equal "=" character. White space is only significant in that
754 indentation of continuation lines is used to indicate a rule
755 definition that spans more than one line. Certain basic rules are
756 in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
757 brackets are used within definitions whenever their presence will
758 facilitate discerning the use of rule names.
761 Quotation marks surround literal text. Unless stated otherwise,
762 the text is case-insensitive.
765 Elements separated by a bar ("|") are alternatives, e.g., "yes |
766 no" will accept yes or no.
769 Elements enclosed in parentheses are treated as a single element.
770 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
771 foo elem" and "elem bar elem".
774 The character "*" preceding an element indicates repetition. The
775 full form is "<n>*<m>element" indicating at least <n> and at most
776 <m> occurrences of element. Default values are 0 and infinity so
777 that "*(element)" allows any number, including zero; "1*element"
778 requires at least one; and "1*2element" allows one or two.
781 Square brackets enclose optional elements; "[foo bar]" is
782 equivalent to "*1(foo bar)".
786Fielding, et al. Standards Track [Page 14]
788RFC 2616 HTTP/1.1 June 1999
792 Specific repetition: "<n>(element)" is equivalent to
793 "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
794 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
795 alphabetic characters.
798 A construct "#" is defined, similar to "*", for defining lists of
799 elements. The full form is "<n>#<m>element" indicating at least
800 <n> and at most <m> elements, each separated by one or more commas
801 (",") and OPTIONAL linear white space (LWS). This makes the usual
802 form of lists very easy; a rule such as
803 ( *LWS element *( *LWS "," *LWS element ))
806 Wherever this construct is used, null elements are allowed, but do
807 not contribute to the count of elements present. That is,
808 "(element), , (element) " is permitted, but counts as only two
809 elements. Therefore, where at least one element is required, at
810 least one non-null element MUST be present. Default values are 0
811 and infinity so that "#element" allows any number, including zero;
812 "1#element" requires at least one; and "1#2element" allows one or
816 A semi-colon, set off some distance to the right of rule text,
817 starts a comment that continues to the end of line. This is a
818 simple way of including useful notes in parallel with the
822 The grammar described by this specification is word-based. Except
823 where noted otherwise, linear white space (LWS) can be included
824 between any two adjacent words (token or quoted-string), and
825 between adjacent words and separators, without changing the
826 interpretation of a field. At least one delimiter (LWS and/or
828 separators) MUST exist between any two tokens (for the definition
829 of "token" below), since they would otherwise be interpreted as a
834 The following rules are used throughout this specification to
835 describe basic parsing constructs. The US-ASCII coded character set
836 is defined by ANSI X3.4-1986 [21].
842Fielding, et al. Standards Track [Page 15]
844RFC 2616 HTTP/1.1 June 1999
847 OCTET = <any 8-bit sequence of data>
848 CHAR = <any US-ASCII character (octets 0 - 127)>
849 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
850 LOALPHA = <any US-ASCII lowercase letter "a".."z">
851 ALPHA = UPALPHA | LOALPHA
852 DIGIT = <any US-ASCII digit "0".."9">
853 CTL = <any US-ASCII control character
854 (octets 0 - 31) and DEL (127)>
855 CR = <US-ASCII CR, carriage return (13)>
856 LF = <US-ASCII LF, linefeed (10)>
857 SP = <US-ASCII SP, space (32)>
858 HT = <US-ASCII HT, horizontal-tab (9)>
859 <"> = <US-ASCII double-quote mark (34)>
861 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
862 protocol elements except the entity-body (see appendix 19.3 for
863 tolerant applications). The end-of-line marker within an entity-body
864 is defined by its associated media type, as described in section 3.7.
868 HTTP/1.1 header field values can be folded onto multiple lines if the
869 continuation line begins with a space or horizontal tab. All linear
870 white space, including folding, has the same semantics as SP. A
871 recipient MAY replace any linear white space with a single SP before
872 interpreting the field value or forwarding the message downstream.
874 LWS = [CRLF] 1*( SP | HT )
876 The TEXT rule is only used for descriptive field contents and values
877 that are not intended to be interpreted by the message parser. Words
878 of *TEXT MAY contain characters from character sets other than ISO-
879 8859-1 [22] only when encoded according to the rules of RFC 2047
882 TEXT = <any OCTET except CTLs,
885 A CRLF is allowed in the definition of TEXT only as part of a header
886 field continuation. It is expected that the folding LWS will be
887 replaced with a single SP before interpretation of the TEXT value.
889 Hexadecimal numeric characters are used in several protocol elements.
891 HEX = "A" | "B" | "C" | "D" | "E" | "F"
892 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
898Fielding, et al. Standards Track [Page 16]
900RFC 2616 HTTP/1.1 June 1999
903 Many HTTP/1.1 header field values consist of words separated by LWS
904 or special characters. These special characters MUST be in a quoted
905 string to be used within a parameter value (as defined in section
908 token = 1*<any CHAR except CTLs or separators>
909 separators = "(" | ")" | "<" | ">" | "@"
910 | "," | ";" | ":" | "\" | <">
911 | "/" | "[" | "]" | "?" | "="
912 | "{" | "}" | SP | HT
914 Comments can be included in some HTTP header fields by surrounding
915 the comment text with parentheses. Comments are only allowed in
916 fields containing "comment" as part of their field value definition.
917 In all other fields, parentheses are considered part of the field
920 comment = "(" *( ctext | quoted-pair | comment ) ")"
921 ctext = <any TEXT excluding "(" and ")">
923 A string of text is parsed as a single word if it is quoted using
926 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
927 qdtext = <any TEXT except <">>
929 The backslash character ("\") MAY be used as a single-character
930 quoting mechanism only within quoted-string and comment constructs.
932 quoted-pair = "\" CHAR
938 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
939 of the protocol. The protocol versioning policy is intended to allow
940 the sender to indicate the format of a message and its capacity for
941 understanding further HTTP communication, rather than the features
942 obtained via that communication. No change is made to the version
943 number for the addition of message components which do not affect
944 communication behavior or which only add to extensible field values.
945 The <minor> number is incremented when the changes made to the
946 protocol add features which do not change the general message parsing
947 algorithm, but which may add to the message semantics and imply
948 additional capabilities of the sender. The <major> number is
949 incremented when the format of a message within the protocol is
950 changed. See RFC 2145 [36] for a fuller explanation.
954Fielding, et al. Standards Track [Page 17]
956RFC 2616 HTTP/1.1 June 1999
959 The version of an HTTP message is indicated by an HTTP-Version field
960 in the first line of the message.
962 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
964 Note that the major and minor numbers MUST be treated as separate
965 integers and that each MAY be incremented higher than a single digit.
966 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
967 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
970 An application that sends a request or response message that includes
971 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
972 with this specification. Applications that are at least conditionally
973 compliant with this specification SHOULD use an HTTP-Version of
974 "HTTP/1.1" in their messages, and MUST do so for any message that is
975 not compatible with HTTP/1.0. For more details on when to send
976 specific HTTP-Version values, see RFC 2145 [36].
978 The HTTP version of an application is the highest HTTP version for
979 which the application is at least conditionally compliant.
981 Proxy and gateway applications need to be careful when forwarding
982 messages in protocol versions different from that of the application.
983 Since the protocol version indicates the protocol capability of the
984 sender, a proxy/gateway MUST NOT send a message with a version
985 indicator which is greater than its actual version. If a higher
986 version request is received, the proxy/gateway MUST either downgrade
987 the request version, or respond with an error, or switch to tunnel
990 Due to interoperability problems with HTTP/1.0 proxies discovered
991 since the publication of RFC 2068[33], caching proxies MUST, gateways
992 MAY, and tunnels MUST NOT upgrade the request to the highest version
993 they support. The proxy/gateway's response to that request MUST be in
994 the same major version as the request.
996 Note: Converting between versions of HTTP may involve modification
997 of header fields required or forbidden by the versions involved.
9993.2 Uniform Resource Identifiers
1001 URIs have been known by many names: WWW addresses, Universal Document
1002 Identifiers, Universal Resource Identifiers [3], and finally the
1003 combination of Uniform Resource Locators (URL) [4] and Names (URN)
1004 [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
1005 simply formatted strings which identify--via name, location, or any
1006 other characteristic--a resource.
1010Fielding, et al. Standards Track [Page 18]
1012RFC 2616 HTTP/1.1 June 1999
1017 URIs in HTTP can be represented in absolute form or relative to some
1018 known base URI [11], depending upon the context of their use. The two
1019 forms are differentiated by the fact that absolute URIs always begin
1020 with a scheme name followed by a colon. For definitive information on
1021 URL syntax and semantics, see "Uniform Resource Identifiers (URI):
1022 Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1023 1738 [4] and RFC 1808 [11]). This specification adopts the
1024 definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
1025 "host","abs_path", "rel_path", and "authority" from that
1028 The HTTP protocol does not place any a priori limit on the length of
1029 a URI. Servers MUST be able to handle the URI of any resource they
1030 serve, and SHOULD be able to handle URIs of unbounded length if they
1031 provide GET-based forms that could generate such URIs. A server
1032 SHOULD return 414 (Request-URI Too Long) status if a URI is longer
1033 than the server can handle (see section 10.4.15).
1035 Note: Servers ought to be cautious about depending on URI lengths
1036 above 255 bytes, because some older client or proxy
1037 implementations might not properly support these lengths.
1041 The "http" scheme is used to locate network resources via the HTTP
1042 protocol. This section defines the scheme-specific syntax and
1043 semantics for http URLs.
1045 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
1047 If the port is empty or not given, port 80 is assumed. The semantics
1048 are that the identified resource is located at the server listening
1049 for TCP connections on that port of that host, and the Request-URI
1050 for the resource is abs_path (section 5.1.2). The use of IP addresses
1051 in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
1052 the abs_path is not present in the URL, it MUST be given as "/" when
1053 used as a Request-URI for a resource (section 5.1.2). If a proxy
1054 receives a host name which is not a fully qualified domain name, it
1055 MAY add its domain to the host name it received. If a proxy receives
1056 a fully qualified domain name, the proxy MUST NOT change the host
1066Fielding, et al. Standards Track [Page 19]
1068RFC 2616 HTTP/1.1 June 1999
1073 When comparing two URIs to decide if they match or not, a client
1074 SHOULD use a case-sensitive octet-by-octet comparison of the entire
1075 URIs, with these exceptions:
1077 - A port that is empty or not given is equivalent to the default
1078 port for that URI-reference;
1080 - Comparisons of host names MUST be case-insensitive;
1082 - Comparisons of scheme names MUST be case-insensitive;
1084 - An empty abs_path is equivalent to an abs_path of "/".
1086 Characters other than those in the "reserved" and "unsafe" sets (see
1087 RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
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
10953.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.
1122Fielding, et al. Standards Track [Page 20]
1124RFC 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
1178Fielding, et al. Standards Track [Page 21]
1180RFC 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 Although HTTP allows an arbitrary token to be used as a charset
1209 value, any token that has a predefined value within the IANA
1210 Character Set registry [19] MUST represent the character set defined
1211 by that registry. Applications SHOULD limit their use of character
1212 sets to those defined by the IANA registry.
1214 Implementors should be aware of IETF character set requirements [38]
12173.4.1 Missing Charset
1219 Some HTTP/1.0 software has interpreted a Content-Type header without
1220 charset parameter incorrectly to mean "recipient should guess."
1221 Senders wishing to defeat this behavior MAY include a charset
1222 parameter even when the charset is ISO-8859-1 and SHOULD do so when
1223 it is known that it will not confuse the recipient.
1225 Unfortunately, some older HTTP/1.0 clients did not deal properly with
1226 an explicit charset parameter. HTTP/1.1 recipients MUST respect the
1227 charset label provided by the sender; and those user agents that have
1228 a provision to "guess" a charset MUST use the charset from the
1234Fielding, et al. Standards Track [Page 22]
1236RFC 2616 HTTP/1.1 June 1999
1239 content-type field if they support that charset, rather than the
1240 recipient's preference, when initially displaying a document. See
1245 Content coding values indicate an encoding transformation that has
1246 been or can be applied to an entity. Content codings are primarily
1247 used to allow a document to be compressed or otherwise usefully
1248 transformed without losing the identity of its underlying media type
1249 and without loss of information. Frequently, the entity is stored in
1250 coded form, transmitted directly, and only decoded by the recipient.
1252 content-coding = token
1254 All content-coding values are case-insensitive. HTTP/1.1 uses
1255 content-coding values in the Accept-Encoding (section 14.3) and
1256 Content-Encoding (section 14.11) header fields. Although the value
1257 describes the content-coding, what is more important is that it
1258 indicates what decoding mechanism will be required to remove the
1261 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1262 content-coding value tokens. Initially, the registry contains the
1265 gzip An encoding format produced by the file compression program
1266 "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
1267 Lempel-Ziv coding (LZ77) with a 32 bit CRC.
1270 The encoding format produced by the common UNIX file compression
1271 program "compress". This format is an adaptive Lempel-Ziv-Welch
1274 Use of program names for the identification of encoding formats
1275 is not desirable and is discouraged for future encodings. Their
1276 use here is representative of historical practice, not good
1277 design. For compatibility with previous implementations of HTTP,
1278 applications SHOULD consider "x-gzip" and "x-compress" to be
1279 equivalent to "gzip" and "compress" respectively.
1282 The "zlib" format defined in RFC 1950 [31] in combination with
1283 the "deflate" compression mechanism described in RFC 1951 [29].
1290Fielding, et al. Standards Track [Page 23]
1292RFC 2616 HTTP/1.1 June 1999
1296 The default (identity) encoding; the use of no transformation
1297 whatsoever. This content-coding is used only in the Accept-
1298 Encoding header, and SHOULD NOT be used in the Content-Encoding
1301 New content-coding value tokens SHOULD be registered; to allow
1302 interoperability between clients and servers, specifications of the
1303 content coding algorithms needed to implement a new value SHOULD be
1304 publicly available and adequate for independent implementation, and
1305 conform to the purpose of content coding defined in this section.
1309 Transfer-coding values are used to indicate an encoding
1310 transformation that has been, can be, or may need to be applied to an
1311 entity-body in order to ensure "safe transport" through the network.
1312 This differs from a content coding in that the transfer-coding is a
1313 property of the message, not of the original entity.
1315 transfer-coding = "chunked" | transfer-extension
1316 transfer-extension = token *( ";" parameter )
1318 Parameters are in the form of attribute/value pairs.
1320 parameter = attribute "=" value
1322 value = token | quoted-string
1324 All transfer-coding values are case-insensitive. HTTP/1.1 uses
1325 transfer-coding values in the TE header field (section 14.39) and in
1326 the Transfer-Encoding header field (section 14.41).
1328 Whenever a transfer-coding is applied to a message-body, the set of
1329 transfer-codings MUST include "chunked", unless the message is
1330 terminated by closing the connection. When the "chunked" transfer-
1331 coding is used, it MUST be the last transfer-coding applied to the
1332 message-body. The "chunked" transfer-coding MUST NOT be applied more
1333 than once to a message-body. These rules allow the recipient to
1334 determine the transfer-length of the message (section 4.4).
1336 Transfer-codings are analogous to the Content-Transfer-Encoding
1337 values of MIME [7], which were designed to enable safe transport of
1338 binary data over a 7-bit transport service. However, safe transport
1339 has a different focus for an 8bit-clean transfer protocol. In HTTP,
1340 the only unsafe characteristic of message-bodies is the difficulty in
1341 determining the exact body length (section 7.2.2), or the desire to
1342 encrypt data over a shared transport.
1346Fielding, et al. Standards Track [Page 24]
1348RFC 2616 HTTP/1.1 June 1999
1351 The Internet Assigned Numbers Authority (IANA) acts as a registry for
1352 transfer-coding value tokens. Initially, the registry contains the
1353 following tokens: "chunked" (section 3.6.1), "identity" (section
1354 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
1357 New transfer-coding value tokens SHOULD be registered in the same way
1358 as new content-coding value tokens (section 3.5).
1360 A server which receives an entity-body with a transfer-coding it does
1361 not understand SHOULD return 501 (Unimplemented), and close the
1362 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
13653.6.1 Chunked Transfer Coding
1367 The chunked encoding modifies the body of a message in order to
1368 transfer it as a series of chunks, each with its own size indicator,
1369 followed by an OPTIONAL trailer containing entity-header fields. This
1370 allows dynamically produced content to be transferred along with the
1371 information necessary for the recipient to verify that it has
1372 received the full message.
1374 Chunked-Body = *chunk
1379 chunk = chunk-size [ chunk-extension ] CRLF
1382 last-chunk = 1*("0") [ chunk-extension ] CRLF
1384 chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1385 chunk-ext-name = token
1386 chunk-ext-val = token | quoted-string
1387 chunk-data = chunk-size(OCTET)
1388 trailer = *(entity-header CRLF)
1390 The chunk-size field is a string of hex digits indicating the size of
1391 the chunk. The chunked encoding is ended by any chunk whose size is
1392 zero, followed by the trailer, which is terminated by an empty line.
1394 The trailer allows the sender to include additional HTTP header
1395 fields at the end of the message. The Trailer header field can be
1396 used to indicate which header fields are included in a trailer (see
1402Fielding, et al. Standards Track [Page 25]
1404RFC 2616 HTTP/1.1 June 1999
1407 A server using chunked transfer-coding in a response MUST NOT use the
1408 trailer for any header fields unless at least one of the following is
1411 a)the request included a TE header field that indicates "trailers" is
1412 acceptable in the transfer-coding of the response, as described in
1415 b)the server is the origin server for the response, the trailer
1416 fields consist entirely of optional metadata, and the recipient
1417 could use the message (in a manner acceptable to the origin server)
1418 without receiving this metadata. In other words, the origin server
1419 is willing to accept the possibility that the trailer fields might
1420 be silently discarded along the path to the client.
1422 This requirement prevents an interoperability failure when the
1423 message is being received by an HTTP/1.1 (or later) proxy and
1424 forwarded to an HTTP/1.0 recipient. It avoids a situation where
1425 compliance with the protocol would have necessitated a possibly
1426 infinite buffer on the proxy.
1428 An example process for decoding a Chunked-Body is presented in
1431 All HTTP/1.1 applications MUST be able to receive and decode the
1432 "chunked" transfer-coding, and MUST ignore chunk-extension extensions
1433 they do not understand.
1437 HTTP uses Internet Media Types [17] in the Content-Type (section
1438 14.17) and Accept (section 14.1) header fields in order to provide
1439 open and extensible data typing and type negotiation.
1441 media-type = type "/" subtype *( ";" parameter )
1445 Parameters MAY follow the type/subtype in the form of attribute/value
1446 pairs (as defined in section 3.6).
1448 The type, subtype, and parameter attribute names are case-
1449 insensitive. Parameter values might or might not be case-sensitive,
1450 depending on the semantics of the parameter name. Linear white space
1451 (LWS) MUST NOT be used between the type and subtype, nor between an
1452 attribute and its value. The presence or absence of a parameter might
1453 be significant to the processing of a media-type, depending on its
1454 definition within the media type registry.
1458Fielding, et al. Standards Track [Page 26]
1460RFC 2616 HTTP/1.1 June 1999
1463 Note that some older HTTP applications do not recognize media type
1464 parameters. When sending data to older HTTP applications,
1465 implementations SHOULD only use media type parameters when they are
1466 required by that type/subtype definition.
1468 Media-type values are registered with the Internet Assigned Number
1469 Authority (IANA [19]). The media type registration process is
1470 outlined in RFC 1590 [17]. Use of non-registered media types is
14733.7.1 Canonicalization and Text Defaults
1475 Internet media types are registered with a canonical form. An
1476 entity-body transferred via HTTP messages MUST be represented in the
1477 appropriate canonical form prior to its transmission except for
1478 "text" types, as defined in the next paragraph.
1480 When in canonical form, media subtypes of the "text" type use CRLF as
1481 the text line break. HTTP relaxes this requirement and allows the
1482 transport of text media with plain CR or LF alone representing a line
1483 break when it is done consistently for an entire entity-body. HTTP
1484 applications MUST accept CRLF, bare CR, and bare LF as being
1485 representative of a line break in text media received via HTTP. In
1486 addition, if the text is represented in a character set that does not
1487 use octets 13 and 10 for CR and LF respectively, as is the case for
1488 some multi-byte character sets, HTTP allows the use of whatever octet
1489 sequences are defined by that character set to represent the
1490 equivalent of CR and LF for line breaks. This flexibility regarding
1491 line breaks applies only to text media in the entity-body; a bare CR
1492 or LF MUST NOT be substituted for CRLF within any of the HTTP control
1493 structures (such as header fields and multipart boundaries).
1495 If an entity-body is encoded with a content-coding, the underlying
1496 data MUST be in a form defined above prior to being encoded.
1498 The "charset" parameter is used with some media types to define the
1499 character set (section 3.4) of the data. When no explicit charset
1500 parameter is provided by the sender, media subtypes of the "text"
1501 type are defined to have a default charset value of "ISO-8859-1" when
1502 received via HTTP. Data in character sets other than "ISO-8859-1" or
1503 its subsets MUST be labeled with an appropriate charset value. See
1504 section 3.4.1 for compatibility problems.
15063.7.2 Multipart Types
1508 MIME provides for a number of "multipart" types -- encapsulations of
1509 one or more entities within a single message-body. All multipart
1510 types share a common syntax, as defined in section 5.1.1 of RFC 2046
1514Fielding, et al. Standards Track [Page 27]
1516RFC 2616 HTTP/1.1 June 1999
1519 [40], and MUST include a boundary parameter as part of the media type
1520 value. The message body is itself a protocol element and MUST
1521 therefore use only CRLF to represent line breaks between body-parts.
1522 Unlike in RFC 2046, the epilogue of any multipart message MUST be
1523 empty; HTTP applications MUST NOT transmit the epilogue (even if the
1524 original multipart contains an epilogue). These restrictions exist in
1525 order to preserve the self-delimiting nature of a multipart message-
1526 body, wherein the "end" of the message-body is indicated by the
1527 ending multipart boundary.
1529 In general, HTTP treats a multipart message-body no differently than
1530 any other media type: strictly as payload. The one exception is the
1531 "multipart/byteranges" type (appendix 19.2) when it appears in a 206
1532 (Partial Content) response, which will be interpreted by some HTTP
1533 caching mechanisms as described in sections 13.5.4 and 14.16. In all
1534 other cases, an HTTP user agent SHOULD follow the same or similar
1535 behavior as a MIME user agent would upon receipt of a multipart type.
1536 The MIME header fields within each body-part of a multipart message-
1537 body do not have any significance to HTTP beyond that defined by
1538 their MIME semantics.
1540 In general, an HTTP user agent SHOULD follow the same or similar
1541 behavior as a MIME user agent would upon receipt of a multipart type.
1542 If an application receives an unrecognized multipart subtype, the
1543 application MUST treat it as being equivalent to "multipart/mixed".
1545 Note: The "multipart/form-data" type has been specifically defined
1546 for carrying form data suitable for processing via the POST
1547 request method, as described in RFC 1867 [15].
1551 Product tokens are used to allow communicating applications to
1552 identify themselves by software name and version. Most fields using
1553 product tokens also allow sub-products which form a significant part
1554 of the application to be listed, separated by white space. By
1555 convention, the products are listed in order of their significance
1556 for identifying the application.
1558 product = token ["/" product-version]
1559 product-version = token
1563 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1564 Server: Apache/0.8.4
1570Fielding, et al. Standards Track [Page 28]
1572RFC 2616 HTTP/1.1 June 1999
1575 Product tokens SHOULD be short and to the point. They MUST NOT be
1576 used for advertising or other non-essential information. Although any
1577 token character MAY appear in a product-version, this token SHOULD
1578 only be used for a version identifier (i.e., successive versions of
1579 the same product SHOULD only differ in the product-version portion of
1584 HTTP content negotiation (section 12) uses short "floating point"
1585 numbers to indicate the relative importance ("weight") of various
1586 negotiable parameters. A weight is normalized to a real number in
1587 the range 0 through 1, where 0 is the minimum and 1 the maximum
1588 value. If a parameter has a quality value of 0, then content with
1589 this parameter is `not acceptable' for the client. HTTP/1.1
1590 applications MUST NOT generate more than three digits after the
1591 decimal point. User configuration of these values SHOULD also be
1592 limited in this fashion.
1594 qvalue = ( "0" [ "." 0*3DIGIT ] )
1595 | ( "1" [ "." 0*3("0") ] )
1597 "Quality values" is a misnomer, since these values merely represent
1598 relative degradation in desired quality.
1602 A language tag identifies a natural language spoken, written, or
1603 otherwise conveyed by human beings for communication of information
1604 to other human beings. Computer languages are explicitly excluded.
1605 HTTP uses language tags within the Accept-Language and Content-
1608 The syntax and registry of HTTP language tags is the same as that
1609 defined by RFC 1766 [1]. In summary, a language tag is composed of 1
1610 or more parts: A primary language tag and a possibly empty series of
1613 language-tag = primary-tag *( "-" subtag )
1614 primary-tag = 1*8ALPHA
1617 White space is not allowed within the tag and all tags are case-
1618 insensitive. The name space of language tags is administered by the
1619 IANA. Example tags include:
1621 en, en-US, en-cockney, i-cherokee, x-pig-latin
1626Fielding, et al. Standards Track [Page 29]
1628RFC 2616 HTTP/1.1 June 1999
1631 where any two-letter primary-tag is an ISO-639 language abbreviation
1632 and any two-letter initial subtag is an ISO-3166 country code. (The
1633 last three tags above are not registered tags; all but the last are
1634 examples of tags which could be registered in future.)
1638 Entity tags are used for comparing two or more entities from the same
1639 requested resource. HTTP/1.1 uses entity tags in the ETag (section
1640 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
1641 If-Range (section 14.27) header fields. The definition of how they
1642 are used and compared as cache validators is in section 13.3.3. An
1643 entity tag consists of an opaque quoted string, possibly prefixed by
1644 a weakness indicator.
1646 entity-tag = [ weak ] opaque-tag
1648 opaque-tag = quoted-string
1650 A "strong entity tag" MAY be shared by two entities of a resource
1651 only if they are equivalent by octet equality.
1653 A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
1654 two entities of a resource only if the entities are equivalent and
1655 could be substituted for each other with no significant change in
1656 semantics. A weak entity tag can only be used for weak comparison.
1658 An entity tag MUST be unique across all versions of all entities
1659 associated with a particular resource. A given entity tag value MAY
1660 be used for entities obtained by requests on different URIs. The use
1661 of the same entity tag value in conjunction with entities obtained by
1662 requests on different URIs does not imply the equivalence of those
1667 HTTP/1.1 allows a client to request that only part (a range of) the
1668 response entity be included within the response. HTTP/1.1 uses range
1669 units in the Range (section 14.35) and Content-Range (section 14.16)
1670 header fields. An entity can be broken down into subranges according
1671 to various structural units.
1673 range-unit = bytes-unit | other-range-unit
1674 bytes-unit = "bytes"
1675 other-range-unit = token
1677 The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
1678 implementations MAY ignore ranges specified using other units.
1682Fielding, et al. Standards Track [Page 30]
1684RFC 2616 HTTP/1.1 June 1999
1687 HTTP/1.1 has been designed to allow implementations of applications
1688 that do not depend on knowledge of ranges.
1694 HTTP messages consist of requests from client to server and responses
1695 from server to client.
1697 HTTP-message = Request | Response ; HTTP/1.1 messages
1699 Request (section 5) and Response (section 6) messages use the generic
1700 message format of RFC 822 [9] for transferring entities (the payload
1701 of the message). Both types of message consist of a start-line, zero
1702 or more header fields (also known as "headers"), an empty line (i.e.,
1703 a line with nothing preceding the CRLF) indicating the end of the
1704 header fields, and possibly a message-body.
1706 generic-message = start-line
1707 *(message-header CRLF)
1710 start-line = Request-Line | Status-Line
1712 In the interest of robustness, servers SHOULD ignore any empty
1713 line(s) received where a Request-Line is expected. In other words, if
1714 the server is reading the protocol stream at the beginning of a
1715 message and receives a CRLF first, it should ignore the CRLF.
1717 Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1718 after a POST request. To restate what is explicitly forbidden by the
1719 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1724 HTTP header fields, which include general-header (section 4.5),
1725 request-header (section 5.3), response-header (section 6.2), and
1726 entity-header (section 7.1) fields, follow the same generic format as
1727 that given in Section 3.1 of RFC 822 [9]. Each header field consists
1728 of a name followed by a colon (":") and the field value. Field names
1729 are case-insensitive. The field value MAY be preceded by any amount
1730 of LWS, though a single SP is preferred. Header fields can be
1731 extended over multiple lines by preceding each extra line with at
1732 least one SP or HT. Applications ought to follow "common form", where
1733 one is known or indicated, when generating HTTP constructs, since
1734 there might exist some implementations that fail to accept anything
1738Fielding, et al. Standards Track [Page 31]
1740RFC 2616 HTTP/1.1 June 1999
1743 beyond the common forms.
1745 message-header = field-name ":" [ field-value ]
1747 field-value = *( field-content | LWS )
1748 field-content = <the OCTETs making up the field-value
1749 and consisting of either *TEXT or combinations
1750 of token, separators, and quoted-string>
1752 The field-content does not include any leading or trailing LWS:
1753 linear white space occurring before the first non-whitespace
1754 character of the field-value or after the last non-whitespace
1755 character of the field-value. Such leading or trailing LWS MAY be
1756 removed without changing the semantics of the field value. Any LWS
1757 that occurs between field-content MAY be replaced with a single SP
1758 before interpreting the field value or forwarding the message
1761 The order in which header fields with differing field names are
1762 received is not significant. However, it is "good practice" to send
1763 general-header fields first, followed by request-header or response-
1764 header fields, and ending with the entity-header fields.
1766 Multiple message-header fields with the same field-name MAY be
1767 present in a message if and only if the entire field-value for that
1768 header field is defined as a comma-separated list [i.e., #(values)].
1769 It MUST be possible to combine the multiple header fields into one
1770 "field-name: field-value" pair, without changing the semantics of the
1771 message, by appending each subsequent field-value to the first, each
1772 separated by a comma. The order in which header fields with the same
1773 field-name are received is therefore significant to the
1774 interpretation of the combined field value, and thus a proxy MUST NOT
1775 change the order of these field values when a message is forwarded.
1779 The message-body (if any) of an HTTP message is used to carry the
1780 entity-body associated with the request or response. The message-body
1781 differs from the entity-body only when a transfer-coding has been
1782 applied, as indicated by the Transfer-Encoding header field (section
1785 message-body = entity-body
1786 | <entity-body encoded as per Transfer-Encoding>
1788 Transfer-Encoding MUST be used to indicate any transfer-codings
1789 applied by an application to ensure safe and proper transfer of the
1790 message. Transfer-Encoding is a property of the message, not of the
1794Fielding, et al. Standards Track [Page 32]
1796RFC 2616 HTTP/1.1 June 1999
1799 entity, and thus MAY be added or removed by any application along the
1800 request/response chain. (However, section 3.6 places restrictions on
1801 when certain transfer-codings may be used.)
1803 The rules for when a message-body is allowed in a message differ for
1804 requests and responses.
1806 The presence of a message-body in a request is signaled by the
1807 inclusion of a Content-Length or Transfer-Encoding header field in
1808 the request's message-headers. A message-body MUST NOT be included in
1809 a request if the specification of the request method (section 5.1.1)
1810 does not allow sending an entity-body in requests. A server SHOULD
1811 read and forward a message-body on any request; if the request method
1812 does not include defined semantics for an entity-body, then the
1813 message-body SHOULD be ignored when handling the request.
1815 For response messages, whether or not a message-body is included with
1816 a message is dependent on both the request method and the response
1817 status code (section 6.1.1). All responses to the HEAD request method
1818 MUST NOT include a message-body, even though the presence of entity-
1819 header fields might lead one to believe they do. All 1xx
1820 (informational), 204 (no content), and 304 (not modified) responses
1821 MUST NOT include a message-body. All other responses do include a
1822 message-body, although it MAY be of zero length.
1826 The transfer-length of a message is the length of the message-body as
1827 it appears in the message; that is, after any transfer-codings have
1828 been applied. When a message-body is included with a message, the
1829 transfer-length of that body is determined by one of the following
1830 (in order of precedence):
1832 1.Any response message which "MUST NOT" include a message-body (such
1833 as the 1xx, 204, and 304 responses and any response to a HEAD
1834 request) is always terminated by the first empty line after the
1835 header fields, regardless of the entity-header fields present in
1838 2.If a Transfer-Encoding header field (section 14.41) is present and
1839 has any value other than "identity", then the transfer-length is
1840 defined by use of the "chunked" transfer-coding (section 3.6),
1841 unless the message is terminated by closing the connection.
1843 3.If a Content-Length header field (section 14.13) is present, its
1844 decimal value in OCTETs represents both the entity-length and the
1845 transfer-length. The Content-Length header field MUST NOT be sent
1846 if these two lengths are different (i.e., if a Transfer-Encoding
1850Fielding, et al. Standards Track [Page 33]
1852RFC 2616 HTTP/1.1 June 1999
1855 header field is present). If a message is received with both a
1856 Transfer-Encoding header field and a Content-Length header field,
1857 the latter MUST be ignored.
1859 4.If the message uses the media type "multipart/byteranges", and the
1860 ransfer-length is not otherwise specified, then this self-
1861 elimiting media type defines the transfer-length. This media type
1862 UST NOT be used unless the sender knows that the recipient can arse
1863 it; the presence in a request of a Range header with ultiple byte-
1864 range specifiers from a 1.1 client implies that the lient can parse
1865 multipart/byteranges responses.
1867 A range header might be forwarded by a 1.0 proxy that does not
1868 understand multipart/byteranges; in this case the server MUST
1869 delimit the message using methods defined in items 1,3 or 5 of
1872 5.By the server closing the connection. (Closing the connection
1873 cannot be used to indicate the end of a request body, since that
1874 would leave no possibility for the server to send back a response.)
1876 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1877 containing a message-body MUST include a valid Content-Length header
1878 field unless the server is known to be HTTP/1.1 compliant. If a
1879 request contains a message-body and a Content-Length is not given,
1880 the server SHOULD respond with 400 (bad request) if it cannot
1881 determine the length of the message, or with 411 (length required) if
1882 it wishes to insist on receiving a valid Content-Length.
1884 All HTTP/1.1 applications that receive entities MUST accept the
1885 "chunked" transfer-coding (section 3.6), thus allowing this mechanism
1886 to be used for messages when the message length cannot be determined
1889 Messages MUST NOT include both a Content-Length header field and a
1890 non-identity transfer-coding. If the message does include a non-
1891 identity transfer-coding, the Content-Length MUST be ignored.
1893 When a Content-Length is given in a message where a message-body is
1894 allowed, its field value MUST exactly match the number of OCTETs in
1895 the message-body. HTTP/1.1 user agents MUST notify the user when an
1896 invalid length is received and detected.
18984.5 General Header Fields
1900 There are a few header fields which have general applicability for
1901 both request and response messages, but which do not apply to the
1902 entity being transferred. These header fields apply only to the
1906Fielding, et al. Standards Track [Page 34]
1908RFC 2616 HTTP/1.1 June 1999
1911 message being transmitted.
1913 general-header = Cache-Control ; Section 14.9
1914 | Connection ; Section 14.10
1915 | Date ; Section 14.18
1916 | Pragma ; Section 14.32
1917 | Trailer ; Section 14.40
1918 | Transfer-Encoding ; Section 14.41
1919 | Upgrade ; Section 14.42
1920 | Via ; Section 14.45
1921 | Warning ; Section 14.46
1923 General-header field names can be extended reliably only in
1924 combination with a change in the protocol version. However, new or
1925 experimental header fields may be given the semantics of general
1926 header fields if all parties in the communication recognize them to
1927 be general-header fields. Unrecognized header fields are treated as
1928 entity-header fields.
1932 A request message from a client to a server includes, within the
1933 first line of that message, the method to be applied to the resource,
1934 the identifier of the resource, and the protocol version in use.
1936 Request = Request-Line ; Section 5.1
1937 *(( general-header ; Section 4.5
1938 | request-header ; Section 5.3
1939 | entity-header ) CRLF) ; Section 7.1
1941 [ message-body ] ; Section 4.3
1945 The Request-Line begins with a method token, followed by the
1946 Request-URI and the protocol version, and ending with CRLF. The
1947 elements are separated by SP characters. No CR or LF is allowed
1948 except in the final CRLF sequence.
1950 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
1962Fielding, et al. Standards Track [Page 35]
1964RFC 2616 HTTP/1.1 June 1999
1969 The Method token indicates the method to be performed on the
1970 resource identified by the Request-URI. The method is case-sensitive.
1972 Method = "OPTIONS" ; Section 9.2
1973 | "GET" ; Section 9.3
1974 | "HEAD" ; Section 9.4
1975 | "POST" ; Section 9.5
1976 | "PUT" ; Section 9.6
1977 | "DELETE" ; Section 9.7
1978 | "TRACE" ; Section 9.8
1979 | "CONNECT" ; Section 9.9
1981 extension-method = token
1983 The list of methods allowed by a resource can be specified in an
1984 Allow header field (section 14.7). The return code of the response
1985 always notifies the client whether a method is currently allowed on a
1986 resource, since the set of allowed methods can change dynamically. An
1987 origin server SHOULD return the status code 405 (Method Not Allowed)
1988 if the method is known by the origin server but not allowed for the
1989 requested resource, and 501 (Not Implemented) if the method is
1990 unrecognized or not implemented by the origin server. The methods GET
1991 and HEAD MUST be supported by all general-purpose servers. All other
1992 methods are OPTIONAL; however, if the above methods are implemented,
1993 they MUST be implemented with the same semantics as those specified
1998 The Request-URI is a Uniform Resource Identifier (section 3.2) and
1999 identifies the resource upon which to apply the request.
2001 Request-URI = "*" | absoluteURI | abs_path | authority
2003 The four options for Request-URI are dependent on the nature of the
2004 request. The asterisk "*" means that the request does not apply to a
2005 particular resource, but to the server itself, and is only allowed
2006 when the method used does not necessarily apply to a resource. One
2011 The absoluteURI form is REQUIRED when the request is being made to a
2012 proxy. The proxy is requested to forward the request or service it
2013 from a valid cache, and return the response. Note that the proxy MAY
2014 forward the request on to another proxy or directly to the server
2018Fielding, et al. Standards Track [Page 36]
2020RFC 2616 HTTP/1.1 June 1999
2023 specified by the absoluteURI. In order to avoid request loops, a
2024 proxy MUST be able to recognize all of its server names, including
2025 any aliases, local variations, and the numeric IP address. An example
2026 Request-Line would be:
2028 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
2030 To allow for transition to absoluteURIs in all requests in future
2031 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
2032 form in requests, even though HTTP/1.1 clients will only generate
2033 them in requests to proxies.
2035 The authority form is only used by the CONNECT method (section 9.9).
2037 The most common form of Request-URI is that used to identify a
2038 resource on an origin server or gateway. In this case the absolute
2039 path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
2040 the Request-URI, and the network location of the URI (authority) MUST
2041 be transmitted in a Host header field. For example, a client wishing
2042 to retrieve the resource above directly from the origin server would
2043 create a TCP connection to port 80 of the host "www.w3.org" and send
2046 GET /pub/WWW/TheProject.html HTTP/1.1
2049 followed by the remainder of the Request. Note that the absolute path
2050 cannot be empty; if none is present in the original URI, it MUST be
2051 given as "/" (the server root).
2053 The Request-URI is transmitted in the format specified in section
2054 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
2055 [42], the origin server MUST decode the Request-URI in order to
2056 properly interpret the request. Servers SHOULD respond to invalid
2057 Request-URIs with an appropriate status code.
2059 A transparent proxy MUST NOT rewrite the "abs_path" part of the
2060 received Request-URI when forwarding it to the next inbound server,
2061 except as noted above to replace a null abs_path with "/".
2063 Note: The "no rewrite" rule prevents the proxy from changing the
2064 meaning of the request when the origin server is improperly using
2065 a non-reserved URI character for a reserved purpose. Implementors
2066 should be aware that some pre-HTTP/1.1 proxies have been known to
2067 rewrite the Request-URI.
2074Fielding, et al. Standards Track [Page 37]
2076RFC 2616 HTTP/1.1 June 1999
20795.2 The Resource Identified by a Request
2081 The exact resource identified by an Internet request is determined by
2082 examining both the Request-URI and the Host header field.
2084 An origin server that does not allow resources to differ by the
2085 requested host MAY ignore the Host header field value when
2086 determining the resource identified by an HTTP/1.1 request. (But see
2087 section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
2089 An origin server that does differentiate resources based on the host
2090 requested (sometimes referred to as virtual hosts or vanity host
2091 names) MUST use the following rules for determining the requested
2092 resource on an HTTP/1.1 request:
2094 1. If Request-URI is an absoluteURI, the host is part of the
2095 Request-URI. Any Host header field value in the request MUST be
2098 2. If the Request-URI is not an absoluteURI, and the request includes
2099 a Host header field, the host is determined by the Host header
2102 3. If the host as determined by rule 1 or 2 is not a valid host on
2103 the server, the response MUST be a 400 (Bad Request) error message.
2105 Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2106 attempt to use heuristics (e.g., examination of the URI path for
2107 something unique to a particular host) in order to determine what
2108 exact resource is being requested.
21105.3 Request Header Fields
2112 The request-header fields allow the client to pass additional
2113 information about the request, and about the client itself, to the
2114 server. These fields act as request modifiers, with semantics
2115 equivalent to the parameters on a programming language method
2118 request-header = Accept ; Section 14.1
2119 | Accept-Charset ; Section 14.2
2120 | Accept-Encoding ; Section 14.3
2121 | Accept-Language ; Section 14.4
2122 | Authorization ; Section 14.8
2123 | Expect ; Section 14.20
2124 | From ; Section 14.22
2125 | Host ; Section 14.23
2126 | If-Match ; Section 14.24
2130Fielding, et al. Standards Track [Page 38]
2132RFC 2616 HTTP/1.1 June 1999
2135 | If-Modified-Since ; Section 14.25
2136 | If-None-Match ; Section 14.26
2137 | If-Range ; Section 14.27
2138 | If-Unmodified-Since ; Section 14.28
2139 | Max-Forwards ; Section 14.31
2140 | Proxy-Authorization ; Section 14.34
2141 | Range ; Section 14.35
2142 | Referer ; Section 14.36
2143 | TE ; Section 14.39
2144 | User-Agent ; Section 14.43
2146 Request-header field names can be extended reliably only in
2147 combination with a change in the protocol version. However, new or
2148 experimental header fields MAY be given the semantics of request-
2149 header fields if all parties in the communication recognize them to
2150 be request-header fields. Unrecognized header fields are treated as
2151 entity-header fields.
2155 After receiving and interpreting a request message, a server responds
2156 with an HTTP response message.
2158 Response = Status-Line ; Section 6.1
2159 *(( general-header ; Section 4.5
2160 | response-header ; Section 6.2
2161 | entity-header ) CRLF) ; Section 7.1
2163 [ message-body ] ; Section 7.2
2167 The first line of a Response message is the Status-Line, consisting
2168 of the protocol version followed by a numeric status code and its
2169 associated textual phrase, with each element separated by SP
2170 characters. No CR or LF is allowed except in the final CRLF sequence.
2172 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
21746.1.1 Status Code and Reason Phrase
2176 The Status-Code element is a 3-digit integer result code of the
2177 attempt to understand and satisfy the request. These codes are fully
2178 defined in section 10. The Reason-Phrase is intended to give a short
2179 textual description of the Status-Code. The Status-Code is intended
2180 for use by automata and the Reason-Phrase is intended for the human
2181 user. The client is not required to examine or display the Reason-
2186Fielding, et al. Standards Track [Page 39]
2188RFC 2616 HTTP/1.1 June 1999
2191 The first digit of the Status-Code defines the class of response. The
2192 last two digits do not have any categorization role. There are 5
2193 values for the first digit:
2195 - 1xx: Informational - Request received, continuing process
2197 - 2xx: Success - The action was successfully received,
2198 understood, and accepted
2200 - 3xx: Redirection - Further action must be taken in order to
2201 complete the request
2203 - 4xx: Client Error - The request contains bad syntax or cannot
2206 - 5xx: Server Error - The server failed to fulfill an apparently
2209 The individual values of the numeric status codes defined for
2210 HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
2211 presented below. The reason phrases listed here are only
2212 recommendations -- they MAY be replaced by local equivalents without
2213 affecting the protocol.
2216 "100" ; Section 10.1.1: Continue
2217 | "101" ; Section 10.1.2: Switching Protocols
2218 | "200" ; Section 10.2.1: OK
2219 | "201" ; Section 10.2.2: Created
2220 | "202" ; Section 10.2.3: Accepted
2221 | "203" ; Section 10.2.4: Non-Authoritative Information
2222 | "204" ; Section 10.2.5: No Content
2223 | "205" ; Section 10.2.6: Reset Content
2224 | "206" ; Section 10.2.7: Partial Content
2225 | "300" ; Section 10.3.1: Multiple Choices
2226 | "301" ; Section 10.3.2: Moved Permanently
2227 | "302" ; Section 10.3.3: Found
2228 | "303" ; Section 10.3.4: See Other
2229 | "304" ; Section 10.3.5: Not Modified
2230 | "305" ; Section 10.3.6: Use Proxy
2231 | "307" ; Section 10.3.8: Temporary Redirect
2232 | "400" ; Section 10.4.1: Bad Request
2233 | "401" ; Section 10.4.2: Unauthorized
2234 | "402" ; Section 10.4.3: Payment Required
2235 | "403" ; Section 10.4.4: Forbidden
2236 | "404" ; Section 10.4.5: Not Found
2237 | "405" ; Section 10.4.6: Method Not Allowed
2238 | "406" ; Section 10.4.7: Not Acceptable
2242Fielding, et al. Standards Track [Page 40]
2244RFC 2616 HTTP/1.1 June 1999
2247 | "407" ; Section 10.4.8: Proxy Authentication Required
2248 | "408" ; Section 10.4.9: Request Time-out
2249 | "409" ; Section 10.4.10: Conflict
2250 | "410" ; Section 10.4.11: Gone
2251 | "411" ; Section 10.4.12: Length Required
2252 | "412" ; Section 10.4.13: Precondition Failed
2253 | "413" ; Section 10.4.14: Request Entity Too Large
2254 | "414" ; Section 10.4.15: Request-URI Too Large
2255 | "415" ; Section 10.4.16: Unsupported Media Type
2256 | "416" ; Section 10.4.17: Requested range not satisfiable
2257 | "417" ; Section 10.4.18: Expectation Failed
2258 | "500" ; Section 10.5.1: Internal Server Error
2259 | "501" ; Section 10.5.2: Not Implemented
2260 | "502" ; Section 10.5.3: Bad Gateway
2261 | "503" ; Section 10.5.4: Service Unavailable
2262 | "504" ; Section 10.5.5: Gateway Time-out
2263 | "505" ; Section 10.5.6: HTTP Version not supported
2266 extension-code = 3DIGIT
2267 Reason-Phrase = *<TEXT, excluding CR, LF>
2269 HTTP status codes are extensible. HTTP applications are not required
2270 to understand the meaning of all registered status codes, though such
2271 understanding is obviously desirable. However, applications MUST
2272 understand the class of any status code, as indicated by the first
2273 digit, and treat any unrecognized response as being equivalent to the
2274 x00 status code of that class, with the exception that an
2275 unrecognized response MUST NOT be cached. For example, if an
2276 unrecognized status code of 431 is received by the client, it can
2277 safely assume that there was something wrong with its request and
2278 treat the response as if it had received a 400 status code. In such
2279 cases, user agents SHOULD present to the user the entity returned
2280 with the response, since that entity is likely to include human-
2281 readable information which will explain the unusual status.
22836.2 Response Header Fields
2285 The response-header fields allow the server to pass additional
2286 information about the response which cannot be placed in the Status-
2287 Line. These header fields give information about the server and about
2288 further access to the resource identified by the Request-URI.
2290 response-header = Accept-Ranges ; Section 14.5
2291 | Age ; Section 14.6
2292 | ETag ; Section 14.19
2293 | Location ; Section 14.30
2294 | Proxy-Authenticate ; Section 14.33
2298Fielding, et al. Standards Track [Page 41]
2300RFC 2616 HTTP/1.1 June 1999
2303 | Retry-After ; Section 14.37
2304 | Server ; Section 14.38
2305 | Vary ; Section 14.44
2306 | WWW-Authenticate ; Section 14.47
2308 Response-header field names can be extended reliably only in
2309 combination with a change in the protocol version. However, new or
2310 experimental header fields MAY be given the semantics of response-
2311 header fields if all parties in the communication recognize them to
2312 be response-header fields. Unrecognized header fields are treated as
2313 entity-header fields.
2317 Request and Response messages MAY transfer an entity if not otherwise
2318 restricted by the request method or response status code. An entity
2319 consists of entity-header fields and an entity-body, although some
2320 responses will only include the entity-headers.
2322 In this section, both sender and recipient refer to either the client
2323 or the server, depending on who sends and who receives the entity.
23257.1 Entity Header Fields
2327 Entity-header fields define metainformation about the entity-body or,
2328 if no body is present, about the resource identified by the request.
2329 Some of this metainformation is OPTIONAL; some might be REQUIRED by
2330 portions of this specification.
2332 entity-header = Allow ; Section 14.7
2333 | Content-Encoding ; Section 14.11
2334 | Content-Language ; Section 14.12
2335 | Content-Length ; Section 14.13
2336 | Content-Location ; Section 14.14
2337 | Content-MD5 ; Section 14.15
2338 | Content-Range ; Section 14.16
2339 | Content-Type ; Section 14.17
2340 | Expires ; Section 14.21
2341 | Last-Modified ; Section 14.29
2344 extension-header = message-header
2346 The extension-header mechanism allows additional entity-header fields
2347 to be defined without changing the protocol, but these fields cannot
2348 be assumed to be recognizable by the recipient. Unrecognized header
2349 fields SHOULD be ignored by the recipient and MUST be forwarded by
2350 transparent proxies.
2354Fielding, et al. Standards Track [Page 42]
2356RFC 2616 HTTP/1.1 June 1999
2361 The entity-body (if any) sent with an HTTP request or response is in
2362 a format and encoding defined by the entity-header fields.
2364 entity-body = *OCTET
2366 An entity-body is only present in a message when a message-body is
2367 present, as described in section 4.3. The entity-body is obtained
2368 from the message-body by decoding any Transfer-Encoding that might
2369 have been applied to ensure safe and proper transfer of the message.
2373 When an entity-body is included with a message, the data type of that
2374 body is determined via the header fields Content-Type and Content-
2375 Encoding. These define a two-layer, ordered encoding model:
2377 entity-body := Content-Encoding( Content-Type( data ) )
2379 Content-Type specifies the media type of the underlying data.
2380 Content-Encoding may be used to indicate any additional content
2381 codings applied to the data, usually for the purpose of data
2382 compression, that are a property of the requested resource. There is
2383 no default encoding.
2385 Any HTTP/1.1 message containing an entity-body SHOULD include a
2386 Content-Type header field defining the media type of that body. If
2387 and only if the media type is not given by a Content-Type field, the
2388 recipient MAY attempt to guess the media type via inspection of its
2389 content and/or the name extension(s) of the URI used to identify the
2390 resource. If the media type remains unknown, the recipient SHOULD
2391 treat it as type "application/octet-stream".
2395 The entity-length of a message is the length of the message-body
2396 before any transfer-codings have been applied. Section 4.4 defines
2397 how the transfer-length of a message-body is determined.
2410Fielding, et al. Standards Track [Page 43]
2412RFC 2616 HTTP/1.1 June 1999
24178.1 Persistent Connections
2421 Prior to persistent connections, a separate TCP connection was
2422 established to fetch each URL, increasing the load on HTTP servers
2423 and causing congestion on the Internet. The use of inline images and
2424 other associated data often require a client to make multiple
2425 requests of the same server in a short amount of time. Analysis of
2426 these performance problems and results from a prototype
2427 implementation are available [26] [30]. Implementation experience and
2428 measurements of actual HTTP/1.1 (RFC 2068) implementations show good
2429 results [39]. Alternatives have also been explored, for example,
2432 Persistent HTTP connections have a number of advantages:
2434 - By opening and closing fewer TCP connections, CPU time is saved
2435 in routers and hosts (clients, servers, proxies, gateways,
2436 tunnels, or caches), and memory used for TCP protocol control
2437 blocks can be saved in hosts.
2439 - HTTP requests and responses can be pipelined on a connection.
2440 Pipelining allows a client to make multiple requests without
2441 waiting for each response, allowing a single TCP connection to
2442 be used much more efficiently, with much lower elapsed time.
2444 - Network congestion is reduced by reducing the number of packets
2445 caused by TCP opens, and by allowing TCP sufficient time to
2446 determine the congestion state of the network.
2448 - Latency on subsequent requests is reduced since there is no time
2449 spent in TCP's connection opening handshake.
2451 - HTTP can evolve more gracefully, since errors can be reported
2452 without the penalty of closing the TCP connection. Clients using
2453 future versions of HTTP might optimistically try a new feature,
2454 but if communicating with an older server, retry with old
2455 semantics after an error is reported.
2457 HTTP implementations SHOULD implement persistent connections.
2466Fielding, et al. Standards Track [Page 44]
2468RFC 2616 HTTP/1.1 June 1999
24718.1.2 Overall Operation
2473 A significant difference between HTTP/1.1 and earlier versions of
2474 HTTP is that persistent connections are the default behavior of any
2475 HTTP connection. That is, unless otherwise indicated, the client
2476 SHOULD assume that the server will maintain a persistent connection,
2477 even after error responses from the server.
2479 Persistent connections provide a mechanism by which a client and a
2480 server can signal the close of a TCP connection. This signaling takes
2481 place using the Connection header field (section 14.10). Once a close
2482 has been signaled, the client MUST NOT send any more requests on that
2487 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2488 maintain a persistent connection unless a Connection header including
2489 the connection-token "close" was sent in the request. If the server
2490 chooses to close the connection immediately after sending the
2491 response, it SHOULD send a Connection header including the
2492 connection-token close.
2494 An HTTP/1.1 client MAY expect a connection to remain open, but would
2495 decide to keep it open based on whether the response from a server
2496 contains a Connection header with the connection-token close. In case
2497 the client does not want to maintain a connection for more than that
2498 request, it SHOULD send a Connection header including the
2499 connection-token close.
2501 If either the client or the server sends the close token in the
2502 Connection header, that request becomes the last one for the
2505 Clients and servers SHOULD NOT assume that a persistent connection is
2506 maintained for HTTP versions less than 1.1 unless it is explicitly
2507 signaled. See section 19.6.2 for more information on backward
2508 compatibility with HTTP/1.0 clients.
2510 In order to remain persistent, all messages on the connection MUST
2511 have a self-defined message length (i.e., one not defined by closure
2512 of the connection), as described in section 4.4.
2522Fielding, et al. Standards Track [Page 45]
2524RFC 2616 HTTP/1.1 June 1999
2529 A client that supports persistent connections MAY "pipeline" its
2530 requests (i.e., send multiple requests without waiting for each
2531 response). A server MUST send its responses to those requests in the
2532 same order that the requests were received.
2534 Clients which assume persistent connections and pipeline immediately
2535 after connection establishment SHOULD be prepared to retry their
2536 connection if the first pipelined attempt fails. If a client does
2537 such a retry, it MUST NOT pipeline before it knows the connection is
2538 persistent. Clients MUST also be prepared to resend their requests if
2539 the server closes the connection before sending all of the
2540 corresponding responses.
2542 Clients SHOULD NOT pipeline requests using non-idempotent methods or
2543 non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
2544 premature termination of the transport connection could lead to
2545 indeterminate results. A client wishing to send a non-idempotent
2546 request SHOULD wait to send that request until it has received the
2547 response status for the previous request.
2551 It is especially important that proxies correctly implement the
2552 properties of the Connection header field as specified in section
2555 The proxy server MUST signal persistent connections separately with
2556 its clients and the origin servers (or other proxy servers) that it
2557 connects to. Each persistent connection applies to only one transport
2560 A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2561 with an HTTP/1.0 client (but see RFC 2068 [33] for information and
2562 discussion of the problems with the Keep-Alive header implemented by
2563 many HTTP/1.0 clients).
25658.1.4 Practical Considerations
2567 Servers will usually have some time-out value beyond which they will
2568 no longer maintain an inactive connection. Proxy servers might make
2569 this a higher value since it is likely that the client will be making
2570 more connections through the same server. The use of persistent
2571 connections places no requirements on the length (or existence) of
2572 this time-out for either the client or the server.
2578Fielding, et al. Standards Track [Page 46]
2580RFC 2616 HTTP/1.1 June 1999
2583 When a client or server wishes to time-out it SHOULD issue a graceful
2584 close on the transport connection. Clients and servers SHOULD both
2585 constantly watch for the other side of the transport close, and
2586 respond to it as appropriate. If a client or server does not detect
2587 the other side's close promptly it could cause unnecessary resource
2588 drain on the network.
2590 A client, server, or proxy MAY close the transport connection at any
2591 time. For example, a client might have started to send a new request
2592 at the same time that the server has decided to close the "idle"
2593 connection. From the server's point of view, the connection is being
2594 closed while it was idle, but from the client's point of view, a
2595 request is in progress.
2597 This means that clients, servers, and proxies MUST be able to recover
2598 from asynchronous close events. Client software SHOULD reopen the
2599 transport connection and retransmit the aborted sequence of requests
2600 without user interaction so long as the request sequence is
2601 idempotent (see section 9.1.2). Non-idempotent methods or sequences
2602 MUST NOT be automatically retried, although user agents MAY offer a
2603 human operator the choice of retrying the request(s). Confirmation by
2604 user-agent software with semantic understanding of the application
2605 MAY substitute for user confirmation. The automatic retry SHOULD NOT
2606 be repeated if the second sequence of requests fails.
2608 Servers SHOULD always respond to at least one request per connection,
2609 if at all possible. Servers SHOULD NOT close a connection in the
2610 middle of transmitting a response, unless a network or client failure
2613 Clients that use persistent connections SHOULD limit the number of
2614 simultaneous connections that they maintain to a given server. A
2615 single-user client SHOULD NOT maintain more than 2 connections with
2616 any server or proxy. A proxy SHOULD use up to 2*N connections to
2617 another server or proxy, where N is the number of simultaneously
2618 active users. These guidelines are intended to improve HTTP response
2619 times and avoid congestion.
26218.2 Message Transmission Requirements
26238.2.1 Persistent Connections and Flow Control
2625 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2626 flow control mechanisms to resolve temporary overloads, rather than
2627 terminating connections with the expectation that clients will retry.
2628 The latter technique can exacerbate network congestion.
2634Fielding, et al. Standards Track [Page 47]
2636RFC 2616 HTTP/1.1 June 1999
26398.2.2 Monitoring Connections for Error Status Messages
2641 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2642 the network connection for an error status while it is transmitting
2643 the request. If the client sees an error status, it SHOULD
2644 immediately cease transmitting the body. If the body is being sent
2645 using a "chunked" encoding (section 3.6), a zero length chunk and
2646 empty trailer MAY be used to prematurely mark the end of the message.
2647 If the body was preceded by a Content-Length header, the client MUST
2648 close the connection.
26508.2.3 Use of the 100 (Continue) Status
2652 The purpose of the 100 (Continue) status (see section 10.1.1) is to
2653 allow a client that is sending a request message with a request body
2654 to determine if the origin server is willing to accept the request
2655 (based on the request headers) before the client sends the request
2656 body. In some cases, it might either be inappropriate or highly
2657 inefficient for the client to send the body if the server will reject
2658 the message without looking at the body.
2660 Requirements for HTTP/1.1 clients:
2662 - If a client will wait for a 100 (Continue) response before
2663 sending the request body, it MUST send an Expect request-header
2664 field (section 14.20) with the "100-continue" expectation.
2666 - A client MUST NOT send an Expect request-header field (section
2667 14.20) with the "100-continue" expectation if it does not intend
2668 to send a request body.
2670 Because of the presence of older implementations, the protocol allows
2671 ambiguous situations in which a client may send "Expect: 100-
2672 continue" without receiving either a 417 (Expectation Failed) status
2673 or a 100 (Continue) status. Therefore, when a client sends this
2674 header field to an origin server (possibly via a proxy) from which it
2675 has never seen a 100 (Continue) status, the client SHOULD NOT wait
2676 for an indefinite period before sending the request body.
2678 Requirements for HTTP/1.1 origin servers:
2680 - Upon receiving a request which includes an Expect request-header
2681 field with the "100-continue" expectation, an origin server MUST
2682 either respond with 100 (Continue) status and continue to read
2683 from the input stream, or respond with a final status code. The
2684 origin server MUST NOT wait for the request body before sending
2685 the 100 (Continue) response. If it responds with a final status
2686 code, it MAY close the transport connection or it MAY continue
2690Fielding, et al. Standards Track [Page 48]
2692RFC 2616 HTTP/1.1 June 1999
2695 to read and discard the rest of the request. It MUST NOT
2696 perform the requested method if it returns a final status code.
2698 - An origin server SHOULD NOT send a 100 (Continue) response if
2699 the request message does not include an Expect request-header
2700 field with the "100-continue" expectation, and MUST NOT send a
2701 100 (Continue) response if such a request comes from an HTTP/1.0
2702 (or earlier) client. There is an exception to this rule: for
2703 compatibility with RFC 2068, a server MAY send a 100 (Continue)
2704 status in response to an HTTP/1.1 PUT or POST request that does
2705 not include an Expect request-header field with the "100-
2706 continue" expectation. This exception, the purpose of which is
2707 to minimize any client processing delays associated with an
2708 undeclared wait for 100 (Continue) status, applies only to
2709 HTTP/1.1 requests, and not to requests with any other HTTP-
2712 - An origin server MAY omit a 100 (Continue) response if it has
2713 already received some or all of the request body for the
2714 corresponding request.
2716 - An origin server that sends a 100 (Continue) response MUST
2717 ultimately send a final status code, once the request body is
2718 received and processed, unless it terminates the transport
2719 connection prematurely.
2721 - If an origin server receives a request that does not include an
2722 Expect request-header field with the "100-continue" expectation,
2723 the request includes a request body, and the server responds
2724 with a final status code before reading the entire request body
2725 from the transport connection, then the server SHOULD NOT close
2726 the transport connection until it has read the entire request,
2727 or until the client closes the connection. Otherwise, the client
2728 might not reliably receive the response message. However, this
2729 requirement is not be construed as preventing a server from
2730 defending itself against denial-of-service attacks, or from
2731 badly broken client implementations.
2733 Requirements for HTTP/1.1 proxies:
2735 - If a proxy receives a request that includes an Expect request-
2736 header field with the "100-continue" expectation, and the proxy
2737 either knows that the next-hop server complies with HTTP/1.1 or
2738 higher, or does not know the HTTP version of the next-hop
2739 server, it MUST forward the request, including the Expect header
2746Fielding, et al. Standards Track [Page 49]
2748RFC 2616 HTTP/1.1 June 1999
2751 - If the proxy knows that the version of the next-hop server is
2752 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2753 respond with a 417 (Expectation Failed) status.
2755 - Proxies SHOULD maintain a cache recording the HTTP version
2756 numbers received from recently-referenced next-hop servers.
2758 - A proxy MUST NOT forward a 100 (Continue) response if the
2759 request message was received from an HTTP/1.0 (or earlier)
2760 client and did not include an Expect request-header field with
2761 the "100-continue" expectation. This requirement overrides the
2762 general rule for forwarding of 1xx responses (see section 10.1).
27648.2.4 Client Behavior if Server Prematurely Closes Connection
2766 If an HTTP/1.1 client sends a request which includes a request body,
2767 but which does not include an Expect request-header field with the
2768 "100-continue" expectation, and if the client is not directly
2769 connected to an HTTP/1.1 origin server, and if the client sees the
2770 connection close before receiving any status from the server, the
2771 client SHOULD retry the request. If the client does retry this
2772 request, it MAY use the following "binary exponential backoff"
2773 algorithm to be assured of obtaining a reliable response:
2775 1. Initiate a new connection to the server
2777 2. Transmit the request-headers
2779 3. Initialize a variable R to the estimated round-trip time to the
2780 server (e.g., based on the time it took to establish the
2781 connection), or to a constant value of 5 seconds if the round-
2782 trip time is not available.
2784 4. Compute T = R * (2**N), where N is the number of previous
2785 retries of this request.
2787 5. Wait either for an error response from the server, or for T
2788 seconds (whichever comes first)
2790 6. If no error response is received, after T seconds transmit the
2791 body of the request.
2793 7. If client sees that the connection is closed prematurely,
2794 repeat from step 1 until the request is accepted, an error
2795 response is received, or the user becomes impatient and
2796 terminates the retry process.
2802Fielding, et al. Standards Track [Page 50]
2804RFC 2616 HTTP/1.1 June 1999
2807 If at any point an error status is received, the client
2809 - SHOULD NOT continue and
2811 - SHOULD close the connection if it has not completed sending the
2816 The set of common methods for HTTP/1.1 is defined below. Although
2817 this set can be expanded, additional methods cannot be assumed to
2818 share the same semantics for separately extended clients and servers.
2820 The Host request-header field (section 14.23) MUST accompany all
28239.1 Safe and Idempotent Methods
2827 Implementors should be aware that the software represents the user in
2828 their interactions over the Internet, and should be careful to allow
2829 the user to be aware of any actions they might take which may have an
2830 unexpected significance to themselves or others.
2832 In particular, the convention has been established that the GET and
2833 HEAD methods SHOULD NOT have the significance of taking an action
2834 other than retrieval. These methods ought to be considered "safe".
2835 This allows user agents to represent other methods, such as POST, PUT
2836 and DELETE, in a special way, so that the user is made aware of the
2837 fact that a possibly unsafe action is being requested.
2839 Naturally, it is not possible to ensure that the server does not
2840 generate side-effects as a result of performing a GET request; in
2841 fact, some dynamic resources consider that a feature. The important
2842 distinction here is that the user did not request the side-effects,
2843 so therefore cannot be held accountable for them.
28459.1.2 Idempotent Methods
2847 Methods can also have the property of "idempotence" in that (aside
2848 from error or expiration issues) the side-effects of N > 0 identical
2849 requests is the same as for a single request. The methods GET, HEAD,
2850 PUT and DELETE share this property. Also, the methods OPTIONS and
2851 TRACE SHOULD NOT have side effects, and so are inherently idempotent.
2858Fielding, et al. Standards Track [Page 51]
2860RFC 2616 HTTP/1.1 June 1999
2863 However, it is possible that a sequence of several requests is non-
2864 idempotent, even if all of the methods executed in that sequence are
2865 idempotent. (A sequence is idempotent if a single execution of the
2866 entire sequence always yields a result that is not changed by a
2867 reexecution of all, or part, of that sequence.) For example, a
2868 sequence is non-idempotent if its result depends on a value that is
2869 later modified in the same sequence.
2871 A sequence that never has side effects is idempotent, by definition
2872 (provided that no concurrent operations are being executed on the
2873 same set of resources).
2877 The OPTIONS method represents a request for information about the
2878 communication options available on the request/response chain
2879 identified by the Request-URI. This method allows the client to
2880 determine the options and/or requirements associated with a resource,
2881 or the capabilities of a server, without implying a resource action
2882 or initiating a resource retrieval.
2884 Responses to this method are not cacheable.
2886 If the OPTIONS request includes an entity-body (as indicated by the
2887 presence of Content-Length or Transfer-Encoding), then the media type
2888 MUST be indicated by a Content-Type field. Although this
2889 specification does not define any use for such a body, future
2890 extensions to HTTP might use the OPTIONS body to make more detailed
2891 queries on the server. A server that does not support such an
2892 extension MAY discard the request body.
2894 If the Request-URI is an asterisk ("*"), the OPTIONS request is
2895 intended to apply to the server in general rather than to a specific
2896 resource. Since a server's communication options typically depend on
2897 the resource, the "*" request is only useful as a "ping" or "no-op"
2898 type of method; it does nothing beyond allowing the client to test
2899 the capabilities of the server. For example, this can be used to test
2900 a proxy for HTTP/1.1 compliance (or lack thereof).
2902 If the Request-URI is not an asterisk, the OPTIONS request applies
2903 only to the options that are available when communicating with that
2906 A 200 response SHOULD include any header fields that indicate
2907 optional features implemented by the server and applicable to that
2908 resource (e.g., Allow), possibly including extensions not defined by
2909 this specification. The response body, if any, SHOULD also include
2910 information about the communication options. The format for such a
2914Fielding, et al. Standards Track [Page 52]
2916RFC 2616 HTTP/1.1 June 1999
2919 body is not defined by this specification, but might be defined by
2920 future extensions to HTTP. Content negotiation MAY be used to select
2921 the appropriate response format. If no response body is included, the
2922 response MUST include a Content-Length field with a field-value of
2925 The Max-Forwards request-header field MAY be used to target a
2926 specific proxy in the request chain. When a proxy receives an OPTIONS
2927 request on an absoluteURI for which request forwarding is permitted,
2928 the proxy MUST check for a Max-Forwards field. If the Max-Forwards
2929 field-value is zero ("0"), the proxy MUST NOT forward the message;
2930 instead, the proxy SHOULD respond with its own communication options.
2931 If the Max-Forwards field-value is an integer greater than zero, the
2932 proxy MUST decrement the field-value when it forwards the request. If
2933 no Max-Forwards field is present in the request, then the forwarded
2934 request MUST NOT include a Max-Forwards field.
2938 The GET method means retrieve whatever information (in the form of an
2939 entity) is identified by the Request-URI. If the Request-URI refers
2940 to a data-producing process, it is the produced data which shall be
2941 returned as the entity in the response and not the source text of the
2942 process, unless that text happens to be the output of the process.
2944 The semantics of the GET method change to a "conditional GET" if the
2945 request message includes an If-Modified-Since, If-Unmodified-Since,
2946 If-Match, If-None-Match, or If-Range header field. A conditional GET
2947 method requests that the entity be transferred only under the
2948 circumstances described by the conditional header field(s). The
2949 conditional GET method is intended to reduce unnecessary network
2950 usage by allowing cached entities to be refreshed without requiring
2951 multiple requests or transferring data already held by the client.
2953 The semantics of the GET method change to a "partial GET" if the
2954 request message includes a Range header field. A partial GET requests
2955 that only part of the entity be transferred, as described in section
2956 14.35. The partial GET method is intended to reduce unnecessary
2957 network usage by allowing partially-retrieved entities to be
2958 completed without transferring data already held by the client.
2960 The response to a GET request is cacheable if and only if it meets
2961 the requirements for HTTP caching described in section 13.
2963 See section 15.1.3 for security considerations when used for forms.
2970Fielding, et al. Standards Track [Page 53]
2972RFC 2616 HTTP/1.1 June 1999
2977 The HEAD method is identical to GET except that the server MUST NOT
2978 return a message-body in the response. The metainformation contained
2979 in the HTTP headers in response to a HEAD request SHOULD be identical
2980 to the information sent in response to a GET request. This method can
2981 be used for obtaining metainformation about the entity implied by the
2982 request without transferring the entity-body itself. This method is
2983 often used for testing hypertext links for validity, accessibility,
2984 and recent modification.
2986 The response to a HEAD request MAY be cacheable in the sense that the
2987 information contained in the response MAY be used to update a
2988 previously cached entity from that resource. If the new field values
2989 indicate that the cached entity differs from the current entity (as
2990 would be indicated by a change in Content-Length, Content-MD5, ETag
2991 or Last-Modified), then the cache MUST treat the cache entry as
2996 The POST method is used to request that the origin server accept the
2997 entity enclosed in the request as a new subordinate of the resource
2998 identified by the Request-URI in the Request-Line. POST is designed
2999 to allow a uniform method to cover the following functions:
3001 - Annotation of existing resources;
3003 - Posting a message to a bulletin board, newsgroup, mailing list,
3004 or similar group of articles;
3006 - Providing a block of data, such as the result of submitting a
3007 form, to a data-handling process;
3009 - Extending a database through an append operation.
3011 The actual function performed by the POST method is determined by the
3012 server and is usually dependent on the Request-URI. The posted entity
3013 is subordinate to that URI in the same way that a file is subordinate
3014 to a directory containing it, a news article is subordinate to a
3015 newsgroup to which it is posted, or a record is subordinate to a
3018 The action performed by the POST method might not result in a
3019 resource that can be identified by a URI. In this case, either 200
3020 (OK) or 204 (No Content) is the appropriate response status,
3021 depending on whether or not the response includes an entity that
3022 describes the result.
3026Fielding, et al. Standards Track [Page 54]
3028RFC 2616 HTTP/1.1 June 1999
3031 If a resource has been created on the origin server, the response
3032 SHOULD be 201 (Created) and contain an entity which describes the
3033 status of the request and refers to the new resource, and a Location
3034 header (see section 14.30).
3036 Responses to this method are not cacheable, unless the response
3037 includes appropriate Cache-Control or Expires header fields. However,
3038 the 303 (See Other) response can be used to direct the user agent to
3039 retrieve a cacheable resource.
3041 POST requests MUST obey the message transmission requirements set out
3044 See section 15.1.3 for security considerations.
3048 The PUT method requests that the enclosed entity be stored under the
3049 supplied Request-URI. If the Request-URI refers to an already
3050 existing resource, the enclosed entity SHOULD be considered as a
3051 modified version of the one residing on the origin server. If the
3052 Request-URI does not point to an existing resource, and that URI is
3053 capable of being defined as a new resource by the requesting user
3054 agent, the origin server can create the resource with that URI. If a
3055 new resource is created, the origin server MUST inform the user agent
3056 via the 201 (Created) response. If an existing resource is modified,
3057 either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
3058 to indicate successful completion of the request. If the resource
3059 could not be created or modified with the Request-URI, an appropriate
3060 error response SHOULD be given that reflects the nature of the
3061 problem. The recipient of the entity MUST NOT ignore any Content-*
3062 (e.g. Content-Range) headers that it does not understand or implement
3063 and MUST return a 501 (Not Implemented) response in such cases.
3065 If the request passes through a cache and the Request-URI identifies
3066 one or more currently cached entities, those entries SHOULD be
3067 treated as stale. Responses to this method are not cacheable.
3069 The fundamental difference between the POST and PUT requests is
3070 reflected in the different meaning of the Request-URI. The URI in a
3071 POST request identifies the resource that will handle the enclosed
3072 entity. That resource might be a data-accepting process, a gateway to
3073 some other protocol, or a separate entity that accepts annotations.
3074 In contrast, the URI in a PUT request identifies the entity enclosed
3075 with the request -- the user agent knows what URI is intended and the
3076 server MUST NOT attempt to apply the request to some other resource.
3077 If the server desires that the request be applied to a different URI,
3082Fielding, et al. Standards Track [Page 55]
3084RFC 2616 HTTP/1.1 June 1999
3087 it MUST send a 301 (Moved Permanently) response; the user agent MAY
3088 then make its own decision regarding whether or not to redirect the
3091 A single resource MAY be identified by many different URIs. For
3092 example, an article might have a URI for identifying "the current
3093 version" which is separate from the URI identifying each particular
3094 version. In this case, a PUT request on a general URI might result in
3095 several other URIs being defined by the origin server.
3097 HTTP/1.1 does not define how a PUT method affects the state of an
3100 PUT requests MUST obey the message transmission requirements set out
3103 Unless otherwise specified for a particular entity-header, the
3104 entity-headers in the PUT request SHOULD be applied to the resource
3105 created or modified by the PUT.
3109 The DELETE method requests that the origin server delete the resource
3110 identified by the Request-URI. This method MAY be overridden by human
3111 intervention (or other means) on the origin server. The client cannot
3112 be guaranteed that the operation has been carried out, even if the
3113 status code returned from the origin server indicates that the action
3114 has been completed successfully. However, the server SHOULD NOT
3115 indicate success unless, at the time the response is given, it
3116 intends to delete the resource or move it to an inaccessible
3119 A successful response SHOULD be 200 (OK) if the response includes an
3120 entity describing the status, 202 (Accepted) if the action has not
3121 yet been enacted, or 204 (No Content) if the action has been enacted
3122 but the response does not include an entity.
3124 If the request passes through a cache and the Request-URI identifies
3125 one or more currently cached entities, those entries SHOULD be
3126 treated as stale. Responses to this method are not cacheable.
3130 The TRACE method is used to invoke a remote, application-layer loop-
3131 back of the request message. The final recipient of the request
3132 SHOULD reflect the message received back to the client as the
3133 entity-body of a 200 (OK) response. The final recipient is either the
3138Fielding, et al. Standards Track [Page 56]
3140RFC 2616 HTTP/1.1 June 1999
3143 origin server or the first proxy or gateway to receive a Max-Forwards
3144 value of zero (0) in the request (see section 14.31). A TRACE request
3145 MUST NOT include an entity.
3147 TRACE allows the client to see what is being received at the other
3148 end of the request chain and use that data for testing or diagnostic
3149 information. The value of the Via header field (section 14.45) is of
3150 particular interest, since it acts as a trace of the request chain.
3151 Use of the Max-Forwards header field allows the client to limit the
3152 length of the request chain, which is useful for testing a chain of
3153 proxies forwarding messages in an infinite loop.
3155 If the request is valid, the response SHOULD contain the entire
3156 request message in the entity-body, with a Content-Type of
3157 "message/http". Responses to this method MUST NOT be cached.
3161 This specification reserves the method name CONNECT for use with a
3162 proxy that can dynamically switch to being a tunnel (e.g. SSL
316510 Status Code Definitions
3167 Each Status-Code is described below, including a description of which
3168 method(s) it can follow and any metainformation required in the
317110.1 Informational 1xx
3173 This class of status code indicates a provisional response,
3174 consisting only of the Status-Line and optional headers, and is
3175 terminated by an empty line. There are no required headers for this
3176 class of status code. Since HTTP/1.0 did not define any 1xx status
3177 codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
3178 except under experimental conditions.
3180 A client MUST be prepared to accept one or more 1xx status responses
3181 prior to a regular response, even if the client does not expect a 100
3182 (Continue) status message. Unexpected 1xx status responses MAY be
3183 ignored by a user agent.
3185 Proxies MUST forward 1xx responses, unless the connection between the
3186 proxy and its client has been closed, or unless the proxy itself
3187 requested the generation of the 1xx response. (For example, if a
3194Fielding, et al. Standards Track [Page 57]
3196RFC 2616 HTTP/1.1 June 1999
3199 proxy adds a "Expect: 100-continue" field when it forwards a request,
3200 then it need not forward the corresponding 100 (Continue)
3205 The client SHOULD continue with its request. This interim response is
3206 used to inform the client that the initial part of the request has
3207 been received and has not yet been rejected by the server. The client
3208 SHOULD continue by sending the remainder of the request or, if the
3209 request has already been completed, ignore this response. The server
3210 MUST send a final response after the request has been completed. See
3211 section 8.2.3 for detailed discussion of the use and handling of this
321410.1.2 101 Switching Protocols
3216 The server understands and is willing to comply with the client's
3217 request, via the Upgrade message header field (section 14.42), for a
3218 change in the application protocol being used on this connection. The
3219 server will switch protocols to those defined by the response's
3220 Upgrade header field immediately after the empty line which
3221 terminates the 101 response.
3223 The protocol SHOULD be switched only when it is advantageous to do
3224 so. For example, switching to a newer version of HTTP is advantageous
3225 over older versions, and switching to a real-time, synchronous
3226 protocol might be advantageous when delivering resources that use
3231 This class of status code indicates that the client's request was
3232 successfully received, understood, and accepted.
3236 The request has succeeded. The information returned with the response
3237 is dependent on the method used in the request, for example:
3239 GET an entity corresponding to the requested resource is sent in
3242 HEAD the entity-header fields corresponding to the requested
3243 resource are sent in the response without any message-body;
3245 POST an entity describing or containing the result of the action;
3250Fielding, et al. Standards Track [Page 58]
3252RFC 2616 HTTP/1.1 June 1999
3255 TRACE an entity containing the request message as received by the
3260 The request has been fulfilled and resulted in a new resource being
3261 created. The newly created resource can be referenced by the URI(s)
3262 returned in the entity of the response, with the most specific URI
3263 for the resource given by a Location header field. The response
3264 SHOULD include an entity containing a list of resource
3265 characteristics and location(s) from which the user or user agent can
3266 choose the one most appropriate. The entity format is specified by
3267 the media type given in the Content-Type header field. The origin
3268 server MUST create the resource before returning the 201 status code.
3269 If the action cannot be carried out immediately, the server SHOULD
3270 respond with 202 (Accepted) response instead.
3272 A 201 response MAY contain an ETag response header field indicating
3273 the current value of the entity tag for the requested variant just
3274 created, see section 14.19.
3278 The request has been accepted for processing, but the processing has
3279 not been completed. The request might or might not eventually be
3280 acted upon, as it might be disallowed when processing actually takes
3281 place. There is no facility for re-sending a status code from an
3282 asynchronous operation such as this.
3284 The 202 response is intentionally non-committal. Its purpose is to
3285 allow a server to accept a request for some other process (perhaps a
3286 batch-oriented process that is only run once per day) without
3287 requiring that the user agent's connection to the server persist
3288 until the process is completed. The entity returned with this
3289 response SHOULD include an indication of the request's current status
3290 and either a pointer to a status monitor or some estimate of when the
3291 user can expect the request to be fulfilled.
329310.2.4 203 Non-Authoritative Information
3295 The returned metainformation in the entity-header is not the
3296 definitive set as available from the origin server, but is gathered
3297 from a local or a third-party copy. The set presented MAY be a subset
3298 or superset of the original version. For example, including local
3299 annotation information about the resource might result in a superset
3300 of the metainformation known by the origin server. Use of this
3301 response code is not required and is only appropriate when the
3302 response would otherwise be 200 (OK).
3306Fielding, et al. Standards Track [Page 59]
3308RFC 2616 HTTP/1.1 June 1999
331110.2.5 204 No Content
3313 The server has fulfilled the request but does not need to return an
3314 entity-body, and might want to return updated metainformation. The
3315 response MAY include new or updated metainformation in the form of
3316 entity-headers, which if present SHOULD be associated with the
3319 If the client is a user agent, it SHOULD NOT change its document view
3320 from that which caused the request to be sent. This response is
3321 primarily intended to allow input for actions to take place without
3322 causing a change to the user agent's active document view, although
3323 any new or updated metainformation SHOULD be applied to the document
3324 currently in the user agent's active view.
3326 The 204 response MUST NOT include a message-body, and thus is always
3327 terminated by the first empty line after the header fields.
332910.2.6 205 Reset Content
3331 The server has fulfilled the request and the user agent SHOULD reset
3332 the document view which caused the request to be sent. This response
3333 is primarily intended to allow input for actions to take place via
3334 user input, followed by a clearing of the form in which the input is
3335 given so that the user can easily initiate another input action. The
3336 response MUST NOT include an entity.
333810.2.7 206 Partial Content
3340 The server has fulfilled the partial GET request for the resource.
3341 The request MUST have included a Range header field (section 14.35)
3342 indicating the desired range, and MAY have included an If-Range
3343 header field (section 14.27) to make the request conditional.
3345 The response MUST include the following header fields:
3347 - Either a Content-Range header field (section 14.16) indicating
3348 the range included with this response, or a multipart/byteranges
3349 Content-Type including Content-Range fields for each part. If a
3350 Content-Length header field is present in the response, its
3351 value MUST match the actual number of OCTETs transmitted in the
3356 - ETag and/or Content-Location, if the header would have been sent
3357 in a 200 response to the same request
3362Fielding, et al. Standards Track [Page 60]
3364RFC 2616 HTTP/1.1 June 1999
3367 - Expires, Cache-Control, and/or Vary, if the field-value might
3368 differ from that sent in any previous response for the same
3371 If the 206 response is the result of an If-Range request that used a
3372 strong cache validator (see section 13.3.3), the response SHOULD NOT
3373 include other entity-headers. If the response is the result of an
3374 If-Range request that used a weak validator, the response MUST NOT
3375 include other entity-headers; this prevents inconsistencies between
3376 cached entity-bodies and updated headers. Otherwise, the response
3377 MUST include all of the entity-headers that would have been returned
3378 with a 200 (OK) response to the same request.
3380 A cache MUST NOT combine a 206 response with other previously cached
3381 content if the ETag or Last-Modified headers do not match exactly,
3384 A cache that does not support the Range and Content-Range headers
3385 MUST NOT cache 206 (Partial) responses.
3389 This class of status code indicates that further action needs to be
3390 taken by the user agent in order to fulfill the request. The action
3391 required MAY be carried out by the user agent without interaction
3392 with the user if and only if the method used in the second request is
3393 GET or HEAD. A client SHOULD detect infinite redirection loops, since
3394 such loops generate network traffic for each redirection.
3396 Note: previous versions of this specification recommended a
3397 maximum of five redirections. Content developers should be aware
3398 that there might be clients that implement such a fixed
340110.3.1 300 Multiple Choices
3403 The requested resource corresponds to any one of a set of
3404 representations, each with its own specific location, and agent-
3405 driven negotiation information (section 12) is being provided so that
3406 the user (or user agent) can select a preferred representation and
3407 redirect its request to that location.
3409 Unless it was a HEAD request, the response SHOULD include an entity
3410 containing a list of resource characteristics and location(s) from
3411 which the user or user agent can choose the one most appropriate. The
3412 entity format is specified by the media type given in the Content-
3413 Type header field. Depending upon the format and the capabilities of
3418Fielding, et al. Standards Track [Page 61]
3420RFC 2616 HTTP/1.1 June 1999
3423 the user agent, selection of the most appropriate choice MAY be
3424 performed automatically. However, this specification does not define
3425 any standard for such automatic selection.
3427 If the server has a preferred choice of representation, it SHOULD
3428 include the specific URI for that representation in the Location
3429 field; user agents MAY use the Location field value for automatic
3430 redirection. This response is cacheable unless indicated otherwise.
343210.3.2 301 Moved Permanently
3434 The requested resource has been assigned a new permanent URI and any
3435 future references to this resource SHOULD use one of the returned
3436 URIs. Clients with link editing capabilities ought to automatically
3437 re-link references to the Request-URI to one or more of the new
3438 references returned by the server, where possible. This response is
3439 cacheable unless indicated otherwise.
3441 The new permanent URI SHOULD be given by the Location field in the
3442 response. Unless the request method was HEAD, the entity of the
3443 response SHOULD contain a short hypertext note with a hyperlink to
3446 If the 301 status code is received in response to a request other
3447 than GET or HEAD, the user agent MUST NOT automatically redirect the
3448 request unless it can be confirmed by the user, since this might
3449 change the conditions under which the request was issued.
3451 Note: When automatically redirecting a POST request after
3452 receiving a 301 status code, some existing HTTP/1.0 user agents
3453 will erroneously change it into a GET request.
3457 The requested resource resides temporarily under a different URI.
3458 Since the redirection might be altered on occasion, the client SHOULD
3459 continue to use the Request-URI for future requests. This response
3460 is only cacheable if indicated by a Cache-Control or Expires header
3463 The temporary URI SHOULD be given by the Location field in the
3464 response. Unless the request method was HEAD, the entity of the
3465 response SHOULD contain a short hypertext note with a hyperlink to
3474Fielding, et al. Standards Track [Page 62]
3476RFC 2616 HTTP/1.1 June 1999
3479 If the 302 status code is received in response to a request other
3480 than GET or HEAD, the user agent MUST NOT automatically redirect the
3481 request unless it can be confirmed by the user, since this might
3482 change the conditions under which the request was issued.
3484 Note: RFC 1945 and RFC 2068 specify that the client is not allowed
3485 to change the method on the redirected request. However, most
3486 existing user agent implementations treat 302 as if it were a 303
3487 response, performing a GET on the Location field-value regardless
3488 of the original request method. The status codes 303 and 307 have
3489 been added for servers that wish to make unambiguously clear which
3490 kind of reaction is expected of the client.
3494 The response to the request can be found under a different URI and
3495 SHOULD be retrieved using a GET method on that resource. This method
3496 exists primarily to allow the output of a POST-activated script to
3497 redirect the user agent to a selected resource. The new URI is not a
3498 substitute reference for the originally requested resource. The 303
3499 response MUST NOT be cached, but the response to the second
3500 (redirected) request might be cacheable.
3502 The different URI SHOULD be given by the Location field in the
3503 response. Unless the request method was HEAD, the entity of the
3504 response SHOULD contain a short hypertext note with a hyperlink to
3507 Note: Many pre-HTTP/1.1 user agents do not understand the 303
3508 status. When interoperability with such clients is a concern, the
3509 302 status code may be used instead, since most user agents react
3510 to a 302 response as described here for 303.
351210.3.5 304 Not Modified
3514 If the client has performed a conditional GET request and access is
3515 allowed, but the document has not been modified, the server SHOULD
3516 respond with this status code. The 304 response MUST NOT contain a
3517 message-body, and thus is always terminated by the first empty line
3518 after the header fields.
3520 The response MUST include the following header fields:
3522 - Date, unless its omission is required by section 14.18.1
3530Fielding, et al. Standards Track [Page 63]
3532RFC 2616 HTTP/1.1 June 1999
3535 If a clockless origin server obeys these rules, and proxies and
3536 clients add their own Date to any response received without one (as
3537 already specified by [RFC 2068], section 14.19), caches will operate
3540 - ETag and/or Content-Location, if the header would have been sent
3541 in a 200 response to the same request
3543 - Expires, Cache-Control, and/or Vary, if the field-value might
3544 differ from that sent in any previous response for the same
3547 If the conditional GET used a strong cache validator (see section
3548 13.3.3), the response SHOULD NOT include other entity-headers.
3549 Otherwise (i.e., the conditional GET used a weak validator), the
3550 response MUST NOT include other entity-headers; this prevents
3551 inconsistencies between cached entity-bodies and updated headers.
3553 If a 304 response indicates an entity not currently cached, then the
3554 cache MUST disregard the response and repeat the request without the
3557 If a cache uses a received 304 response to update a cache entry, the
3558 cache MUST update the entry to reflect any new field values given in
3563 The requested resource MUST be accessed through the proxy given by
3564 the Location field. The Location field gives the URI of the proxy.
3565 The recipient is expected to repeat this single request via the
3566 proxy. 305 responses MUST only be generated by origin servers.
3568 Note: RFC 2068 was not clear that 305 was intended to redirect a
3569 single request, and to be generated by origin servers only. Not
3570 observing these limitations has significant security consequences.
3574 The 306 status code was used in a previous version of the
3575 specification, is no longer used, and the code is reserved.
3586Fielding, et al. Standards Track [Page 64]
3588RFC 2616 HTTP/1.1 June 1999
359110.3.8 307 Temporary Redirect
3593 The requested resource resides temporarily under a different URI.
3594 Since the redirection MAY be altered on occasion, the client SHOULD
3595 continue to use the Request-URI for future requests. This response
3596 is only cacheable if indicated by a Cache-Control or Expires header
3599 The temporary URI SHOULD be given by the Location field in the
3600 response. Unless the request method was HEAD, the entity of the
3601 response SHOULD contain a short hypertext note with a hyperlink to
3602 the new URI(s) , since many pre-HTTP/1.1 user agents do not
3603 understand the 307 status. Therefore, the note SHOULD contain the
3604 information necessary for a user to repeat the original request on
3607 If the 307 status code is received in response to a request other
3608 than GET or HEAD, the user agent MUST NOT automatically redirect the
3609 request unless it can be confirmed by the user, since this might
3610 change the conditions under which the request was issued.
361210.4 Client Error 4xx
3614 The 4xx class of status code is intended for cases in which the
3615 client seems to have erred. Except when responding to a HEAD request,
3616 the server SHOULD include an entity containing an explanation of the
3617 error situation, and whether it is a temporary or permanent
3618 condition. These status codes are applicable to any request method.
3619 User agents SHOULD display any included entity to the user.
3621 If the client is sending data, a server implementation using TCP
3622 SHOULD be careful to ensure that the client acknowledges receipt of
3623 the packet(s) containing the response, before the server closes the
3624 input connection. If the client continues sending data to the server
3625 after the close, the server's TCP stack will send a reset packet to
3626 the client, which may erase the client's unacknowledged input buffers
3627 before they can be read and interpreted by the HTTP application.
362910.4.1 400 Bad Request
3631 The request could not be understood by the server due to malformed
3632 syntax. The client SHOULD NOT repeat the request without
3642Fielding, et al. Standards Track [Page 65]
3644RFC 2616 HTTP/1.1 June 1999
364710.4.2 401 Unauthorized
3649 The request requires user authentication. The response MUST include a
3650 WWW-Authenticate header field (section 14.47) containing a challenge
3651 applicable to the requested resource. The client MAY repeat the
3652 request with a suitable Authorization header field (section 14.8). If
3653 the request already included Authorization credentials, then the 401
3654 response indicates that authorization has been refused for those
3655 credentials. If the 401 response contains the same challenge as the
3656 prior response, and the user agent has already attempted
3657 authentication at least once, then the user SHOULD be presented the
3658 entity that was given in the response, since that entity might
3659 include relevant diagnostic information. HTTP access authentication
3660 is explained in "HTTP Authentication: Basic and Digest Access
3661 Authentication" [43].
366310.4.3 402 Payment Required
3665 This code is reserved for future use.
3669 The server understood the request, but is refusing to fulfill it.
3670 Authorization will not help and the request SHOULD NOT be repeated.
3671 If the request method was not HEAD and the server wishes to make
3672 public why the request has not been fulfilled, it SHOULD describe the
3673 reason for the refusal in the entity. If the server does not wish to
3674 make this information available to the client, the status code 404
3675 (Not Found) can be used instead.
3679 The server has not found anything matching the Request-URI. No
3680 indication is given of whether the condition is temporary or
3681 permanent. The 410 (Gone) status code SHOULD be used if the server
3682 knows, through some internally configurable mechanism, that an old
3683 resource is permanently unavailable and has no forwarding address.
3684 This status code is commonly used when the server does not wish to
3685 reveal exactly why the request has been refused, or when no other
3686 response is applicable.
368810.4.6 405 Method Not Allowed
3690 The method specified in the Request-Line is not allowed for the
3691 resource identified by the Request-URI. The response MUST include an
3692 Allow header containing a list of valid methods for the requested
3698Fielding, et al. Standards Track [Page 66]
3700RFC 2616 HTTP/1.1 June 1999
370310.4.7 406 Not Acceptable
3705 The resource identified by the request is only capable of generating
3706 response entities which have content characteristics not acceptable
3707 according to the accept headers sent in the request.
3709 Unless it was a HEAD request, the response SHOULD include an entity
3710 containing a list of available entity characteristics and location(s)
3711 from which the user or user agent can choose the one most
3712 appropriate. The entity format is specified by the media type given
3713 in the Content-Type header field. Depending upon the format and the
3714 capabilities of the user agent, selection of the most appropriate
3715 choice MAY be performed automatically. However, this specification
3716 does not define any standard for such automatic selection.
3718 Note: HTTP/1.1 servers are allowed to return responses which are
3719 not acceptable according to the accept headers sent in the
3720 request. In some cases, this may even be preferable to sending a
3721 406 response. User agents are encouraged to inspect the headers of
3722 an incoming response to determine if it is acceptable.
3724 If the response could be unacceptable, a user agent SHOULD
3725 temporarily stop receipt of more data and query the user for a
3726 decision on further actions.
372810.4.8 407 Proxy Authentication Required
3730 This code is similar to 401 (Unauthorized), but indicates that the
3731 client must first authenticate itself with the proxy. The proxy MUST
3732 return a Proxy-Authenticate header field (section 14.33) containing a
3733 challenge applicable to the proxy for the requested resource. The
3734 client MAY repeat the request with a suitable Proxy-Authorization
3735 header field (section 14.34). HTTP access authentication is explained
3736 in "HTTP Authentication: Basic and Digest Access Authentication"
373910.4.9 408 Request Timeout
3741 The client did not produce a request within the time that the server
3742 was prepared to wait. The client MAY repeat the request without
3743 modifications at any later time.
3747 The request could not be completed due to a conflict with the current
3748 state of the resource. This code is only allowed in situations where
3749 it is expected that the user might be able to resolve the conflict
3750 and resubmit the request. The response body SHOULD include enough
3754Fielding, et al. Standards Track [Page 67]
3756RFC 2616 HTTP/1.1 June 1999
3759 information for the user to recognize the source of the conflict.
3760 Ideally, the response entity would include enough information for the
3761 user or user agent to fix the problem; however, that might not be
3762 possible and is not required.
3764 Conflicts are most likely to occur in response to a PUT request. For
3765 example, if versioning were being used and the entity being PUT
3766 included changes to a resource which conflict with those made by an
3767 earlier (third-party) request, the server might use the 409 response
3768 to indicate that it can't complete the request. In this case, the
3769 response entity would likely contain a list of the differences
3770 between the two versions in a format defined by the response
3775 The requested resource is no longer available at the server and no
3776 forwarding address is known. This condition is expected to be
3777 considered permanent. Clients with link editing capabilities SHOULD
3778 delete references to the Request-URI after user approval. If the
3779 server does not know, or has no facility to determine, whether or not
3780 the condition is permanent, the status code 404 (Not Found) SHOULD be
3781 used instead. This response is cacheable unless indicated otherwise.
3783 The 410 response is primarily intended to assist the task of web
3784 maintenance by notifying the recipient that the resource is
3785 intentionally unavailable and that the server owners desire that
3786 remote links to that resource be removed. Such an event is common for
3787 limited-time, promotional services and for resources belonging to
3788 individuals no longer working at the server's site. It is not
3789 necessary to mark all permanently unavailable resources as "gone" or
3790 to keep the mark for any length of time -- that is left to the
3791 discretion of the server owner.
379310.4.12 411 Length Required
3795 The server refuses to accept the request without a defined Content-
3796 Length. The client MAY repeat the request if it adds a valid
3797 Content-Length header field containing the length of the message-body
3798 in the request message.
380010.4.13 412 Precondition Failed
3802 The precondition given in one or more of the request-header fields
3803 evaluated to false when it was tested on the server. This response
3804 code allows the client to place preconditions on the current resource
3805 metainformation (header field data) and thus prevent the requested
3806 method from being applied to a resource other than the one intended.
3810Fielding, et al. Standards Track [Page 68]
3812RFC 2616 HTTP/1.1 June 1999
381510.4.14 413 Request Entity Too Large
3817 The server is refusing to process a request because the request
3818 entity is larger than the server is willing or able to process. The
3819 server MAY close the connection to prevent the client from continuing
3822 If the condition is temporary, the server SHOULD include a Retry-
3823 After header field to indicate that it is temporary and after what
3824 time the client MAY try again.
382610.4.15 414 Request-URI Too Long
3828 The server is refusing to service the request because the Request-URI
3829 is longer than the server is willing to interpret. This rare
3830 condition is only likely to occur when a client has improperly
3831 converted a POST request to a GET request with long query
3832 information, when the client has descended into a URI "black hole" of
3833 redirection (e.g., a redirected URI prefix that points to a suffix of
3834 itself), or when the server is under attack by a client attempting to
3835 exploit security holes present in some servers using fixed-length
3836 buffers for reading or manipulating the Request-URI.
383810.4.16 415 Unsupported Media Type
3840 The server is refusing to service the request because the entity of
3841 the request is in a format not supported by the requested resource
3842 for the requested method.
384410.4.17 416 Requested Range Not Satisfiable
3846 A server SHOULD return a response with this status code if a request
3847 included a Range request-header field (section 14.35), and none of
3848 the range-specifier values in this field overlap the current extent
3849 of the selected resource, and the request did not include an If-Range
3850 request-header field. (For byte-ranges, this means that the first-
3851 byte-pos of all of the byte-range-spec values were greater than the
3852 current length of the selected resource.)
3854 When this status code is returned for a byte-range request, the
3855 response SHOULD include a Content-Range entity-header field
3856 specifying the current length of the selected resource (see section
3857 14.16). This response MUST NOT use the multipart/byteranges content-
3866Fielding, et al. Standards Track [Page 69]
3868RFC 2616 HTTP/1.1 June 1999
387110.4.18 417 Expectation Failed
3873 The expectation given in an Expect request-header field (see section
3874 14.20) could not be met by this server, or, if the server is a proxy,
3875 the server has unambiguous evidence that the request could not be met
3876 by the next-hop server.
387810.5 Server Error 5xx
3880 Response status codes beginning with the digit "5" indicate cases in
3881 which the server is aware that it has erred or is incapable of
3882 performing the request. Except when responding to a HEAD request, the
3883 server SHOULD include an entity containing an explanation of the
3884 error situation, and whether it is a temporary or permanent
3885 condition. User agents SHOULD display any included entity to the
3886 user. These response codes are applicable to any request method.
388810.5.1 500 Internal Server Error
3890 The server encountered an unexpected condition which prevented it
3891 from fulfilling the request.
389310.5.2 501 Not Implemented
3895 The server does not support the functionality required to fulfill the
3896 request. This is the appropriate response when the server does not
3897 recognize the request method and is not capable of supporting it for
390010.5.3 502 Bad Gateway
3902 The server, while acting as a gateway or proxy, received an invalid
3903 response from the upstream server it accessed in attempting to
3904 fulfill the request.
390610.5.4 503 Service Unavailable
3908 The server is currently unable to handle the request due to a
3909 temporary overloading or maintenance of the server. The implication
3910 is that this is a temporary condition which will be alleviated after
3911 some delay. If known, the length of the delay MAY be indicated in a
3912 Retry-After header. If no Retry-After is given, the client SHOULD
3913 handle the response as it would for a 500 response.
3915 Note: The existence of the 503 status code does not imply that a
3916 server must use it when becoming overloaded. Some servers may wish
3917 to simply refuse the connection.
3922Fielding, et al. Standards Track [Page 70]
3924RFC 2616 HTTP/1.1 June 1999
392710.5.5 504 Gateway Timeout
3929 The server, while acting as a gateway or proxy, did not receive a
3930 timely response from the upstream server specified by the URI (e.g.
3931 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
3932 to access in attempting to complete the request.
3934 Note: Note to implementors: some deployed proxies are known to
3935 return 400 or 500 when DNS lookups time out.
393710.5.6 505 HTTP Version Not Supported
3939 The server does not support, or refuses to support, the HTTP protocol
3940 version that was used in the request message. The server is
3941 indicating that it is unable or unwilling to complete the request
3942 using the same major version as the client, as described in section
3943 3.1, other than with this error message. The response SHOULD contain
3944 an entity describing why that version is not supported and what other
3945 protocols are supported by that server.
394711 Access Authentication
3949 HTTP provides several OPTIONAL challenge-response authentication
3950 mechanisms which can be used by a server to challenge a client
3951 request and by a client to provide authentication information. The
3952 general framework for access authentication, and the specification of
3953 "basic" and "digest" authentication, are specified in "HTTP
3954 Authentication: Basic and Digest Access Authentication" [43]. This
3955 specification adopts the definitions of "challenge" and "credentials"
3956 from that specification.
395812 Content Negotiation
3960 Most HTTP responses include an entity which contains information for
3961 interpretation by a human user. Naturally, it is desirable to supply
3962 the user with the "best available" entity corresponding to the
3963 request. Unfortunately for servers and caches, not all users have the
3964 same preferences for what is "best," and not all user agents are
3965 equally capable of rendering all entity types. For that reason, HTTP
3966 has provisions for several mechanisms for "content negotiation" --
3967 the process of selecting the best representation for a given response
3968 when there are multiple representations available.
3970 Note: This is not called "format negotiation" because the
3971 alternate representations may be of the same media type, but use
3972 different capabilities of that type, be in different languages,
3978Fielding, et al. Standards Track [Page 71]
3980RFC 2616 HTTP/1.1 June 1999
3983 Any response containing an entity-body MAY be subject to negotiation,
3984 including error responses.
3986 There are two kinds of content negotiation which are possible in
3987 HTTP: server-driven and agent-driven negotiation. These two kinds of
3988 negotiation are orthogonal and thus may be used separately or in
3989 combination. One method of combination, referred to as transparent
3990 negotiation, occurs when a cache uses the agent-driven negotiation
3991 information provided by the origin server in order to provide
3992 server-driven negotiation for subsequent requests.
399412.1 Server-driven Negotiation
3996 If the selection of the best representation for a response is made by
3997 an algorithm located at the server, it is called server-driven
3998 negotiation. Selection is based on the available representations of
3999 the response (the dimensions over which it can vary; e.g. language,
4000 content-coding, etc.) and the contents of particular header fields in
4001 the request message or on other information pertaining to the request
4002 (such as the network address of the client).
4004 Server-driven negotiation is advantageous when the algorithm for
4005 selecting from among the available representations is difficult to
4006 describe to the user agent, or when the server desires to send its
4007 "best guess" to the client along with the first response (hoping to
4008 avoid the round-trip delay of a subsequent request if the "best
4009 guess" is good enough for the user). In order to improve the server's
4010 guess, the user agent MAY include request header fields (Accept,
4011 Accept-Language, Accept-Encoding, etc.) which describe its
4012 preferences for such a response.
4014 Server-driven negotiation has disadvantages:
4016 1. It is impossible for the server to accurately determine what
4017 might be "best" for any given user, since that would require
4018 complete knowledge of both the capabilities of the user agent
4019 and the intended use for the response (e.g., does the user want
4020 to view it on screen or print it on paper?).
4022 2. Having the user agent describe its capabilities in every
4023 request can be both very inefficient (given that only a small
4024 percentage of responses have multiple representations) and a
4025 potential violation of the user's privacy.
4027 3. It complicates the implementation of an origin server and the
4028 algorithms for generating responses to a request.
4034Fielding, et al. Standards Track [Page 72]
4036RFC 2616 HTTP/1.1 June 1999
4039 4. It may limit a public cache's ability to use the same response
4040 for multiple user's requests.
4042 HTTP/1.1 includes the following request-header fields for enabling
4043 server-driven negotiation through description of user agent
4044 capabilities and user preferences: Accept (section 14.1), Accept-
4045 Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
4046 Language (section 14.4), and User-Agent (section 14.43). However, an
4047 origin server is not limited to these dimensions and MAY vary the
4048 response based on any aspect of the request, including information
4049 outside the request-header fields or within extension header fields
4050 not defined by this specification.
4052 The Vary header field can be used to express the parameters the
4053 server uses to select a representation that is subject to server-
4054 driven negotiation. See section 13.6 for use of the Vary header field
4055 by caches and section 14.44 for use of the Vary header field by
405812.2 Agent-driven Negotiation
4060 With agent-driven negotiation, selection of the best representation
4061 for a response is performed by the user agent after receiving an
4062 initial response from the origin server. Selection is based on a list
4063 of the available representations of the response included within the
4064 header fields or entity-body of the initial response, with each
4065 representation identified by its own URI. Selection from among the
4066 representations may be performed automatically (if the user agent is
4067 capable of doing so) or manually by the user selecting from a
4068 generated (possibly hypertext) menu.
4070 Agent-driven negotiation is advantageous when the response would vary
4071 over commonly-used dimensions (such as type, language, or encoding),
4072 when the origin server is unable to determine a user agent's
4073 capabilities from examining the request, and generally when public
4074 caches are used to distribute server load and reduce network usage.
4076 Agent-driven negotiation suffers from the disadvantage of needing a
4077 second request to obtain the best alternate representation. This
4078 second request is only efficient when caching is used. In addition,
4079 this specification does not define any mechanism for supporting
4080 automatic selection, though it also does not prevent any such
4081 mechanism from being developed as an extension and used within
4090Fielding, et al. Standards Track [Page 73]
4092RFC 2616 HTTP/1.1 June 1999
4095 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
4096 status codes for enabling agent-driven negotiation when the server is
4097 unwilling or unable to provide a varying response using server-driven
410012.3 Transparent Negotiation
4102 Transparent negotiation is a combination of both server-driven and
4103 agent-driven negotiation. When a cache is supplied with a form of the
4104 list of available representations of the response (as in agent-driven
4105 negotiation) and the dimensions of variance are completely understood
4106 by the cache, then the cache becomes capable of performing server-
4107 driven negotiation on behalf of the origin server for subsequent
4108 requests on that resource.
4110 Transparent negotiation has the advantage of distributing the
4111 negotiation work that would otherwise be required of the origin
4112 server and also removing the second request delay of agent-driven
4113 negotiation when the cache is able to correctly guess the right
4116 This specification does not define any mechanism for transparent
4117 negotiation, though it also does not prevent any such mechanism from
4118 being developed as an extension that could be used within HTTP/1.1.
4122 HTTP is typically used for distributed information systems, where
4123 performance can be improved by the use of response caches. The
4124 HTTP/1.1 protocol includes a number of elements intended to make
4125 caching work as well as possible. Because these elements are
4126 inextricable from other aspects of the protocol, and because they
4127 interact with each other, it is useful to describe the basic caching
4128 design of HTTP separately from the detailed descriptions of methods,
4129 headers, response codes, etc.
4131 Caching would be useless if it did not significantly improve
4132 performance. The goal of caching in HTTP/1.1 is to eliminate the need
4133 to send requests in many cases, and to eliminate the need to send
4134 full responses in many other cases. The former reduces the number of
4135 network round-trips required for many operations; we use an
4136 "expiration" mechanism for this purpose (see section 13.2). The
4137 latter reduces network bandwidth requirements; we use a "validation"
4138 mechanism for this purpose (see section 13.3).
4140 Requirements for performance, availability, and disconnected
4141 operation require us to be able to relax the goal of semantic
4142 transparency. The HTTP/1.1 protocol allows origin servers, caches,
4146Fielding, et al. Standards Track [Page 74]
4148RFC 2616 HTTP/1.1 June 1999
4151 and clients to explicitly reduce transparency when necessary.
4152 However, because non-transparent operation may confuse non-expert
4153 users, and might be incompatible with certain server applications
4154 (such as those for ordering merchandise), the protocol requires that
4155 transparency be relaxed
4157 - only by an explicit protocol-level request when relaxed by
4158 client or origin server
4160 - only with an explicit warning to the end user when relaxed by
4163 Therefore, the HTTP/1.1 protocol provides these important elements:
4165 1. Protocol features that provide full semantic transparency when
4166 this is required by all parties.
4168 2. Protocol features that allow an origin server or user agent to
4169 explicitly request and control non-transparent operation.
4171 3. Protocol features that allow a cache to attach warnings to
4172 responses that do not preserve the requested approximation of
4173 semantic transparency.
4175 A basic principle is that it must be possible for the clients to
4176 detect any potential relaxation of semantic transparency.
4178 Note: The server, cache, or client implementor might be faced with
4179 design decisions not explicitly discussed in this specification.
4180 If a decision might affect semantic transparency, the implementor
4181 ought to err on the side of maintaining transparency unless a
4182 careful and complete analysis shows significant benefits in
4183 breaking transparency.
418513.1.1 Cache Correctness
4187 A correct cache MUST respond to a request with the most up-to-date
4188 response held by the cache that is appropriate to the request (see
4189 sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
4192 1. It has been checked for equivalence with what the origin server
4193 would have returned by revalidating the response with the
4194 origin server (section 13.3);
4202Fielding, et al. Standards Track [Page 75]
4204RFC 2616 HTTP/1.1 June 1999
4207 2. It is "fresh enough" (see section 13.2). In the default case,
4208 this means it meets the least restrictive freshness requirement
4209 of the client, origin server, and cache (see section 14.9); if
4210 the origin server so specifies, it is the freshness requirement
4211 of the origin server alone.
4213 If a stored response is not "fresh enough" by the most
4214 restrictive freshness requirement of both the client and the
4215 origin server, in carefully considered circumstances the cache
4216 MAY still return the response with the appropriate Warning
4217 header (see section 13.1.5 and 14.46), unless such a response
4218 is prohibited (e.g., by a "no-store" cache-directive, or by a
4219 "no-cache" cache-request-directive; see section 14.9).
4221 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
4222 or error (4xx or 5xx) response message.
4224 If the cache can not communicate with the origin server, then a
4225 correct cache SHOULD respond as above if the response can be
4226 correctly served from the cache; if not it MUST return an error or
4227 warning indicating that there was a communication failure.
4229 If a cache receives a response (either an entire response, or a 304
4230 (Not Modified) response) that it would normally forward to the
4231 requesting client, and the received response is no longer fresh, the
4232 cache SHOULD forward it to the requesting client without adding a new
4233 Warning (but without removing any existing Warning headers). A cache
4234 SHOULD NOT attempt to revalidate a response simply because that
4235 response became stale in transit; this might lead to an infinite
4236 loop. A user agent that receives a stale response without a Warning
4237 MAY display a warning indication to the user.
4241 Whenever a cache returns a response that is neither first-hand nor
4242 "fresh enough" (in the sense of condition 2 in section 13.1.1), it
4243 MUST attach a warning to that effect, using a Warning general-header.
4244 The Warning header and the currently defined warnings are described
4245 in section 14.46. The warning allows clients to take appropriate
4248 Warnings MAY be used for other purposes, both cache-related and
4249 otherwise. The use of a warning, rather than an error status code,
4250 distinguish these responses from true failures.
4252 Warnings are assigned three digit warn-codes. The first digit
4253 indicates whether the Warning MUST or MUST NOT be deleted from a
4254 stored cache entry after a successful revalidation:
4258Fielding, et al. Standards Track [Page 76]
4260RFC 2616 HTTP/1.1 June 1999
4263 1xx Warnings that describe the freshness or revalidation status of
4264 the response, and so MUST be deleted after a successful
4265 revalidation. 1XX warn-codes MAY be generated by a cache only when
4266 validating a cached entry. It MUST NOT be generated by clients.
4268 2xx Warnings that describe some aspect of the entity body or entity
4269 headers that is not rectified by a revalidation (for example, a
4270 lossy compression of the entity bodies) and which MUST NOT be
4271 deleted after a successful revalidation.
4273 See section 14.46 for the definitions of the codes themselves.
4275 HTTP/1.0 caches will cache all Warnings in responses, without
4276 deleting the ones in the first category. Warnings in responses that
4277 are passed to HTTP/1.0 caches carry an extra warning-date field,
4278 which prevents a future HTTP/1.1 recipient from believing an
4279 erroneously cached Warning.
4281 Warnings also carry a warning text. The text MAY be in any
4282 appropriate natural language (perhaps based on the client's Accept
4283 headers), and include an OPTIONAL indication of what character set is
4286 Multiple warnings MAY be attached to a response (either by the origin
4287 server or by a cache), including multiple warnings with the same code
4288 number. For example, a server might provide the same warning with
4289 texts in both English and Basque.
4291 When multiple warnings are attached to a response, it might not be
4292 practical or reasonable to display all of them to the user. This
4293 version of HTTP does not specify strict priority rules for deciding
4294 which warnings to display and in what order, but does suggest some
429713.1.3 Cache-control Mechanisms
4299 The basic cache mechanisms in HTTP/1.1 (server-specified expiration
4300 times and validators) are implicit directives to caches. In some
4301 cases, a server or client might need to provide explicit directives
4302 to the HTTP caches. We use the Cache-Control header for this purpose.
4304 The Cache-Control header allows a client or server to transmit a
4305 variety of directives in either requests or responses. These
4306 directives typically override the default caching algorithms. As a
4307 general rule, if there is any apparent conflict between header
4308 values, the most restrictive interpretation is applied (that is, the
4309 one that is most likely to preserve semantic transparency). However,
4314Fielding, et al. Standards Track [Page 77]
4316RFC 2616 HTTP/1.1 June 1999
4319 in some cases, cache-control directives are explicitly specified as
4320 weakening the approximation of semantic transparency (for example,
4321 "max-stale" or "public").
4323 The cache-control directives are described in detail in section 14.9.
432513.1.4 Explicit User Agent Warnings
4327 Many user agents make it possible for users to override the basic
4328 caching mechanisms. For example, the user agent might allow the user
4329 to specify that cached entities (even explicitly stale ones) are
4330 never validated. Or the user agent might habitually add "Cache-
4331 Control: max-stale=3600" to every request. The user agent SHOULD NOT
4332 default to either non-transparent behavior, or behavior that results
4333 in abnormally ineffective caching, but MAY be explicitly configured
4334 to do so by an explicit action of the user.
4336 If the user has overridden the basic caching mechanisms, the user
4337 agent SHOULD explicitly indicate to the user whenever this results in
4338 the display of information that might not meet the server's
4339 transparency requirements (in particular, if the displayed entity is
4340 known to be stale). Since the protocol normally allows the user agent
4341 to determine if responses are stale or not, this indication need only
4342 be displayed when this actually happens. The indication need not be a
4343 dialog box; it could be an icon (for example, a picture of a rotting
4344 fish) or some other indicator.
4346 If the user has overridden the caching mechanisms in a way that would
4347 abnormally reduce the effectiveness of caches, the user agent SHOULD
4348 continually indicate this state to the user (for example, by a
4349 display of a picture of currency in flames) so that the user does not
4350 inadvertently consume excess resources or suffer from excessive
435313.1.5 Exceptions to the Rules and Warnings
4355 In some cases, the operator of a cache MAY choose to configure it to
4356 return stale responses even when not requested by clients. This
4357 decision ought not be made lightly, but may be necessary for reasons
4358 of availability or performance, especially when the cache is poorly
4359 connected to the origin server. Whenever a cache returns a stale
4360 response, it MUST mark it as such (using a Warning header) enabling
4361 the client software to alert the user that there might be a potential
4370Fielding, et al. Standards Track [Page 78]
4372RFC 2616 HTTP/1.1 June 1999
4375 It also allows the user agent to take steps to obtain a first-hand or
4376 fresh response. For this reason, a cache SHOULD NOT return a stale
4377 response if the client explicitly requests a first-hand or fresh one,
4378 unless it is impossible to comply for technical or policy reasons.
438013.1.6 Client-controlled Behavior
4382 While the origin server (and to a lesser extent, intermediate caches,
4383 by their contribution to the age of a response) are the primary
4384 source of expiration information, in some cases the client might need
4385 to control a cache's decision about whether to return a cached
4386 response without validating it. Clients do this using several
4387 directives of the Cache-Control header.
4389 A client's request MAY specify the maximum age it is willing to
4390 accept of an unvalidated response; specifying a value of zero forces
4391 the cache(s) to revalidate all responses. A client MAY also specify
4392 the minimum time remaining before a response expires. Both of these
4393 options increase constraints on the behavior of caches, and so cannot
4394 further relax the cache's approximation of semantic transparency.
4396 A client MAY also specify that it will accept stale responses, up to
4397 some maximum amount of staleness. This loosens the constraints on the
4398 caches, and so might violate the origin server's specified
4399 constraints on semantic transparency, but might be necessary to
4400 support disconnected operation, or high availability in the face of
440313.2 Expiration Model
440513.2.1 Server-Specified Expiration
4407 HTTP caching works best when caches can entirely avoid making
4408 requests to the origin server. The primary mechanism for avoiding
4409 requests is for an origin server to provide an explicit expiration
4410 time in the future, indicating that a response MAY be used to satisfy
4411 subsequent requests. In other words, a cache can return a fresh
4412 response without first contacting the server.
4414 Our expectation is that servers will assign future explicit
4415 expiration times to responses in the belief that the entity is not
4416 likely to change, in a semantically significant way, before the
4417 expiration time is reached. This normally preserves semantic
4418 transparency, as long as the server's expiration times are carefully
4426Fielding, et al. Standards Track [Page 79]
4428RFC 2616 HTTP/1.1 June 1999
4431 The expiration mechanism applies only to responses taken from a cache
4432 and not to first-hand responses forwarded immediately to the
4435 If an origin server wishes to force a semantically transparent cache
4436 to validate every request, it MAY assign an explicit expiration time
4437 in the past. This means that the response is always stale, and so the
4438 cache SHOULD validate it before using it for subsequent requests. See
4439 section 14.9.4 for a more restrictive way to force revalidation.
4441 If an origin server wishes to force any HTTP/1.1 cache, no matter how
4442 it is configured, to validate every request, it SHOULD use the "must-
4443 revalidate" cache-control directive (see section 14.9).
4445 Servers specify explicit expiration times using either the Expires
4446 header, or the max-age directive of the Cache-Control header.
4448 An expiration time cannot be used to force a user agent to refresh
4449 its display or reload a resource; its semantics apply only to caching
4450 mechanisms, and such mechanisms need only check a resource's
4451 expiration status when a new request for that resource is initiated.
4452 See section 13.13 for an explanation of the difference between caches
4453 and history mechanisms.
445513.2.2 Heuristic Expiration
4457 Since origin servers do not always provide explicit expiration times,
4458 HTTP caches typically assign heuristic expiration times, employing
4459 algorithms that use other header values (such as the Last-Modified
4460 time) to estimate a plausible expiration time. The HTTP/1.1
4461 specification does not provide specific algorithms, but does impose
4462 worst-case constraints on their results. Since heuristic expiration
4463 times might compromise semantic transparency, they ought to used
4464 cautiously, and we encourage origin servers to provide explicit
4465 expiration times as much as possible.
446713.2.3 Age Calculations
4469 In order to know if a cached entry is fresh, a cache needs to know if
4470 its age exceeds its freshness lifetime. We discuss how to calculate
4471 the latter in section 13.2.4; this section describes how to calculate
4472 the age of a response or cache entry.
4474 In this discussion, we use the term "now" to mean "the current value
4475 of the clock at the host performing the calculation." Hosts that use
4476 HTTP, but especially hosts running origin servers and caches, SHOULD
4477 use NTP [28] or some similar protocol to synchronize their clocks to
4478 a globally accurate time standard.
4482Fielding, et al. Standards Track [Page 80]
4484RFC 2616 HTTP/1.1 June 1999
4487 HTTP/1.1 requires origin servers to send a Date header, if possible,
4488 with every response, giving the time at which the response was
4489 generated (see section 14.18). We use the term "date_value" to denote
4490 the value of the Date header, in a form appropriate for arithmetic
4493 HTTP/1.1 uses the Age response-header to convey the estimated age of
4494 the response message when obtained from a cache. The Age field value
4495 is the cache's estimate of the amount of time since the response was
4496 generated or revalidated by the origin server.
4498 In essence, the Age value is the sum of the time that the response
4499 has been resident in each of the caches along the path from the
4500 origin server, plus the amount of time it has been in transit along
4503 We use the term "age_value" to denote the value of the Age header, in
4504 a form appropriate for arithmetic operations.
4506 A response's age can be calculated in two entirely independent ways:
4508 1. now minus date_value, if the local clock is reasonably well
4509 synchronized to the origin server's clock. If the result is
4510 negative, the result is replaced by zero.
4512 2. age_value, if all of the caches along the response path
4515 Given that we have two independent ways to compute the age of a
4516 response when it is received, we can combine these as
4518 corrected_received_age = max(now - date_value, age_value)
4520 and as long as we have either nearly synchronized clocks or all-
4521 HTTP/1.1 paths, one gets a reliable (conservative) result.
4523 Because of network-imposed delays, some significant interval might
4524 pass between the time that a server generates a response and the time
4525 it is received at the next outbound cache or client. If uncorrected,
4526 this delay could result in improperly low ages.
4528 Because the request that resulted in the returned Age value must have
4529 been initiated prior to that Age value's generation, we can correct
4530 for delays imposed by the network by recording the time at which the
4531 request was initiated. Then, when an Age value is received, it MUST
4532 be interpreted relative to the time the request was initiated, not
4538Fielding, et al. Standards Track [Page 81]
4540RFC 2616 HTTP/1.1 June 1999
4543 the time that the response was received. This algorithm results in
4544 conservative behavior no matter how much delay is experienced. So, we
4547 corrected_initial_age = corrected_received_age
4548 + (now - request_time)
4550 where "request_time" is the time (according to the local clock) when
4551 the request that elicited this response was sent.
4553 Summary of age calculation algorithm, when a cache receives a
4558 * is the value of Age: header received by the cache with
4561 * is the value of the origin server's Date: header
4563 * is the (local) time when the cache made the request
4564 * that resulted in this cached response
4566 * is the (local) time when the cache received the
4569 * is the current (local) time
4572 apparent_age = max(0, response_time - date_value);
4573 corrected_received_age = max(apparent_age, age_value);
4574 response_delay = response_time - request_time;
4575 corrected_initial_age = corrected_received_age + response_delay;
4576 resident_time = now - response_time;
4577 current_age = corrected_initial_age + resident_time;
4579 The current_age of a cache entry is calculated by adding the amount
4580 of time (in seconds) since the cache entry was last validated by the
4581 origin server to the corrected_initial_age. When a response is
4582 generated from a cache entry, the cache MUST include a single Age
4583 header field in the response with a value equal to the cache entry's
4586 The presence of an Age header field in a response implies that a
4587 response is not first-hand. However, the converse is not true, since
4588 the lack of an Age header field in a response does not imply that the
4594Fielding, et al. Standards Track [Page 82]
4596RFC 2616 HTTP/1.1 June 1999
4599 response is first-hand unless all caches along the request path are
4600 compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
4601 the Age header field).
460313.2.4 Expiration Calculations
4605 In order to decide whether a response is fresh or stale, we need to
4606 compare its freshness lifetime to its age. The age is calculated as
4607 described in section 13.2.3; this section describes how to calculate
4608 the freshness lifetime, and to determine if a response has expired.
4609 In the discussion below, the values can be represented in any form
4610 appropriate for arithmetic operations.
4612 We use the term "expires_value" to denote the value of the Expires
4613 header. We use the term "max_age_value" to denote an appropriate
4614 value of the number of seconds carried by the "max-age" directive of
4615 the Cache-Control header in a response (see section 14.9.3).
4617 The max-age directive takes priority over Expires, so if max-age is
4618 present in a response, the calculation is simply:
4620 freshness_lifetime = max_age_value
4622 Otherwise, if Expires is present in the response, the calculation is:
4624 freshness_lifetime = expires_value - date_value
4626 Note that neither of these calculations is vulnerable to clock skew,
4627 since all of the information comes from the origin server.
4629 If none of Expires, Cache-Control: max-age, or Cache-Control: s-
4630 maxage (see section 14.9.3) appears in the response, and the response
4631 does not include other restrictions on caching, the cache MAY compute
4632 a freshness lifetime using a heuristic. The cache MUST attach Warning
4633 113 to any response whose age is more than 24 hours if such warning
4634 has not already been added.
4636 Also, if the response does have a Last-Modified time, the heuristic
4637 expiration value SHOULD be no more than some fraction of the interval
4638 since that time. A typical setting of this fraction might be 10%.
4640 The calculation to determine if a response has expired is quite
4643 response_is_fresh = (freshness_lifetime > current_age)
4650Fielding, et al. Standards Track [Page 83]
4652RFC 2616 HTTP/1.1 June 1999
465513.2.5 Disambiguating Expiration Values
4657 Because expiration values are assigned optimistically, it is possible
4658 for two caches to contain fresh values for the same resource that are
4661 If a client performing a retrieval receives a non-first-hand response
4662 for a request that was already fresh in its own cache, and the Date
4663 header in its existing cache entry is newer than the Date on the new
4664 response, then the client MAY ignore the response. If so, it MAY
4665 retry the request with a "Cache-Control: max-age=0" directive (see
4666 section 14.9), to force a check with the origin server.
4668 If a cache has two fresh responses for the same representation with
4669 different validators, it MUST use the one with the more recent Date
4670 header. This situation might arise because the cache is pooling
4671 responses from other caches, or because a client has asked for a
4672 reload or a revalidation of an apparently fresh cache entry.
467413.2.6 Disambiguating Multiple Responses
4676 Because a client might be receiving responses via multiple paths, so
4677 that some responses flow through one set of caches and other
4678 responses flow through a different set of caches, a client might
4679 receive responses in an order different from that in which the origin
4680 server sent them. We would like the client to use the most recently
4681 generated response, even if older responses are still apparently
4684 Neither the entity tag nor the expiration value can impose an
4685 ordering on responses, since it is possible that a later response
4686 intentionally carries an earlier expiration time. The Date values are
4687 ordered to a granularity of one second.
4689 When a client tries to revalidate a cache entry, and the response it
4690 receives contains a Date header that appears to be older than the one
4691 for the existing entry, then the client SHOULD repeat the request
4692 unconditionally, and include
4694 Cache-Control: max-age=0
4696 to force any intermediate caches to validate their copies directly
4697 with the origin server, or
4699 Cache-Control: no-cache
4701 to force any intermediate caches to obtain a new copy from the origin
4706Fielding, et al. Standards Track [Page 84]
4708RFC 2616 HTTP/1.1 June 1999
4711 If the Date values are equal, then the client MAY use either response
4712 (or MAY, if it is being extremely prudent, request a new response).
4713 Servers MUST NOT depend on clients being able to choose
4714 deterministically between responses generated during the same second,
4715 if their expiration times overlap.
471713.3 Validation Model
4719 When a cache has a stale entry that it would like to use as a
4720 response to a client's request, it first has to check with the origin
4721 server (or possibly an intermediate cache with a fresh response) to
4722 see if its cached entry is still usable. We call this "validating"
4723 the cache entry. Since we do not want to have to pay the overhead of
4724 retransmitting the full response if the cached entry is good, and we
4725 do not want to pay the overhead of an extra round trip if the cached
4726 entry is invalid, the HTTP/1.1 protocol supports the use of
4727 conditional methods.
4729 The key protocol features for supporting conditional methods are
4730 those concerned with "cache validators." When an origin server
4731 generates a full response, it attaches some sort of validator to it,
4732 which is kept with the cache entry. When a client (user agent or
4733 proxy cache) makes a conditional request for a resource for which it
4734 has a cache entry, it includes the associated validator in the
4737 The server then checks that validator against the current validator
4738 for the entity, and, if they match (see section 13.3.3), it responds
4739 with a special status code (usually, 304 (Not Modified)) and no
4740 entity-body. Otherwise, it returns a full response (including
4741 entity-body). Thus, we avoid transmitting the full response if the
4742 validator matches, and we avoid an extra round trip if it does not
4745 In HTTP/1.1, a conditional request looks exactly the same as a normal
4746 request for the same resource, except that it carries a special
4747 header (which includes the validator) that implicitly turns the
4748 method (usually, GET) into a conditional.
4750 The protocol includes both positive and negative senses of cache-
4751 validating conditions. That is, it is possible to request either that
4752 a method be performed if and only if a validator matches or if and
4753 only if no validators match.
4762Fielding, et al. Standards Track [Page 85]
4764RFC 2616 HTTP/1.1 June 1999
4767 Note: a response that lacks a validator may still be cached, and
4768 served from cache until it expires, unless this is explicitly
4769 prohibited by a cache-control directive. However, a cache cannot
4770 do a conditional retrieval if it does not have a validator for the
4771 entity, which means it will not be refreshable after it expires.
477313.3.1 Last-Modified Dates
4775 The Last-Modified entity-header field value is often used as a cache
4776 validator. In simple terms, a cache entry is considered to be valid
4777 if the entity has not been modified since the Last-Modified value.
477913.3.2 Entity Tag Cache Validators
4781 The ETag response-header field value, an entity tag, provides for an
4782 "opaque" cache validator. This might allow more reliable validation
4783 in situations where it is inconvenient to store modification dates,
4784 where the one-second resolution of HTTP date values is not
4785 sufficient, or where the origin server wishes to avoid certain
4786 paradoxes that might arise from the use of modification dates.
4788 Entity Tags are described in section 3.11. The headers used with
4789 entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
479113.3.3 Weak and Strong Validators
4793 Since both origin servers and caches will compare two validators to
4794 decide if they represent the same or different entities, one normally
4795 would expect that if the entity (the entity-body or any entity-
4796 headers) changes in any way, then the associated validator would
4797 change as well. If this is true, then we call this validator a
4800 However, there might be cases when a server prefers to change the
4801 validator only on semantically significant changes, and not when
4802 insignificant aspects of the entity change. A validator that does not
4803 always change when the resource changes is a "weak validator."
4805 Entity tags are normally "strong validators," but the protocol
4806 provides a mechanism to tag an entity tag as "weak." One can think of
4807 a strong validator as one that changes whenever the bits of an entity
4808 changes, while a weak value changes whenever the meaning of an entity
4809 changes. Alternatively, one can think of a strong validator as part
4810 of an identifier for a specific entity, while a weak validator is
4811 part of an identifier for a set of semantically equivalent entities.
4813 Note: One example of a strong validator is an integer that is
4814 incremented in stable storage every time an entity is changed.
4818Fielding, et al. Standards Track [Page 86]
4820RFC 2616 HTTP/1.1 June 1999
4823 An entity's modification time, if represented with one-second
4824 resolution, could be a weak validator, since it is possible that
4825 the resource might be modified twice during a single second.
4827 Support for weak validators is optional. However, weak validators
4828 allow for more efficient caching of equivalent objects; for
4829 example, a hit counter on a site is probably good enough if it is
4830 updated every few days or weeks, and any value during that period
4831 is likely "good enough" to be equivalent.
4833 A "use" of a validator is either when a client generates a request
4834 and includes the validator in a validating header field, or when a
4835 server compares two validators.
4837 Strong validators are usable in any context. Weak validators are only
4838 usable in contexts that do not depend on exact equality of an entity.
4839 For example, either kind is usable for a conditional GET of a full
4840 entity. However, only a strong validator is usable for a sub-range
4841 retrieval, since otherwise the client might end up with an internally
4842 inconsistent entity.
4844 Clients MAY issue simple (non-subrange) GET requests with either weak
4845 validators or strong validators. Clients MUST NOT use weak validators
4846 in other forms of request.
4848 The only function that the HTTP/1.1 protocol defines on validators is
4849 comparison. There are two validator comparison functions, depending
4850 on whether the comparison context allows the use of weak validators
4853 - The strong comparison function: in order to be considered equal,
4854 both validators MUST be identical in every way, and both MUST
4857 - The weak comparison function: in order to be considered equal,
4858 both validators MUST be identical in every way, but either or
4859 both of them MAY be tagged as "weak" without affecting the
4862 An entity tag is strong unless it is explicitly tagged as weak.
4863 Section 3.11 gives the syntax for entity tags.
4865 A Last-Modified time, when used as a validator in a request, is
4866 implicitly weak unless it is possible to deduce that it is strong,
4867 using the following rules:
4869 - The validator is being compared by an origin server to the
4870 actual current validator for the entity and,
4874Fielding, et al. Standards Track [Page 87]
4876RFC 2616 HTTP/1.1 June 1999
4879 - That origin server reliably knows that the associated entity did
4880 not change twice during the second covered by the presented
4885 - The validator is about to be used by a client in an If-
4886 Modified-Since or If-Unmodified-Since header, because the client
4887 has a cache entry for the associated entity, and
4889 - That cache entry includes a Date value, which gives the time
4890 when the origin server sent the original response, and
4892 - The presented Last-Modified time is at least 60 seconds before
4897 - The validator is being compared by an intermediate cache to the
4898 validator stored in its cache entry for the entity, and
4900 - That cache entry includes a Date value, which gives the time
4901 when the origin server sent the original response, and
4903 - The presented Last-Modified time is at least 60 seconds before
4906 This method relies on the fact that if two different responses were
4907 sent by the origin server during the same second, but both had the
4908 same Last-Modified time, then at least one of those responses would
4909 have a Date value equal to its Last-Modified time. The arbitrary 60-
4910 second limit guards against the possibility that the Date and Last-
4911 Modified values are generated from different clocks, or at somewhat
4912 different times during the preparation of the response. An
4913 implementation MAY use a value larger than 60 seconds, if it is
4914 believed that 60 seconds is too short.
4916 If a client wishes to perform a sub-range retrieval on a value for
4917 which it has only a Last-Modified time and no opaque validator, it
4918 MAY do this only if the Last-Modified time is strong in the sense
4921 A cache or origin server receiving a conditional request, other than
4922 a full-body GET request, MUST use the strong comparison function to
4923 evaluate the condition.
4925 These rules allow HTTP/1.1 caches and clients to safely perform sub-
4926 range retrievals on values that have been obtained from HTTP/1.0
4930Fielding, et al. Standards Track [Page 88]
4932RFC 2616 HTTP/1.1 June 1999
493713.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
4939 We adopt a set of rules and recommendations for origin servers,
4940 clients, and caches regarding when various validator types ought to
4941 be used, and for what purposes.
4943 HTTP/1.1 origin servers:
4945 - SHOULD send an entity tag validator unless it is not feasible to
4948 - MAY send a weak entity tag instead of a strong entity tag, if
4949 performance considerations support the use of weak entity tags,
4950 or if it is unfeasible to send a strong entity tag.
4952 - SHOULD send a Last-Modified value if it is feasible to send one,
4953 unless the risk of a breakdown in semantic transparency that
4954 could result from using this date in an If-Modified-Since header
4955 would lead to serious problems.
4957 In other words, the preferred behavior for an HTTP/1.1 origin server
4958 is to send both a strong entity tag and a Last-Modified value.
4960 In order to be legal, a strong entity tag MUST change whenever the
4961 associated entity value changes in any way. A weak entity tag SHOULD
4962 change whenever the associated entity changes in a semantically
4965 Note: in order to provide semantically transparent caching, an
4966 origin server must avoid reusing a specific strong entity tag
4967 value for two different entities, or reusing a specific weak
4968 entity tag value for two semantically different entities. Cache
4969 entries might persist for arbitrarily long periods, regardless of
4970 expiration times, so it might be inappropriate to expect that a
4971 cache will never again attempt to validate an entry using a
4972 validator that it obtained at some point in the past.
4976 - If an entity tag has been provided by the origin server, MUST
4977 use that entity tag in any cache-conditional request (using If-
4978 Match or If-None-Match).
4980 - If only a Last-Modified value has been provided by the origin
4981 server, SHOULD use that value in non-subrange cache-conditional
4982 requests (using If-Modified-Since).
4986Fielding, et al. Standards Track [Page 89]
4988RFC 2616 HTTP/1.1 June 1999
4991 - If only a Last-Modified value has been provided by an HTTP/1.0
4992 origin server, MAY use that value in subrange cache-conditional
4993 requests (using If-Unmodified-Since:). The user agent SHOULD
4994 provide a way to disable this, in case of difficulty.
4996 - If both an entity tag and a Last-Modified value have been
4997 provided by the origin server, SHOULD use both validators in
4998 cache-conditional requests. This allows both HTTP/1.0 and
4999 HTTP/1.1 caches to respond appropriately.
5001 An HTTP/1.1 origin server, upon receiving a conditional request that
5002 includes both a Last-Modified date (e.g., in an If-Modified-Since or
5003 If-Unmodified-Since header field) and one or more entity tags (e.g.,
5004 in an If-Match, If-None-Match, or If-Range header field) as cache
5005 validators, MUST NOT return a response status of 304 (Not Modified)
5006 unless doing so is consistent with all of the conditional header
5007 fields in the request.
5009 An HTTP/1.1 caching proxy, upon receiving a conditional request that
5010 includes both a Last-Modified date and one or more entity tags as
5011 cache validators, MUST NOT return a locally cached response to the
5012 client unless that cached response is consistent with all of the
5013 conditional header fields in the request.
5015 Note: The general principle behind these rules is that HTTP/1.1
5016 servers and clients should transmit as much non-redundant
5017 information as is available in their responses and requests.
5018 HTTP/1.1 systems receiving this information will make the most
5019 conservative assumptions about the validators they receive.
5021 HTTP/1.0 clients and caches will ignore entity tags. Generally,
5022 last-modified values received or used by these systems will
5023 support transparent and efficient caching, and so HTTP/1.1 origin
5024 servers should provide Last-Modified values. In those rare cases
5025 where the use of a Last-Modified value as a validator by an
5026 HTTP/1.0 system could result in a serious problem, then HTTP/1.1
5027 origin servers should not provide one.
502913.3.5 Non-validating Conditionals
5031 The principle behind entity tags is that only the service author
5032 knows the semantics of a resource well enough to select an
5033 appropriate cache validation mechanism, and the specification of any
5034 validator comparison function more complex than byte-equality would
5035 open up a can of worms. Thus, comparisons of any other headers
5036 (except Last-Modified, for compatibility with HTTP/1.0) are never
5037 used for purposes of validating a cache entry.
5042Fielding, et al. Standards Track [Page 90]
5044RFC 2616 HTTP/1.1 June 1999
504713.4 Response Cacheability
5049 Unless specifically constrained by a cache-control (section 14.9)
5050 directive, a caching system MAY always store a successful response
5051 (see section 13.8) as a cache entry, MAY return it without validation
5052 if it is fresh, and MAY return it after successful validation. If
5053 there is neither a cache validator nor an explicit expiration time
5054 associated with a response, we do not expect it to be cached, but
5055 certain caches MAY violate this expectation (for example, when little
5056 or no network connectivity is available). A client can usually detect
5057 that such a response was taken from a cache by comparing the Date
5058 header to the current time.
5060 Note: some HTTP/1.0 caches are known to violate this expectation
5061 without providing any Warning.
5063 However, in some cases it might be inappropriate for a cache to
5064 retain an entity, or to return it in response to a subsequent
5065 request. This might be because absolute semantic transparency is
5066 deemed necessary by the service author, or because of security or
5067 privacy considerations. Certain cache-control directives are
5068 therefore provided so that the server can indicate that certain
5069 resource entities, or portions thereof, are not to be cached
5070 regardless of other considerations.
5072 Note that section 14.8 normally prevents a shared cache from saving
5073 and returning a response to a previous request if that request
5074 included an Authorization header.
5076 A response received with a status code of 200, 203, 206, 300, 301 or
5077 410 MAY be stored by a cache and used in reply to a subsequent
5078 request, subject to the expiration mechanism, unless a cache-control
5079 directive prohibits caching. However, a cache that does not support
5080 the Range and Content-Range headers MUST NOT cache 206 (Partial
5083 A response received with any other status code (e.g. status codes 302
5084 and 307) MUST NOT be returned in a reply to a subsequent request
5085 unless there are cache-control directives or another header(s) that
5086 explicitly allow it. For example, these include the following: an
5087 Expires header (section 14.21); a "max-age", "s-maxage", "must-
5088 revalidate", "proxy-revalidate", "public" or "private" cache-control
5089 directive (section 14.9).
5098Fielding, et al. Standards Track [Page 91]
5100RFC 2616 HTTP/1.1 June 1999
510313.5 Constructing Responses From Caches
5105 The purpose of an HTTP cache is to store information received in
5106 response to requests for use in responding to future requests. In
5107 many cases, a cache simply returns the appropriate parts of a
5108 response to the requester. However, if the cache holds a cache entry
5109 based on a previous response, it might have to combine parts of a new
5110 response with what is held in the cache entry.
511213.5.1 End-to-end and Hop-by-hop Headers
5114 For the purpose of defining the behavior of caches and non-caching
5115 proxies, we divide HTTP headers into two categories:
5117 - End-to-end headers, which are transmitted to the ultimate
5118 recipient of a request or response. End-to-end headers in
5119 responses MUST be stored as part of a cache entry and MUST be
5120 transmitted in any response formed from a cache entry.
5122 - Hop-by-hop headers, which are meaningful only for a single
5123 transport-level connection, and are not stored by caches or
5124 forwarded by proxies.
5126 The following HTTP/1.1 headers are hop-by-hop headers:
5130 - Proxy-Authenticate
5131 - Proxy-Authorization
5137 All other headers defined by HTTP/1.1 are end-to-end headers.
5139 Other hop-by-hop headers MUST be listed in a Connection header,
5140 (section 14.10) to be introduced into HTTP/1.1 (or later).
514213.5.2 Non-modifiable Headers
5144 Some features of the HTTP/1.1 protocol, such as Digest
5145 Authentication, depend on the value of certain end-to-end headers. A
5146 transparent proxy SHOULD NOT modify an end-to-end header unless the
5147 definition of that header requires or specifically allows that.
5154Fielding, et al. Standards Track [Page 92]
5156RFC 2616 HTTP/1.1 June 1999
5159 A transparent proxy MUST NOT modify any of the following fields in a
5160 request or response, and it MUST NOT add any of these fields if not
5171 A transparent proxy MUST NOT modify any of the following fields in a
5176 but it MAY add any of these fields if not already present. If an
5177 Expires header is added, it MUST be given a field-value identical to
5178 that of the Date header in that response.
5180 A proxy MUST NOT modify or add any of the following fields in a
5181 message that contains the no-transform cache-control directive, or in
5190 A non-transparent proxy MAY modify or add these fields to a message
5191 that does not include no-transform, but if it does so, it MUST add a
5192 Warning 214 (Transformation applied) if one does not already appear
5193 in the message (see section 14.46).
5195 Warning: unnecessary modification of end-to-end headers might
5196 cause authentication failures if stronger authentication
5197 mechanisms are introduced in later versions of HTTP. Such
5198 authentication mechanisms MAY rely on the values of header fields
5201 The Content-Length field of a request or response is added or deleted
5202 according to the rules in section 4.4. A transparent proxy MUST
5203 preserve the entity-length (section 7.2.2) of the entity-body,
5204 although it MAY change the transfer-length (section 4.4).
5210Fielding, et al. Standards Track [Page 93]
5212RFC 2616 HTTP/1.1 June 1999
521513.5.3 Combining Headers
5217 When a cache makes a validating request to a server, and the server
5218 provides a 304 (Not Modified) response or a 206 (Partial Content)
5219 response, the cache then constructs a response to send to the
5222 If the status code is 304 (Not Modified), the cache uses the entity-
5223 body stored in the cache entry as the entity-body of this outgoing
5224 response. If the status code is 206 (Partial Content) and the ETag or
5225 Last-Modified headers match exactly, the cache MAY combine the
5226 contents stored in the cache entry with the new contents received in
5227 the response and use the result as the entity-body of this outgoing
5228 response, (see 13.5.4).
5230 The end-to-end headers stored in the cache entry are used for the
5231 constructed response, except that
5233 - any stored Warning headers with warn-code 1xx (see section
5234 14.46) MUST be deleted from the cache entry and the forwarded
5237 - any stored Warning headers with warn-code 2xx MUST be retained
5238 in the cache entry and the forwarded response.
5240 - any end-to-end headers provided in the 304 or 206 response MUST
5241 replace the corresponding headers from the cache entry.
5243 Unless the cache decides to remove the cache entry, it MUST also
5244 replace the end-to-end headers stored with the cache entry with
5245 corresponding headers received in the incoming response, except for
5246 Warning headers as described immediately above. If a header field-
5247 name in the incoming response matches more than one header in the
5248 cache entry, all such old headers MUST be replaced.
5250 In other words, the set of end-to-end headers received in the
5251 incoming response overrides all corresponding end-to-end headers
5252 stored with the cache entry (except for stored Warning headers with
5253 warn-code 1xx, which are deleted even if not overridden).
5255 Note: this rule allows an origin server to use a 304 (Not
5256 Modified) or a 206 (Partial Content) response to update any header
5257 associated with a previous response for the same entity or sub-
5258 ranges thereof, although it might not always be meaningful or
5259 correct to do so. This rule does not allow an origin server to use
5260 a 304 (Not Modified) or a 206 (Partial Content) response to
5261 entirely delete a header that it had provided with a previous
5266Fielding, et al. Standards Track [Page 94]
5268RFC 2616 HTTP/1.1 June 1999
527113.5.4 Combining Byte Ranges
5273 A response might transfer only a subrange of the bytes of an entity-
5274 body, either because the request included one or more Range
5275 specifications, or because a connection was broken prematurely. After
5276 several such transfers, a cache might have received several ranges of
5277 the same entity-body.
5279 If a cache has a stored non-empty set of subranges for an entity, and
5280 an incoming response transfers another subrange, the cache MAY
5281 combine the new subrange with the existing set if both the following
5284 - Both the incoming response and the cache entry have a cache
5287 - The two cache validators match using the strong comparison
5288 function (see section 13.3.3).
5290 If either requirement is not met, the cache MUST use only the most
5291 recent partial response (based on the Date values transmitted with
5292 every response, and using the incoming response if these values are
5293 equal or missing), and MUST discard the other partial information.
529513.6 Caching Negotiated Responses
5297 Use of server-driven content negotiation (section 12.1), as indicated
5298 by the presence of a Vary header field in a response, alters the
5299 conditions and procedure by which a cache can use the response for
5300 subsequent requests. See section 14.44 for use of the Vary header
5303 A server SHOULD use the Vary header field to inform a cache of what
5304 request-header fields were used to select among multiple
5305 representations of a cacheable response subject to server-driven
5306 negotiation. The set of header fields named by the Vary field value
5307 is known as the "selecting" request-headers.
5309 When the cache receives a subsequent request whose Request-URI
5310 specifies one or more cache entries including a Vary header field,
5311 the cache MUST NOT use such a cache entry to construct a response to
5312 the new request unless all of the selecting request-headers present
5313 in the new request match the corresponding stored request-headers in
5314 the original request.
5316 The selecting request-headers from two requests are defined to match
5317 if and only if the selecting request-headers in the first request can
5318 be transformed to the selecting request-headers in the second request
5322Fielding, et al. Standards Track [Page 95]
5324RFC 2616 HTTP/1.1 June 1999
5327 by adding or removing linear white space (LWS) at places where this
5328 is allowed by the corresponding BNF, and/or combining multiple
5329 message-header fields with the same field name following the rules
5330 about message headers in section 4.2.
5332 A Vary header field-value of "*" always fails to match and subsequent
5333 requests on that resource can only be properly interpreted by the
5336 If the selecting request header fields for the cached entry do not
5337 match the selecting request header fields of the new request, then
5338 the cache MUST NOT use a cached entry to satisfy the request unless
5339 it first relays the new request to the origin server in a conditional
5340 request and the server responds with 304 (Not Modified), including an
5341 entity tag or Content-Location that indicates the entity to be used.
5343 If an entity tag was assigned to a cached representation, the
5344 forwarded request SHOULD be conditional and include the entity tags
5345 in an If-None-Match header field from all its cache entries for the
5346 resource. This conveys to the server the set of entities currently
5347 held by the cache, so that if any one of these entities matches the
5348 requested entity, the server can use the ETag header field in its 304
5349 (Not Modified) response to tell the cache which entry is appropriate.
5350 If the entity-tag of the new response matches that of an existing
5351 entry, the new response SHOULD be used to update the header fields of
5352 the existing entry, and the result MUST be returned to the client.
5354 If any of the existing cache entries contains only partial content
5355 for the associated entity, its entity-tag SHOULD NOT be included in
5356 the If-None-Match header field unless the request is for a range that
5357 would be fully satisfied by that entry.
5359 If a cache receives a successful response whose Content-Location
5360 field matches that of an existing cache entry for the same Request-
5361 ]URI, whose entity-tag differs from that of the existing entry, and
5362 whose Date is more recent than that of the existing entry, the
5363 existing entry SHOULD NOT be returned in response to future requests
5364 and SHOULD be deleted from the cache.
536613.7 Shared and Non-Shared Caches
5368 For reasons of security and privacy, it is necessary to make a
5369 distinction between "shared" and "non-shared" caches. A non-shared
5370 cache is one that is accessible only to a single user. Accessibility
5371 in this case SHOULD be enforced by appropriate security mechanisms.
5372 All other caches are considered to be "shared." Other sections of
5378Fielding, et al. Standards Track [Page 96]
5380RFC 2616 HTTP/1.1 June 1999
5383 this specification place certain constraints on the operation of
5384 shared caches in order to prevent loss of privacy or failure of
538713.8 Errors or Incomplete Response Cache Behavior
5389 A cache that receives an incomplete response (for example, with fewer
5390 bytes of data than specified in a Content-Length header) MAY store
5391 the response. However, the cache MUST treat this as a partial
5392 response. Partial responses MAY be combined as described in section
5393 13.5.4; the result might be a full response or might still be
5394 partial. A cache MUST NOT return a partial response to a client
5395 without explicitly marking it as such, using the 206 (Partial
5396 Content) status code. A cache MUST NOT return a partial response
5397 using a status code of 200 (OK).
5399 If a cache receives a 5xx response while attempting to revalidate an
5400 entry, it MAY either forward this response to the requesting client,
5401 or act as if the server failed to respond. In the latter case, it MAY
5402 return a previously received response unless the cached entry
5403 includes the "must-revalidate" cache-control directive (see section
540613.9 Side Effects of GET and HEAD
5408 Unless the origin server explicitly prohibits the caching of their
5409 responses, the application of GET and HEAD methods to any resources
5410 SHOULD NOT have side effects that would lead to erroneous behavior if
5411 these responses are taken from a cache. They MAY still have side
5412 effects, but a cache is not required to consider such side effects in
5413 its caching decisions. Caches are always expected to observe an
5414 origin server's explicit restrictions on caching.
5416 We note one exception to this rule: since some applications have
5417 traditionally used GETs and HEADs with query URLs (those containing a
5418 "?" in the rel_path part) to perform operations with significant side
5419 effects, caches MUST NOT treat responses to such URIs as fresh unless
5420 the server provides an explicit expiration time. This specifically
5421 means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
5422 be taken from a cache. See section 9.1.1 for related information.
542413.10 Invalidation After Updates or Deletions
5426 The effect of certain methods performed on a resource at the origin
5427 server might cause one or more existing cache entries to become non-
5428 transparently invalid. That is, although they might continue to be
5429 "fresh," they do not accurately reflect what the origin server would
5430 return for a new request on that resource.
5434Fielding, et al. Standards Track [Page 97]
5436RFC 2616 HTTP/1.1 June 1999
5439 There is no way for the HTTP protocol to guarantee that all such
5440 cache entries are marked invalid. For example, the request that
5441 caused the change at the origin server might not have gone through
5442 the proxy where a cache entry is stored. However, several rules help
5443 reduce the likelihood of erroneous behavior.
5445 In this section, the phrase "invalidate an entity" means that the
5446 cache will either remove all instances of that entity from its
5447 storage, or will mark these as "invalid" and in need of a mandatory
5448 revalidation before they can be returned in response to a subsequent
5451 Some HTTP methods MUST cause a cache to invalidate an entity. This is
5452 either the entity referred to by the Request-URI, or by the Location
5453 or Content-Location headers (if present). These methods are:
5461 In order to prevent denial of service attacks, an invalidation based
5462 on the URI in a Location or Content-Location header MUST only be
5463 performed if the host part is the same as in the Request-URI.
5465 A cache that passes through requests for methods it does not
5466 understand SHOULD invalidate any entities referred to by the
546913.11 Write-Through Mandatory
5471 All methods that might be expected to cause modifications to the
5472 origin server's resources MUST be written through to the origin
5473 server. This currently includes all methods except for GET and HEAD.
5474 A cache MUST NOT reply to such a request from a client before having
5475 transmitted the request to the inbound server, and having received a
5476 corresponding response from the inbound server. This does not prevent
5477 a proxy cache from sending a 100 (Continue) response before the
5478 inbound server has sent its final reply.
5480 The alternative (known as "write-back" or "copy-back" caching) is not
5481 allowed in HTTP/1.1, due to the difficulty of providing consistent
5482 updates and the problems arising from server, cache, or network
5483 failure prior to write-back.
5490Fielding, et al. Standards Track [Page 98]
5492RFC 2616 HTTP/1.1 June 1999
549513.12 Cache Replacement
5497 If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
5498 response is received from a resource while any existing responses for
5499 the same resource are cached, the cache SHOULD use the new response
5500 to reply to the current request. It MAY insert it into cache storage
5501 and MAY, if it meets all other requirements, use it to respond to any
5502 future requests that would previously have caused the old response to
5503 be returned. If it inserts the new response into cache storage the
5504 rules in section 13.5.3 apply.
5506 Note: a new response that has an older Date header value than
5507 existing cached responses is not cacheable.
5511 User agents often have history mechanisms, such as "Back" buttons and
5512 history lists, which can be used to redisplay an entity retrieved
5513 earlier in a session.
5515 History mechanisms and caches are different. In particular history
5516 mechanisms SHOULD NOT try to show a semantically transparent view of
5517 the current state of a resource. Rather, a history mechanism is meant
5518 to show exactly what the user saw at the time when the resource was
5521 By default, an expiration time does not apply to history mechanisms.
5522 If the entity is still in storage, a history mechanism SHOULD display
5523 it even if the entity has expired, unless the user has specifically
5524 configured the agent to refresh expired history documents.
5526 This is not to be construed to prohibit the history mechanism from
5527 telling the user that a view might be stale.
5529 Note: if history list mechanisms unnecessarily prevent users from
5530 viewing stale resources, this will tend to force service authors
5531 to avoid using HTTP expiration controls and cache controls when
5532 they would otherwise like to. Service authors may consider it
5533 important that users not be presented with error messages or
5534 warning messages when they use navigation controls (such as BACK)
5535 to view previously fetched resources. Even though sometimes such
5536 resources ought not to cached, or ought to expire quickly, user
5537 interface considerations may force service authors to resort to
5538 other means of preventing caching (e.g. "once-only" URLs) in order
5539 not to suffer the effects of improperly functioning history
5546Fielding, et al. Standards Track [Page 99]
5548RFC 2616 HTTP/1.1 June 1999
555114 Header Field Definitions
5553 This section defines the syntax and semantics of all standard
5554 HTTP/1.1 header fields. For entity-header fields, both sender and
5555 recipient refer to either the client or the server, depending on who
5556 sends and who receives the entity.
5560 The Accept request-header field can be used to specify certain media
5561 types which are acceptable for the response. Accept headers can be
5562 used to indicate that the request is specifically limited to a small
5563 set of desired types, as in the case of a request for an in-line
5566 Accept = "Accept" ":"
5567 #( media-range [ accept-params ] )
5569 media-range = ( "*/*"
5571 | ( type "/" subtype )
5572 ) *( ";" parameter )
5573 accept-params = ";" "q" "=" qvalue *( accept-extension )
5574 accept-extension = ";" token [ "=" ( token | quoted-string ) ]
5576 The asterisk "*" character is used to group media types into ranges,
5577 with "*/*" indicating all media types and "type/*" indicating all
5578 subtypes of that type. The media-range MAY include media type
5579 parameters that are applicable to that range.
5581 Each media-range MAY be followed by one or more accept-params,
5582 beginning with the "q" parameter for indicating a relative quality
5583 factor. The first "q" parameter (if any) separates the media-range
5584 parameter(s) from the accept-params. Quality factors allow the user
5585 or user agent to indicate the relative degree of preference for that
5586 media-range, using the qvalue scale from 0 to 1 (section 3.9). The
5587 default value is q=1.
5589 Note: Use of the "q" parameter name to separate media type
5590 parameters from Accept extension parameters is due to historical
5591 practice. Although this prevents any media type parameter named
5592 "q" from being used with a media range, such an event is believed
5593 to be unlikely given the lack of any "q" parameters in the IANA
5594 media type registry and the rare usage of any media type
5595 parameters in Accept. Future media types are discouraged from
5596 registering any parameter named "q".
5602Fielding, et al. Standards Track [Page 100]
5604RFC 2616 HTTP/1.1 June 1999
5609 Accept: audio/*; q=0.2, audio/basic
5611 SHOULD be interpreted as "I prefer audio/basic, but send me any audio
5612 type if it is the best available after an 80% mark-down in quality."
5614 If no Accept header field is present, then it is assumed that the
5615 client accepts all media types. If an Accept header field is present,
5616 and if the server cannot send a response which is acceptable
5617 according to the combined Accept field value, then the server SHOULD
5618 send a 406 (not acceptable) response.
5620 A more elaborate example is
5622 Accept: text/plain; q=0.5, text/html,
5623 text/x-dvi; q=0.8, text/x-c
5625 Verbally, this would be interpreted as "text/html and text/x-c are
5626 the preferred media types, but if they do not exist, then send the
5627 text/x-dvi entity, and if that does not exist, send the text/plain
5630 Media ranges can be overridden by more specific media ranges or
5631 specific media types. If more than one media range applies to a given
5632 type, the most specific reference has precedence. For example,
5634 Accept: text/*, text/html, text/html;level=1, */*
5636 have the following precedence:
5638 1) text/html;level=1
5643 The media type quality factor associated with a given type is
5644 determined by finding the media range with the highest precedence
5645 which matches that type. For example,
5647 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
5648 text/html;level=2;q=0.4, */*;q=0.5
5650 would cause the following values to be associated:
5652 text/html;level=1 = 1
5658Fielding, et al. Standards Track [Page 101]
5660RFC 2616 HTTP/1.1 June 1999
5664 text/html;level=2 = 0.4
5665 text/html;level=3 = 0.7
5667 Note: A user agent might be provided with a default set of quality
5668 values for certain media ranges. However, unless the user agent is
5669 a closed system which cannot interact with other rendering agents,
5670 this default set ought to be configurable by the user.
5674 The Accept-Charset request-header field can be used to indicate what
5675 character sets are acceptable for the response. This field allows
5676 clients capable of understanding more comprehensive or special-
5677 purpose character sets to signal that capability to a server which is
5678 capable of representing documents in those character sets.
5680 Accept-Charset = "Accept-Charset" ":"
5681 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
5684 Character set values are described in section 3.4. Each charset MAY
5685 be given an associated quality value which represents the user's
5686 preference for that charset. The default value is q=1. An example is
5688 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
5690 The special value "*", if present in the Accept-Charset field,
5691 matches every character set (including ISO-8859-1) which is not
5692 mentioned elsewhere in the Accept-Charset field. If no "*" is present
5693 in an Accept-Charset field, then all character sets not explicitly
5694 mentioned get a quality value of 0, except for ISO-8859-1, which gets
5695 a quality value of 1 if not explicitly mentioned.
5697 If no Accept-Charset header is present, the default is that any
5698 character set is acceptable. If an Accept-Charset header is present,
5699 and if the server cannot send a response which is acceptable
5700 according to the Accept-Charset header, then the server SHOULD send
5701 an error response with the 406 (not acceptable) status code, though
5702 the sending of an unacceptable response is also allowed.
5706 The Accept-Encoding request-header field is similar to Accept, but
5707 restricts the content-codings (section 3.5) that are acceptable in
5710 Accept-Encoding = "Accept-Encoding" ":"
5714Fielding, et al. Standards Track [Page 102]
5716RFC 2616 HTTP/1.1 June 1999
5719 1#( codings [ ";" "q" "=" qvalue ] )
5720 codings = ( content-coding | "*" )
5722 Examples of its use are:
5724 Accept-Encoding: compress, gzip
5727 Accept-Encoding: compress;q=0.5, gzip;q=1.0
5728 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
5730 A server tests whether a content-coding is acceptable, according to
5731 an Accept-Encoding field, using these rules:
5733 1. If the content-coding is one of the content-codings listed in
5734 the Accept-Encoding field, then it is acceptable, unless it is
5735 accompanied by a qvalue of 0. (As defined in section 3.9, a
5736 qvalue of 0 means "not acceptable.")
5738 2. The special "*" symbol in an Accept-Encoding field matches any
5739 available content-coding not explicitly listed in the header
5742 3. If multiple content-codings are acceptable, then the acceptable
5743 content-coding with the highest non-zero qvalue is preferred.
5745 4. The "identity" content-coding is always acceptable, unless
5746 specifically refused because the Accept-Encoding field includes
5747 "identity;q=0", or because the field includes "*;q=0" and does
5748 not explicitly include the "identity" content-coding. If the
5749 Accept-Encoding field-value is empty, then only the "identity"
5750 encoding is acceptable.
5752 If an Accept-Encoding field is present in a request, and if the
5753 server cannot send a response which is acceptable according to the
5754 Accept-Encoding header, then the server SHOULD send an error response
5755 with the 406 (Not Acceptable) status code.
5757 If no Accept-Encoding field is present in a request, the server MAY
5758 assume that the client will accept any content coding. In this case,
5759 if "identity" is one of the available content-codings, then the
5760 server SHOULD use the "identity" content-coding, unless it has
5761 additional information that a different content-coding is meaningful
5764 Note: If the request does not include an Accept-Encoding field,
5765 and if the "identity" content-coding is unavailable, then
5766 content-codings commonly understood by HTTP/1.0 clients (i.e.,
5770Fielding, et al. Standards Track [Page 103]
5772RFC 2616 HTTP/1.1 June 1999
5775 "gzip" and "compress") are preferred; some older clients
5776 improperly display messages sent with other content-codings. The
5777 server might also make this decision based on information about
5778 the particular user-agent or client.
5780 Note: Most HTTP/1.0 applications do not recognize or obey qvalues
5781 associated with content-codings. This means that qvalues will not
5782 work and are not permitted with x-gzip or x-compress.
5786 The Accept-Language request-header field is similar to Accept, but
5787 restricts the set of natural languages that are preferred as a
5788 response to the request. Language tags are defined in section 3.10.
5790 Accept-Language = "Accept-Language" ":"
5791 1#( language-range [ ";" "q" "=" qvalue ] )
5792 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
5794 Each language-range MAY be given an associated quality value which
5795 represents an estimate of the user's preference for the languages
5796 specified by that range. The quality value defaults to "q=1". For
5799 Accept-Language: da, en-gb;q=0.8, en;q=0.7
5801 would mean: "I prefer Danish, but will accept British English and
5802 other types of English." A language-range matches a language-tag if
5803 it exactly equals the tag, or if it exactly equals a prefix of the
5804 tag such that the first tag character following the prefix is "-".
5805 The special range "*", if present in the Accept-Language field,
5806 matches every tag not matched by any other range present in the
5807 Accept-Language field.
5809 Note: This use of a prefix matching rule does not imply that
5810 language tags are assigned to languages in such a way that it is
5811 always true that if a user understands a language with a certain
5812 tag, then this user will also understand all languages with tags
5813 for which this tag is a prefix. The prefix rule simply allows the
5814 use of prefix tags if this is the case.
5816 The language quality factor assigned to a language-tag by the
5817 Accept-Language field is the quality value of the longest language-
5818 range in the field that matches the language-tag. If no language-
5819 range in the field matches the tag, the language quality factor
5820 assigned is 0. If no Accept-Language header is present in the
5826Fielding, et al. Standards Track [Page 104]
5828RFC 2616 HTTP/1.1 June 1999
5831 SHOULD assume that all languages are equally acceptable. If an
5832 Accept-Language header is present, then all languages which are
5833 assigned a quality factor greater than 0 are acceptable.
5835 It might be contrary to the privacy expectations of the user to send
5836 an Accept-Language header with the complete linguistic preferences of
5837 the user in every request. For a discussion of this issue, see
5840 As intelligibility is highly dependent on the individual user, it is
5841 recommended that client applications make the choice of linguistic
5842 preference available to the user. If the choice is not made
5843 available, then the Accept-Language header field MUST NOT be given in
5846 Note: When making the choice of linguistic preference available to
5847 the user, we remind implementors of the fact that users are not
5848 familiar with the details of language matching as described above,
5849 and should provide appropriate guidance. As an example, users
5850 might assume that on selecting "en-gb", they will be served any
5851 kind of English document if British English is not available. A
5852 user agent might suggest in such a case to add "en" to get the
5853 best matching behavior.
5857 The Accept-Ranges response-header field allows the server to
5858 indicate its acceptance of range requests for a resource:
5860 Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
5861 acceptable-ranges = 1#range-unit | "none"
5863 Origin servers that accept byte-range requests MAY send
5865 Accept-Ranges: bytes
5867 but are not required to do so. Clients MAY generate byte-range
5868 requests without having received this header for the resource
5869 involved. Range units are defined in section 3.12.
5871 Servers that do not accept any kind of range request for a
5876 to advise the client not to attempt a range request.
5882Fielding, et al. Standards Track [Page 105]
5884RFC 2616 HTTP/1.1 June 1999
5889 The Age response-header field conveys the sender's estimate of the
5890 amount of time since the response (or its revalidation) was
5891 generated at the origin server. A cached response is "fresh" if
5892 its age does not exceed its freshness lifetime. Age values are
5893 calculated as specified in section 13.2.3.
5895 Age = "Age" ":" age-value
5896 age-value = delta-seconds
5898 Age values are non-negative decimal integers, representing time in
5901 If a cache receives a value larger than the largest positive
5902 integer it can represent, or if any of its age calculations
5903 overflows, it MUST transmit an Age header with a value of
5904 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
5905 include an Age header field in every response generated from its
5906 own cache. Caches SHOULD use an arithmetic type of at least 31
5911 The Allow entity-header field lists the set of methods supported
5912 by the resource identified by the Request-URI. The purpose of this
5913 field is strictly to inform the recipient of valid methods
5914 associated with the resource. An Allow header field MUST be
5915 present in a 405 (Method Not Allowed) response.
5917 Allow = "Allow" ":" #Method
5921 Allow: GET, HEAD, PUT
5923 This field cannot prevent a client from trying other methods.
5924 However, the indications given by the Allow header field value
5925 SHOULD be followed. The actual set of allowed methods is defined
5926 by the origin server at the time of each request.
5928 The Allow header field MAY be provided with a PUT request to
5929 recommend the methods to be supported by the new or modified
5930 resource. The server is not required to support these methods and
5931 SHOULD include an Allow header in the response giving the actual
5938Fielding, et al. Standards Track [Page 106]
5940RFC 2616 HTTP/1.1 June 1999
5943 A proxy MUST NOT modify the Allow header field even if it does not
5944 understand all the methods specified, since the user agent might
5945 have other means of communicating with the origin server.
5949 A user agent that wishes to authenticate itself with a server--
5950 usually, but not necessarily, after receiving a 401 response--does
5951 so by including an Authorization request-header field with the
5952 request. The Authorization field value consists of credentials
5953 containing the authentication information of the user agent for
5954 the realm of the resource being requested.
5956 Authorization = "Authorization" ":" credentials
5958 HTTP access authentication is described in "HTTP Authentication:
5959 Basic and Digest Access Authentication" [43]. If a request is
5960 authenticated and a realm specified, the same credentials SHOULD
5961 be valid for all other requests within this realm (assuming that
5962 the authentication scheme itself does not require otherwise, such
5963 as credentials that vary according to a challenge value or using
5964 synchronized clocks).
5966 When a shared cache (see section 13.7) receives a request
5967 containing an Authorization field, it MUST NOT return the
5968 corresponding response as a reply to any other request, unless one
5969 of the following specific exceptions holds:
5971 1. If the response includes the "s-maxage" cache-control
5972 directive, the cache MAY use that response in replying to a
5973 subsequent request. But (if the specified maximum age has
5974 passed) a proxy cache MUST first revalidate it with the origin
5975 server, using the request-headers from the new request to allow
5976 the origin server to authenticate the new request. (This is the
5977 defined behavior for s-maxage.) If the response includes "s-
5978 maxage=0", the proxy MUST always revalidate it before re-using
5981 2. If the response includes the "must-revalidate" cache-control
5982 directive, the cache MAY use that response in replying to a
5983 subsequent request. But if the response is stale, all caches
5984 MUST first revalidate it with the origin server, using the
5985 request-headers from the new request to allow the origin server
5986 to authenticate the new request.
5988 3. If the response includes the "public" cache-control directive,
5989 it MAY be returned in reply to any subsequent request.
5994Fielding, et al. Standards Track [Page 107]
5996RFC 2616 HTTP/1.1 June 1999
6001 The Cache-Control general-header field is used to specify directives
6002 that MUST be obeyed by all caching mechanisms along the
6003 request/response chain. The directives specify behavior intended to
6004 prevent caches from adversely interfering with the request or
6005 response. These directives typically override the default caching
6006 algorithms. Cache directives are unidirectional in that the presence
6007 of a directive in a request does not imply that the same directive is
6008 to be given in the response.
6010 Note that HTTP/1.0 caches might not implement Cache-Control and
6011 might only implement Pragma: no-cache (see section 14.32).
6013 Cache directives MUST be passed through by a proxy or gateway
6014 application, regardless of their significance to that application,
6015 since the directives might be applicable to all recipients along the
6016 request/response chain. It is not possible to specify a cache-
6017 directive for a specific cache.
6019 Cache-Control = "Cache-Control" ":" 1#cache-directive
6021 cache-directive = cache-request-directive
6022 | cache-response-directive
6024 cache-request-directive =
6025 "no-cache" ; Section 14.9.1
6026 | "no-store" ; Section 14.9.2
6027 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
6028 | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
6029 | "min-fresh" "=" delta-seconds ; Section 14.9.3
6030 | "no-transform" ; Section 14.9.5
6031 | "only-if-cached" ; Section 14.9.4
6032 | cache-extension ; Section 14.9.6
6034 cache-response-directive =
6035 "public" ; Section 14.9.1
6036 | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
6037 | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
6038 | "no-store" ; Section 14.9.2
6039 | "no-transform" ; Section 14.9.5
6040 | "must-revalidate" ; Section 14.9.4
6041 | "proxy-revalidate" ; Section 14.9.4
6042 | "max-age" "=" delta-seconds ; Section 14.9.3
6043 | "s-maxage" "=" delta-seconds ; Section 14.9.3
6044 | cache-extension ; Section 14.9.6
6046 cache-extension = token [ "=" ( token | quoted-string ) ]
6050Fielding, et al. Standards Track [Page 108]
6052RFC 2616 HTTP/1.1 June 1999
6055 When a directive appears without any 1#field-name parameter, the
6056 directive applies to the entire request or response. When such a
6057 directive appears with a 1#field-name parameter, it applies only to
6058 the named field or fields, and not to the rest of the request or
6059 response. This mechanism supports extensibility; implementations of
6060 future versions of the HTTP protocol might apply these directives to
6061 header fields not defined in HTTP/1.1.
6063 The cache-control directives can be broken down into these general
6066 - Restrictions on what are cacheable; these may only be imposed by
6069 - Restrictions on what may be stored by a cache; these may be
6070 imposed by either the origin server or the user agent.
6072 - Modifications of the basic expiration mechanism; these may be
6073 imposed by either the origin server or the user agent.
6075 - Controls over cache revalidation and reload; these may only be
6076 imposed by a user agent.
6078 - Control over transformation of entities.
6080 - Extensions to the caching system.
608214.9.1 What is Cacheable
6084 By default, a response is cacheable if the requirements of the
6085 request method, request header fields, and the response status
6086 indicate that it is cacheable. Section 13.4 summarizes these defaults
6087 for cacheability. The following Cache-Control response directives
6088 allow an origin server to override the default cacheability of a
6092 Indicates that the response MAY be cached by any cache, even if it
6093 would normally be non-cacheable or cacheable only within a non-
6094 shared cache. (See also Authorization, section 14.8, for
6095 additional details.)
6098 Indicates that all or part of the response message is intended for
6099 a single user and MUST NOT be cached by a shared cache. This
6100 allows an origin server to state that the specified parts of the
6106Fielding, et al. Standards Track [Page 109]
6108RFC 2616 HTTP/1.1 June 1999
6111 response are intended for only one user and are not a valid
6112 response for requests by other users. A private (non-shared) cache
6113 MAY cache the response.
6115 Note: This usage of the word private only controls where the
6116 response may be cached, and cannot ensure the privacy of the
6120 If the no-cache directive does not specify a field-name, then a
6121 cache MUST NOT use the response to satisfy a subsequent request
6122 without successful revalidation with the origin server. This
6123 allows an origin server to prevent caching even by caches that
6124 have been configured to return stale responses to client requests.
6126 If the no-cache directive does specify one or more field-names,
6127 then a cache MAY use the response to satisfy a subsequent request,
6128 subject to any other restrictions on caching. However, the
6129 specified field-name(s) MUST NOT be sent in the response to a
6130 subsequent request without successful revalidation with the origin
6131 server. This allows an origin server to prevent the re-use of
6132 certain header fields in a response, while still allowing caching
6133 of the rest of the response.
6135 Note: Most HTTP/1.0 caches will not recognize or obey this
613814.9.2 What May be Stored by Caches
6141 The purpose of the no-store directive is to prevent the
6142 inadvertent release or retention of sensitive information (for
6143 example, on backup tapes). The no-store directive applies to the
6144 entire message, and MAY be sent either in a response or in a
6145 request. If sent in a request, a cache MUST NOT store any part of
6146 either this request or any response to it. If sent in a response,
6147 a cache MUST NOT store any part of either this response or the
6148 request that elicited it. This directive applies to both non-
6149 shared and shared caches. "MUST NOT store" in this context means
6150 that the cache MUST NOT intentionally store the information in
6151 non-volatile storage, and MUST make a best-effort attempt to
6152 remove the information from volatile storage as promptly as
6153 possible after forwarding it.
6155 Even when this directive is associated with a response, users
6156 might explicitly store such a response outside of the caching
6157 system (e.g., with a "Save As" dialog). History buffers MAY store
6158 such responses as part of their normal operation.
6162Fielding, et al. Standards Track [Page 110]
6164RFC 2616 HTTP/1.1 June 1999
6167 The purpose of this directive is to meet the stated requirements
6168 of certain users and service authors who are concerned about
6169 accidental releases of information via unanticipated accesses to
6170 cache data structures. While the use of this directive might
6171 improve privacy in some cases, we caution that it is NOT in any
6172 way a reliable or sufficient mechanism for ensuring privacy. In
6173 particular, malicious or compromised caches might not recognize or
6174 obey this directive, and communications networks might be
6175 vulnerable to eavesdropping.
617714.9.3 Modifications of the Basic Expiration Mechanism
6179 The expiration time of an entity MAY be specified by the origin
6180 server using the Expires header (see section 14.21). Alternatively,
6181 it MAY be specified using the max-age directive in a response. When
6182 the max-age cache-control directive is present in a cached response,
6183 the response is stale if its current age is greater than the age
6184 value given (in seconds) at the time of a new request for that
6185 resource. The max-age directive on a response implies that the
6186 response is cacheable (i.e., "public") unless some other, more
6187 restrictive cache directive is also present.
6189 If a response includes both an Expires header and a max-age
6190 directive, the max-age directive overrides the Expires header, even
6191 if the Expires header is more restrictive. This rule allows an origin
6192 server to provide, for a given response, a longer expiration time to
6193 an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
6194 useful if certain HTTP/1.0 caches improperly calculate ages or
6195 expiration times, perhaps due to desynchronized clocks.
6197 Many HTTP/1.0 cache implementations will treat an Expires value that
6198 is less than or equal to the response Date value as being equivalent
6199 to the Cache-Control response directive "no-cache". If an HTTP/1.1
6200 cache receives such a response, and the response does not include a
6201 Cache-Control header field, it SHOULD consider the response to be
6202 non-cacheable in order to retain compatibility with HTTP/1.0 servers.
6204 Note: An origin server might wish to use a relatively new HTTP
6205 cache control feature, such as the "private" directive, on a
6206 network including older caches that do not understand that
6207 feature. The origin server will need to combine the new feature
6208 with an Expires field whose value is less than or equal to the
6209 Date value. This will prevent older caches from improperly
6210 caching the response.
6218Fielding, et al. Standards Track [Page 111]
6220RFC 2616 HTTP/1.1 June 1999
6224 If a response includes an s-maxage directive, then for a shared
6225 cache (but not for a private cache), the maximum age specified by
6226 this directive overrides the maximum age specified by either the
6227 max-age directive or the Expires header. The s-maxage directive
6228 also implies the semantics of the proxy-revalidate directive (see
6229 section 14.9.4), i.e., that the shared cache must not use the
6230 entry after it becomes stale to respond to a subsequent request
6231 without first revalidating it with the origin server. The s-
6232 maxage directive is always ignored by a private cache.
6234 Note that most older caches, not compliant with this specification,
6235 do not implement any cache-control directives. An origin server
6236 wishing to use a cache-control directive that restricts, but does not
6237 prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
6238 requirement that the max-age directive overrides the Expires header,
6239 and the fact that pre-HTTP/1.1-compliant caches do not observe the
6242 Other directives allow a user agent to modify the basic expiration
6243 mechanism. These directives MAY be specified on a request:
6246 Indicates that the client is willing to accept a response whose
6247 age is no greater than the specified time in seconds. Unless max-
6248 stale directive is also included, the client is not willing to
6249 accept a stale response.
6252 Indicates that the client is willing to accept a response whose
6253 freshness lifetime is no less than its current age plus the
6254 specified time in seconds. That is, the client wants a response
6255 that will still be fresh for at least the specified number of
6259 Indicates that the client is willing to accept a response that has
6260 exceeded its expiration time. If max-stale is assigned a value,
6261 then the client is willing to accept a response that has exceeded
6262 its expiration time by no more than the specified number of
6263 seconds. If no value is assigned to max-stale, then the client is
6264 willing to accept a stale response of any age.
6266 If a cache returns a stale response, either because of a max-stale
6267 directive on a request, or because the cache is configured to
6268 override the expiration time of a response, the cache MUST attach a
6269 Warning header to the stale response, using Warning 110 (Response is
6274Fielding, et al. Standards Track [Page 112]
6276RFC 2616 HTTP/1.1 June 1999
6279 A cache MAY be configured to return stale responses without
6280 validation, but only if this does not conflict with any "MUST"-level
6281 requirements concerning cache validation (e.g., a "must-revalidate"
6282 cache-control directive).
6284 If both the new request and the cached entry include "max-age"
6285 directives, then the lesser of the two values is used for determining
6286 the freshness of the cached entry for that request.
628814.9.4 Cache Revalidation and Reload Controls
6290 Sometimes a user agent might want or need to insist that a cache
6291 revalidate its cache entry with the origin server (and not just with
6292 the next cache along the path to the origin server), or to reload its
6293 cache entry from the origin server. End-to-end revalidation might be
6294 necessary if either the cache or the origin server has overestimated
6295 the expiration time of the cached response. End-to-end reload may be
6296 necessary if the cache entry has become corrupted for some reason.
6298 End-to-end revalidation may be requested either when the client does
6299 not have its own local cached copy, in which case we call it
6300 "unspecified end-to-end revalidation", or when the client does have a
6301 local cached copy, in which case we call it "specific end-to-end
6304 The client can specify these three kinds of action using Cache-
6305 Control request directives:
6308 The request includes a "no-cache" cache-control directive or, for
6309 compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
6310 names MUST NOT be included with the no-cache directive in a
6311 request. The server MUST NOT use a cached copy when responding to
6314 Specific end-to-end revalidation
6315 The request includes a "max-age=0" cache-control directive, which
6316 forces each cache along the path to the origin server to
6317 revalidate its own entry, if any, with the next cache or server.
6318 The initial request includes a cache-validating conditional with
6319 the client's current validator.
6321 Unspecified end-to-end revalidation
6322 The request includes "max-age=0" cache-control directive, which
6323 forces each cache along the path to the origin server to
6324 revalidate its own entry, if any, with the next cache or server.
6325 The initial request does not include a cache-validating
6330Fielding, et al. Standards Track [Page 113]
6332RFC 2616 HTTP/1.1 June 1999
6335 conditional; the first cache along the path (if any) that holds a
6336 cache entry for this resource includes a cache-validating
6337 conditional with its current validator.
6340 When an intermediate cache is forced, by means of a max-age=0
6341 directive, to revalidate its own cache entry, and the client has
6342 supplied its own validator in the request, the supplied validator
6343 might differ from the validator currently stored with the cache
6344 entry. In this case, the cache MAY use either validator in making
6345 its own request without affecting semantic transparency.
6347 However, the choice of validator might affect performance. The
6348 best approach is for the intermediate cache to use its own
6349 validator when making its request. If the server replies with 304
6350 (Not Modified), then the cache can return its now validated copy
6351 to the client with a 200 (OK) response. If the server replies with
6352 a new entity and cache validator, however, the intermediate cache
6353 can compare the returned validator with the one provided in the
6354 client's request, using the strong comparison function. If the
6355 client's validator is equal to the origin server's, then the
6356 intermediate cache simply returns 304 (Not Modified). Otherwise,
6357 it returns the new entity with a 200 (OK) response.
6359 If a request includes the no-cache directive, it SHOULD NOT
6360 include min-fresh, max-stale, or max-age.
6363 In some cases, such as times of extremely poor network
6364 connectivity, a client may want a cache to return only those
6365 responses that it currently has stored, and not to reload or
6366 revalidate with the origin server. To do this, the client may
6367 include the only-if-cached directive in a request. If it receives
6368 this directive, a cache SHOULD either respond using a cached entry
6369 that is consistent with the other constraints of the request, or
6370 respond with a 504 (Gateway Timeout) status. However, if a group
6371 of caches is being operated as a unified system with good internal
6372 connectivity, such a request MAY be forwarded within that group of
6376 Because a cache MAY be configured to ignore a server's specified
6377 expiration time, and because a client request MAY include a max-
6378 stale directive (which has a similar effect), the protocol also
6379 includes a mechanism for the origin server to require revalidation
6380 of a cache entry on any subsequent use. When the must-revalidate
6381 directive is present in a response received by a cache, that cache
6382 MUST NOT use the entry after it becomes stale to respond to a
6386Fielding, et al. Standards Track [Page 114]
6388RFC 2616 HTTP/1.1 June 1999
6391 subsequent request without first revalidating it with the origin
6392 server. (I.e., the cache MUST do an end-to-end revalidation every
6393 time, if, based solely on the origin server's Expires or max-age
6394 value, the cached response is stale.)
6396 The must-revalidate directive is necessary to support reliable
6397 operation for certain protocol features. In all circumstances an
6398 HTTP/1.1 cache MUST obey the must-revalidate directive; in
6399 particular, if the cache cannot reach the origin server for any
6400 reason, it MUST generate a 504 (Gateway Timeout) response.
6402 Servers SHOULD send the must-revalidate directive if and only if
6403 failure to revalidate a request on the entity could result in
6404 incorrect operation, such as a silently unexecuted financial
6405 transaction. Recipients MUST NOT take any automated action that
6406 violates this directive, and MUST NOT automatically provide an
6407 unvalidated copy of the entity if revalidation fails.
6409 Although this is not recommended, user agents operating under
6410 severe connectivity constraints MAY violate this directive but, if
6411 so, MUST explicitly warn the user that an unvalidated response has
6412 been provided. The warning MUST be provided on each unvalidated
6413 access, and SHOULD require explicit user confirmation.
6416 The proxy-revalidate directive has the same meaning as the must-
6417 revalidate directive, except that it does not apply to non-shared
6418 user agent caches. It can be used on a response to an
6419 authenticated request to permit the user's cache to store and
6420 later return the response without needing to revalidate it (since
6421 it has already been authenticated once by that user), while still
6422 requiring proxies that service many users to revalidate each time
6423 (in order to make sure that each user has been authenticated).
6424 Note that such authenticated responses also need the public cache
6425 control directive in order to allow them to be cached at all.
642714.9.5 No-Transform Directive
6430 Implementors of intermediate caches (proxies) have found it useful
6431 to convert the media type of certain entity bodies. A non-
6432 transparent proxy might, for example, convert between image
6433 formats in order to save cache space or to reduce the amount of
6434 traffic on a slow link.
6436 Serious operational problems occur, however, when these
6437 transformations are applied to entity bodies intended for certain
6438 kinds of applications. For example, applications for medical
6442Fielding, et al. Standards Track [Page 115]
6444RFC 2616 HTTP/1.1 June 1999
6447 imaging, scientific data analysis and those using end-to-end
6448 authentication, all depend on receiving an entity body that is bit
6449 for bit identical to the original entity-body.
6451 Therefore, if a message includes the no-transform directive, an
6452 intermediate cache or proxy MUST NOT change those headers that are
6453 listed in section 13.5.2 as being subject to the no-transform
6454 directive. This implies that the cache or proxy MUST NOT change
6455 any aspect of the entity-body that is specified by these headers,
6456 including the value of the entity-body itself.
645814.9.6 Cache Control Extensions
6460 The Cache-Control header field can be extended through the use of one
6461 or more cache-extension tokens, each with an optional assigned value.
6462 Informational extensions (those which do not require a change in
6463 cache behavior) MAY be added without changing the semantics of other
6464 directives. Behavioral extensions are designed to work by acting as
6465 modifiers to the existing base of cache directives. Both the new
6466 directive and the standard directive are supplied, such that
6467 applications which do not understand the new directive will default
6468 to the behavior specified by the standard directive, and those that
6469 understand the new directive will recognize it as modifying the
6470 requirements associated with the standard directive. In this way,
6471 extensions to the cache-control directives can be made without
6472 requiring changes to the base protocol.
6474 This extension mechanism depends on an HTTP cache obeying all of the
6475 cache-control directives defined for its native HTTP-version, obeying
6476 certain extensions, and ignoring all directives that it does not
6479 For example, consider a hypothetical new response directive called
6480 community which acts as a modifier to the private directive. We
6481 define this new directive to mean that, in addition to any non-shared
6482 cache, any cache which is shared only by members of the community
6483 named within its value may cache the response. An origin server
6484 wishing to allow the UCI community to use an otherwise private
6485 response in their shared cache(s) could do so by including
6487 Cache-Control: private, community="UCI"
6489 A cache seeing this header field will act correctly even if the cache
6490 does not understand the community cache-extension, since it will also
6491 see and understand the private directive and thus default to the safe
6498Fielding, et al. Standards Track [Page 116]
6500RFC 2616 HTTP/1.1 June 1999
6503 Unrecognized cache-directives MUST be ignored; it is assumed that any
6504 cache-directive likely to be unrecognized by an HTTP/1.1 cache will
6505 be combined with standard directives (or the response's default
6506 cacheability) such that the cache behavior will remain minimally
6507 correct even if the cache does not understand the extension(s).
6511 The Connection general-header field allows the sender to specify
6512 options that are desired for that particular connection and MUST NOT
6513 be communicated by proxies over further connections.
6515 The Connection header has the following grammar:
6517 Connection = "Connection" ":" 1#(connection-token)
6518 connection-token = token
6520 HTTP/1.1 proxies MUST parse the Connection header field before a
6521 message is forwarded and, for each connection-token in this field,
6522 remove any header field(s) from the message with the same name as the
6523 connection-token. Connection options are signaled by the presence of
6524 a connection-token in the Connection header field, not by any
6525 corresponding additional header field(s), since the additional header
6526 field may not be sent if there are no parameters associated with that
6529 Message headers listed in the Connection header MUST NOT include
6530 end-to-end headers, such as Cache-Control.
6532 HTTP/1.1 defines the "close" connection option for the sender to
6533 signal that the connection will be closed after completion of the
6534 response. For example,
6538 in either the request or the response header fields indicates that
6539 the connection SHOULD NOT be considered `persistent' (section 8.1)
6540 after the current request/response is complete.
6542 HTTP/1.1 applications that do not support persistent connections MUST
6543 include the "close" connection option in every message.
6545 A system receiving an HTTP/1.0 (or lower-version) message that
6546 includes a Connection header MUST, for each connection-token in this
6547 field, remove and ignore any header field(s) from the message with
6548 the same name as the connection-token. This protects against mistaken
6549 forwarding of such header fields by pre-HTTP/1.1 proxies. See section
6554Fielding, et al. Standards Track [Page 117]
6556RFC 2616 HTTP/1.1 June 1999
655914.11 Content-Encoding
6561 The Content-Encoding entity-header field is used as a modifier to the
6562 media-type. When present, its value indicates what additional content
6563 codings have been applied to the entity-body, and thus what decoding
6564 mechanisms must be applied in order to obtain the media-type
6565 referenced by the Content-Type header field. Content-Encoding is
6566 primarily used to allow a document to be compressed without losing
6567 the identity of its underlying media type.
6569 Content-Encoding = "Content-Encoding" ":" 1#content-coding
6571 Content codings are defined in section 3.5. An example of its use is
6573 Content-Encoding: gzip
6575 The content-coding is a characteristic of the entity identified by
6576 the Request-URI. Typically, the entity-body is stored with this
6577 encoding and is only decoded before rendering or analogous usage.
6578 However, a non-transparent proxy MAY modify the content-coding if the
6579 new coding is known to be acceptable to the recipient, unless the
6580 "no-transform" cache-control directive is present in the message.
6582 If the content-coding of an entity is not "identity", then the
6583 response MUST include a Content-Encoding entity-header (section
6584 14.11) that lists the non-identity content-coding(s) used.
6586 If the content-coding of an entity in a request message is not
6587 acceptable to the origin server, the server SHOULD respond with a
6588 status code of 415 (Unsupported Media Type).
6590 If multiple encodings have been applied to an entity, the content
6591 codings MUST be listed in the order in which they were applied.
6592 Additional information about the encoding parameters MAY be provided
6593 by other entity-header fields not defined by this specification.
659514.12 Content-Language
6597 The Content-Language entity-header field describes the natural
6598 language(s) of the intended audience for the enclosed entity. Note
6599 that this might not be equivalent to all the languages used within
6602 Content-Language = "Content-Language" ":" 1#language-tag
6610Fielding, et al. Standards Track [Page 118]
6612RFC 2616 HTTP/1.1 June 1999
6615 Language tags are defined in section 3.10. The primary purpose of
6616 Content-Language is to allow a user to identify and differentiate
6617 entities according to the user's own preferred language. Thus, if the
6618 body content is intended only for a Danish-literate audience, the
6619 appropriate field is
6621 Content-Language: da
6623 If no Content-Language is specified, the default is that the content
6624 is intended for all language audiences. This might mean that the
6625 sender does not consider it to be specific to any natural language,
6626 or that the sender does not know for which language it is intended.
6628 Multiple languages MAY be listed for content that is intended for
6629 multiple audiences. For example, a rendition of the "Treaty of
6630 Waitangi," presented simultaneously in the original Maori and English
6631 versions, would call for
6633 Content-Language: mi, en
6635 However, just because multiple languages are present within an entity
6636 does not mean that it is intended for multiple linguistic audiences.
6637 An example would be a beginner's language primer, such as "A First
6638 Lesson in Latin," which is clearly intended to be used by an
6639 English-literate audience. In this case, the Content-Language would
6640 properly only include "en".
6642 Content-Language MAY be applied to any media type -- it is not
6643 limited to textual documents.
6647 The Content-Length entity-header field indicates the size of the
6648 entity-body, in decimal number of OCTETs, sent to the recipient or,
6649 in the case of the HEAD method, the size of the entity-body that
6650 would have been sent had the request been a GET.
6652 Content-Length = "Content-Length" ":" 1*DIGIT
6656 Content-Length: 3495
6658 Applications SHOULD use this field to indicate the transfer-length of
6659 the message-body, unless this is prohibited by the rules in section
6666Fielding, et al. Standards Track [Page 119]
6668RFC 2616 HTTP/1.1 June 1999
6671 Any Content-Length greater than or equal to zero is a valid value.
6672 Section 4.4 describes how to determine the length of a message-body
6673 if a Content-Length is not given.
6675 Note that the meaning of this field is significantly different from
6676 the corresponding definition in MIME, where it is an optional field
6677 used within the "message/external-body" content-type. In HTTP, it
6678 SHOULD be sent whenever the message's length can be determined prior
6679 to being transferred, unless this is prohibited by the rules in
668214.14 Content-Location
6684 The Content-Location entity-header field MAY be used to supply the
6685 resource location for the entity enclosed in the message when that
6686 entity is accessible from a location separate from the requested
6687 resource's URI. A server SHOULD provide a Content-Location for the
6688 variant corresponding to the response entity; especially in the case
6689 where a resource has multiple entities associated with it, and those
6690 entities actually have separate locations by which they might be
6691 individually accessed, the server SHOULD provide a Content-Location
6692 for the particular variant which is returned.
6694 Content-Location = "Content-Location" ":"
6695 ( absoluteURI | relativeURI )
6697 The value of Content-Location also defines the base URI for the
6700 The Content-Location value is not a replacement for the original
6701 requested URI; it is only a statement of the location of the resource
6702 corresponding to this particular entity at the time of the request.
6703 Future requests MAY specify the Content-Location URI as the request-
6704 URI if the desire is to identify the source of that particular
6707 A cache cannot assume that an entity with a Content-Location
6708 different from the URI used to retrieve it can be used to respond to
6709 later requests on that Content-Location URI. However, the Content-
6710 Location can be used to differentiate between multiple entities
6711 retrieved from a single requested resource, as described in section
6714 If the Content-Location is a relative URI, the relative URI is
6715 interpreted relative to the Request-URI.
6717 The meaning of the Content-Location header in PUT or POST requests is
6718 undefined; servers are free to ignore it in those cases.
6722Fielding, et al. Standards Track [Page 120]
6724RFC 2616 HTTP/1.1 June 1999
6729 The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
6730 an MD5 digest of the entity-body for the purpose of providing an
6731 end-to-end message integrity check (MIC) of the entity-body. (Note: a
6732 MIC is good for detecting accidental modification of the entity-body
6733 in transit, but is not proof against malicious attacks.)
6735 Content-MD5 = "Content-MD5" ":" md5-digest
6736 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
6738 The Content-MD5 header field MAY be generated by an origin server or
6739 client to function as an integrity check of the entity-body. Only
6740 origin servers or clients MAY generate the Content-MD5 header field;
6741 proxies and gateways MUST NOT generate it, as this would defeat its
6742 value as an end-to-end integrity check. Any recipient of the entity-
6743 body, including gateways and proxies, MAY check that the digest value
6744 in this header field matches that of the entity-body as received.
6746 The MD5 digest is computed based on the content of the entity-body,
6747 including any content-coding that has been applied, but not including
6748 any transfer-encoding applied to the message-body. If the message is
6749 received with a transfer-encoding, that encoding MUST be removed
6750 prior to checking the Content-MD5 value against the received entity.
6752 This has the result that the digest is computed on the octets of the
6753 entity-body exactly as, and in the order that, they would be sent if
6754 no transfer-encoding were being applied.
6756 HTTP extends RFC 1864 to permit the digest to be computed for MIME
6757 composite media-types (e.g., multipart/* and message/rfc822), but
6758 this does not change how the digest is computed as defined in the
6759 preceding paragraph.
6761 There are several consequences of this. The entity-body for composite
6762 types MAY contain many body-parts, each with its own MIME and HTTP
6763 headers (including Content-MD5, Content-Transfer-Encoding, and
6764 Content-Encoding headers). If a body-part has a Content-Transfer-
6765 Encoding or Content-Encoding header, it is assumed that the content
6766 of the body-part has had the encoding applied, and the body-part is
6767 included in the Content-MD5 digest as is -- i.e., after the
6768 application. The Transfer-Encoding header field is not allowed within
6771 Conversion of all line breaks to CRLF MUST NOT be done before
6772 computing or checking the digest: the line break convention used in
6773 the text actually transmitted MUST be left unaltered when computing
6778Fielding, et al. Standards Track [Page 121]
6780RFC 2616 HTTP/1.1 June 1999
6783 Note: while the definition of Content-MD5 is exactly the same for
6784 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
6785 in which the application of Content-MD5 to HTTP entity-bodies
6786 differs from its application to MIME entity-bodies. One is that
6787 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
6788 does use Transfer-Encoding and Content-Encoding. Another is that
6789 HTTP more frequently uses binary content types than MIME, so it is
6790 worth noting that, in such cases, the byte order used to compute
6791 the digest is the transmission byte order defined for the type.
6792 Lastly, HTTP allows transmission of text types with any of several
6793 line break conventions and not just the canonical form using CRLF.
6797 The Content-Range entity-header is sent with a partial entity-body to
6798 specify where in the full entity-body the partial body should be
6799 applied. Range units are defined in section 3.12.
6801 Content-Range = "Content-Range" ":" content-range-spec
6803 content-range-spec = byte-content-range-spec
6804 byte-content-range-spec = bytes-unit SP
6805 byte-range-resp-spec "/"
6806 ( instance-length | "*" )
6808 byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
6810 instance-length = 1*DIGIT
6812 The header SHOULD indicate the total length of the full entity-body,
6813 unless this length is unknown or difficult to determine. The asterisk
6814 "*" character means that the instance-length is unknown at the time
6815 when the response was generated.
6817 Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
6818 range-resp-spec MUST only specify one range, and MUST contain
6819 absolute byte positions for both the first and last byte of the
6822 A byte-content-range-spec with a byte-range-resp-spec whose last-
6823 byte-pos value is less than its first-byte-pos value, or whose
6824 instance-length value is less than or equal to its last-byte-pos
6825 value, is invalid. The recipient of an invalid byte-content-range-
6826 spec MUST ignore it and any content transferred along with it.
6828 A server sending a response with status code 416 (Requested range not
6829 satisfiable) SHOULD include a Content-Range field with a byte-range-
6830 resp-spec of "*". The instance-length specifies the current length of
6834Fielding, et al. Standards Track [Page 122]
6836RFC 2616 HTTP/1.1 June 1999
6839 the selected resource. A response with status code 206 (Partial
6840 Content) MUST NOT include a Content-Range field with a byte-range-
6843 Examples of byte-content-range-spec values, assuming that the entity
6844 contains a total of 1234 bytes:
6846 . The first 500 bytes:
6849 . The second 500 bytes:
6852 . All except for the first 500 bytes:
6855 . The last 500 bytes:
6858 When an HTTP message includes the content of a single range (for
6859 example, a response to a request for a single range, or to a request
6860 for a set of ranges that overlap without any holes), this content is
6861 transmitted with a Content-Range header, and a Content-Length header
6862 showing the number of bytes actually transferred. For example,
6864 HTTP/1.1 206 Partial content
6865 Date: Wed, 15 Nov 1995 06:25:24 GMT
6866 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
6867 Content-Range: bytes 21010-47021/47022
6868 Content-Length: 26012
6869 Content-Type: image/gif
6871 When an HTTP message includes the content of multiple ranges (for
6872 example, a response to a request for multiple non-overlapping
6873 ranges), these are transmitted as a multipart message. The multipart
6874 media type used for this purpose is "multipart/byteranges" as defined
6875 in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
6877 A response to a request for a single range MUST NOT be sent using the
6878 multipart/byteranges media type. A response to a request for
6879 multiple ranges, whose result is a single range, MAY be sent as a
6880 multipart/byteranges media type with one part. A client that cannot
6881 decode a multipart/byteranges message MUST NOT ask for multiple
6882 byte-ranges in a single request.
6884 When a client requests multiple byte-ranges in one request, the
6885 server SHOULD return them in the order that they appeared in the
6890Fielding, et al. Standards Track [Page 123]
6892RFC 2616 HTTP/1.1 June 1999
6895 If the server ignores a byte-range-spec because it is syntactically
6896 invalid, the server SHOULD treat the request as if the invalid Range
6897 header field did not exist. (Normally, this means return a 200
6898 response containing the full entity).
6900 If the server receives a request (other than one including an If-
6901 Range request-header field) with an unsatisfiable Range request-
6902 header field (that is, all of whose byte-range-spec values have a
6903 first-byte-pos value greater than the current length of the selected
6904 resource), it SHOULD return a response code of 416 (Requested range
6905 not satisfiable) (section 10.4.17).
6907 Note: clients cannot depend on servers to send a 416 (Requested
6908 range not satisfiable) response instead of a 200 (OK) response for
6909 an unsatisfiable Range request-header, since not all servers
6910 implement this request-header.
6914 The Content-Type entity-header field indicates the media type of the
6915 entity-body sent to the recipient or, in the case of the HEAD method,
6916 the media type that would have been sent had the request been a GET.
6918 Content-Type = "Content-Type" ":" media-type
6920 Media types are defined in section 3.7. An example of the field is
6922 Content-Type: text/html; charset=ISO-8859-4
6924 Further discussion of methods for identifying the media type of an
6925 entity is provided in section 7.2.1.
6929 The Date general-header field represents the date and time at which
6930 the message was originated, having the same semantics as orig-date in
6931 RFC 822. The field value is an HTTP-date, as described in section
6932 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
6934 Date = "Date" ":" HTTP-date
6938 Date: Tue, 15 Nov 1994 08:12:31 GMT
6940 Origin servers MUST include a Date header field in all responses,
6941 except in these cases:
6946Fielding, et al. Standards Track [Page 124]
6948RFC 2616 HTTP/1.1 June 1999
6951 1. If the response status code is 100 (Continue) or 101 (Switching
6952 Protocols), the response MAY include a Date header field, at
6953 the server's option.
6955 2. If the response status code conveys a server error, e.g. 500
6956 (Internal Server Error) or 503 (Service Unavailable), and it is
6957 inconvenient or impossible to generate a valid Date.
6959 3. If the server does not have a clock that can provide a
6960 reasonable approximation of the current time, its responses
6961 MUST NOT include a Date header field. In this case, the rules
6962 in section 14.18.1 MUST be followed.
6964 A received message that does not have a Date header field MUST be
6965 assigned one by the recipient if the message will be cached by that
6966 recipient or gatewayed via a protocol which requires a Date. An HTTP
6967 implementation without a clock MUST NOT cache responses without
6968 revalidating them on every use. An HTTP cache, especially a shared
6969 cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
6970 clock with a reliable external standard.
6972 Clients SHOULD only send a Date header field in messages that include
6973 an entity-body, as in the case of the PUT and POST requests, and even
6974 then it is optional. A client without a clock MUST NOT send a Date
6975 header field in a request.
6977 The HTTP-date sent in a Date header SHOULD NOT represent a date and
6978 time subsequent to the generation of the message. It SHOULD represent
6979 the best available approximation of the date and time of message
6980 generation, unless the implementation has no means of generating a
6981 reasonably accurate date and time. In theory, the date ought to
6982 represent the moment just before the entity is generated. In
6983 practice, the date can be generated at any time during the message
6984 origination without affecting its semantic value.
698614.18.1 Clockless Origin Server Operation
6988 Some origin server implementations might not have a clock available.
6989 An origin server without a clock MUST NOT assign Expires or Last-
6990 Modified values to a response, unless these values were associated
6991 with the resource by a system or user with a reliable clock. It MAY
6992 assign an Expires value that is known, at or before server
6993 configuration time, to be in the past (this allows "pre-expiration"
6994 of responses without storing separate Expires values for each
7002Fielding, et al. Standards Track [Page 125]
7004RFC 2616 HTTP/1.1 June 1999
7009 The ETag response-header field provides the current value of the
7010 entity tag for the requested variant. The headers used with entity
7011 tags are described in sections 14.24, 14.26 and 14.44. The entity tag
7012 MAY be used for comparison with other entities from the same resource
7013 (see section 13.3.3).
7015 ETag = "ETag" ":" entity-tag
7025 The Expect request-header field is used to indicate that particular
7026 server behaviors are required by the client.
7028 Expect = "Expect" ":" 1#expectation
7030 expectation = "100-continue" | expectation-extension
7031 expectation-extension = token [ "=" ( token | quoted-string )
7033 expect-params = ";" token [ "=" ( token | quoted-string ) ]
7036 A server that does not understand or is unable to comply with any of
7037 the expectation values in the Expect field of a request MUST respond
7038 with appropriate error status. The server MUST respond with a 417
7039 (Expectation Failed) status if any of the expectations cannot be met
7040 or, if there are other problems with the request, some other 4xx
7043 This header field is defined with extensible syntax to allow for
7044 future extensions. If a server receives a request containing an
7045 Expect field that includes an expectation-extension that it does not
7046 support, it MUST respond with a 417 (Expectation Failed) status.
7048 Comparison of expectation values is case-insensitive for unquoted
7049 tokens (including the 100-continue token), and is case-sensitive for
7050 quoted-string expectation-extensions.
7058Fielding, et al. Standards Track [Page 126]
7060RFC 2616 HTTP/1.1 June 1999
7063 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
7064 return a 417 (Expectation Failed) status if it receives a request
7065 with an expectation that it cannot meet. However, the Expect
7066 request-header itself is end-to-end; it MUST be forwarded if the
7067 request is forwarded.
7069 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
7072 See section 8.2.3 for the use of the 100 (continue) status.
7076 The Expires entity-header field gives the date/time after which the
7077 response is considered stale. A stale cache entry may not normally be
7078 returned by a cache (either a proxy cache or a user agent cache)
7079 unless it is first validated with the origin server (or with an
7080 intermediate cache that has a fresh copy of the entity). See section
7081 13.2 for further discussion of the expiration model.
7083 The presence of an Expires field does not imply that the original
7084 resource will change or cease to exist at, before, or after that
7087 The format is an absolute date and time as defined by HTTP-date in
7088 section 3.3.1; it MUST be in RFC 1123 date format:
7090 Expires = "Expires" ":" HTTP-date
7092 An example of its use is
7094 Expires: Thu, 01 Dec 1994 16:00:00 GMT
7096 Note: if a response includes a Cache-Control field with the max-
7097 age directive (see section 14.9.3), that directive overrides the
7100 HTTP/1.1 clients and caches MUST treat other invalid date formats,
7101 especially including the value "0", as in the past (i.e., "already
7104 To mark a response as "already expired," an origin server sends an
7105 Expires date that is equal to the Date header value. (See the rules
7106 for expiration calculations in section 13.2.4.)
7114Fielding, et al. Standards Track [Page 127]
7116RFC 2616 HTTP/1.1 June 1999
7119 To mark a response as "never expires," an origin server sends an
7120 Expires date approximately one year from the time the response is
7121 sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
7124 The presence of an Expires header field with a date value of some
7125 time in the future on a response that otherwise would by default be
7126 non-cacheable indicates that the response is cacheable, unless
7127 indicated otherwise by a Cache-Control header field (section 14.9).
7131 The From request-header field, if given, SHOULD contain an Internet
7132 e-mail address for the human user who controls the requesting user
7133 agent. The address SHOULD be machine-usable, as defined by "mailbox"
7134 in RFC 822 [9] as updated by RFC 1123 [8]:
7136 From = "From" ":" mailbox
7140 From: webmaster@w3.org
7142 This header field MAY be used for logging purposes and as a means for
7143 identifying the source of invalid or unwanted requests. It SHOULD NOT
7144 be used as an insecure form of access protection. The interpretation
7145 of this field is that the request is being performed on behalf of the
7146 person given, who accepts responsibility for the method performed. In
7147 particular, robot agents SHOULD include this header so that the
7148 person responsible for running the robot can be contacted if problems
7149 occur on the receiving end.
7151 The Internet e-mail address in this field MAY be separate from the
7152 Internet host which issued the request. For example, when a request
7153 is passed through a proxy the original issuer's address SHOULD be
7156 The client SHOULD NOT send the From header field without the user's
7157 approval, as it might conflict with the user's privacy interests or
7158 their site's security policy. It is strongly recommended that the
7159 user be able to disable, enable, and modify the value of this field
7160 at any time prior to a request.
7164 The Host request-header field specifies the Internet host and port
7165 number of the resource being requested, as obtained from the original
7166 URI given by the user or referring resource (generally an HTTP URL,
7170Fielding, et al. Standards Track [Page 128]
7172RFC 2616 HTTP/1.1 June 1999
7175 as described in section 3.2.2). The Host field value MUST represent
7176 the naming authority of the origin server or gateway given by the
7177 original URL. This allows the origin server or gateway to
7178 differentiate between internally-ambiguous URLs, such as the root "/"
7179 URL of a server for multiple host names on a single IP address.
7181 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
7183 A "host" without any trailing port information implies the default
7184 port for the service requested (e.g., "80" for an HTTP URL). For
7185 example, a request on the origin server for
7186 <http://www.w3.org/pub/WWW/> would properly include:
7188 GET /pub/WWW/ HTTP/1.1
7191 A client MUST include a Host header field in all HTTP/1.1 request
7192 messages . If the requested URI does not include an Internet host
7193 name for the service being requested, then the Host header field MUST
7194 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
7195 request message it forwards does contain an appropriate Host header
7196 field that identifies the service being requested by the proxy. All
7197 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
7198 status code to any HTTP/1.1 request message which lacks a Host header
7201 See sections 5.2 and 19.6.1.1 for other requirements relating to
7206 The If-Match request-header field is used with a method to make it
7207 conditional. A client that has one or more entities previously
7208 obtained from the resource can verify that one of those entities is
7209 current by including a list of their associated entity tags in the
7210 If-Match header field. Entity tags are defined in section 3.11. The
7211 purpose of this feature is to allow efficient updates of cached
7212 information with a minimum amount of transaction overhead. It is also
7213 used, on updating requests, to prevent inadvertent modification of
7214 the wrong version of a resource. As a special case, the value "*"
7215 matches any current entity of the resource.
7217 If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
7219 If any of the entity tags match the entity tag of the entity that
7220 would have been returned in the response to a similar GET request
7221 (without the If-Match header) on that resource, or if "*" is given
7226Fielding, et al. Standards Track [Page 129]
7228RFC 2616 HTTP/1.1 June 1999
7231 and any current entity exists for that resource, then the server MAY
7232 perform the requested method as if the If-Match header field did not
7235 A server MUST use the strong comparison function (see section 13.3.3)
7236 to compare the entity tags in If-Match.
7238 If none of the entity tags match, or if "*" is given and no current
7239 entity exists, the server MUST NOT perform the requested method, and
7240 MUST return a 412 (Precondition Failed) response. This behavior is
7241 most useful when the client wants to prevent an updating method, such
7242 as PUT, from modifying a resource that has changed since the client
7245 If the request would, without the If-Match header field, result in
7246 anything other than a 2xx or 412 status, then the If-Match header
7249 The meaning of "If-Match: *" is that the method SHOULD be performed
7250 if the representation selected by the origin server (or by a cache,
7251 possibly using the Vary mechanism, see section 14.44) exists, and
7252 MUST NOT be performed if the representation does not exist.
7254 A request intended to update a resource (e.g., a PUT) MAY include an
7255 If-Match header field to signal that the request method MUST NOT be
7256 applied if the entity corresponding to the If-Match value (a single
7257 entity tag) is no longer a representation of that resource. This
7258 allows the user to indicate that they do not wish the request to be
7259 successful if the resource has been changed without their knowledge.
7263 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
7266 The result of a request having both an If-Match header field and
7267 either an If-None-Match or an If-Modified-Since header fields is
7268 undefined by this specification.
727014.25 If-Modified-Since
7272 The If-Modified-Since request-header field is used with a method to
7273 make it conditional: if the requested variant has not been modified
7274 since the time specified in this field, an entity will not be
7275 returned from the server; instead, a 304 (not modified) response will
7276 be returned without any message-body.
7278 If-Modified-Since = "If-Modified-Since" ":" HTTP-date
7282Fielding, et al. Standards Track [Page 130]
7284RFC 2616 HTTP/1.1 June 1999
7287 An example of the field is:
7289 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
7291 A GET method with an If-Modified-Since header and no Range header
7292 requests that the identified entity be transferred only if it has
7293 been modified since the date given by the If-Modified-Since header.
7294 The algorithm for determining this includes the following cases:
7296 a) If the request would normally result in anything other than a
7297 200 (OK) status, or if the passed If-Modified-Since date is
7298 invalid, the response is exactly the same as for a normal GET.
7299 A date which is later than the server's current time is
7302 b) If the variant has been modified since the If-Modified-Since
7303 date, the response is exactly the same as for a normal GET.
7305 c) If the variant has not been modified since a valid If-
7306 Modified-Since date, the server SHOULD return a 304 (Not
7309 The purpose of this feature is to allow efficient updates of cached
7310 information with a minimum amount of transaction overhead.
7312 Note: The Range request-header field modifies the meaning of If-
7313 Modified-Since; see section 14.35 for full details.
7315 Note: If-Modified-Since times are interpreted by the server, whose
7316 clock might not be synchronized with the client.
7318 Note: When handling an If-Modified-Since header field, some
7319 servers will use an exact date comparison function, rather than a
7320 less-than function, for deciding whether to send a 304 (Not
7321 Modified) response. To get best results when sending an If-
7322 Modified-Since header field for cache validation, clients are
7323 advised to use the exact date string received in a previous Last-
7324 Modified header field whenever possible.
7326 Note: If a client uses an arbitrary date in the If-Modified-Since
7327 header instead of a date taken from the Last-Modified header for
7328 the same request, the client should be aware of the fact that this
7329 date is interpreted in the server's understanding of time. The
7330 client should consider unsynchronized clocks and rounding problems
7331 due to the different encodings of time between the client and
7332 server. This includes the possibility of race conditions if the
7333 document has changed between the time it was first requested and
7334 the If-Modified-Since date of a subsequent request, and the
7338Fielding, et al. Standards Track [Page 131]
7340RFC 2616 HTTP/1.1 June 1999
7343 possibility of clock-skew-related problems if the If-Modified-
7344 Since date is derived from the client's clock without correction
7345 to the server's clock. Corrections for different time bases
7346 between client and server are at best approximate due to network
7349 The result of a request having both an If-Modified-Since header field
7350 and either an If-Match or an If-Unmodified-Since header fields is
7351 undefined by this specification.
7355 The If-None-Match request-header field is used with a method to make
7356 it conditional. A client that has one or more entities previously
7357 obtained from the resource can verify that none of those entities is
7358 current by including a list of their associated entity tags in the
7359 If-None-Match header field. The purpose of this feature is to allow
7360 efficient updates of cached information with a minimum amount of
7361 transaction overhead. It is also used to prevent a method (e.g. PUT)
7362 from inadvertently modifying an existing resource when the client
7363 believes that the resource does not exist.
7365 As a special case, the value "*" matches any current entity of the
7368 If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
7370 If any of the entity tags match the entity tag of the entity that
7371 would have been returned in the response to a similar GET request
7372 (without the If-None-Match header) on that resource, or if "*" is
7373 given and any current entity exists for that resource, then the
7374 server MUST NOT perform the requested method, unless required to do
7375 so because the resource's modification date fails to match that
7376 supplied in an If-Modified-Since header field in the request.
7377 Instead, if the request method was GET or HEAD, the server SHOULD
7378 respond with a 304 (Not Modified) response, including the cache-
7379 related header fields (particularly ETag) of one of the entities that
7380 matched. For all other request methods, the server MUST respond with
7381 a status of 412 (Precondition Failed).
7383 See section 13.3.3 for rules on how to determine if two entities tags
7384 match. The weak comparison function can only be used with GET or HEAD
7394Fielding, et al. Standards Track [Page 132]
7396RFC 2616 HTTP/1.1 June 1999
7399 If none of the entity tags match, then the server MAY perform the
7400 requested method as if the If-None-Match header field did not exist,
7401 but MUST also ignore any If-Modified-Since header field(s) in the
7402 request. That is, if no entity tags match, then the server MUST NOT
7403 return a 304 (Not Modified) response.
7405 If the request would, without the If-None-Match header field, result
7406 in anything other than a 2xx or 304 status, then the If-None-Match
7407 header MUST be ignored. (See section 13.3.4 for a discussion of
7408 server behavior when both If-Modified-Since and If-None-Match appear
7409 in the same request.)
7411 The meaning of "If-None-Match: *" is that the method MUST NOT be
7412 performed if the representation selected by the origin server (or by
7413 a cache, possibly using the Vary mechanism, see section 14.44)
7414 exists, and SHOULD be performed if the representation does not exist.
7415 This feature is intended to be useful in preventing races between PUT
7420 If-None-Match: "xyzzy"
7421 If-None-Match: W/"xyzzy"
7422 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
7423 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
7426 The result of a request having both an If-None-Match header field and
7427 either an If-Match or an If-Unmodified-Since header fields is
7428 undefined by this specification.
7432 If a client has a partial copy of an entity in its cache, and wishes
7433 to have an up-to-date copy of the entire entity in its cache, it
7434 could use the Range request-header with a conditional GET (using
7435 either or both of If-Unmodified-Since and If-Match.) However, if the
7436 condition fails because the entity has been modified, the client
7437 would then have to make a second request to obtain the entire current
7440 The If-Range header allows a client to "short-circuit" the second
7441 request. Informally, its meaning is `if the entity is unchanged, send
7442 me the part(s) that I am missing; otherwise, send me the entire new
7445 If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
7450Fielding, et al. Standards Track [Page 133]
7452RFC 2616 HTTP/1.1 June 1999
7455 If the client has no entity tag for an entity, but does have a Last-
7456 Modified date, it MAY use that date in an If-Range header. (The
7457 server can distinguish between a valid HTTP-date and any form of
7458 entity-tag by examining no more than two characters.) The If-Range
7459 header SHOULD only be used together with a Range header, and MUST be
7460 ignored if the request does not include a Range header, or if the
7461 server does not support the sub-range operation.
7463 If the entity tag given in the If-Range header matches the current
7464 entity tag for the entity, then the server SHOULD provide the
7465 specified sub-range of the entity using a 206 (Partial content)
7466 response. If the entity tag does not match, then the server SHOULD
7467 return the entire entity using a 200 (OK) response.
746914.28 If-Unmodified-Since
7471 The If-Unmodified-Since request-header field is used with a method to
7472 make it conditional. If the requested resource has not been modified
7473 since the time specified in this field, the server SHOULD perform the
7474 requested operation as if the If-Unmodified-Since header were not
7477 If the requested variant has been modified since the specified time,
7478 the server MUST NOT perform the requested operation, and MUST return
7479 a 412 (Precondition Failed).
7481 If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
7483 An example of the field is:
7485 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
7487 If the request normally (i.e., without the If-Unmodified-Since
7488 header) would result in anything other than a 2xx or 412 status, the
7489 If-Unmodified-Since header SHOULD be ignored.
7491 If the specified date is invalid, the header is ignored.
7493 The result of a request having both an If-Unmodified-Since header
7494 field and either an If-None-Match or an If-Modified-Since header
7495 fields is undefined by this specification.
7499 The Last-Modified entity-header field indicates the date and time at
7500 which the origin server believes the variant was last modified.
7502 Last-Modified = "Last-Modified" ":" HTTP-date
7506Fielding, et al. Standards Track [Page 134]
7508RFC 2616 HTTP/1.1 June 1999
7511 An example of its use is
7513 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
7515 The exact meaning of this header field depends on the implementation
7516 of the origin server and the nature of the original resource. For
7517 files, it may be just the file system last-modified time. For
7518 entities with dynamically included parts, it may be the most recent
7519 of the set of last-modify times for its component parts. For database
7520 gateways, it may be the last-update time stamp of the record. For
7521 virtual objects, it may be the last time the internal state changed.
7523 An origin server MUST NOT send a Last-Modified date which is later
7524 than the server's time of message origination. In such cases, where
7525 the resource's last modification would indicate some time in the
7526 future, the server MUST replace that date with the message
7529 An origin server SHOULD obtain the Last-Modified value of the entity
7530 as close as possible to the time that it generates the Date value of
7531 its response. This allows a recipient to make an accurate assessment
7532 of the entity's modification time, especially if the entity changes
7533 near the time that the response is generated.
7535 HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
7539 The Location response-header field is used to redirect the recipient
7540 to a location other than the Request-URI for completion of the
7541 request or identification of a new resource. For 201 (Created)
7542 responses, the Location is that of the new resource which was created
7543 by the request. For 3xx responses, the location SHOULD indicate the
7544 server's preferred URI for automatic redirection to the resource. The
7545 field value consists of a single absolute URI.
7547 Location = "Location" ":" absoluteURI
7551 Location: http://www.w3.org/pub/WWW/People.html
7553 Note: The Content-Location header field (section 14.14) differs
7554 from Location in that the Content-Location identifies the original
7555 location of the entity enclosed in the request. It is therefore
7556 possible for a response to contain header fields for both Location
7557 and Content-Location. Also see section 13.10 for cache
7558 requirements of some methods.
7562Fielding, et al. Standards Track [Page 135]
7564RFC 2616 HTTP/1.1 June 1999
7569 The Max-Forwards request-header field provides a mechanism with the
7570 TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
7571 number of proxies or gateways that can forward the request to the
7572 next inbound server. This can be useful when the client is attempting
7573 to trace a request chain which appears to be failing or looping in
7576 Max-Forwards = "Max-Forwards" ":" 1*DIGIT
7578 The Max-Forwards value is a decimal integer indicating the remaining
7579 number of times this request message may be forwarded.
7581 Each proxy or gateway recipient of a TRACE or OPTIONS request
7582 containing a Max-Forwards header field MUST check and update its
7583 value prior to forwarding the request. If the received value is zero
7584 (0), the recipient MUST NOT forward the request; instead, it MUST
7585 respond as the final recipient. If the received Max-Forwards value is
7586 greater than zero, then the forwarded message MUST contain an updated
7587 Max-Forwards field with a value decremented by one (1).
7589 The Max-Forwards header field MAY be ignored for all other methods
7590 defined by this specification and for any extension methods for which
7591 it is not explicitly referred to as part of that method definition.
7595 The Pragma general-header field is used to include implementation-
7596 specific directives that might apply to any recipient along the
7597 request/response chain. All pragma directives specify optional
7598 behavior from the viewpoint of the protocol; however, some systems
7599 MAY require that behavior be consistent with the directives.
7601 Pragma = "Pragma" ":" 1#pragma-directive
7602 pragma-directive = "no-cache" | extension-pragma
7603 extension-pragma = token [ "=" ( token | quoted-string ) ]
7605 When the no-cache directive is present in a request message, an
7606 application SHOULD forward the request toward the origin server even
7607 if it has a cached copy of what is being requested. This pragma
7608 directive has the same semantics as the no-cache cache-directive (see
7609 section 14.9) and is defined here for backward compatibility with
7610 HTTP/1.0. Clients SHOULD include both header fields when a no-cache
7611 request is sent to a server not known to be HTTP/1.1 compliant.
7618Fielding, et al. Standards Track [Page 136]
7620RFC 2616 HTTP/1.1 June 1999
7623 Pragma directives MUST be passed through by a proxy or gateway
7624 application, regardless of their significance to that application,
7625 since the directives might be applicable to all recipients along the
7626 request/response chain. It is not possible to specify a pragma for a
7627 specific recipient; however, any pragma directive not relevant to a
7628 recipient SHOULD be ignored by that recipient.
7630 HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
7631 sent "Cache-Control: no-cache". No new Pragma directives will be
7634 Note: because the meaning of "Pragma: no-cache as a response
7635 header field is not actually specified, it does not provide a
7636 reliable replacement for "Cache-Control: no-cache" in a response
763814.33 Proxy-Authenticate
7640 The Proxy-Authenticate response-header field MUST be included as part
7641 of a 407 (Proxy Authentication Required) response. The field value
7642 consists of a challenge that indicates the authentication scheme and
7643 parameters applicable to the proxy for this Request-URI.
7645 Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
7647 The HTTP access authentication process is described in "HTTP
7648 Authentication: Basic and Digest Access Authentication" [43]. Unlike
7649 WWW-Authenticate, the Proxy-Authenticate header field applies only to
7650 the current connection and SHOULD NOT be passed on to downstream
7651 clients. However, an intermediate proxy might need to obtain its own
7652 credentials by requesting them from the downstream client, which in
7653 some circumstances will appear as if the proxy is forwarding the
7654 Proxy-Authenticate header field.
765614.34 Proxy-Authorization
7658 The Proxy-Authorization request-header field allows the client to
7659 identify itself (or its user) to a proxy which requires
7660 authentication. The Proxy-Authorization field value consists of
7661 credentials containing the authentication information of the user
7662 agent for the proxy and/or realm of the resource being requested.
7664 Proxy-Authorization = "Proxy-Authorization" ":" credentials
7666 The HTTP access authentication process is described in "HTTP
7667 Authentication: Basic and Digest Access Authentication" [43] . Unlike
7668 Authorization, the Proxy-Authorization header field applies only to
7669 the next outbound proxy that demanded authentication using the Proxy-
7670 Authenticate field. When multiple proxies are used in a chain, the
7674Fielding, et al. Standards Track [Page 137]
7676RFC 2616 HTTP/1.1 June 1999
7679 Proxy-Authorization header field is consumed by the first outbound
7680 proxy that was expecting to receive credentials. A proxy MAY relay
7681 the credentials from the client request to the next proxy if that is
7682 the mechanism by which the proxies cooperatively authenticate a given
7689 Since all HTTP entities are represented in HTTP messages as sequences
7690 of bytes, the concept of a byte range is meaningful for any HTTP
7691 entity. (However, not all clients and servers need to support byte-
7694 Byte range specifications in HTTP apply to the sequence of bytes in
7695 the entity-body (not necessarily the same as the message-body).
7697 A byte range operation MAY specify a single range of bytes, or a set
7698 of ranges within a single entity.
7700 ranges-specifier = byte-ranges-specifier
7701 byte-ranges-specifier = bytes-unit "=" byte-range-set
7702 byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
7703 byte-range-spec = first-byte-pos "-" [last-byte-pos]
7704 first-byte-pos = 1*DIGIT
7705 last-byte-pos = 1*DIGIT
7707 The first-byte-pos value in a byte-range-spec gives the byte-offset
7708 of the first byte in a range. The last-byte-pos value gives the
7709 byte-offset of the last byte in the range; that is, the byte
7710 positions specified are inclusive. Byte offsets start at zero.
7712 If the last-byte-pos value is present, it MUST be greater than or
7713 equal to the first-byte-pos in that byte-range-spec, or the byte-
7714 range-spec is syntactically invalid. The recipient of a byte-range-
7715 set that includes one or more syntactically invalid byte-range-spec
7716 values MUST ignore the header field that includes that byte-range-
7719 If the last-byte-pos value is absent, or if the value is greater than
7720 or equal to the current length of the entity-body, last-byte-pos is
7721 taken to be equal to one less than the current length of the entity-
7724 By its choice of last-byte-pos, a client can limit the number of
7725 bytes retrieved without knowing the size of the entity.
7730Fielding, et al. Standards Track [Page 138]
7732RFC 2616 HTTP/1.1 June 1999
7735 suffix-byte-range-spec = "-" suffix-length
7736 suffix-length = 1*DIGIT
7738 A suffix-byte-range-spec is used to specify the suffix of the
7739 entity-body, of a length given by the suffix-length value. (That is,
7740 this form specifies the last N bytes of an entity-body.) If the
7741 entity is shorter than the specified suffix-length, the entire
7742 entity-body is used.
7744 If a syntactically valid byte-range-set includes at least one byte-
7745 range-spec whose first-byte-pos is less than the current length of
7746 the entity-body, or at least one suffix-byte-range-spec with a non-
7747 zero suffix-length, then the byte-range-set is satisfiable.
7748 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
7749 is unsatisfiable, the server SHOULD return a response with a status
7750 of 416 (Requested range not satisfiable). Otherwise, the server
7751 SHOULD return a response with a status of 206 (Partial Content)
7752 containing the satisfiable ranges of the entity-body.
7754 Examples of byte-ranges-specifier values (assuming an entity-body of
7757 - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
7760 - The second 500 bytes (byte offsets 500-999, inclusive):
7763 - The final 500 bytes (byte offsets 9500-9999, inclusive):
7768 - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
7770 - Several legal but not canonical specifications of the second 500
7771 bytes (byte offsets 500-999, inclusive):
7772 bytes=500-600,601-999
7773 bytes=500-700,601-999
777514.35.2 Range Retrieval Requests
7777 HTTP retrieval requests using conditional or unconditional GET
7778 methods MAY request one or more sub-ranges of the entity, instead of
7779 the entire entity, using the Range request header, which applies to
7780 the entity returned as the result of the request:
7782 Range = "Range" ":" ranges-specifier
7786Fielding, et al. Standards Track [Page 139]
7788RFC 2616 HTTP/1.1 June 1999
7791 A server MAY ignore the Range header. However, HTTP/1.1 origin
7792 servers and intermediate caches ought to support byte ranges when
7793 possible, since Range supports efficient recovery from partially
7794 failed transfers, and supports efficient partial retrieval of large
7797 If the server supports the Range header and the specified range or
7798 ranges are appropriate for the entity:
7800 - The presence of a Range header in an unconditional GET modifies
7801 what is returned if the GET is otherwise successful. In other
7802 words, the response carries a status code of 206 (Partial
7803 Content) instead of 200 (OK).
7805 - The presence of a Range header in a conditional GET (a request
7806 using one or both of If-Modified-Since and If-None-Match, or
7807 one or both of If-Unmodified-Since and If-Match) modifies what
7808 is returned if the GET is otherwise successful and the
7809 condition is true. It does not affect the 304 (Not Modified)
7810 response returned if the conditional is false.
7812 In some cases, it might be more appropriate to use the If-Range
7813 header (see section 14.27) in addition to the Range header.
7815 If a proxy that supports ranges receives a Range request, forwards
7816 the request to an inbound server, and receives an entire entity in
7817 reply, it SHOULD only return the requested range to its client. It
7818 SHOULD store the entire received response in its cache if that is
7819 consistent with its cache allocation policies.
7823 The Referer[sic] request-header field allows the client to specify,
7824 for the server's benefit, the address (URI) of the resource from
7825 which the Request-URI was obtained (the "referrer", although the
7826 header field is misspelled.) The Referer request-header allows a
7827 server to generate lists of back-links to resources for interest,
7828 logging, optimized caching, etc. It also allows obsolete or mistyped
7829 links to be traced for maintenance. The Referer field MUST NOT be
7830 sent if the Request-URI was obtained from a source that does not have
7831 its own URI, such as input from the user keyboard.
7833 Referer = "Referer" ":" ( absoluteURI | relativeURI )
7837 Referer: http://www.w3.org/hypertext/DataSources/Overview.html
7842Fielding, et al. Standards Track [Page 140]
7844RFC 2616 HTTP/1.1 June 1999
7847 If the field value is a relative URI, it SHOULD be interpreted
7848 relative to the Request-URI. The URI MUST NOT include a fragment. See
7849 section 15.1.3 for security considerations.
7853 The Retry-After response-header field can be used with a 503 (Service
7854 Unavailable) response to indicate how long the service is expected to
7855 be unavailable to the requesting client. This field MAY also be used
7856 with any 3xx (Redirection) response to indicate the minimum time the
7857 user-agent is asked wait before issuing the redirected request. The
7858 value of this field can be either an HTTP-date or an integer number
7859 of seconds (in decimal) after the time of the response.
7861 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
7863 Two examples of its use are
7865 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
7868 In the latter example, the delay is 2 minutes.
7872 The Server response-header field contains information about the
7873 software used by the origin server to handle the request. The field
7874 can contain multiple product tokens (section 3.8) and comments
7875 identifying the server and any significant subproducts. The product
7876 tokens are listed in order of their significance for identifying the
7879 Server = "Server" ":" 1*( product | comment )
7883 Server: CERN/3.0 libwww/2.17
7885 If the response is being forwarded through a proxy, the proxy
7886 application MUST NOT modify the Server response-header. Instead, it
7887 SHOULD include a Via field (as described in section 14.45).
7889 Note: Revealing the specific software version of the server might
7890 allow the server machine to become more vulnerable to attacks
7891 against software that is known to contain security holes. Server
7892 implementors are encouraged to make this field a configurable
7898Fielding, et al. Standards Track [Page 141]
7900RFC 2616 HTTP/1.1 June 1999
7905 The TE request-header field indicates what extension transfer-codings
7906 it is willing to accept in the response and whether or not it is
7907 willing to accept trailer fields in a chunked transfer-coding. Its
7908 value may consist of the keyword "trailers" and/or a comma-separated
7909 list of extension transfer-coding names with optional accept
7910 parameters (as described in section 3.6).
7912 TE = "TE" ":" #( t-codings )
7913 t-codings = "trailers" | ( transfer-extension [ accept-params ] )
7915 The presence of the keyword "trailers" indicates that the client is
7916 willing to accept trailer fields in a chunked transfer-coding, as
7917 defined in section 3.6.1. This keyword is reserved for use with
7918 transfer-coding values even though it does not itself represent a
7921 Examples of its use are:
7925 TE: trailers, deflate;q=0.5
7927 The TE header field only applies to the immediate connection.
7928 Therefore, the keyword MUST be supplied within a Connection header
7929 field (section 14.10) whenever TE is present in an HTTP/1.1 message.
7931 A server tests whether a transfer-coding is acceptable, according to
7932 a TE field, using these rules:
7934 1. The "chunked" transfer-coding is always acceptable. If the
7935 keyword "trailers" is listed, the client indicates that it is
7936 willing to accept trailer fields in the chunked response on
7937 behalf of itself and any downstream clients. The implication is
7938 that, if given, the client is stating that either all
7939 downstream clients are willing to accept trailer fields in the
7940 forwarded response, or that it will attempt to buffer the
7941 response on behalf of downstream recipients.
7943 Note: HTTP/1.1 does not define any means to limit the size of a
7944 chunked response such that a client can be assured of buffering
7945 the entire response.
7947 2. If the transfer-coding being tested is one of the transfer-
7948 codings listed in the TE field, then it is acceptable unless it
7949 is accompanied by a qvalue of 0. (As defined in section 3.9, a
7950 qvalue of 0 means "not acceptable.")
7954Fielding, et al. Standards Track [Page 142]
7956RFC 2616 HTTP/1.1 June 1999
7959 3. If multiple transfer-codings are acceptable, then the
7960 acceptable transfer-coding with the highest non-zero qvalue is
7961 preferred. The "chunked" transfer-coding always has a qvalue
7964 If the TE field-value is empty or if no TE field is present, the only
7965 transfer-coding is "chunked". A message with no transfer-coding is
7970 The Trailer general field value indicates that the given set of
7971 header fields is present in the trailer of a message encoded with
7972 chunked transfer-coding.
7974 Trailer = "Trailer" ":" 1#field-name
7976 An HTTP/1.1 message SHOULD include a Trailer header field in a
7977 message using chunked transfer-coding with a non-empty trailer. Doing
7978 so allows the recipient to know which header fields to expect in the
7981 If no Trailer header field is present, the trailer SHOULD NOT include
7982 any header fields. See section 3.6.1 for restrictions on the use of
7983 trailer fields in a "chunked" transfer-coding.
7985 Message header fields listed in the Trailer header field MUST NOT
7986 include the following header fields:
799414.41 Transfer-Encoding
7996 The Transfer-Encoding general-header field indicates what (if any)
7997 type of transformation has been applied to the message body in order
7998 to safely transfer it between the sender and the recipient. This
7999 differs from the content-coding in that the transfer-coding is a
8000 property of the message, not of the entity.
8002 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
8004 Transfer-codings are defined in section 3.6. An example is:
8006 Transfer-Encoding: chunked
8010Fielding, et al. Standards Track [Page 143]
8012RFC 2616 HTTP/1.1 June 1999
8015 If multiple encodings have been applied to an entity, the transfer-
8016 codings MUST be listed in the order in which they were applied.
8017 Additional information about the encoding parameters MAY be provided
8018 by other entity-header fields not defined by this specification.
8020 Many older HTTP/1.0 applications do not understand the Transfer-
8025 The Upgrade general-header allows the client to specify what
8026 additional communication protocols it supports and would like to use
8027 if the server finds it appropriate to switch protocols. The server
8028 MUST use the Upgrade header field within a 101 (Switching Protocols)
8029 response to indicate which protocol(s) are being switched.
8031 Upgrade = "Upgrade" ":" 1#product
8035 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
8037 The Upgrade header field is intended to provide a simple mechanism
8038 for transition from HTTP/1.1 to some other, incompatible protocol. It
8039 does so by allowing the client to advertise its desire to use another
8040 protocol, such as a later version of HTTP with a higher major version
8041 number, even though the current request has been made using HTTP/1.1.
8042 This eases the difficult transition between incompatible protocols by
8043 allowing the client to initiate a request in the more commonly
8044 supported protocol while indicating to the server that it would like
8045 to use a "better" protocol if available (where "better" is determined
8046 by the server, possibly according to the nature of the method and/or
8047 resource being requested).
8049 The Upgrade header field only applies to switching application-layer
8050 protocols upon the existing transport-layer connection. Upgrade
8051 cannot be used to insist on a protocol change; its acceptance and use
8052 by the server is optional. The capabilities and nature of the
8053 application-layer communication after the protocol change is entirely
8054 dependent upon the new protocol chosen, although the first action
8055 after changing the protocol MUST be a response to the initial HTTP
8056 request containing the Upgrade header field.
8058 The Upgrade header field only applies to the immediate connection.
8059 Therefore, the upgrade keyword MUST be supplied within a Connection
8060 header field (section 14.10) whenever Upgrade is present in an
8066Fielding, et al. Standards Track [Page 144]
8068RFC 2616 HTTP/1.1 June 1999
8071 The Upgrade header field cannot be used to indicate a switch to a
8072 protocol on a different connection. For that purpose, it is more
8073 appropriate to use a 301, 302, 303, or 305 redirection response.
8075 This specification only defines the protocol name "HTTP" for use by
8076 the family of Hypertext Transfer Protocols, as defined by the HTTP
8077 version rules of section 3.1 and future updates to this
8078 specification. Any token can be used as a protocol name; however, it
8079 will only be useful if both the client and server associate the name
8080 with the same protocol.
8084 The User-Agent request-header field contains information about the
8085 user agent originating the request. This is for statistical purposes,
8086 the tracing of protocol violations, and automated recognition of user
8087 agents for the sake of tailoring responses to avoid particular user
8088 agent limitations. User agents SHOULD include this field with
8089 requests. The field can contain multiple product tokens (section 3.8)
8090 and comments identifying the agent and any subproducts which form a
8091 significant part of the user agent. By convention, the product tokens
8092 are listed in order of their significance for identifying the
8095 User-Agent = "User-Agent" ":" 1*( product | comment )
8099 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
8103 The Vary field value indicates the set of request-header fields that
8104 fully determines, while the response is fresh, whether a cache is
8105 permitted to use the response to reply to a subsequent request
8106 without revalidation. For uncacheable or stale responses, the Vary
8107 field value advises the user agent about the criteria that were used
8108 to select the representation. A Vary field value of "*" implies that
8109 a cache cannot determine from the request headers of a subsequent
8110 request whether this response is the appropriate representation. See
8111 section 13.6 for use of the Vary header field by caches.
8113 Vary = "Vary" ":" ( "*" | 1#field-name )
8115 An HTTP/1.1 server SHOULD include a Vary header field with any
8116 cacheable response that is subject to server-driven negotiation.
8117 Doing so allows a cache to properly interpret future requests on that
8118 resource and informs the user agent about the presence of negotiation
8122Fielding, et al. Standards Track [Page 145]
8124RFC 2616 HTTP/1.1 June 1999
8127 on that resource. A server MAY include a Vary header field with a
8128 non-cacheable response that is subject to server-driven negotiation,
8129 since this might provide the user agent with useful information about
8130 the dimensions over which the response varies at the time of the
8133 A Vary field value consisting of a list of field-names signals that
8134 the representation selected for the response is based on a selection
8135 algorithm which considers ONLY the listed request-header field values
8136 in selecting the most appropriate representation. A cache MAY assume
8137 that the same selection will be made for future requests with the
8138 same values for the listed field names, for the duration of time for
8139 which the response is fresh.
8141 The field-names given are not limited to the set of standard
8142 request-header fields defined by this specification. Field names are
8145 A Vary field value of "*" signals that unspecified parameters not
8146 limited to the request-headers (e.g., the network address of the
8147 client), play a role in the selection of the response representation.
8148 The "*" value MUST NOT be generated by a proxy server; it may only be
8149 generated by an origin server.
8153 The Via general-header field MUST be used by gateways and proxies to
8154 indicate the intermediate protocols and recipients between the user
8155 agent and the server on requests, and between the origin server and
8156 the client on responses. It is analogous to the "Received" field of
8157 RFC 822 [9] and is intended to be used for tracking message forwards,
8158 avoiding request loops, and identifying the protocol capabilities of
8159 all senders along the request/response chain.
8161 Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
8162 received-protocol = [ protocol-name "/" ] protocol-version
8163 protocol-name = token
8164 protocol-version = token
8165 received-by = ( host [ ":" port ] ) | pseudonym
8168 The received-protocol indicates the protocol version of the message
8169 received by the server or client along each segment of the
8170 request/response chain. The received-protocol version is appended to
8171 the Via field value when the message is forwarded so that information
8172 about the protocol capabilities of upstream applications remains
8173 visible to all recipients.
8178Fielding, et al. Standards Track [Page 146]
8180RFC 2616 HTTP/1.1 June 1999
8183 The protocol-name is optional if and only if it would be "HTTP". The
8184 received-by field is normally the host and optional port number of a
8185 recipient server or client that subsequently forwarded the message.
8186 However, if the real host is considered to be sensitive information,
8187 it MAY be replaced by a pseudonym. If the port is not given, it MAY
8188 be assumed to be the default port of the received-protocol.
8190 Multiple Via field values represents each proxy or gateway that has
8191 forwarded the message. Each recipient MUST append its information
8192 such that the end result is ordered according to the sequence of
8193 forwarding applications.
8195 Comments MAY be used in the Via header field to identify the software
8196 of the recipient proxy or gateway, analogous to the User-Agent and
8197 Server header fields. However, all comments in the Via field are
8198 optional and MAY be removed by any recipient prior to forwarding the
8201 For example, a request message could be sent from an HTTP/1.0 user
8202 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
8203 forward the request to a public proxy at nowhere.com, which completes
8204 the request by forwarding it to the origin server at www.ics.uci.edu.
8205 The request received by www.ics.uci.edu would then have the following
8208 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
8210 Proxies and gateways used as a portal through a network firewall
8211 SHOULD NOT, by default, forward the names and ports of hosts within
8212 the firewall region. This information SHOULD only be propagated if
8213 explicitly enabled. If not enabled, the received-by host of any host
8214 behind the firewall SHOULD be replaced by an appropriate pseudonym
8217 For organizations that have strong privacy requirements for hiding
8218 internal structures, a proxy MAY combine an ordered subsequence of
8219 Via header field entries with identical received-protocol values into
8220 a single such entry. For example,
8222 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
8224 could be collapsed to
8226 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
8234Fielding, et al. Standards Track [Page 147]
8236RFC 2616 HTTP/1.1 June 1999
8239 Applications SHOULD NOT combine multiple entries unless they are all
8240 under the same organizational control and the hosts have already been
8241 replaced by pseudonyms. Applications MUST NOT combine entries which
8242 have different received-protocol values.
8246 The Warning general-header field is used to carry additional
8247 information about the status or transformation of a message which
8248 might not be reflected in the message. This information is typically
8249 used to warn about a possible lack of semantic transparency from
8250 caching operations or transformations applied to the entity body of
8253 Warning headers are sent with responses using:
8255 Warning = "Warning" ":" 1#warning-value
8257 warning-value = warn-code SP warn-agent SP warn-text
8261 warn-agent = ( host [ ":" port ] ) | pseudonym
8262 ; the name or pseudonym of the server adding
8263 ; the Warning header, for use in debugging
8264 warn-text = quoted-string
8265 warn-date = <"> HTTP-date <">
8267 A response MAY carry more than one Warning header.
8269 The warn-text SHOULD be in a natural language and character set that
8270 is most likely to be intelligible to the human user receiving the
8271 response. This decision MAY be based on any available knowledge, such
8272 as the location of the cache or user, the Accept-Language field in a
8273 request, the Content-Language field in a response, etc. The default
8274 language is English and the default character set is ISO-8859-1.
8276 If a character set other than ISO-8859-1 is used, it MUST be encoded
8277 in the warn-text using the method described in RFC 2047 [14].
8279 Warning headers can in general be applied to any message, however
8280 some specific warn-codes are specific to caches and can only be
8281 applied to response messages. New Warning headers SHOULD be added
8282 after any existing Warning headers. A cache MUST NOT delete any
8283 Warning header that it received with a message. However, if a cache
8284 successfully validates a cache entry, it SHOULD remove any Warning
8285 headers previously attached to that entry except as specified for
8290Fielding, et al. Standards Track [Page 148]
8292RFC 2616 HTTP/1.1 June 1999
8295 specific Warning codes. It MUST then add any Warning headers received
8296 in the validating response. In other words, Warning headers are those
8297 that would be attached to the most recent relevant response.
8299 When multiple Warning headers are attached to a response, the user
8300 agent ought to inform the user of as many of them as possible, in the
8301 order that they appear in the response. If it is not possible to
8302 inform the user of all of the warnings, the user agent SHOULD follow
8305 - Warnings that appear early in the response take priority over
8306 those appearing later in the response.
8308 - Warnings in the user's preferred character set take priority
8309 over warnings in other character sets but with identical warn-
8310 codes and warn-agents.
8312 Systems that generate multiple Warning headers SHOULD order them with
8313 this user agent behavior in mind.
8315 Requirements for the behavior of caches with respect to Warnings are
8316 stated in section 13.1.2.
8318 This is a list of the currently-defined warn-codes, each with a
8319 recommended warn-text in English, and a description of its meaning.
8321 110 Response is stale
8322 MUST be included whenever the returned response is stale.
8324 111 Revalidation failed
8325 MUST be included if a cache returns a stale response because an
8326 attempt to revalidate the response failed, due to an inability to
8329 112 Disconnected operation
8330 SHOULD be included if the cache is intentionally disconnected from
8331 the rest of the network for a period of time.
8333 113 Heuristic expiration
8334 MUST be included if the cache heuristically chose a freshness
8335 lifetime greater than 24 hours and the response's age is greater
8338 199 Miscellaneous warning
8339 The warning text MAY include arbitrary information to be presented
8340 to a human user, or logged. A system receiving this warning MUST
8341 NOT take any automated action, besides presenting the warning to
8346Fielding, et al. Standards Track [Page 149]
8348RFC 2616 HTTP/1.1 June 1999
8351 214 Transformation applied
8352 MUST be added by an intermediate cache or proxy if it applies any
8353 transformation changing the content-coding (as specified in the
8354 Content-Encoding header) or media-type (as specified in the
8355 Content-Type header) of the response, or the entity-body of the
8356 response, unless this Warning code already appears in the response.
8358 299 Miscellaneous persistent warning
8359 The warning text MAY include arbitrary information to be presented
8360 to a human user, or logged. A system receiving this warning MUST
8361 NOT take any automated action.
8363 If an implementation sends a message with one or more Warning headers
8364 whose version is HTTP/1.0 or lower, then the sender MUST include in
8365 each warning-value a warn-date that matches the date in the response.
8367 If an implementation receives a message with a warning-value that
8368 includes a warn-date, and that warn-date is different from the Date
8369 value in the response, then that warning-value MUST be deleted from
8370 the message before storing, forwarding, or using it. (This prevents
8371 bad consequences of naive caching of Warning header fields.) If all
8372 of the warning-values are deleted for this reason, the Warning header
8373 MUST be deleted as well.
837514.47 WWW-Authenticate
8377 The WWW-Authenticate response-header field MUST be included in 401
8378 (Unauthorized) response messages. The field value consists of at
8379 least one challenge that indicates the authentication scheme(s) and
8380 parameters applicable to the Request-URI.
8382 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
8384 The HTTP access authentication process is described in "HTTP
8385 Authentication: Basic and Digest Access Authentication" [43]. User
8386 agents are advised to take special care in parsing the WWW-
8387 Authenticate field value as it might contain more than one challenge,
8388 or if more than one WWW-Authenticate header field is provided, the
8389 contents of a challenge itself can contain a comma-separated list of
8390 authentication parameters.
839215 Security Considerations
8394 This section is meant to inform application developers, information
8395 providers, and users of the security limitations in HTTP/1.1 as
8396 described by this document. The discussion does not include
8397 definitive solutions to the problems revealed, though it does make
8398 some suggestions for reducing security risks.
8402Fielding, et al. Standards Track [Page 150]
8404RFC 2616 HTTP/1.1 June 1999
840715.1 Personal Information
8409 HTTP clients are often privy to large amounts of personal information
8410 (e.g. the user's name, location, mail address, passwords, encryption
8411 keys, etc.), and SHOULD be very careful to prevent unintentional
8412 leakage of this information via the HTTP protocol to other sources.
8413 We very strongly recommend that a convenient interface be provided
8414 for the user to control dissemination of such information, and that
8415 designers and implementors be particularly careful in this area.
8416 History shows that errors in this area often create serious security
8417 and/or privacy problems and generate highly adverse publicity for the
8418 implementor's company.
842015.1.1 Abuse of Server Log Information
8422 A server is in the position to save personal data about a user's
8423 requests which might identify their reading patterns or subjects of
8424 interest. This information is clearly confidential in nature and its
8425 handling can be constrained by law in certain countries. People using
8426 the HTTP protocol to provide data are responsible for ensuring that
8427 such material is not distributed without the permission of any
8428 individuals that are identifiable by the published results.
843015.1.2 Transfer of Sensitive Information
8432 Like any generic data transfer protocol, HTTP cannot regulate the
8433 content of the data that is transferred, nor is there any a priori
8434 method of determining the sensitivity of any particular piece of
8435 information within the context of any given request. Therefore,
8436 applications SHOULD supply as much control over this information as
8437 possible to the provider of that information. Four header fields are
8438 worth special mention in this context: Server, Via, Referer and From.
8440 Revealing the specific software version of the server might allow the
8441 server machine to become more vulnerable to attacks against software
8442 that is known to contain security holes. Implementors SHOULD make the
8443 Server header field a configurable option.
8445 Proxies which serve as a portal through a network firewall SHOULD
8446 take special precautions regarding the transfer of header information
8447 that identifies the hosts behind the firewall. In particular, they
8448 SHOULD remove, or replace with sanitized versions, any Via fields
8449 generated behind the firewall.
8451 The Referer header allows reading patterns to be studied and reverse
8452 links drawn. Although it can be very useful, its power can be abused
8453 if user details are not separated from the information contained in
8458Fielding, et al. Standards Track [Page 151]
8460RFC 2616 HTTP/1.1 June 1999
8463 the Referer. Even when the personal information has been removed, the
8464 Referer header might indicate a private document's URI whose
8465 publication would be inappropriate.
8467 The information sent in the From field might conflict with the user's
8468 privacy interests or their site's security policy, and hence it
8469 SHOULD NOT be transmitted without the user being able to disable,
8470 enable, and modify the contents of the field. The user MUST be able
8471 to set the contents of this field within a user preference or
8472 application defaults configuration.
8474 We suggest, though do not require, that a convenient toggle interface
8475 be provided for the user to enable or disable the sending of From and
8476 Referer information.
8478 The User-Agent (section 14.43) or Server (section 14.38) header
8479 fields can sometimes be used to determine that a specific client or
8480 server have a particular security hole which might be exploited.
8481 Unfortunately, this same information is often used for other valuable
8482 purposes for which HTTP currently has no better mechanism.
848415.1.3 Encoding Sensitive Information in URI's
8486 Because the source of a link might be private information or might
8487 reveal an otherwise private information source, it is strongly
8488 recommended that the user be able to select whether or not the
8489 Referer field is sent. For example, a browser client could have a
8490 toggle switch for browsing openly/anonymously, which would
8491 respectively enable/disable the sending of Referer and From
8494 Clients SHOULD NOT include a Referer header field in a (non-secure)
8495 HTTP request if the referring page was transferred with a secure
8498 Authors of services which use the HTTP protocol SHOULD NOT use GET
8499 based forms for the submission of sensitive data, because this will
8500 cause this data to be encoded in the Request-URI. Many existing
8501 servers, proxies, and user agents will log the request URI in some
8502 place where it might be visible to third parties. Servers can use
8503 POST-based form submission instead
850515.1.4 Privacy Issues Connected to Accept Headers
8507 Accept request-headers can reveal information about the user to all
8508 servers which are accessed. The Accept-Language header in particular
8509 can reveal information the user would consider to be of a private
8510 nature, because the understanding of particular languages is often
8514Fielding, et al. Standards Track [Page 152]
8516RFC 2616 HTTP/1.1 June 1999
8519 strongly correlated to the membership of a particular ethnic group.
8520 User agents which offer the option to configure the contents of an
8521 Accept-Language header to be sent in every request are strongly
8522 encouraged to let the configuration process include a message which
8523 makes the user aware of the loss of privacy involved.
8525 An approach that limits the loss of privacy would be for a user agent
8526 to omit the sending of Accept-Language headers by default, and to ask
8527 the user whether or not to start sending Accept-Language headers to a
8528 server if it detects, by looking for any Vary response-header fields
8529 generated by the server, that such sending could improve the quality
8532 Elaborate user-customized accept header fields sent in every request,
8533 in particular if these include quality values, can be used by servers
8534 as relatively reliable and long-lived user identifiers. Such user
8535 identifiers would allow content providers to do click-trail tracking,
8536 and would allow collaborating content providers to match cross-server
8537 click-trails or form submissions of individual users. Note that for
8538 many users not behind a proxy, the network address of the host
8539 running the user agent will also serve as a long-lived user
8540 identifier. In environments where proxies are used to enhance
8541 privacy, user agents ought to be conservative in offering accept
8542 header configuration options to end users. As an extreme privacy
8543 measure, proxies could filter the accept headers in relayed requests.
8544 General purpose user agents which provide a high degree of header
8545 configurability SHOULD warn users about the loss of privacy which can
854815.2 Attacks Based On File and Path Names
8550 Implementations of HTTP origin servers SHOULD be careful to restrict
8551 the documents returned by HTTP requests to be only those that were
8552 intended by the server administrators. If an HTTP server translates
8553 HTTP URIs directly into file system calls, the server MUST take
8554 special care not to serve files that were not intended to be
8555 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
8556 other operating systems use ".." as a path component to indicate a
8557 directory level above the current one. On such a system, an HTTP
8558 server MUST disallow any such construct in the Request-URI if it
8559 would otherwise allow access to a resource outside those intended to
8560 be accessible via the HTTP server. Similarly, files intended for
8561 reference only internally to the server (such as access control
8562 files, configuration files, and script code) MUST be protected from
8563 inappropriate retrieval, since they might contain sensitive
8564 information. Experience has shown that minor bugs in such HTTP server
8565 implementations have turned into security risks.
8570Fielding, et al. Standards Track [Page 153]
8572RFC 2616 HTTP/1.1 June 1999
8577 Clients using HTTP rely heavily on the Domain Name Service, and are
8578 thus generally prone to security attacks based on the deliberate
8579 mis-association of IP addresses and DNS names. Clients need to be
8580 cautious in assuming the continuing validity of an IP number/DNS name
8583 In particular, HTTP clients SHOULD rely on their name resolver for
8584 confirmation of an IP number/DNS name association, rather than
8585 caching the result of previous host name lookups. Many platforms
8586 already can cache host name lookups locally when appropriate, and
8587 they SHOULD be configured to do so. It is proper for these lookups to
8588 be cached, however, only when the TTL (Time To Live) information
8589 reported by the name server makes it likely that the cached
8590 information will remain useful.
8592 If HTTP clients cache the results of host name lookups in order to
8593 achieve a performance improvement, they MUST observe the TTL
8594 information reported by DNS.
8596 If HTTP clients do not observe this rule, they could be spoofed when
8597 a previously-accessed server's IP address changes. As network
8598 renumbering is expected to become increasingly common [24], the
8599 possibility of this form of attack will grow. Observing this
8600 requirement thus reduces this potential security vulnerability.
8602 This requirement also improves the load-balancing behavior of clients
8603 for replicated servers using the same DNS name and reduces the
8604 likelihood of a user's experiencing failure in accessing sites which
860715.4 Location Headers and Spoofing
8609 If a single server supports multiple organizations that do not trust
8610 one another, then it MUST check the values of Location and Content-
8611 Location headers in responses that are generated under control of
8612 said organizations to make sure that they do not attempt to
8613 invalidate resources over which they have no authority.
861515.5 Content-Disposition Issues
8617 RFC 1806 [35], from which the often implemented Content-Disposition
8618 (see section 19.5.1) header in HTTP is derived, has a number of very
8619 serious security considerations. Content-Disposition is not part of
8620 the HTTP standard, but since it is widely implemented, we are
8621 documenting its use and risks for implementors. See RFC 2183 [49]
8622 (which updates RFC 1806) for details.
8626Fielding, et al. Standards Track [Page 154]
8628RFC 2616 HTTP/1.1 June 1999
863115.6 Authentication Credentials and Idle Clients
8633 Existing HTTP clients and user agents typically retain authentication
8634 information indefinitely. HTTP/1.1. does not provide a method for a
8635 server to direct clients to discard these cached credentials. This is
8636 a significant defect that requires further extensions to HTTP.
8637 Circumstances under which credential caching can interfere with the
8638 application's security model include but are not limited to:
8640 - Clients which have been idle for an extended period following
8641 which the server might wish to cause the client to reprompt the
8642 user for credentials.
8644 - Applications which include a session termination indication
8645 (such as a `logout' or `commit' button on a page) after which
8646 the server side of the application `knows' that there is no
8647 further reason for the client to retain the credentials.
8649 This is currently under separate study. There are a number of work-
8650 arounds to parts of this problem, and we encourage the use of
8651 password protection in screen savers, idle time-outs, and other
8652 methods which mitigate the security problems inherent in this
8653 problem. In particular, user agents which cache credentials are
8654 encouraged to provide a readily accessible mechanism for discarding
8655 cached credentials under user control.
865715.7 Proxies and Caching
8659 By their very nature, HTTP proxies are men-in-the-middle, and
8660 represent an opportunity for man-in-the-middle attacks. Compromise of
8661 the systems on which the proxies run can result in serious security
8662 and privacy problems. Proxies have access to security-related
8663 information, personal information about individual users and
8664 organizations, and proprietary information belonging to users and
8665 content providers. A compromised proxy, or a proxy implemented or
8666 configured without regard to security and privacy considerations,
8667 might be used in the commission of a wide range of potential attacks.
8669 Proxy operators should protect the systems on which proxies run as
8670 they would protect any system that contains or transports sensitive
8671 information. In particular, log information gathered at proxies often
8672 contains highly sensitive personal information, and/or information
8673 about organizations. Log information should be carefully guarded, and
8674 appropriate guidelines for use developed and followed. (Section
8682Fielding, et al. Standards Track [Page 155]
8684RFC 2616 HTTP/1.1 June 1999
8687 Caching proxies provide additional potential vulnerabilities, since
8688 the contents of the cache represent an attractive target for
8689 malicious exploitation. Because cache contents persist after an HTTP
8690 request is complete, an attack on the cache can reveal information
8691 long after a user believes that the information has been removed from
8692 the network. Therefore, cache contents should be protected as
8693 sensitive information.
8695 Proxy implementors should consider the privacy and security
8696 implications of their design and coding decisions, and of the
8697 configuration options they provide to proxy operators (especially the
8698 default configuration).
8700 Users of a proxy need to be aware that they are no trustworthier than
8701 the people who run the proxy; HTTP itself cannot solve this problem.
8703 The judicious use of cryptography, when appropriate, may suffice to
8704 protect against a broad range of security and privacy attacks. Such
8705 cryptography is beyond the scope of the HTTP/1.1 specification.
870715.7.1 Denial of Service Attacks on Proxies
8709 They exist. They are hard to defend against. Research continues.
8714 This specification makes heavy use of the augmented BNF and generic
8715 constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
8716 reuses many of the definitions provided by Nathaniel Borenstein and
8717 Ned Freed for MIME [7]. We hope that their inclusion in this
8718 specification will help reduce past confusion over the relationship
8719 between HTTP and Internet mail message formats.
8721 The HTTP protocol has evolved considerably over the years. It has
8722 benefited from a large and active developer community--the many
8723 people who have participated on the www-talk mailing list--and it is
8724 that community which has been most responsible for the success of
8725 HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
8726 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
8727 Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
8728 McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
8729 VanHeyningen deserve special recognition for their efforts in
8730 defining early aspects of the protocol.
8732 This document has benefited greatly from the comments of all those
8733 participating in the HTTP-WG. In addition to those already mentioned,
8734 the following individuals have contributed to this specification:
8738Fielding, et al. Standards Track [Page 156]
8740RFC 2616 HTTP/1.1 June 1999
8743 Gary Adams Ross Patterson
8744 Harald Tveit Alvestrand Albert Lunde
8745 Keith Ball John C. Mallery
8746 Brian Behlendorf Jean-Philippe Martin-Flatin
8748 Maurizio Codogno David Morris
8749 Mike Cowlishaw Gavin Nicol
8750 Roman Czyborra Bill Perry
8751 Michael A. Dolan Jeffrey Perry
8752 David J. Fiander Scott Powers
8753 Alan Freier Owen Rees
8754 Marc Hedlund Luigi Rizzo
8755 Greg Herlihy David Robinson
8756 Koen Holtman Marc Salomon
8757 Alex Hopmann Rich Salz
8758 Bob Jernigan Allan M. Schiffman
8759 Shel Kaphan Jim Seidman
8760 Rohit Khare Chuck Shotton
8761 John Klensin Eric W. Sink
8762 Martijn Koster Simon E. Spero
8763 Alexei Kosut Richard N. Taylor
8764 David M. Kristol Robert S. Thau
8765 Daniel LaLiberte Bill (BearHeart) Weinman
8766 Ben Laurie Francois Yergeau
8767 Paul J. Leach Mary Ellen Zurko
8768 Daniel DuBois Josh Cohen
8771 Much of the content and presentation of the caching design is due to
8772 suggestions and comments from individuals including: Shel Kaphan,
8773 Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
8775 Most of the specification of ranges is based on work originally done
8776 by Ari Luotonen and John Franks, with additional input from Steve
8779 Thanks to the "cave men" of Palo Alto. You know who you are.
8781 Jim Gettys (the current editor of this document) wishes particularly
8782 to thank Roy Fielding, the previous editor of this document, along
8783 with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
8784 Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
8785 Larry Masinter for their help. And thanks go particularly to Jeff
8786 Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
8794Fielding, et al. Standards Track [Page 157]
8796RFC 2616 HTTP/1.1 June 1999
8799 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
8800 Frystyk implemented RFC 2068 early, and we wish to thank them for the
8801 discovery of many of the problems that this document attempts to
8806 [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
8809 [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
8810 D. and B. Alberti, "The Internet Gopher Protocol (a distributed
8811 document search and retrieval protocol)", RFC 1436, March 1993.
8813 [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
8816 [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
8817 Locators (URL)", RFC 1738, December 1994.
8819 [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
8820 2.0", RFC 1866, November 1995.
8822 [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
8823 Protocol -- HTTP/1.0", RFC 1945, May 1996.
8825 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
8826 Extensions (MIME) Part One: Format of Internet Message Bodies",
8827 RFC 2045, November 1996.
8829 [8] Braden, R., "Requirements for Internet Hosts -- Communication
8830 Layers", STD 3, RFC 1123, October 1989.
8832 [9] Crocker, D., "Standard for The Format of ARPA Internet Text
8833 Messages", STD 11, RFC 822, August 1982.
8835 [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
8836 Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
8837 Functional Specification," (v1.5), Thinking Machines
8838 Corporation, April 1990.
8840 [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
8843 [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
8844 Messages", RFC 1036, December 1987.
8850Fielding, et al. Standards Track [Page 158]
8852RFC 2616 HTTP/1.1 June 1999
8855 [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
8858 [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
8859 Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
8862 [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
8863 1867, November 1995.
8865 [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
8868 [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
8871 [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
8874 [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
8877 [20] Sollins, K. and L. Masinter, "Functional Requirements for
8878 Uniform Resource Names", RFC 1737, December 1994.
8880 [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
8881 Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
8883 [22] ISO-8859. International Standard -- Information Processing --
8884 8-bit Single-Byte Coded Graphic Character Sets --
8885 Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
8886 Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
8887 Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
8888 Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
8889 Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
8890 Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
8891 Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
8892 Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
8893 Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
8895 [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
8898 [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
8899 1900, February 1996.
8901 [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
8906Fielding, et al. Standards Track [Page 159]
8908RFC 2616 HTTP/1.1 June 1999
8911 [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
8912 Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
8913 Dec. 1995. Slightly revised version of paper in Proc. 2nd
8914 International WWW Conference '94: Mosaic and the Web, Oct. 1994,
8915 which is available at
8916 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
8919 [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
8920 Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
8921 ISI Research Report ISI/RR-98-463, (original report dated Aug.
8922 1996), USC/Information Sciences Institute, August 1998.
8924 [28] Mills, D., "Network Time Protocol (Version 3) Specification,
8925 Implementation and Analysis", RFC 1305, March 1992.
8927 [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
8928 version 1.3", RFC 1951, May 1996.
8930 [30] S. Spero, "Analysis of HTTP Performance Problems,"
8931 http://sunsite.unc.edu/mdma-release/http-prob.html.
8933 [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
8934 Specification version 3.3", RFC 1950, May 1996.
8936 [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
8937 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
8938 Digest Access Authentication", RFC 2069, January 1997.
8940 [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
8941 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
8944 [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
8945 Levels", BCP 14, RFC 2119, March 1997.
8947 [35] Troost, R. and Dorner, S., "Communicating Presentation
8948 Information in Internet Messages: The Content-Disposition
8949 Header", RFC 1806, June 1995.
8951 [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
8952 Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
8955 [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
8962Fielding, et al. Standards Track [Page 160]
8964RFC 2616 HTTP/1.1 June 1999
8967 [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
8968 ISO-10646", RFC 2279, January 1998. [jg641]
8970 [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
8971 Lie, H., and C. Lilley. "Network Performance Effects of
8972 HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
8973 France, September 1997.[jg642]
8975 [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
8976 Extensions (MIME) Part Two: Media Types", RFC 2046, November
8979 [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
8980 BCP 18, RFC 2277, January 1998. [jg644]
8982 [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
8983 Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
8984 August 1998. [jg645]
8986 [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
8987 Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
8988 Authentication: Basic and Digest Access Authentication", RFC
8989 2617, June 1999. [jg646]
8991 [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
8992 servers," Work in Progress. [jg647]
8994 [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
8995 Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
8998 [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
8999 9, RFC 2026, October 1996.
9001 [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
9002 (HTCPCP/1.0)", RFC 2324, 1 April 1998.
9004 [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
9005 Extensions (MIME) Part Five: Conformance Criteria and Examples",
9006 RFC 2049, November 1996.
9008 [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
9009 Information in Internet Messages: The Content-Disposition Header
9010 Field", RFC 2183, August 1997.
9018Fielding, et al. Standards Track [Page 161]
9020RFC 2616 HTTP/1.1 June 1999
902318 Authors' Addresses
9026 Information and Computer Science
9027 University of California, Irvine
9028 Irvine, CA 92697-3425, USA
9030 Fax: +1 (949) 824-1715
9031 EMail: fielding@ics.uci.edu
9035 World Wide Web Consortium
9036 MIT Laboratory for Computer Science
9037 545 Technology Square
9038 Cambridge, MA 02139, USA
9040 Fax: +1 (617) 258 8682
9045 Western Research Laboratory
9046 Compaq Computer Corporation
9047 250 University Avenue
9048 Palo Alto, California, 94305, USA
9050 EMail: mogul@wrl.dec.com
9053 Henrik Frystyk Nielsen
9054 World Wide Web Consortium
9055 MIT Laboratory for Computer Science
9056 545 Technology Square
9057 Cambridge, MA 02139, USA
9059 Fax: +1 (617) 258 8682
9060 EMail: frystyk@w3.org
9065 3333 Coyote Hill Road
9066 Palo Alto, CA 94034, USA
9068 EMail: masinter@parc.xerox.com
9074Fielding, et al. Standards Track [Page 162]
9076RFC 2616 HTTP/1.1 June 1999
9080 Microsoft Corporation
9082 Redmond, WA 98052, USA
9084 EMail: paulle@microsoft.com
9088 Director, World Wide Web Consortium
9089 MIT Laboratory for Computer Science
9090 545 Technology Square
9091 Cambridge, MA 02139, USA
9093 Fax: +1 (617) 258 8682
9130Fielding, et al. Standards Track [Page 163]
9132RFC 2616 HTTP/1.1 June 1999
913719.1 Internet Media Type message/http and application/http
9139 In addition to defining the HTTP/1.1 protocol, this document serves
9140 as the specification for the Internet media type "message/http" and
9141 "application/http". The message/http type can be used to enclose a
9142 single HTTP request or response message, provided that it obeys the
9143 MIME restrictions for all "message" types regarding line length and
9144 encodings. The application/http type can be used to enclose a
9145 pipeline of one or more HTTP request or response messages (not
9146 intermixed). The following is to be registered with IANA [17].
9148 Media Type name: message
9149 Media subtype name: http
9150 Required parameters: none
9151 Optional parameters: version, msgtype
9152 version: The HTTP-Version number of the enclosed message
9153 (e.g., "1.1"). If not present, the version can be
9154 determined from the first line of the body.
9155 msgtype: The message type -- "request" or "response". If not
9156 present, the type can be determined from the first
9158 Encoding considerations: only "7bit", "8bit", or "binary" are
9160 Security considerations: none
9162 Media Type name: application
9163 Media subtype name: http
9164 Required parameters: none
9165 Optional parameters: version, msgtype
9166 version: The HTTP-Version number of the enclosed messages
9167 (e.g., "1.1"). If not present, the version can be
9168 determined from the first line of the body.
9169 msgtype: The message type -- "request" or "response". If not
9170 present, the type can be determined from the first
9172 Encoding considerations: HTTP messages enclosed by this type
9173 are in "binary" format; use of an appropriate
9174 Content-Transfer-Encoding is required when
9175 transmitted via E-mail.
9176 Security considerations: none
9186Fielding, et al. Standards Track [Page 164]
9188RFC 2616 HTTP/1.1 June 1999
919119.2 Internet Media Type multipart/byteranges
9193 When an HTTP 206 (Partial Content) response message includes the
9194 content of multiple ranges (a response to a request for multiple
9195 non-overlapping ranges), these are transmitted as a multipart
9196 message-body. The media type for this purpose is called
9197 "multipart/byteranges".
9199 The multipart/byteranges media type includes two or more parts, each
9200 with its own Content-Type and Content-Range fields. The required
9201 boundary parameter specifies the boundary string used to separate
9204 Media Type name: multipart
9205 Media subtype name: byteranges
9206 Required parameters: boundary
9207 Optional parameters: none
9208 Encoding considerations: only "7bit", "8bit", or "binary" are
9210 Security considerations: none
9215 HTTP/1.1 206 Partial Content
9216 Date: Wed, 15 Nov 1995 06:25:24 GMT
9217 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
9218 Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
9220 --THIS_STRING_SEPARATES
9221 Content-type: application/pdf
9222 Content-range: bytes 500-999/8000
9224 ...the first range...
9225 --THIS_STRING_SEPARATES
9226 Content-type: application/pdf
9227 Content-range: bytes 7000-7999/8000
9230 --THIS_STRING_SEPARATES--
9234 1) Additional CRLFs may precede the first boundary string in the
9242Fielding, et al. Standards Track [Page 165]
9244RFC 2616 HTTP/1.1 June 1999
9247 2) Although RFC 2046 [40] permits the boundary string to be
9248 quoted, some existing implementations handle a quoted boundary
9251 3) A number of browsers and servers were coded to an early draft
9252 of the byteranges specification to use a media type of
9253 multipart/x-byteranges, which is almost, but not quite
9254 compatible with the version documented in HTTP/1.1.
925619.3 Tolerant Applications
9258 Although this document specifies the requirements for the generation
9259 of HTTP/1.1 messages, not all applications will be correct in their
9260 implementation. We therefore recommend that operational applications
9261 be tolerant of deviations whenever those deviations can be
9262 interpreted unambiguously.
9264 Clients SHOULD be tolerant in parsing the Status-Line and servers
9265 tolerant when parsing the Request-Line. In particular, they SHOULD
9266 accept any amount of SP or HT characters between fields, even though
9267 only a single SP is required.
9269 The line terminator for message-header fields is the sequence CRLF.
9270 However, we recommend that applications, when parsing such headers,
9271 recognize a single LF as a line terminator and ignore the leading CR.
9273 The character set of an entity-body SHOULD be labeled as the lowest
9274 common denominator of the character codes used within that body, with
9275 the exception that not labeling the entity is preferred over labeling
9276 the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
9279 Additional rules for requirements on parsing and encoding of dates
9280 and other potential problems with date encodings include:
9282 - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
9283 which appears to be more than 50 years in the future is in fact
9284 in the past (this helps solve the "year 2000" problem).
9286 - An HTTP/1.1 implementation MAY internally represent a parsed
9287 Expires date as earlier than the proper value, but MUST NOT
9288 internally represent a parsed Expires date as later than the
9291 - All expiration-related calculations MUST be done in GMT. The
9292 local time zone MUST NOT influence the calculation or comparison
9293 of an age or expiration time.
9298Fielding, et al. Standards Track [Page 166]
9300RFC 2616 HTTP/1.1 June 1999
9303 - If an HTTP header incorrectly carries a date value with a time
9304 zone other than GMT, it MUST be converted into GMT using the
9305 most conservative possible conversion.
930719.4 Differences Between HTTP Entities and RFC 2045 Entities
9309 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
9310 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
9311 allow entities to be transmitted in an open variety of
9312 representations and with extensible mechanisms. However, RFC 2045
9313 discusses mail, and HTTP has a few features that are different from
9314 those described in RFC 2045. These differences were carefully chosen
9315 to optimize performance over binary connections, to allow greater
9316 freedom in the use of new media types, to make date comparisons
9317 easier, and to acknowledge the practice of some early HTTP servers
9320 This appendix describes specific areas where HTTP differs from RFC
9321 2045. Proxies and gateways to strict MIME environments SHOULD be
9322 aware of these differences and provide the appropriate conversions
9323 where necessary. Proxies and gateways from MIME environments to HTTP
9324 also need to be aware of the differences because some conversions
9329 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
9330 include a single MIME-Version general-header field to indicate what
9331 version of the MIME protocol was used to construct the message. Use
9332 of the MIME-Version header field indicates that the message is in
9333 full compliance with the MIME protocol (as defined in RFC 2045[7]).
9334 Proxies/gateways are responsible for ensuring full compliance (where
9335 possible) when exporting HTTP messages to strict MIME environments.
9337 MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
9339 MIME version "1.0" is the default for use in HTTP/1.1. However,
9340 HTTP/1.1 message parsing and semantics are defined by this document
9341 and not the MIME specification.
934319.4.2 Conversion to Canonical Form
9345 RFC 2045 [7] requires that an Internet mail entity be converted to
9346 canonical form prior to being transferred, as described in section 4
9347 of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
9348 allowed for subtypes of the "text" media type when transmitted over
9349 HTTP. RFC 2046 requires that content with a type of "text" represent
9350 line breaks as CRLF and forbids the use of CR or LF outside of line
9354Fielding, et al. Standards Track [Page 167]
9356RFC 2616 HTTP/1.1 June 1999
9359 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
9360 line break within text content when a message is transmitted over
9363 Where it is possible, a proxy or gateway from HTTP to a strict MIME
9364 environment SHOULD translate all line breaks within the text media
9365 types described in section 3.7.1 of this document to the RFC 2049
9366 canonical form of CRLF. Note, however, that this might be complicated
9367 by the presence of a Content-Encoding and by the fact that HTTP
9368 allows the use of some character sets which do not use octets 13 and
9369 10 to represent CR and LF, as is the case for some multi-byte
9372 Implementors should note that conversion will break any cryptographic
9373 checksums applied to the original content unless the original content
9374 is already in canonical form. Therefore, the canonical form is
9375 recommended for any content that uses such checksums in HTTP.
937719.4.3 Conversion of Date Formats
9379 HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
9380 simplify the process of date comparison. Proxies and gateways from
9381 other protocols SHOULD ensure that any Date header field present in a
9382 message conforms to one of the HTTP/1.1 formats and rewrite the date
938519.4.4 Introduction of Content-Encoding
9387 RFC 2045 does not include any concept equivalent to HTTP/1.1's
9388 Content-Encoding header field. Since this acts as a modifier on the
9389 media type, proxies and gateways from HTTP to MIME-compliant
9390 protocols MUST either change the value of the Content-Type header
9391 field or decode the entity-body before forwarding the message. (Some
9392 experimental applications of Content-Type for Internet mail have used
9393 a media-type parameter of ";conversions=<content-coding>" to perform
9394 a function equivalent to Content-Encoding. However, this parameter is
9395 not part of RFC 2045.)
939719.4.5 No Content-Transfer-Encoding
9399 HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
9400 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
9401 remove any non-identity CTE ("quoted-printable" or "base64") encoding
9402 prior to delivering the response message to an HTTP client.
9404 Proxies and gateways from HTTP to MIME-compliant protocols are
9405 responsible for ensuring that the message is in the correct format
9406 and encoding for safe transport on that protocol, where "safe
9410Fielding, et al. Standards Track [Page 168]
9412RFC 2616 HTTP/1.1 June 1999
9415 transport" is defined by the limitations of the protocol being used.
9416 Such a proxy or gateway SHOULD label the data with an appropriate
9417 Content-Transfer-Encoding if doing so will improve the likelihood of
9418 safe transport over the destination protocol.
942019.4.6 Introduction of Transfer-Encoding
9422 HTTP/1.1 introduces the Transfer-Encoding header field (section
9423 14.41). Proxies/gateways MUST remove any transfer-coding prior to
9424 forwarding a message via a MIME-compliant protocol.
9426 A process for decoding the "chunked" transfer-coding (section 3.6)
9427 can be represented in pseudo-code as:
9430 read chunk-size, chunk-extension (if any) and CRLF
9431 while (chunk-size > 0) {
9432 read chunk-data and CRLF
9433 append chunk-data to entity-body
9434 length := length + chunk-size
9435 read chunk-size and CRLF
9438 while (entity-header not empty) {
9439 append entity-header to existing header fields
9442 Content-Length := length
9443 Remove "chunked" from Transfer-Encoding
944519.4.7 MHTML and Line Length Limitations
9447 HTTP implementations which share code with MHTML [45] implementations
9448 need to be aware of MIME line length limitations. Since HTTP does not
9449 have this limitation, HTTP does not fold long lines. MHTML messages
9450 being transported by HTTP follow all conventions of MHTML, including
9451 line length limitations and folding, canonicalization, etc., since
9452 HTTP transports all message-bodies as payload (see section 3.7.2) and
9453 does not interpret the content or any MIME header lines that might be
945619.5 Additional Features
9458 RFC 1945 and RFC 2068 document protocol elements used by some
9459 existing HTTP implementations, but not consistently and correctly
9460 across most HTTP/1.1 applications. Implementors are advised to be
9461 aware of these features, but cannot rely upon their presence in, or
9462 interoperability with, other HTTP/1.1 applications. Some of these
9466Fielding, et al. Standards Track [Page 169]
9468RFC 2616 HTTP/1.1 June 1999
9471 describe proposed experimental features, and some describe features
9472 that experimental deployment found lacking that are now addressed in
9473 the base HTTP/1.1 specification.
9475 A number of other headers, such as Content-Disposition and Title,
9476 from SMTP and MIME are also often implemented (see RFC 2076 [37]).
947819.5.1 Content-Disposition
9480 The Content-Disposition response-header field has been proposed as a
9481 means for the origin server to suggest a default filename if the user
9482 requests that the content is saved to a file. This usage is derived
9483 from the definition of Content-Disposition in RFC 1806 [35].
9485 content-disposition = "Content-Disposition" ":"
9486 disposition-type *( ";" disposition-parm )
9487 disposition-type = "attachment" | disp-extension-token
9488 disposition-parm = filename-parm | disp-extension-parm
9489 filename-parm = "filename" "=" quoted-string
9490 disp-extension-token = token
9491 disp-extension-parm = token "=" ( token | quoted-string )
9495 Content-Disposition: attachment; filename="fname.ext"
9497 The receiving user agent SHOULD NOT respect any directory path
9498 information present in the filename-parm parameter, which is the only
9499 parameter believed to apply to HTTP implementations at this time. The
9500 filename SHOULD be treated as a terminal component only.
9502 If this header is used in a response with the application/octet-
9503 stream content-type, the implied suggestion is that the user agent
9504 should not display the response, but directly enter a `save response
9507 See section 15.5 for Content-Disposition security issues.
950919.6 Compatibility with Previous Versions
9511 It is beyond the scope of a protocol specification to mandate
9512 compliance with previous versions. HTTP/1.1 was deliberately
9513 designed, however, to make supporting previous versions easy. It is
9514 worth noting that, at the time of composing this specification
9515 (1996), we would expect commercial HTTP/1.1 servers to:
9517 - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
9522Fielding, et al. Standards Track [Page 170]
9524RFC 2616 HTTP/1.1 June 1999
9527 - understand any valid request in the format of HTTP/0.9, 1.0, or
9530 - respond appropriately with a message in the same major version
9533 And we would expect HTTP/1.1 clients to:
9535 - recognize the format of the Status-Line for HTTP/1.0 and 1.1
9538 - understand any valid response in the format of HTTP/0.9, 1.0, or
9541 For most implementations of HTTP/1.0, each connection is established
9542 by the client prior to the request and closed by the server after
9543 sending the response. Some implementations implement the Keep-Alive
9544 version of persistent connections described in section 19.7.1 of RFC
954719.6.1 Changes from HTTP/1.0
9549 This section summarizes major differences between versions HTTP/1.0
955219.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
9555 The requirements that clients and servers support the Host request-
9556 header, report an error if the Host request-header (section 14.23) is
9557 missing from an HTTP/1.1 request, and accept absolute URIs (section
9558 5.1.2) are among the most important changes defined by this
9561 Older HTTP/1.0 clients assumed a one-to-one relationship of IP
9562 addresses and servers; there was no other established mechanism for
9563 distinguishing the intended server of a request than the IP address
9564 to which that request was directed. The changes outlined above will
9565 allow the Internet, once older HTTP clients are no longer common, to
9566 support multiple Web sites from a single IP address, greatly
9567 simplifying large operational Web servers, where allocation of many
9568 IP addresses to a single host has created serious problems. The
9569 Internet will also be able to recover the IP addresses that have been
9570 allocated for the sole purpose of allowing special-purpose domain
9571 names to be used in root-level HTTP URLs. Given the rate of growth of
9572 the Web, and the number of servers already deployed, it is extremely
9578Fielding, et al. Standards Track [Page 171]
9580RFC 2616 HTTP/1.1 June 1999
9583 important that all implementations of HTTP (including updates to
9584 existing HTTP/1.0 applications) correctly implement these
9587 - Both clients and servers MUST support the Host request-header.
9589 - A client that sends an HTTP/1.1 request MUST send a Host header.
9591 - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
9592 request does not include a Host request-header.
9594 - Servers MUST accept absolute URIs.
959619.6.2 Compatibility with HTTP/1.0 Persistent Connections
9598 Some clients and servers might wish to be compatible with some
9599 previous implementations of persistent connections in HTTP/1.0
9600 clients and servers. Persistent connections in HTTP/1.0 are
9601 explicitly negotiated as they are not the default behavior. HTTP/1.0
9602 experimental implementations of persistent connections are faulty,
9603 and the new facilities in HTTP/1.1 are designed to rectify these
9604 problems. The problem was that some existing 1.0 clients may be
9605 sending Keep-Alive to a proxy server that doesn't understand
9606 Connection, which would then erroneously forward it to the next
9607 inbound server, which would establish the Keep-Alive connection and
9608 result in a hung HTTP/1.0 proxy waiting for the close on the
9609 response. The result is that HTTP/1.0 clients must be prevented from
9610 using Keep-Alive when talking to proxies.
9612 However, talking to proxies is the most important use of persistent
9613 connections, so that prohibition is clearly unacceptable. Therefore,
9614 we need some other mechanism for indicating a persistent connection
9615 is desired, which is safe to use even when talking to an old proxy
9616 that ignores Connection. Persistent connections are the default for
9617 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
9618 declaring non-persistence. See section 14.10.
9620 The original HTTP/1.0 form of persistent connections (the Connection:
9621 Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
962319.6.3 Changes from RFC 2068
9625 This specification has been carefully audited to correct and
9626 disambiguate key word usage; RFC 2068 had many problems in respect to
9627 the conventions laid out in RFC 2119 [34].
9629 Clarified which error code should be used for inbound server failures
9630 (e.g. DNS failures). (Section 10.5.5).
9634Fielding, et al. Standards Track [Page 172]
9636RFC 2616 HTTP/1.1 June 1999
9639 CREATE had a race that required an Etag be sent when a resource is
9640 first created. (Section 10.2.2).
9642 Content-Base was deleted from the specification: it was not
9643 implemented widely, and there is no simple, safe way to introduce it
9644 without a robust extension mechanism. In addition, it is used in a
9645 similar, but not identical fashion in MHTML [45].
9647 Transfer-coding and message lengths all interact in ways that
9648 required fixing exactly when chunked encoding is used (to allow for
9649 transfer encoding that may not be self delimiting); it was important
9650 to straighten out exactly how message lengths are computed. (Sections
9651 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
9653 A content-coding of "identity" was introduced, to solve problems
9654 discovered in caching. (section 3.5)
9656 Quality Values of zero should indicate that "I don't want something"
9657 to allow clients to refuse a representation. (Section 3.9)
9659 The use and interpretation of HTTP version numbers has been clarified
9660 by RFC 2145. Require proxies to upgrade requests to highest protocol
9661 version they support to deal with problems discovered in HTTP/1.0
9662 implementations (Section 3.1)
9664 Charset wildcarding is introduced to avoid explosion of character set
9665 names in accept headers. (Section 14.2)
9667 A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
9668 was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
9671 The Cache-Control: max-age directive was not properly defined for
9672 responses. (Section 14.9.3)
9674 There are situations where a server (especially a proxy) does not
9675 know the full length of a response but is capable of serving a
9676 byterange request. We therefore need a mechanism to allow byteranges
9677 with a content-range not indicating the full length of the message.
9680 Range request responses would become very verbose if all meta-data
9681 were always returned; by allowing the server to only send needed
9682 headers in a 206 response, this problem can be avoided. (Section
9683 10.2.7, 13.5.3, and 14.27)
9690Fielding, et al. Standards Track [Page 173]
9692RFC 2616 HTTP/1.1 June 1999
9695 Fix problem with unsatisfiable range requests; there are two cases:
9696 syntactic problems, and range doesn't exist in the document. The 416
9697 status code was needed to resolve this ambiguity needed to indicate
9698 an error for a byte range request that falls outside of the actual
9699 contents of a document. (Section 10.4.17, 14.16)
9701 Rewrite of message transmission requirements to make it much harder
9702 for implementors to get it wrong, as the consequences of errors here
9703 can have significant impact on the Internet, and to deal with the
9706 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
9707 this was incorrectly placing a requirement on the behavior of
9708 an implementation of a future version of HTTP/1.x
9710 2. Made it clear that user-agents should retry requests, not
9711 "clients" in general.
9713 3. Converted requirements for clients to ignore unexpected 100
9714 (Continue) responses, and for proxies to forward 100 responses,
9715 into a general requirement for 1xx responses.
9717 4. Modified some TCP-specific language, to make it clearer that
9718 non-TCP transports are possible for HTTP.
9720 5. Require that the origin server MUST NOT wait for the request
9721 body before it sends a required 100 (Continue) response.
9723 6. Allow, rather than require, a server to omit 100 (Continue) if
9724 it has already seen some of the request body.
9726 7. Allow servers to defend against denial-of-service attacks and
9729 This change adds the Expect header and 417 status code. The message
9730 transmission requirements fixes are in sections 8.2, 10.4.18,
9731 8.1.2.2, 13.11, and 14.20.
9733 Proxies should be able to add Content-Length when appropriate.
9736 Clean up confusion between 403 and 404 responses. (Section 10.4.4,
9737 10.4.5, and 10.4.11)
9739 Warnings could be cached incorrectly, or not updated appropriately.
9740 (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
9741 also needed to be a general header, as PUT or other methods may have
9742 need for it in requests.
9746Fielding, et al. Standards Track [Page 174]
9748RFC 2616 HTTP/1.1 June 1999
9751 Transfer-coding had significant problems, particularly with
9752 interactions with chunked encoding. The solution is that transfer-
9753 codings become as full fledged as content-codings. This involves
9754 adding an IANA registry for transfer-codings (separate from content
9755 codings), a new header field (TE) and enabling trailer headers in the
9756 future. Transfer encoding is a major performance benefit, so it was
9757 worth fixing [39]. TE also solves another, obscure, downward
9758 interoperability problem that could have occurred due to interactions
9759 between authentication trailers, chunked encoding and HTTP/1.0
9760 clients.(Section 3.6, 3.6.1, and 14.39)
9762 The PATCH, LINK, UNLINK methods were defined but not commonly
9763 implemented in previous versions of this specification. See RFC 2068
9766 The Alternates, Content-Version, Derived-From, Link, URI, Public and
9767 Content-Base header fields were defined in previous versions of this
9768 specification, but not commonly implemented. See RFC 2068 [33].
9772 Please see the PostScript version of this RFC for the INDEX.
9802Fielding, et al. Standards Track [Page 175]
9804RFC 2616 HTTP/1.1 June 1999
980721. Full Copyright Statement
9809 Copyright (C) The Internet Society (1999). All Rights Reserved.
9811 This document and translations of it may be copied and furnished to
9812 others, and derivative works that comment on or otherwise explain it
9813 or assist in its implementation may be prepared, copied, published
9814 and distributed, in whole or in part, without restriction of any
9815 kind, provided that the above copyright notice and this paragraph are
9816 included on all such copies and derivative works. However, this
9817 document itself may not be modified in any way, such as by removing
9818 the copyright notice or references to the Internet Society or other
9819 Internet organizations, except as needed for the purpose of
9820 developing Internet standards in which case the procedures for
9821 copyrights defined in the Internet Standards process must be
9822 followed, or as required to translate it into languages other than
9825 The limited permissions granted above are perpetual and will not be
9826 revoked by the Internet Society or its successors or assigns.
9828 This document and the information contained herein is provided on an
9829 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
9830 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
9831 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
9832 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
9833 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9837 Funding for the RFC Editor function is currently provided by the
9858Fielding, et al. Standards Track [Page 176]