7 Network Working Group R. Fielding
8 Request for Comments: 2616 UC Irvine
9 Obsoletes: 2068 J. Gettys
10 Category: 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].
58 Fielding, et al. Standards Track [Page 1]
60 RFC 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
114 Fielding, et al. Standards Track [Page 2]
116 RFC 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
170 Fielding, et al. Standards Track [Page 3]
172 RFC 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
226 Fielding, et al. Standards Track [Page 4]
228 RFC 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
282 Fielding, et al. Standards Track [Page 5]
284 RFC 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
338 Fielding, et al. Standards Track [Page 6]
340 RFC 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
394 Fielding, et al. Standards Track [Page 7]
396 RFC 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.
450 Fielding, et al. Standards Track [Page 8]
452 RFC 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
506 Fielding, et al. Standards Track [Page 9]
508 RFC 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.
562 Fielding, et al. Standards Track [Page 10]
564 RFC 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.
618 Fielding, et al. Standards Track [Page 11]
620 RFC 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"
628 1.4 Overall Operation
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
674 Fielding, et al. Standards Track [Page 12]
676 RFC 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.
730 Fielding, et al. Standards Track [Page 13]
732 RFC 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).
740 2 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)".
786 Fielding, et al. Standards Track [Page 14]
788 RFC 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].
842 Fielding, et al. Standards Track [Page 15]
844 RFC 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
898 Fielding, et al. Standards Track [Page 16]
900 RFC 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
934 3 Protocol Parameters
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.
954 Fielding, et al. Standards Track [Page 17]
956 RFC 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.
999 3.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.
1010 Fielding, et al. Standards Track [Page 18]
1012 RFC 2616 HTTP/1.1 June 1999
1015 3.2.1 General Syntax
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
1066 Fielding, et al. Standards Track [Page 19]
1068 RFC 2616 HTTP/1.1 June 1999
1071 3.2.3 URI Comparison
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
1095 3.3 Date/Time Formats
1099 HTTP applications have historically allowed three different formats
1100 for the representation of date/time stamps:
1102 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
1103 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
1104 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1106 The first format is preferred as an Internet standard and represents
1107 a fixed-length subset of that defined by RFC 1123 [8] (an update to
1108 RFC 822 [9]). The second format is in common use, but is based on the
1109 obsolete RFC 850 [12] date format and lacks a four-digit year.
1110 HTTP/1.1 clients and servers that parse the date value MUST accept
1111 all three formats (for compatibility with HTTP/1.0), though they MUST
1112 only generate the RFC 1123 format for representing HTTP-date values
1113 in header fields. See section 19.3 for further information.
1115 Note: Recipients of date values are encouraged to be robust in
1116 accepting date values that may have been sent by non-HTTP
1117 applications, as is sometimes the case when retrieving or posting
1118 messages via proxies/gateways to SMTP or NNTP.
1122 Fielding, et al. Standards Track [Page 20]
1124 RFC 2616 HTTP/1.1 June 1999
1127 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1128 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1129 equal to UTC (Coordinated Universal Time). This is indicated in the
1130 first two formats by the inclusion of "GMT" as the three-letter
1131 abbreviation for time zone, and MUST be assumed when reading the
1132 asctime format. HTTP-date is case sensitive and MUST NOT include
1133 additional LWS beyond that specifically included as SP in the
1136 HTTP-date = rfc1123-date | rfc850-date | asctime-date
1137 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1138 rfc850-date = weekday "," SP date2 SP time SP "GMT"
1139 asctime-date = wkday SP date3 SP time SP 4DIGIT
1140 date1 = 2DIGIT SP month SP 4DIGIT
1141 ; day month year (e.g., 02 Jun 1982)
1142 date2 = 2DIGIT "-" month "-" 2DIGIT
1143 ; day-month-year (e.g., 02-Jun-82)
1144 date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
1145 ; month day (e.g., Jun 2)
1146 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1147 ; 00:00:00 - 23:59:59
1148 wkday = "Mon" | "Tue" | "Wed"
1149 | "Thu" | "Fri" | "Sat" | "Sun"
1150 weekday = "Monday" | "Tuesday" | "Wednesday"
1151 | "Thursday" | "Friday" | "Saturday" | "Sunday"
1152 month = "Jan" | "Feb" | "Mar" | "Apr"
1153 | "May" | "Jun" | "Jul" | "Aug"
1154 | "Sep" | "Oct" | "Nov" | "Dec"
1156 Note: HTTP requirements for the date/time stamp format apply only
1157 to their usage within the protocol stream. Clients and servers are
1158 not required to use these formats for user presentation, request
1163 Some HTTP header fields allow a time value to be specified as an
1164 integer number of seconds, represented in decimal, after the time
1165 that the message was received.
1167 delta-seconds = 1*DIGIT
1171 HTTP uses the same definition of the term "character set" as that
1178 Fielding, et al. Standards Track [Page 21]
1180 RFC 2616 HTTP/1.1 June 1999
1183 The term "character set" is used in this document to refer to a
1184 method used with one or more tables to convert a sequence of octets
1185 into a sequence of characters. Note that unconditional conversion in
1186 the other direction is not required, in that not all characters may
1187 be available in a given character set and a character set may provide
1188 more than one sequence of octets to represent a particular character.
1189 This definition is intended to allow various kinds of character
1190 encoding, from simple single-table mappings such as US-ASCII to
1191 complex table switching methods such as those that use ISO-2022's
1192 techniques. However, the definition associated with a MIME character
1193 set name MUST fully specify the mapping to be performed from octets
1194 to characters. In particular, use of external profiling information
1195 to determine the exact mapping is not permitted.
1197 Note: This use of the term "character set" is more commonly
1198 referred to as a "character encoding." However, since HTTP and
1199 MIME share the same registry, it is important that the terminology
1202 HTTP character sets are identified by case-insensitive tokens. The
1203 complete set of tokens is defined by the IANA Character Set registry
1208 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]
1217 3.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
1234 Fielding, et al. Standards Track [Page 22]
1236 RFC 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].
1290 Fielding, et al. Standards Track [Page 23]
1292 RFC 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.
1307 3.6 Transfer Codings
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.
1346 Fielding, et al. Standards Track [Page 24]
1348 RFC 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
1365 3.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
1402 Fielding, et al. Standards Track [Page 25]
1404 RFC 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.
1458 Fielding, et al. Standards Track [Page 26]
1460 RFC 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
1473 3.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.
1506 3.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
1514 Fielding, et al. Standards Track [Page 27]
1516 RFC 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
1570 Fielding, et al. Standards Track [Page 28]
1572 RFC 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
1626 Fielding, et al. Standards Track [Page 29]
1628 RFC 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.
1682 Fielding, et al. Standards Track [Page 30]
1684 RFC 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
1738 Fielding, et al. Standards Track [Page 31]
1740 RFC 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
1794 Fielding, et al. Standards Track [Page 32]
1796 RFC 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
1850 Fielding, et al. Standards Track [Page 33]
1852 RFC 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.
1898 4.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
1906 Fielding, et al. Standards Track [Page 34]
1908 RFC 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
1962 Fielding, et al. Standards Track [Page 35]
1964 RFC 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
2018 Fielding, et al. Standards Track [Page 36]
2020 RFC 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.
2074 Fielding, et al. Standards Track [Page 37]
2076 RFC 2616 HTTP/1.1 June 1999
2079 5.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.
2110 5.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
2130 Fielding, et al. Standards Track [Page 38]
2132 RFC 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
2174 6.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-
2186 Fielding, et al. Standards Track [Page 39]
2188 RFC 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
2242 Fielding, et al. Standards Track [Page 40]
2244 RFC 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.
2283 6.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
2298 Fielding, et al. Standards Track [Page 41]
2300 RFC 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.
2325 7.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.
2354 Fielding, et al. Standards Track [Page 42]
2356 RFC 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.
2410 Fielding, et al. Standards Track [Page 43]
2412 RFC 2616 HTTP/1.1 June 1999
2417 8.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.
2466 Fielding, et al. Standards Track [Page 44]
2468 RFC 2616 HTTP/1.1 June 1999
2471 8.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.
2522 Fielding, et al. Standards Track [Page 45]
2524 RFC 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).
2565 8.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.
2578 Fielding, et al. Standards Track [Page 46]
2580 RFC 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.
2621 8.2 Message Transmission Requirements
2623 8.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.
2634 Fielding, et al. Standards Track [Page 47]
2636 RFC 2616 HTTP/1.1 June 1999
2639 8.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.
2650 8.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
2690 Fielding, et al. Standards Track [Page 48]
2692 RFC 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
2746 Fielding, et al. Standards Track [Page 49]
2748 RFC 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).
2764 8.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.
2802 Fielding, et al. Standards Track [Page 50]
2804 RFC 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
2814 9 Method Definitions
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
2823 9.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.
2845 9.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.
2858 Fielding, et al. Standards Track [Page 51]
2860 RFC 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
2914 Fielding, et al. Standards Track [Page 52]
2916 RFC 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.
2970 Fielding, et al. Standards Track [Page 53]
2972 RFC 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.
3026 Fielding, et al. Standards Track [Page 54]
3028 RFC 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,
3082 Fielding, et al. Standards Track [Page 55]
3084 RFC 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
3138 Fielding, et al. Standards Track [Page 56]
3140 RFC 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
3165 10 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
3171 10.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
3194 Fielding, et al. Standards Track [Page 57]
3196 RFC 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
3214 10.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;
3250 Fielding, et al. Standards Track [Page 58]
3252 RFC 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.
3293 10.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).
3306 Fielding, et al. Standards Track [Page 59]
3308 RFC 2616 HTTP/1.1 June 1999
3311 10.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
projects / thirdparty / cups.git / blob