7Internet Engineering Task Force (IETF) R. Fielding, Ed.
8Request for Comments: 7230 Adobe
9Obsoletes: 2145, 2616 J. Reschke, Ed.
10Updates: 2817, 2818 greenbytes
11Category: Standards Track June 2014
15 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
19 The Hypertext Transfer Protocol (HTTP) is a stateless application-
20 level protocol for distributed, collaborative, hypertext information
21 systems. This document provides an overview of HTTP architecture and
22 its associated terminology, defines the "http" and "https" Uniform
23 Resource Identifier (URI) schemes, defines the HTTP/1.1 message
24 syntax and parsing requirements, and describes related security
25 concerns for implementations.
29 This is an Internet Standards Track document.
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 Internet Standards is available in Section 2 of RFC 5741.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc7230.
58Fielding & Reschke Standards Track [Page 1]
60RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
65 Copyright (c) 2014 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
92 1. Introduction ....................................................5
93 1.1. Requirements Notation ......................................6
94 1.2. Syntax Notation ............................................6
95 2. Architecture ....................................................6
96 2.1. Client/Server Messaging ....................................7
97 2.2. Implementation Diversity ...................................8
98 2.3. Intermediaries .............................................9
99 2.4. Caches ....................................................11
100 2.5. Conformance and Error Handling ............................12
101 2.6. Protocol Versioning .......................................13
102 2.7. Uniform Resource Identifiers ..............................16
103 2.7.1. http URI Scheme ....................................17
104 2.7.2. https URI Scheme ...................................18
105 2.7.3. http and https URI Normalization and Comparison ....19
106 3. Message Format .................................................19
107 3.1. Start Line ................................................20
108 3.1.1. Request Line .......................................21
109 3.1.2. Status Line ........................................22
110 3.2. Header Fields .............................................22
114Fielding & Reschke Standards Track [Page 2]
116RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
119 3.2.1. Field Extensibility ................................23
120 3.2.2. Field Order ........................................23
121 3.2.3. Whitespace .........................................24
122 3.2.4. Field Parsing ......................................25
123 3.2.5. Field Limits .......................................26
124 3.2.6. Field Value Components .............................27
125 3.3. Message Body ..............................................28
126 3.3.1. Transfer-Encoding ..................................28
127 3.3.2. Content-Length .....................................30
128 3.3.3. Message Body Length ................................32
129 3.4. Handling Incomplete Messages ..............................34
130 3.5. Message Parsing Robustness ................................34
131 4. Transfer Codings ...............................................35
132 4.1. Chunked Transfer Coding ...................................36
133 4.1.1. Chunk Extensions ...................................36
134 4.1.2. Chunked Trailer Part ...............................37
135 4.1.3. Decoding Chunked ...................................38
136 4.2. Compression Codings .......................................38
137 4.2.1. Compress Coding ....................................38
138 4.2.2. Deflate Coding .....................................38
139 4.2.3. Gzip Coding ........................................39
140 4.3. TE ........................................................39
141 4.4. Trailer ...................................................40
142 5. Message Routing ................................................40
143 5.1. Identifying a Target Resource .............................40
144 5.2. Connecting Inbound ........................................41
145 5.3. Request Target ............................................41
146 5.3.1. origin-form ........................................42
147 5.3.2. absolute-form ......................................42
148 5.3.3. authority-form .....................................43
149 5.3.4. asterisk-form ......................................43
150 5.4. Host ......................................................44
151 5.5. Effective Request URI .....................................45
152 5.6. Associating a Response to a Request .......................46
153 5.7. Message Forwarding ........................................47
154 5.7.1. Via ................................................47
155 5.7.2. Transformations ....................................49
156 6. Connection Management ..........................................50
157 6.1. Connection ................................................51
158 6.2. Establishment .............................................52
159 6.3. Persistence ...............................................52
160 6.3.1. Retrying Requests ..................................53
161 6.3.2. Pipelining .........................................54
162 6.4. Concurrency ...............................................55
163 6.5. Failures and Timeouts .....................................55
164 6.6. Tear-down .................................................56
165 6.7. Upgrade ...................................................57
166 7. ABNF List Extension: #rule .....................................59
170Fielding & Reschke Standards Track [Page 3]
172RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
175 8. IANA Considerations ............................................61
176 8.1. Header Field Registration .................................61
177 8.2. URI Scheme Registration ...................................62
178 8.3. Internet Media Type Registration ..........................62
179 8.3.1. Internet Media Type message/http ...................62
180 8.3.2. Internet Media Type application/http ...............63
181 8.4. Transfer Coding Registry ..................................64
182 8.4.1. Procedure ..........................................65
183 8.4.2. Registration .......................................65
184 8.5. Content Coding Registration ...............................66
185 8.6. Upgrade Token Registry ....................................66
186 8.6.1. Procedure ..........................................66
187 8.6.2. Upgrade Token Registration .........................67
188 9. Security Considerations ........................................67
189 9.1. Establishing Authority ....................................67
190 9.2. Risks of Intermediaries ...................................68
191 9.3. Attacks via Protocol Element Length .......................69
192 9.4. Response Splitting ........................................69
193 9.5. Request Smuggling .........................................70
194 9.6. Message Integrity .........................................70
195 9.7. Message Confidentiality ...................................71
196 9.8. Privacy of Server Log Information .........................71
197 10. Acknowledgments ...............................................72
198 11. References ....................................................74
199 11.1. Normative References .....................................74
200 11.2. Informative References ...................................75
201 Appendix A. HTTP Version History ..................................78
202 A.1. Changes from HTTP/1.0 ....................................78
203 A.1.1. Multihomed Web Servers ............................78
204 A.1.2. Keep-Alive Connections ............................79
205 A.1.3. Introduction of Transfer-Encoding .................79
206 A.2. Changes from RFC 2616 ....................................80
207 Appendix B. Collected ABNF ........................................82
208 Index .............................................................85
226Fielding & Reschke Standards Track [Page 4]
228RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
233 The Hypertext Transfer Protocol (HTTP) is a stateless application-
234 level request/response protocol that uses extensible semantics and
235 self-descriptive message payloads for flexible interaction with
236 network-based hypertext information systems. This document is the
237 first in a series of documents that collectively form the HTTP/1.1
240 1. "Message Syntax and Routing" (this document)
242 2. "Semantics and Content" [RFC7231]
244 3. "Conditional Requests" [RFC7232]
246 4. "Range Requests" [RFC7233]
248 5. "Caching" [RFC7234]
250 6. "Authentication" [RFC7235]
252 This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
253 versioning). This specification also updates the use of CONNECT to
254 establish a tunnel, previously defined in RFC 2817, and defines the
255 "https" URI scheme that was described informally in RFC 2818.
257 HTTP is a generic interface protocol for information systems. It is
258 designed to hide the details of how a service is implemented by
259 presenting a uniform interface to clients that is independent of the
260 types of resources provided. Likewise, servers do not need to be
261 aware of each client's purpose: an HTTP request can be considered in
262 isolation rather than being associated with a specific type of client
263 or a predetermined sequence of application steps. The result is a
264 protocol that can be used effectively in many different contexts and
265 for which implementations can evolve independently over time.
267 HTTP is also designed for use as an intermediation protocol for
268 translating communication to and from non-HTTP information systems.
269 HTTP proxies and gateways can provide access to alternative
270 information services by translating their diverse protocols into a
271 hypertext format that can be viewed and manipulated by clients in the
272 same way as HTTP services.
274 One consequence of this flexibility is that the protocol cannot be
275 defined in terms of what occurs behind the interface. Instead, we
276 are limited to defining the syntax of communication, the intent of
277 received communication, and the expected behavior of recipients. If
278 the communication is considered in isolation, then successful actions
282Fielding & Reschke Standards Track [Page 5]
284RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
287 ought to be reflected in corresponding changes to the observable
288 interface provided by servers. However, since multiple clients might
289 act in parallel and perhaps at cross-purposes, we cannot require that
290 such changes be observable beyond the scope of a single response.
292 This document describes the architectural elements that are used or
293 referred to in HTTP, defines the "http" and "https" URI schemes,
294 describes overall network operation and connection management, and
295 defines HTTP message framing and forwarding requirements. Our goal
296 is to define all of the mechanisms necessary for HTTP message
297 handling that are independent of message semantics, thereby defining
298 the complete set of requirements for message parsers and message-
299 forwarding intermediaries.
3011.1. Requirements Notation
303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
304 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
305 document are to be interpreted as described in [RFC2119].
307 Conformance criteria and considerations regarding error handling are
308 defined in Section 2.5.
312 This specification uses the Augmented Backus-Naur Form (ABNF)
313 notation of [RFC5234] with a list extension, defined in Section 7,
314 that allows for compact definition of comma-separated lists using a
315 '#' operator (similar to how the '*' operator indicates repetition).
316 Appendix B shows the collected grammar with all list operators
317 expanded to standard ABNF notation.
319 The following core rules are included by reference, as defined in
320 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
321 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
322 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
323 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
324 visible [USASCII] character).
326 As a convention, ABNF rule names prefixed with "obs-" denote
327 "obsolete" grammar rules that appear for historical reasons.
331 HTTP was created for the World Wide Web (WWW) architecture and has
332 evolved over time to support the scalability needs of a worldwide
333 hypertext system. Much of that architecture is reflected in the
334 terminology and syntax productions used to define HTTP.
338Fielding & Reschke Standards Track [Page 6]
340RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3432.1. Client/Server Messaging
345 HTTP is a stateless request/response protocol that operates by
346 exchanging messages (Section 3) across a reliable transport- or
347 session-layer "connection" (Section 6). An HTTP "client" is a
348 program that establishes a connection to a server for the purpose of
349 sending one or more HTTP requests. An HTTP "server" is a program
350 that accepts connections in order to service HTTP requests by sending
353 The terms "client" and "server" refer only to the roles that these
354 programs perform for a particular connection. The same program might
355 act as a client on some connections and a server on others. The term
356 "user agent" refers to any of the various client programs that
357 initiate a request, including (but not limited to) browsers, spiders
358 (web-based robots), command-line tools, custom applications, and
359 mobile apps. The term "origin server" refers to the program that can
360 originate authoritative responses for a given target resource. The
361 terms "sender" and "recipient" refer to any implementation that sends
362 or receives a given message, respectively.
364 HTTP relies upon the Uniform Resource Identifier (URI) standard
365 [RFC3986] to indicate the target resource (Section 5.1) and
366 relationships between resources. Messages are passed in a format
367 similar to that used by Internet mail [RFC5322] and the Multipurpose
368 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of
369 [RFC7231] for the differences between HTTP and MIME messages).
371 Most HTTP communication consists of a retrieval request (GET) for a
372 representation of some resource identified by a URI. In the simplest
373 case, this might be accomplished via a single bidirectional
374 connection (===) between the user agent (UA) and the origin
378 UA ======================================= O
381 A client sends an HTTP request to a server in the form of a request
382 message, beginning with a request-line that includes a method, URI,
383 and protocol version (Section 3.1.1), followed by header fields
384 containing request modifiers, client information, and representation
385 metadata (Section 3.2), an empty line to indicate the end of the
386 header section, and finally a message body containing the payload
387 body (if any, Section 3.3).
394Fielding & Reschke Standards Track [Page 7]
396RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
399 A server responds to a client's request by sending one or more HTTP
400 response messages, each beginning with a status line that includes
401 the protocol version, a success or error code, and textual reason
402 phrase (Section 3.1.2), possibly followed by header fields containing
403 server information, resource metadata, and representation metadata
404 (Section 3.2), an empty line to indicate the end of the header
405 section, and finally a message body containing the payload body (if
408 A connection might be used for multiple request/response exchanges,
409 as defined in Section 6.3.
411 The following example illustrates a typical message exchange for a
412 GET request (Section 4.3.1 of [RFC7231]) on the URI
413 "http://www.example.com/hello.txt":
417 GET /hello.txt HTTP/1.1
418 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
419 Host: www.example.com
420 Accept-Language: en, mi
426 Date: Mon, 27 Jul 2009 12:28:53 GMT
428 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
429 ETag: "34aa387-d-1568eb00"
432 Vary: Accept-Encoding
433 Content-Type: text/plain
435 Hello World! My payload includes a trailing CRLF.
4372.2. Implementation Diversity
439 When considering the design of HTTP, it is easy to fall into a trap
440 of thinking that all user agents are general-purpose browsers and all
441 origin servers are large public websites. That is not the case in
442 practice. Common HTTP user agents include household appliances,
443 stereos, scales, firmware update scripts, command-line programs,
444 mobile apps, and communication devices in a multitude of shapes and
445 sizes. Likewise, common HTTP origin servers include home automation
450Fielding & Reschke Standards Track [Page 8]
452RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
455 units, configurable networking components, office machines,
456 autonomous robots, news feeds, traffic cameras, ad selectors, and
457 video-delivery platforms.
459 The term "user agent" does not imply that there is a human user
460 directly interacting with the software agent at the time of a
461 request. In many cases, a user agent is installed or configured to
462 run in the background and save its results for later inspection (or
463 save only a subset of those results that might be interesting or
464 erroneous). Spiders, for example, are typically given a start URI
465 and configured to follow certain behavior while crawling the Web as a
468 The implementation diversity of HTTP means that not all user agents
469 can make interactive suggestions to their user or provide adequate
470 warning for security or privacy concerns. In the few cases where
471 this specification requires reporting of errors to the user, it is
472 acceptable for such reporting to only be observable in an error
473 console or log file. Likewise, requirements that an automated action
474 be confirmed by the user before proceeding might be met via advance
475 configuration choices, run-time options, or simple avoidance of the
476 unsafe action; confirmation does not imply any specific user
477 interface or interruption of normal processing if the user has
478 already made that choice.
482 HTTP enables the use of intermediaries to satisfy requests through a
483 chain of connections. There are three common forms of HTTP
484 intermediary: proxy, gateway, and tunnel. In some cases, a single
485 intermediary might act as an origin server, proxy, gateway, or
486 tunnel, switching behavior based on the nature of each request.
489 UA =========== A =========== B =========== C =========== O
492 The figure above shows three intermediaries (A, B, and C) between the
493 user agent and origin server. A request or response message that
494 travels the whole chain will pass through four separate connections.
495 Some HTTP communication options might apply only to the connection
496 with the nearest, non-tunnel neighbor, only to the endpoints of the
497 chain, or to all connections along the chain. Although the diagram
498 is linear, each participant might be engaged in multiple,
499 simultaneous communications. For example, B might be receiving
500 requests from many clients other than A, and/or forwarding requests
501 to servers other than C, at the same time that it is handling A's
506Fielding & Reschke Standards Track [Page 9]
508RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
511 request. Likewise, later requests might be sent through a different
512 path of connections, often based on dynamic configuration for load
515 The terms "upstream" and "downstream" are used to describe
516 directional requirements in relation to the message flow: all
517 messages flow from upstream to downstream. The terms "inbound" and
518 "outbound" are used to describe directional requirements in relation
519 to the request route: "inbound" means toward the origin server and
520 "outbound" means toward the user agent.
522 A "proxy" is a message-forwarding agent that is selected by the
523 client, usually via local configuration rules, to receive requests
524 for some type(s) of absolute URI and attempt to satisfy those
525 requests via translation through the HTTP interface. Some
526 translations are minimal, such as for proxy requests for "http" URIs,
527 whereas other requests might require translation to and from entirely
528 different application-level protocols. Proxies are often used to
529 group an organization's HTTP requests through a common intermediary
530 for the sake of security, annotation services, or shared caching.
531 Some proxies are designed to apply transformations to selected
532 messages or payloads while they are being forwarded, as described in
535 A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
536 an origin server for the outbound connection but translates received
537 requests and forwards them inbound to another server or servers.
538 Gateways are often used to encapsulate legacy or untrusted
539 information services, to improve server performance through
540 "accelerator" caching, and to enable partitioning or load balancing
541 of HTTP services across multiple machines.
543 All HTTP requirements applicable to an origin server also apply to
544 the outbound communication of a gateway. A gateway communicates with
545 inbound servers using any protocol that it desires, including private
546 extensions to HTTP that are outside the scope of this specification.
547 However, an HTTP-to-HTTP gateway that wishes to interoperate with
548 third-party HTTP servers ought to conform to user agent requirements
549 on the gateway's inbound connection.
551 A "tunnel" acts as a blind relay between two connections without
552 changing the messages. Once active, a tunnel is not considered a
553 party to the HTTP communication, though the tunnel might have been
554 initiated by an HTTP request. A tunnel ceases to exist when both
555 ends of the relayed connection are closed. Tunnels are used to
556 extend a virtual connection through an intermediary, such as when
557 Transport Layer Security (TLS, [RFC5246]) is used to establish
558 confidential communication through a shared firewall proxy.
562Fielding & Reschke Standards Track [Page 10]
564RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
567 The above categories for intermediary only consider those acting as
568 participants in the HTTP communication. There are also
569 intermediaries that can act on lower layers of the network protocol
570 stack, filtering or redirecting HTTP traffic without the knowledge or
571 permission of message senders. Network intermediaries are
572 indistinguishable (at a protocol level) from a man-in-the-middle
573 attack, often introducing security flaws or interoperability problems
574 due to mistakenly violating HTTP semantics.
576 For example, an "interception proxy" [RFC3040] (also commonly known
577 as a "transparent proxy" [RFC1919] or "captive portal") differs from
578 an HTTP proxy because it is not selected by the client. Instead, an
579 interception proxy filters or redirects outgoing TCP port 80 packets
580 (and occasionally other common port traffic). Interception proxies
581 are commonly found on public network access points, as a means of
582 enforcing account subscription prior to allowing use of non-local
583 Internet services, and within corporate firewalls to enforce network
586 HTTP is defined as a stateless protocol, meaning that each request
587 message can be understood in isolation. Many implementations depend
588 on HTTP's stateless design in order to reuse proxied connections or
589 dynamically load balance requests across multiple servers. Hence, a
590 server MUST NOT assume that two requests on the same connection are
591 from the same user agent unless the connection is secured and
592 specific to that agent. Some non-standard HTTP extensions (e.g.,
593 [RFC4559]) have been known to violate this requirement, resulting in
594 security and interoperability problems.
598 A "cache" is a local store of previous response messages and the
599 subsystem that controls its message storage, retrieval, and deletion.
600 A cache stores cacheable responses in order to reduce the response
601 time and network bandwidth consumption on future, equivalent
602 requests. Any client or server MAY employ a cache, though a cache
603 cannot be used by a server while it is acting as a tunnel.
605 The effect of a cache is that the request/response chain is shortened
606 if one of the participants along the chain has a cached response
607 applicable to that request. The following illustrates the resulting
608 chain if B has a cached copy of an earlier response from O (via C)
609 for a request that has not been cached by UA or A.
612 UA =========== A =========== B - - - - - - C - - - - - - O
618Fielding & Reschke Standards Track [Page 11]
620RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
623 A response is "cacheable" if a cache is allowed to store a copy of
624 the response message for use in answering subsequent requests. Even
625 when a response is cacheable, there might be additional constraints
626 placed by the client or by the origin server on when that cached
627 response can be used for a particular request. HTTP requirements for
628 cache behavior and cacheable responses are defined in Section 2 of
631 There is a wide variety of architectures and configurations of caches
632 deployed across the World Wide Web and inside large organizations.
633 These include national hierarchies of proxy caches to save
634 transoceanic bandwidth, collaborative systems that broadcast or
635 multicast cache entries, archives of pre-fetched cache entries for
636 use in off-line or high-latency environments, and so on.
6382.5. Conformance and Error Handling
640 This specification targets conformance criteria according to the role
641 of a participant in HTTP communication. Hence, HTTP requirements are
642 placed on senders, recipients, clients, servers, user agents,
643 intermediaries, origin servers, proxies, gateways, or caches,
644 depending on what behavior is being constrained by the requirement.
645 Additional (social) requirements are placed on implementations,
646 resource owners, and protocol element registrations when they apply
647 beyond the scope of a single communication.
649 The verb "generate" is used instead of "send" where a requirement
650 differentiates between creating a protocol element and merely
651 forwarding a received element downstream.
653 An implementation is considered conformant if it complies with all of
654 the requirements associated with the roles it partakes in HTTP.
656 Conformance includes both the syntax and semantics of protocol
657 elements. A sender MUST NOT generate protocol elements that convey a
658 meaning that is known by that sender to be false. A sender MUST NOT
659 generate protocol elements that do not match the grammar defined by
660 the corresponding ABNF rules. Within a given message, a sender MUST
661 NOT generate protocol elements or syntax alternatives that are only
662 allowed to be generated by participants in other roles (i.e., a role
663 that the sender does not have for that message).
665 When a received protocol element is parsed, the recipient MUST be
666 able to parse any value of reasonable length that is applicable to
667 the recipient's role and that matches the grammar defined by the
668 corresponding ABNF rules. Note, however, that some received protocol
669 elements might not be parsed. For example, an intermediary
674Fielding & Reschke Standards Track [Page 12]
676RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
679 forwarding a message might parse a header-field into generic
680 field-name and field-value components, but then forward the header
681 field without further parsing inside the field-value.
683 HTTP does not have specific length limitations for many of its
684 protocol elements because the lengths that might be appropriate will
685 vary widely, depending on the deployment context and purpose of the
686 implementation. Hence, interoperability between senders and
687 recipients depends on shared expectations regarding what is a
688 reasonable length for each protocol element. Furthermore, what is
689 commonly understood to be a reasonable length for some protocol
690 elements has changed over the course of the past two decades of HTTP
691 use and is expected to continue changing in the future.
693 At a minimum, a recipient MUST be able to parse and process protocol
694 element lengths that are at least as long as the values that it
695 generates for those same protocol elements in other messages. For
696 example, an origin server that publishes very long URI references to
697 its own resources needs to be able to parse and process those same
698 references when received as a request target.
700 A recipient MUST interpret a received protocol element according to
701 the semantics defined for it by this specification, including
702 extensions to this specification, unless the recipient has determined
703 (through experience or configuration) that the sender incorrectly
704 implements what is implied by those semantics. For example, an
705 origin server might disregard the contents of a received
706 Accept-Encoding header field if inspection of the User-Agent header
707 field indicates a specific implementation version that is known to
708 fail on receipt of certain content codings.
710 Unless noted otherwise, a recipient MAY attempt to recover a usable
711 protocol element from an invalid construct. HTTP does not define
712 specific error handling mechanisms except when they have a direct
713 impact on security, since different applications of the protocol
714 require different error handling strategies. For example, a Web
715 browser might wish to transparently recover from a response where the
716 Location header field doesn't parse according to the ABNF, whereas a
717 systems control client might consider any form of error recovery to
7202.6. Protocol Versioning
722 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
723 of the protocol. This specification defines version "1.1". The
724 protocol version as a whole indicates the sender's conformance with
725 the set of requirements laid out in that version's corresponding
726 specification of HTTP.
730Fielding & Reschke Standards Track [Page 13]
732RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
735 The version of an HTTP message is indicated by an HTTP-version field
736 in the first line of the message. HTTP-version is case-sensitive.
738 HTTP-version = HTTP-name "/" DIGIT "." DIGIT
739 HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
741 The HTTP version number consists of two decimal digits separated by a
742 "." (period or decimal point). The first digit ("major version")
743 indicates the HTTP messaging syntax, whereas the second digit ("minor
744 version") indicates the highest minor version within that major
745 version to which the sender is conformant and able to understand for
746 future communication. The minor version advertises the sender's
747 communication capabilities even when the sender is only using a
748 backwards-compatible subset of the protocol, thereby letting the
749 recipient know that more advanced features can be used in response
750 (by servers) or in future requests (by clients).
752 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
753 or a recipient whose version is unknown, the HTTP/1.1 message is
754 constructed such that it can be interpreted as a valid HTTP/1.0
755 message if all of the newer features are ignored. This specification
756 places recipient-version requirements on some new features so that a
757 conformant sender will only use compatible features until it has
758 determined, through configuration or the receipt of a message, that
759 the recipient supports HTTP/1.1.
761 The interpretation of a header field does not change between minor
762 versions of the same major HTTP version, though the default behavior
763 of a recipient in the absence of such a field can change. Unless
764 specified otherwise, header fields defined in HTTP/1.1 are defined
765 for all versions of HTTP/1.x. In particular, the Host and Connection
766 header fields ought to be implemented by all HTTP/1.x implementations
767 whether or not they advertise conformance with HTTP/1.1.
769 New header fields can be introduced without changing the protocol
770 version if their defined semantics allow them to be safely ignored by
771 recipients that do not recognize them. Header field extensibility is
772 discussed in Section 3.2.1.
774 Intermediaries that process HTTP messages (i.e., all intermediaries
775 other than those acting as tunnels) MUST send their own HTTP-version
776 in forwarded messages. In other words, they are not allowed to
777 blindly forward the first line of an HTTP message without ensuring
778 that the protocol version in that message matches a version to which
779 that intermediary is conformant for both the receiving and sending of
780 messages. Forwarding an HTTP message without rewriting the
786Fielding & Reschke Standards Track [Page 14]
788RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
791 HTTP-version might result in communication errors when downstream
792 recipients use the message sender's version to determine what
793 features are safe to use for later communication with that sender.
795 A client SHOULD send a request version equal to the highest version
796 to which the client is conformant and whose major version is no
797 higher than the highest version supported by the server, if this is
798 known. A client MUST NOT send a version to which it is not
801 A client MAY send a lower request version if it is known that the
802 server incorrectly implements the HTTP specification, but only after
803 the client has attempted at least one normal request and determined
804 from the response status code or header fields (e.g., Server) that
805 the server improperly handles higher request versions.
807 A server SHOULD send a response version equal to the highest version
808 to which the server is conformant that has a major version less than
809 or equal to the one received in the request. A server MUST NOT send
810 a version to which it is not conformant. A server can send a 505
811 (HTTP Version Not Supported) response if it wishes, for any reason,
812 to refuse service of the client's major protocol version.
814 A server MAY send an HTTP/1.0 response to a request if it is known or
815 suspected that the client incorrectly implements the HTTP
816 specification and is incapable of correctly processing later version
817 responses, such as when a client fails to parse the version number
818 correctly or when an intermediary is known to blindly forward the
819 HTTP-version even when it doesn't conform to the given minor version
820 of the protocol. Such protocol downgrades SHOULD NOT be performed
821 unless triggered by specific client attributes, such as when one or
822 more of the request header fields (e.g., User-Agent) uniquely match
823 the values sent by a client known to be in error.
825 The intention of HTTP's versioning design is that the major number
826 will only be incremented if an incompatible message syntax is
827 introduced, and that the minor number will only be incremented when
828 changes made to the protocol have the effect of adding to the message
829 semantics or implying additional capabilities of the sender.
830 However, the minor version was not incremented for the changes
831 introduced between [RFC2068] and [RFC2616], and this revision has
832 specifically avoided any such changes to the protocol.
834 When an HTTP message is received with a major version number that the
835 recipient implements, but a higher minor version number than what the
836 recipient implements, the recipient SHOULD process the message as if
837 it were in the highest minor version within that major version to
838 which the recipient is conformant. A recipient can assume that a
842Fielding & Reschke Standards Track [Page 15]
844RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
847 message with a higher minor version, when sent to a recipient that
848 has not yet indicated support for that higher version, is
849 sufficiently backwards-compatible to be safely processed by any
850 implementation of the same major version.
8522.7. Uniform Resource Identifiers
854 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
855 HTTP as the means for identifying resources (Section 2 of [RFC7231]).
856 URI references are used to target requests, indicate redirects, and
857 define relationships.
859 The definitions of "URI-reference", "absolute-URI", "relative-part",
860 "scheme", "authority", "port", "host", "path-abempty", "segment",
861 "query", and "fragment" are adopted from the URI generic syntax. An
862 "absolute-path" rule is defined for protocol elements that can
863 contain a non-empty path component. (This rule differs slightly from
864 the path-abempty rule of RFC 3986, which allows for an empty path to
865 be used in references, and path-absolute rule, which does not allow
866 paths that begin with "//".) A "partial-URI" rule is defined for
867 protocol elements that can contain a relative URI but not a fragment
870 URI-reference = <URI-reference, see [RFC3986], Section 4.1>
871 absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
872 relative-part = <relative-part, see [RFC3986], Section 4.2>
873 scheme = <scheme, see [RFC3986], Section 3.1>
874 authority = <authority, see [RFC3986], Section 3.2>
875 uri-host = <host, see [RFC3986], Section 3.2.2>
876 port = <port, see [RFC3986], Section 3.2.3>
877 path-abempty = <path-abempty, see [RFC3986], Section 3.3>
878 segment = <segment, see [RFC3986], Section 3.3>
879 query = <query, see [RFC3986], Section 3.4>
880 fragment = <fragment, see [RFC3986], Section 3.5>
882 absolute-path = 1*( "/" segment )
883 partial-URI = relative-part [ "?" query ]
885 Each protocol element in HTTP that allows a URI reference will
886 indicate in its ABNF production whether the element allows any form
887 of reference (URI-reference), only a URI in absolute form
888 (absolute-URI), only the path and optional query components, or some
889 combination of the above. Unless otherwise indicated, URI references
890 are parsed relative to the effective request URI (Section 5.5).
898Fielding & Reschke Standards Track [Page 16]
900RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
9032.7.1. http URI Scheme
905 The "http" URI scheme is hereby defined for the purpose of minting
906 identifiers according to their association with the hierarchical
907 namespace governed by a potential HTTP origin server listening for
908 TCP ([RFC0793]) connections on a given port.
910 http-URI = "http:" "//" authority path-abempty [ "?" query ]
913 The origin server for an "http" URI is identified by the authority
914 component, which includes a host identifier and optional TCP port
915 ([RFC3986], Section 3.2.2). The hierarchical path component and
916 optional query component serve as an identifier for a potential
917 target resource within that origin server's name space. The optional
918 fragment component allows for indirect identification of a secondary
919 resource, independent of the URI scheme, as defined in Section 3.5 of
922 A sender MUST NOT generate an "http" URI with an empty host
923 identifier. A recipient that processes such a URI reference MUST
924 reject it as invalid.
926 If the host identifier is provided as an IP address, the origin
927 server is the listener (if any) on the indicated TCP port at that IP
928 address. If host is a registered name, the registered name is an
929 indirect identifier for use with a name resolution service, such as
930 DNS, to find an address for that origin server. If the port
931 subcomponent is empty or not given, TCP port 80 (the reserved port
932 for WWW services) is the default.
934 Note that the presence of a URI with a given authority component does
935 not imply that there is always an HTTP server listening for
936 connections on that host and port. Anyone can mint a URI. What the
937 authority component determines is who has the right to respond
938 authoritatively to requests that target the identified resource. The
939 delegated nature of registered names and IP addresses creates a
940 federated namespace, based on control over the indicated host and
941 port, whether or not an HTTP server is present. See Section 9.1 for
942 security considerations related to establishing authority.
944 When an "http" URI is used within a context that calls for access to
945 the indicated resource, a client MAY attempt access by resolving the
946 host to an IP address, establishing a TCP connection to that address
947 on the indicated port, and sending an HTTP request message
948 (Section 3) containing the URI's identifying data (Section 5) to the
949 server. If the server responds to that request with a non-interim
954Fielding & Reschke Standards Track [Page 17]
956RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
959 HTTP response message, as described in Section 6 of [RFC7231], then
960 that response is considered an authoritative answer to the client's
963 Although HTTP is independent of the transport protocol, the "http"
964 scheme is specific to TCP-based services because the name delegation
965 process depends on TCP for establishing authority. An HTTP service
966 based on some other underlying connection protocol would presumably
967 be identified using a different URI scheme, just as the "https"
968 scheme (below) is used for resources that require an end-to-end
969 secured connection. Other protocols might also be used to provide
970 access to "http" identified resources -- it is only the authoritative
971 interface that is specific to TCP.
973 The URI generic syntax for authority also includes a deprecated
974 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
975 authentication information in the URI. Some implementations make use
976 of the userinfo component for internal configuration of
977 authentication information, such as within command invocation
978 options, configuration files, or bookmark lists, even though such
979 usage might expose a user identifier or password. A sender MUST NOT
980 generate the userinfo subcomponent (and its "@" delimiter) when an
981 "http" URI reference is generated within a message as a request
982 target or header field value. Before making use of an "http" URI
983 reference received from an untrusted source, a recipient SHOULD parse
984 for userinfo and treat its presence as an error; it is likely being
985 used to obscure the authority for the sake of phishing attacks.
9872.7.2. https URI Scheme
989 The "https" URI scheme is hereby defined for the purpose of minting
990 identifiers according to their association with the hierarchical
991 namespace governed by a potential HTTP origin server listening to a
992 given TCP port for TLS-secured connections ([RFC5246]).
994 All of the requirements listed above for the "http" scheme are also
995 requirements for the "https" scheme, except that TCP port 443 is the
996 default if the port subcomponent is empty or not given, and the user
997 agent MUST ensure that its connection to the origin server is secured
998 through the use of strong encryption, end-to-end, prior to sending
999 the first HTTP request.
1001 https-URI = "https:" "//" authority path-abempty [ "?" query ]
1004 Note that the "https" URI scheme depends on both TLS and TCP for
1005 establishing authority. Resources made available via the "https"
1006 scheme have no shared identity with the "http" scheme even if their
1010Fielding & Reschke Standards Track [Page 18]
1012RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1015 resource identifiers indicate the same authority (the same host
1016 listening to the same TCP port). They are distinct namespaces and
1017 are considered to be distinct origin servers. However, an extension
1018 to HTTP that is defined to apply to entire host domains, such as the
1019 Cookie protocol [RFC6265], can allow information set by one service
1020 to impact communication with other services within a matching group
1023 The process for authoritative access to an "https" identified
1024 resource is defined in [RFC2818].
10262.7.3. http and https URI Normalization and Comparison
1028 Since the "http" and "https" schemes conform to the URI generic
1029 syntax, such URIs are normalized and compared according to the
1030 algorithm defined in Section 6 of [RFC3986], using the defaults
1031 described above for each scheme.
1033 If the port is equal to the default port for a scheme, the normal
1034 form is to omit the port subcomponent. When not being used in
1035 absolute form as the request target of an OPTIONS request, an empty
1036 path component is equivalent to an absolute path of "/", so the
1037 normal form is to provide a path of "/" instead. The scheme and host
1038 are case-insensitive and normally provided in lowercase; all other
1039 components are compared in a case-sensitive manner. Characters other
1040 than those in the "reserved" set are equivalent to their
1041 percent-encoded octets: the normal form is to not encode them (see
1042 Sections 2.1 and 2.2 of [RFC3986]).
1044 For example, the following three URIs are equivalent:
1046 http://example.com:80/~smith/home.html
1047 http://EXAMPLE.com/%7Esmith/home.html
1048 http://EXAMPLE.com:/%7esmith/home.html
1052 All HTTP/1.1 messages consist of a start-line followed by a sequence
1053 of octets in a format similar to the Internet Message Format
1054 [RFC5322]: zero or more header fields (collectively referred to as
1055 the "headers" or the "header section"), an empty line indicating the
1056 end of the header section, and an optional message body.
1058 HTTP-message = start-line
1059 *( header-field CRLF )
1066Fielding & Reschke Standards Track [Page 19]
1068RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1071 The normal procedure for parsing an HTTP message is to read the
1072 start-line into a structure, read each header field into a hash table
1073 by field name until the empty line, and then use the parsed data to
1074 determine if a message body is expected. If a message body has been
1075 indicated, then it is read as a stream until an amount of octets
1076 equal to the message body length is read or the connection is closed.
1078 A recipient MUST parse an HTTP message as a sequence of octets in an
1079 encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
1080 message as a stream of Unicode characters, without regard for the
1081 specific encoding, creates security vulnerabilities due to the
1082 varying ways that string processing libraries handle invalid
1083 multibyte character sequences that contain the octet LF (%x0A).
1084 String-based parsers can only be safely used within protocol elements
1085 after the element has been extracted from the message, such as within
1086 a header field-value after message parsing has delineated the
1089 An HTTP message can be parsed as a stream for incremental processing
1090 or forwarding downstream. However, recipients cannot rely on
1091 incremental delivery of partial messages, since some implementations
1092 will buffer or delay message forwarding for the sake of network
1093 efficiency, security checks, or payload transformations.
1095 A sender MUST NOT send whitespace between the start-line and the
1096 first header field. A recipient that receives whitespace between the
1097 start-line and the first header field MUST either reject the message
1098 as invalid or consume each whitespace-preceded line without further
1099 processing of it (i.e., ignore the entire line, along with any
1100 subsequent lines preceded by whitespace, until a properly formed
1101 header field is received or the header section is terminated).
1103 The presence of such whitespace in a request might be an attempt to
1104 trick a server into ignoring that field or processing the line after
1105 it as a new request, either of which might result in a security
1106 vulnerability if other implementations within the request chain
1107 interpret the same message differently. Likewise, the presence of
1108 such whitespace in a response might be ignored by some clients or
1109 cause others to cease parsing.
1113 An HTTP message can be either a request from client to server or a
1114 response from server to client. Syntactically, the two types of
1115 message differ only in the start-line, which is either a request-line
1116 (for requests) or a status-line (for responses), and in the algorithm
1117 for determining the length of the message body (Section 3.3).
1122Fielding & Reschke Standards Track [Page 20]
1124RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1127 In theory, a client could receive requests and a server could receive
1128 responses, distinguishing them by their different start-line formats,
1129 but, in practice, servers are implemented to only expect a request (a
1130 response is interpreted as an unknown or invalid request method) and
1131 clients are implemented to only expect a response.
1133 start-line = request-line / status-line
1137 A request-line begins with a method token, followed by a single space
1138 (SP), the request-target, another single space (SP), the protocol
1139 version, and ends with CRLF.
1141 request-line = method SP request-target SP HTTP-version CRLF
1143 The method token indicates the request method to be performed on the
1144 target resource. The request method is case-sensitive.
1148 The request methods defined by this specification can be found in
1149 Section 4 of [RFC7231], along with information regarding the HTTP
1150 method registry and considerations for defining new methods.
1152 The request-target identifies the target resource upon which to apply
1153 the request, as defined in Section 5.3.
1155 Recipients typically parse the request-line into its component parts
1156 by splitting on whitespace (see Section 3.5), since no whitespace is
1157 allowed in the three components. Unfortunately, some user agents
1158 fail to properly encode or exclude whitespace found in hypertext
1159 references, resulting in those disallowed characters being sent in a
1162 Recipients of an invalid request-line SHOULD respond with either a
1163 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
1164 the request-target properly encoded. A recipient SHOULD NOT attempt
1165 to autocorrect and then process the request without a redirect, since
1166 the invalid request-line might be deliberately crafted to bypass
1167 security filters along the request chain.
1169 HTTP does not place a predefined limit on the length of a
1170 request-line, as described in Section 2.5. A server that receives a
1171 method longer than any that it implements SHOULD respond with a 501
1172 (Not Implemented) status code. A server that receives a
1178Fielding & Reschke Standards Track [Page 21]
1180RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1183 request-target longer than any URI it wishes to parse MUST respond
1184 with a 414 (URI Too Long) status code (see Section 6.5.12 of
1187 Various ad hoc limitations on request-line length are found in
1188 practice. It is RECOMMENDED that all HTTP senders and recipients
1189 support, at a minimum, request-line lengths of 8000 octets.
1193 The first line of a response message is the status-line, consisting
1194 of the protocol version, a space (SP), the status code, another
1195 space, a possibly empty textual phrase describing the status code,
1196 and ending with CRLF.
1198 status-line = HTTP-version SP status-code SP reason-phrase CRLF
1200 The status-code element is a 3-digit integer code describing the
1201 result of the server's attempt to understand and satisfy the client's
1202 corresponding request. The rest of the response message is to be
1203 interpreted in light of the semantics defined for that status code.
1204 See Section 6 of [RFC7231] for information about the semantics of
1205 status codes, including the classes of status code (indicated by the
1206 first digit), the status codes defined by this specification,
1207 considerations for the definition of new status codes, and the IANA
1210 status-code = 3DIGIT
1212 The reason-phrase element exists for the sole purpose of providing a
1213 textual description associated with the numeric status code, mostly
1214 out of deference to earlier Internet application protocols that were
1215 more frequently used with interactive text clients. A client SHOULD
1216 ignore the reason-phrase content.
1218 reason-phrase = *( HTAB / SP / VCHAR / obs-text )
1222 Each header field consists of a case-insensitive field name followed
1223 by a colon (":"), optional leading whitespace, the field value, and
1224 optional trailing whitespace.
1234Fielding & Reschke Standards Track [Page 22]
1236RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1239 header-field = field-name ":" OWS field-value OWS
1242 field-value = *( field-content / obs-fold )
1243 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
1244 field-vchar = VCHAR / obs-text
1246 obs-fold = CRLF 1*( SP / HTAB )
1247 ; obsolete line folding
1250 The field-name token labels the corresponding field-value as having
1251 the semantics defined by that header field. For example, the Date
1252 header field is defined in Section 7.1.1.2 of [RFC7231] as containing
1253 the origination timestamp for the message in which it appears.
12553.2.1. Field Extensibility
1257 Header fields are fully extensible: there is no limit on the
1258 introduction of new field names, each presumably defining new
1259 semantics, nor on the number of header fields used in a given
1260 message. Existing fields are defined in each part of this
1261 specification and in many other specifications outside this document
1264 New header fields can be defined such that, when they are understood
1265 by a recipient, they might override or enhance the interpretation of
1266 previously defined header fields, define preconditions on request
1267 evaluation, or refine the meaning of responses.
1269 A proxy MUST forward unrecognized header fields unless the field-name
1270 is listed in the Connection header field (Section 6.1) or the proxy
1271 is specifically configured to block, or otherwise transform, such
1272 fields. Other recipients SHOULD ignore unrecognized header fields.
1273 These requirements allow HTTP's functionality to be enhanced without
1274 requiring prior update of deployed intermediaries.
1276 All defined header fields ought to be registered with IANA in the
1277 "Message Headers" registry, as described in Section 8.3 of [RFC7231].
1281 The order in which header fields with differing field names are
1282 received is not significant. However, it is good practice to send
1283 header fields that contain control data first, such as Host on
1284 requests and Date on responses, so that implementations can decide
1285 when not to handle a message as early as possible. A server MUST NOT
1286 apply a request to the target resource until the entire request
1290Fielding & Reschke Standards Track [Page 23]
1292RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1295 header section is received, since later header fields might include
1296 conditionals, authentication credentials, or deliberately misleading
1297 duplicate header fields that would impact request processing.
1299 A sender MUST NOT generate multiple header fields with the same field
1300 name in a message unless either the entire field value for that
1301 header field is defined as a comma-separated list [i.e., #(values)]
1302 or the header field is a well-known exception (as noted below).
1304 A recipient MAY combine multiple header fields with the same field
1305 name into one "field-name: field-value" pair, without changing the
1306 semantics of the message, by appending each subsequent field value to
1307 the combined field value in order, separated by a comma. The order
1308 in which header fields with the same field name are received is
1309 therefore significant to the interpretation of the combined field
1310 value; a proxy MUST NOT change the order of these field values when
1311 forwarding a message.
1313 Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
1314 appears multiple times in a response message and does not use the
1315 list syntax, violating the above requirements on multiple header
1316 fields with the same name. Since it cannot be combined into a
1317 single field-value, recipients ought to handle "Set-Cookie" as a
1318 special case while processing header fields. (See Appendix A.2.3
1319 of [Kri2001] for details.)
1323 This specification uses three rules to denote the use of linear
1324 whitespace: OWS (optional whitespace), RWS (required whitespace), and
1325 BWS ("bad" whitespace).
1327 The OWS rule is used where zero or more linear whitespace octets
1328 might appear. For protocol elements where optional whitespace is
1329 preferred to improve readability, a sender SHOULD generate the
1330 optional whitespace as a single SP; otherwise, a sender SHOULD NOT
1331 generate optional whitespace except as needed to white out invalid or
1332 unwanted protocol elements during in-place message filtering.
1334 The RWS rule is used when at least one linear whitespace octet is
1335 required to separate field tokens. A sender SHOULD generate RWS as a
1338 The BWS rule is used where the grammar allows optional whitespace
1339 only for historical reasons. A sender MUST NOT generate BWS in
1340 messages. A recipient MUST parse for such bad whitespace and remove
1341 it before interpreting the protocol element.
1346Fielding & Reschke Standards Track [Page 24]
1348RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1351 OWS = *( SP / HTAB )
1352 ; optional whitespace
1353 RWS = 1*( SP / HTAB )
1354 ; required whitespace
1360 Messages are parsed using a generic algorithm, independent of the
1361 individual header field names. The contents within a given field
1362 value are not parsed until a later stage of message interpretation
1363 (usually after the message's entire header section has been
1364 processed). Consequently, this specification does not use ABNF rules
1365 to define each "Field-Name: Field Value" pair, as was done in
1366 previous editions. Instead, this specification uses ABNF rules that
1367 are named according to each registered field name, wherein the rule
1368 defines the valid grammar for that field's corresponding field values
1369 (i.e., after the field-value has been extracted from the header
1370 section by a generic field parser).
1372 No whitespace is allowed between the header field-name and colon. In
1373 the past, differences in the handling of such whitespace have led to
1374 security vulnerabilities in request routing and response handling. A
1375 server MUST reject any received request message that contains
1376 whitespace between a header field-name and colon with a response code
1377 of 400 (Bad Request). A proxy MUST remove any such whitespace from a
1378 response message before forwarding the message downstream.
1380 A field value might be preceded and/or followed by optional
1381 whitespace (OWS); a single SP preceding the field-value is preferred
1382 for consistent readability by humans. The field value does not
1383 include any leading or trailing whitespace: OWS occurring before the
1384 first non-whitespace octet of the field value or after the last
1385 non-whitespace octet of the field value ought to be excluded by
1386 parsers when extracting the field value from a header field.
1388 Historically, HTTP header field values could be extended over
1389 multiple lines by preceding each extra line with at least one space
1390 or horizontal tab (obs-fold). This specification deprecates such
1391 line folding except within the message/http media type
1392 (Section 8.3.1). A sender MUST NOT generate a message that includes
1393 line folding (i.e., that has any field-value that contains a match to
1394 the obs-fold rule) unless the message is intended for packaging
1395 within the message/http media type.
1402Fielding & Reschke Standards Track [Page 25]
1404RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1407 A server that receives an obs-fold in a request message that is not
1408 within a message/http container MUST either reject the message by
1409 sending a 400 (Bad Request), preferably with a representation
1410 explaining that obsolete line folding is unacceptable, or replace
1411 each received obs-fold with one or more SP octets prior to
1412 interpreting the field value or forwarding the message downstream.
1414 A proxy or gateway that receives an obs-fold in a response message
1415 that is not within a message/http container MUST either discard the
1416 message and replace it with a 502 (Bad Gateway) response, preferably
1417 with a representation explaining that unacceptable line folding was
1418 received, or replace each received obs-fold with one or more SP
1419 octets prior to interpreting the field value or forwarding the
1422 A user agent that receives an obs-fold in a response message that is
1423 not within a message/http container MUST replace each received
1424 obs-fold with one or more SP octets prior to interpreting the field
1427 Historically, HTTP has allowed field content with text in the
1428 ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
1429 through use of [RFC2047] encoding. In practice, most HTTP header
1430 field values use only a subset of the US-ASCII charset [USASCII].
1431 Newly defined header fields SHOULD limit their field values to
1432 US-ASCII octets. A recipient SHOULD treat other octets in field
1433 content (obs-text) as opaque data.
1437 HTTP does not place a predefined limit on the length of each header
1438 field or on the length of the header section as a whole, as described
1439 in Section 2.5. Various ad hoc limitations on individual header
1440 field length are found in practice, often depending on the specific
1443 A server that receives a request header field, or set of fields,
1444 larger than it wishes to process MUST respond with an appropriate 4xx
1445 (Client Error) status code. Ignoring such header fields would
1446 increase the server's vulnerability to request smuggling attacks
1449 A client MAY discard or truncate received header fields that are
1450 larger than the client wishes to process if the field semantics are
1451 such that the dropped value(s) can be safely ignored without changing
1452 the message framing or response semantics.
1458Fielding & Reschke Standards Track [Page 26]
1460RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
14633.2.6. Field Value Components
1465 Most HTTP header field values are defined using common syntax
1466 components (token, quoted-string, and comment) separated by
1467 whitespace or specific delimiting characters. Delimiters are chosen
1468 from the set of US-ASCII visual characters not allowed in a token
1469 (DQUOTE and "(),/:;<=>?@[\]{}").
1473 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1474 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1476 ; any VCHAR, except delimiters
1478 A string of text is parsed as a single value if it is quoted using
1481 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1482 qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
1485 Comments can be included in some HTTP header fields by surrounding
1486 the comment text with parentheses. Comments are only allowed in
1487 fields containing "comment" as part of their field value definition.
1489 comment = "(" *( ctext / quoted-pair / comment ) ")"
1490 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1492 The backslash octet ("\") can be used as a single-octet quoting
1493 mechanism within quoted-string and comment constructs. Recipients
1494 that process the value of a quoted-string MUST handle a quoted-pair
1495 as if it were replaced by the octet following the backslash.
1497 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1499 A sender SHOULD NOT generate a quoted-pair in a quoted-string except
1500 where necessary to quote DQUOTE and backslash octets occurring within
1501 that string. A sender SHOULD NOT generate a quoted-pair in a comment
1502 except where necessary to quote parentheses ["(" and ")"] and
1503 backslash octets occurring within that comment.
1514Fielding & Reschke Standards Track [Page 27]
1516RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1521 The message body (if any) of an HTTP message is used to carry the
1522 payload body of that request or response. The message body is
1523 identical to the payload body unless a transfer coding has been
1524 applied, as described in Section 3.3.1.
1526 message-body = *OCTET
1528 The rules for when a message body is allowed in a message differ for
1529 requests and responses.
1531 The presence of a message body in a request is signaled by a
1532 Content-Length or Transfer-Encoding header field. Request message
1533 framing is independent of method semantics, even if the method does
1534 not define any use for a message body.
1536 The presence of a message body in a response depends on both the
1537 request method to which it is responding and the response status code
1538 (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2
1539 of [RFC7231]) never include a message body because the associated
1540 response header fields (e.g., Transfer-Encoding, Content-Length,
1541 etc.), if present, indicate only what their values would have been if
1542 the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx
1543 (Successful) responses to a CONNECT request method (Section 4.3.6 of
1544 [RFC7231]) switch to tunnel mode instead of having a message body.
1545 All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1546 responses do not include a message body. All other responses do
1547 include a message body, although the body might be of zero length.
15493.3.1. Transfer-Encoding
1551 The Transfer-Encoding header field lists the transfer coding names
1552 corresponding to the sequence of transfer codings that have been (or
1553 will be) applied to the payload body in order to form the message
1554 body. Transfer codings are defined in Section 4.
1556 Transfer-Encoding = 1#transfer-coding
1558 Transfer-Encoding is analogous to the Content-Transfer-Encoding field
1559 of MIME, which was designed to enable safe transport of binary data
1560 over a 7-bit transport service ([RFC2045], Section 6). However, safe
1561 transport has a different focus for an 8bit-clean transfer protocol.
1562 In HTTP's case, Transfer-Encoding is primarily intended to accurately
1563 delimit a dynamically generated payload and to distinguish payload
1564 encodings that are only applied for transport efficiency or security
1565 from those that are characteristics of the selected resource.
1570Fielding & Reschke Standards Track [Page 28]
1572RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1575 A recipient MUST be able to parse the chunked transfer coding
1576 (Section 4.1) because it plays a crucial role in framing messages
1577 when the payload body size is not known in advance. A sender MUST
1578 NOT apply chunked more than once to a message body (i.e., chunking an
1579 already chunked message is not allowed). If any transfer coding
1580 other than chunked is applied to a request payload body, the sender
1581 MUST apply chunked as the final transfer coding to ensure that the
1582 message is properly framed. If any transfer coding other than
1583 chunked is applied to a response payload body, the sender MUST either
1584 apply chunked as the final transfer coding or terminate the message
1585 by closing the connection.
1589 Transfer-Encoding: gzip, chunked
1591 indicates that the payload body has been compressed using the gzip
1592 coding and then chunked using the chunked coding while forming the
1595 Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
1596 Transfer-Encoding is a property of the message, not of the
1597 representation, and any recipient along the request/response chain
1598 MAY decode the received transfer coding(s) or apply additional
1599 transfer coding(s) to the message body, assuming that corresponding
1600 changes are made to the Transfer-Encoding field-value. Additional
1601 information about the encoding parameters can be provided by other
1602 header fields not defined by this specification.
1604 Transfer-Encoding MAY be sent in a response to a HEAD request or in a
1605 304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET
1606 request, neither of which includes a message body, to indicate that
1607 the origin server would have applied a transfer coding to the message
1608 body if the request had been an unconditional GET. This indication
1609 is not required, however, because any recipient on the response chain
1610 (including the origin server) can remove transfer codings when they
1613 A server MUST NOT send a Transfer-Encoding header field in any
1614 response with a status code of 1xx (Informational) or 204 (No
1615 Content). A server MUST NOT send a Transfer-Encoding header field in
1616 any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of
1619 Transfer-Encoding was added in HTTP/1.1. It is generally assumed
1620 that implementations advertising only HTTP/1.0 support will not
1621 understand how to process a transfer-encoded payload. A client MUST
1622 NOT send a request containing Transfer-Encoding unless it knows the
1626Fielding & Reschke Standards Track [Page 29]
1628RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1631 server will handle HTTP/1.1 (or later) requests; such knowledge might
1632 be in the form of specific user configuration or by remembering the
1633 version of a prior received response. A server MUST NOT send a
1634 response containing Transfer-Encoding unless the corresponding
1635 request indicates HTTP/1.1 (or later).
1637 A server that receives a request message with a transfer coding it
1638 does not understand SHOULD respond with 501 (Not Implemented).
16403.3.2. Content-Length
1642 When a message does not have a Transfer-Encoding header field, a
1643 Content-Length header field can provide the anticipated size, as a
1644 decimal number of octets, for a potential payload body. For messages
1645 that do include a payload body, the Content-Length field-value
1646 provides the framing information necessary for determining where the
1647 body (and message) ends. For messages that do not include a payload
1648 body, the Content-Length indicates the size of the selected
1649 representation (Section 3 of [RFC7231]).
1651 Content-Length = 1*DIGIT
1655 Content-Length: 3495
1657 A sender MUST NOT send a Content-Length header field in any message
1658 that contains a Transfer-Encoding header field.
1660 A user agent SHOULD send a Content-Length in a request message when
1661 no Transfer-Encoding is sent and the request method defines a meaning
1662 for an enclosed payload body. For example, a Content-Length header
1663 field is normally sent in a POST request even when the value is 0
1664 (indicating an empty payload body). A user agent SHOULD NOT send a
1665 Content-Length header field when the request message does not contain
1666 a payload body and the method semantics do not anticipate such a
1669 A server MAY send a Content-Length header field in a response to a
1670 HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send
1671 Content-Length in such a response unless its field-value equals the
1672 decimal number of octets that would have been sent in the payload
1673 body of a response if the same request had used the GET method.
1675 A server MAY send a Content-Length header field in a 304 (Not
1676 Modified) response to a conditional GET request (Section 4.1 of
1677 [RFC7232]); a server MUST NOT send Content-Length in such a response
1682Fielding & Reschke Standards Track [Page 30]
1684RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1687 unless its field-value equals the decimal number of octets that would
1688 have been sent in the payload body of a 200 (OK) response to the same
1691 A server MUST NOT send a Content-Length header field in any response
1692 with a status code of 1xx (Informational) or 204 (No Content). A
1693 server MUST NOT send a Content-Length header field in any 2xx
1694 (Successful) response to a CONNECT request (Section 4.3.6 of
1697 Aside from the cases defined above, in the absence of
1698 Transfer-Encoding, an origin server SHOULD send a Content-Length
1699 header field when the payload body size is known prior to sending the
1700 complete header section. This will allow downstream recipients to
1701 measure transfer progress, know when a received message is complete,
1702 and potentially reuse the connection for additional requests.
1704 Any Content-Length field value greater than or equal to zero is
1705 valid. Since there is no predefined limit to the length of a
1706 payload, a recipient MUST anticipate potentially large decimal
1707 numerals and prevent parsing errors due to integer conversion
1708 overflows (Section 9.3).
1710 If a message is received that has multiple Content-Length header
1711 fields with field-values consisting of the same decimal value, or a
1712 single Content-Length header field with a field value containing a
1713 list of identical decimal values (e.g., "Content-Length: 42, 42"),
1714 indicating that duplicate Content-Length header fields have been
1715 generated or combined by an upstream message processor, then the
1716 recipient MUST either reject the message as invalid or replace the
1717 duplicated field-values with a single valid Content-Length field
1718 containing that decimal value prior to determining the message body
1719 length or forwarding the message.
1721 Note: HTTP's use of Content-Length for message framing differs
1722 significantly from the same field's use in MIME, where it is an
1723 optional field used only within the "message/external-body"
1738Fielding & Reschke Standards Track [Page 31]
1740RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
17433.3.3. Message Body Length
1745 The length of a message body is determined by one of the following
1746 (in order of precedence):
1748 1. Any response to a HEAD request and any response with a 1xx
1749 (Informational), 204 (No Content), or 304 (Not Modified) status
1750 code is always terminated by the first empty line after the
1751 header fields, regardless of the header fields present in the
1752 message, and thus cannot contain a message body.
1754 2. Any 2xx (Successful) response to a CONNECT request implies that
1755 the connection will become a tunnel immediately after the empty
1756 line that concludes the header fields. A client MUST ignore any
1757 Content-Length or Transfer-Encoding header fields received in
1760 3. If a Transfer-Encoding header field is present and the chunked
1761 transfer coding (Section 4.1) is the final encoding, the message
1762 body length is determined by reading and decoding the chunked
1763 data until the transfer coding indicates the data is complete.
1765 If a Transfer-Encoding header field is present in a response and
1766 the chunked transfer coding is not the final encoding, the
1767 message body length is determined by reading the connection until
1768 it is closed by the server. If a Transfer-Encoding header field
1769 is present in a request and the chunked transfer coding is not
1770 the final encoding, the message body length cannot be determined
1771 reliably; the server MUST respond with the 400 (Bad Request)
1772 status code and then close the connection.
1774 If a message is received with both a Transfer-Encoding and a
1775 Content-Length header field, the Transfer-Encoding overrides the
1776 Content-Length. Such a message might indicate an attempt to
1777 perform request smuggling (Section 9.5) or response splitting
1778 (Section 9.4) and ought to be handled as an error. A sender MUST
1779 remove the received Content-Length field prior to forwarding such
1780 a message downstream.
1782 4. If a message is received without Transfer-Encoding and with
1783 either multiple Content-Length header fields having differing
1784 field-values or a single Content-Length header field having an
1785 invalid value, then the message framing is invalid and the
1786 recipient MUST treat it as an unrecoverable error. If this is a
1787 request message, the server MUST respond with a 400 (Bad Request)
1788 status code and then close the connection. If this is a response
1789 message received by a proxy, the proxy MUST close the connection
1790 to the server, discard the received response, and send a 502 (Bad
1794Fielding & Reschke Standards Track [Page 32]
1796RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1799 Gateway) response to the client. If this is a response message
1800 received by a user agent, the user agent MUST close the
1801 connection to the server and discard the received response.
1803 5. If a valid Content-Length header field is present without
1804 Transfer-Encoding, its decimal value defines the expected message
1805 body length in octets. If the sender closes the connection or
1806 the recipient times out before the indicated number of octets are
1807 received, the recipient MUST consider the message to be
1808 incomplete and close the connection.
1810 6. If this is a request message and none of the above are true, then
1811 the message body length is zero (no message body is present).
1813 7. Otherwise, this is a response message without a declared message
1814 body length, so the message body length is determined by the
1815 number of octets received prior to the server closing the
1818 Since there is no way to distinguish a successfully completed,
1819 close-delimited message from a partially received message interrupted
1820 by network failure, a server SHOULD generate encoding or
1821 length-delimited messages whenever possible. The close-delimiting
1822 feature exists primarily for backwards compatibility with HTTP/1.0.
1824 A server MAY reject a request that contains a message body but not a
1825 Content-Length by responding with 411 (Length Required).
1827 Unless a transfer coding other than chunked has been applied, a
1828 client that sends a request containing a message body SHOULD use a
1829 valid Content-Length header field if the message body length is known
1830 in advance, rather than the chunked transfer coding, since some
1831 existing services respond to chunked with a 411 (Length Required)
1832 status code even though they understand the chunked transfer coding.
1833 This is typically because such services are implemented via a gateway
1834 that requires a content-length in advance of being called and the
1835 server is unable or unwilling to buffer the entire request before
1838 A user agent that sends a request containing a message body MUST send
1839 a valid Content-Length header field if it does not know the server
1840 will handle HTTP/1.1 (or later) requests; such knowledge can be in
1841 the form of specific user configuration or by remembering the version
1842 of a prior received response.
1844 If the final response to the last request on a connection has been
1845 completely received and there remains additional data to read, a user
1846 agent MAY discard the remaining data or attempt to determine if that
1850Fielding & Reschke Standards Track [Page 33]
1852RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1855 data belongs as part of the prior response body, which might be the
1856 case if the prior message's Content-Length value is incorrect. A
1857 client MUST NOT process, cache, or forward such extra data as a
1858 separate response, since such behavior would be vulnerable to cache
18613.4. Handling Incomplete Messages
1863 A server that receives an incomplete request message, usually due to
1864 a canceled request or a triggered timeout exception, MAY send an
1865 error response prior to closing the connection.
1867 A client that receives an incomplete response message, which can
1868 occur when a connection is closed prematurely or when decoding a
1869 supposedly chunked transfer coding fails, MUST record the message as
1870 incomplete. Cache requirements for incomplete responses are defined
1871 in Section 3 of [RFC7234].
1873 If a response terminates in the middle of the header section (before
1874 the empty line is received) and the status code might rely on header
1875 fields to convey the full meaning of the response, then the client
1876 cannot assume that meaning has been conveyed; the client might need
1877 to repeat the request in order to determine what action to take next.
1879 A message body that uses the chunked transfer coding is incomplete if
1880 the zero-sized chunk that terminates the encoding has not been
1881 received. A message that uses a valid Content-Length is incomplete
1882 if the size of the message body received (in octets) is less than the
1883 value given by Content-Length. A response that has neither chunked
1884 transfer coding nor Content-Length is terminated by closure of the
1885 connection and, thus, is considered complete regardless of the number
1886 of message body octets received, provided that the header section was
18893.5. Message Parsing Robustness
1891 Older HTTP/1.0 user agent implementations might send an extra CRLF
1892 after a POST request as a workaround for some early server
1893 applications that failed to read message body content that was not
1894 terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
1895 or follow a request with an extra CRLF. If terminating the request
1896 message body with a line-ending is desired, then the user agent MUST
1897 count the terminating CRLF octets as part of the message body length.
1899 In the interest of robustness, a server that is expecting to receive
1900 and parse a request-line SHOULD ignore at least one empty line (CRLF)
1901 received prior to the request-line.
1906Fielding & Reschke Standards Track [Page 34]
1908RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1911 Although the line terminator for the start-line and header fields is
1912 the sequence CRLF, a recipient MAY recognize a single LF as a line
1913 terminator and ignore any preceding CR.
1915 Although the request-line and status-line grammar rules require that
1916 each of the component elements be separated by a single SP octet,
1917 recipients MAY instead parse on whitespace-delimited word boundaries
1918 and, aside from the CRLF terminator, treat any form of whitespace as
1919 the SP separator while ignoring preceding or trailing whitespace;
1920 such whitespace includes one or more of the following octets: SP,
1921 HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can
1922 result in security vulnerabilities if there are multiple recipients
1923 of the message and each has its own unique interpretation of
1924 robustness (see Section 9.5).
1926 When a server listening only for HTTP request messages, or processing
1927 what appears from the start-line to be an HTTP request message,
1928 receives a sequence of octets that does not match the HTTP-message
1929 grammar aside from the robustness exceptions listed above, the server
1930 SHOULD respond with a 400 (Bad Request) response.
1934 Transfer coding names are used to indicate an encoding transformation
1935 that has been, can be, or might need to be applied to a payload body
1936 in order to ensure "safe transport" through the network. This
1937 differs from a content coding in that the transfer coding is a
1938 property of the message rather than a property of the representation
1939 that is being transferred.
1941 transfer-coding = "chunked" ; Section 4.1
1942 / "compress" ; Section 4.2.1
1943 / "deflate" ; Section 4.2.2
1944 / "gzip" ; Section 4.2.3
1945 / transfer-extension
1946 transfer-extension = token *( OWS ";" OWS transfer-parameter )
1948 Parameters are in the form of a name or name=value pair.
1950 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
1952 All transfer-coding names are case-insensitive and ought to be
1953 registered within the HTTP Transfer Coding registry, as defined in
1954 Section 8.4. They are used in the TE (Section 4.3) and
1955 Transfer-Encoding (Section 3.3.1) header fields.
1962Fielding & Reschke Standards Track [Page 35]
1964RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
19674.1. Chunked Transfer Coding
1969 The chunked transfer coding wraps the payload body in order to
1970 transfer it as a series of chunks, each with its own size indicator,
1971 followed by an OPTIONAL trailer containing header fields. Chunked
1972 enables content streams of unknown size to be transferred as a
1973 sequence of length-delimited buffers, which enables the sender to
1974 retain connection persistence and the recipient to know when it has
1975 received the entire message.
1977 chunked-body = *chunk
1982 chunk = chunk-size [ chunk-ext ] CRLF
1984 chunk-size = 1*HEXDIG
1985 last-chunk = 1*("0") [ chunk-ext ] CRLF
1987 chunk-data = 1*OCTET ; a sequence of chunk-size octets
1989 The chunk-size field is a string of hex digits indicating the size of
1990 the chunk-data in octets. The chunked transfer coding is complete
1991 when a chunk with a chunk-size of zero is received, possibly followed
1992 by a trailer, and finally terminated by an empty line.
1994 A recipient MUST be able to parse and decode the chunked transfer
19974.1.1. Chunk Extensions
1999 The chunked encoding allows each chunk to include zero or more chunk
2000 extensions, immediately following the chunk-size, for the sake of
2001 supplying per-chunk metadata (such as a signature or hash),
2002 mid-message control information, or randomization of message body
2005 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
2007 chunk-ext-name = token
2008 chunk-ext-val = token / quoted-string
2010 The chunked encoding is specific to each connection and is likely to
2011 be removed or recoded by each recipient (including intermediaries)
2012 before any higher-level application would have a chance to inspect
2013 the extensions. Hence, use of chunk extensions is generally limited
2018Fielding & Reschke Standards Track [Page 36]
2020RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2023 to specialized HTTP services such as "long polling" (where client and
2024 server can have shared expectations regarding the use of chunk
2025 extensions) or for padding within an end-to-end secured connection.
2027 A recipient MUST ignore unrecognized chunk extensions. A server
2028 ought to limit the total length of chunk extensions received in a
2029 request to an amount reasonable for the services provided, in the
2030 same way that it applies length limitations and timeouts for other
2031 parts of a message, and generate an appropriate 4xx (Client Error)
2032 response if that amount is exceeded.
20344.1.2. Chunked Trailer Part
2036 A trailer allows the sender to include additional fields at the end
2037 of a chunked message in order to supply metadata that might be
2038 dynamically generated while the message body is sent, such as a
2039 message integrity check, digital signature, or post-processing
2040 status. The trailer fields are identical to header fields, except
2041 they are sent in a chunked trailer instead of the message's header
2044 trailer-part = *( header-field CRLF )
2046 A sender MUST NOT generate a trailer that contains a field necessary
2047 for message framing (e.g., Transfer-Encoding and Content-Length),
2048 routing (e.g., Host), request modifiers (e.g., controls and
2049 conditionals in Section 5 of [RFC7231]), authentication (e.g., see
2050 [RFC7235] and [RFC6265]), response control data (e.g., see Section
2051 7.1 of [RFC7231]), or determining how to process the payload (e.g.,
2052 Content-Encoding, Content-Type, Content-Range, and Trailer).
2054 When a chunked message containing a non-empty trailer is received,
2055 the recipient MAY process the fields (aside from those forbidden
2056 above) as if they were appended to the message's header section. A
2057 recipient MUST ignore (or consider as an error) any fields that are
2058 forbidden to be sent in a trailer, since processing them as if they
2059 were present in the header section might bypass external security
2062 Unless the request includes a TE header field indicating "trailers"
2063 is acceptable, as described in Section 4.3, a server SHOULD NOT
2064 generate trailer fields that it believes are necessary for the user
2065 agent to receive. Without a TE containing "trailers", the server
2066 ought to assume that the trailer fields might be silently discarded
2067 along the path to the user agent. This requirement allows
2068 intermediaries to forward a de-chunked message to an HTTP/1.0
2069 recipient without buffering the entire response.
2074Fielding & Reschke Standards Track [Page 37]
2076RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
20794.1.3. Decoding Chunked
2081 A process for decoding the chunked transfer coding can be represented
2085 read chunk-size, chunk-ext (if any), and CRLF
2086 while (chunk-size > 0) {
2087 read chunk-data and CRLF
2088 append chunk-data to decoded-body
2089 length := length + chunk-size
2090 read chunk-size, chunk-ext (if any), and CRLF
2093 while (trailer field is not empty) {
2094 if (trailer field is allowed to be sent in a trailer) {
2095 append trailer field to existing header fields
2099 Content-Length := length
2100 Remove "chunked" from Transfer-Encoding
2101 Remove Trailer from existing header fields
21034.2. Compression Codings
2105 The codings defined below can be used to compress the payload of a
21084.2.1. Compress Coding
2110 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
2111 [Welch] that is commonly produced by the UNIX file compression
2112 program "compress". A recipient SHOULD consider "x-compress" to be
2113 equivalent to "compress".
21154.2.2. Deflate Coding
2117 The "deflate" coding is a "zlib" data format [RFC1950] containing a
2118 "deflate" compressed data stream [RFC1951] that uses a combination of
2119 the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
2121 Note: Some non-conformant implementations send the "deflate"
2122 compressed data without the zlib wrapper.
2130Fielding & Reschke Standards Track [Page 38]
2132RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2137 The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
2138 Check (CRC) that is commonly produced by the gzip file compression
2139 program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
2140 equivalent to "gzip".
2144 The "TE" header field in a request indicates what transfer codings,
2145 besides chunked, the client is willing to accept in response, and
2146 whether or not the client is willing to accept trailer fields in a
2147 chunked transfer coding.
2149 The TE field-value consists of a comma-separated list of transfer
2150 coding names, each allowing for optional parameters (as described in
2151 Section 4), and/or the keyword "trailers". A client MUST NOT send
2152 the chunked transfer coding name in TE; chunked is always acceptable
2153 for HTTP/1.1 recipients.
2156 t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
2157 t-ranking = OWS ";" OWS "q=" rank
2158 rank = ( "0" [ "." 0*3DIGIT ] )
2159 / ( "1" [ "." 0*3("0") ] )
2161 Three examples of TE use are below.
2165 TE: trailers, deflate;q=0.5
2167 The presence of the keyword "trailers" indicates that the client is
2168 willing to accept trailer fields in a chunked transfer coding, as
2169 defined in Section 4.1.2, on behalf of itself and any downstream
2170 clients. For requests from an intermediary, this implies that
2171 either: (a) all downstream clients are willing to accept trailer
2172 fields in the forwarded response; or, (b) the intermediary will
2173 attempt to buffer the response on behalf of downstream recipients.
2174 Note that HTTP/1.1 does not define any means to limit the size of a
2175 chunked response such that an intermediary can be assured of
2176 buffering the entire response.
2178 When multiple transfer codings are acceptable, the client MAY rank
2179 the codings by preference using a case-insensitive "q" parameter
2180 (similar to the qvalues used in content negotiation fields, Section
2186Fielding & Reschke Standards Track [Page 39]
2188RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2191 5.3.1 of [RFC7231]). The rank value is a real number in the range 0
2192 through 1, where 0.001 is the least preferred and 1 is the most
2193 preferred; a value of 0 means "not acceptable".
2195 If the TE field-value is empty or if no TE field is present, the only
2196 acceptable transfer coding is chunked. A message with no transfer
2197 coding is always acceptable.
2199 Since the TE header field only applies to the immediate connection, a
2200 sender of TE MUST also send a "TE" connection option within the
2201 Connection header field (Section 6.1) in order to prevent the TE
2202 field from being forwarded by intermediaries that do not support its
2207 When a message includes a message body encoded with the chunked
2208 transfer coding and the sender desires to send metadata in the form
2209 of trailer fields at the end of the message, the sender SHOULD
2210 generate a Trailer header field before the message body to indicate
2211 which fields will be present in the trailers. This allows the
2212 recipient to prepare for receipt of that metadata before it starts
2213 processing the body, which is useful if the message is being streamed
2214 and the recipient wishes to confirm an integrity check on the fly.
2216 Trailer = 1#field-name
2220 HTTP request message routing is determined by each client based on
2221 the target resource, the client's proxy configuration, and
2222 establishment or reuse of an inbound connection. The corresponding
2223 response routing follows the same connection chain back to the
22265.1. Identifying a Target Resource
2228 HTTP is used in a wide variety of applications, ranging from
2229 general-purpose computers to home appliances. In some cases,
2230 communication options are hard-coded in a client's configuration.
2231 However, most HTTP clients rely on the same resource identification
2232 mechanism and configuration techniques as general-purpose Web
2235 HTTP communication is initiated by a user agent for some purpose.
2236 The purpose is a combination of request semantics, which are defined
2237 in [RFC7231], and a target resource upon which to apply those
2238 semantics. A URI reference (Section 2.7) is typically used as an
2242Fielding & Reschke Standards Track [Page 40]
2244RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2247 identifier for the "target resource", which a user agent would
2248 resolve to its absolute form in order to obtain the "target URI".
2249 The target URI excludes the reference's fragment component, if any,
2250 since fragment identifiers are reserved for client-side processing
2251 ([RFC3986], Section 3.5).
22535.2. Connecting Inbound
2255 Once the target URI is determined, a client needs to decide whether a
2256 network request is necessary to accomplish the desired semantics and,
2257 if so, where that request is to be directed.
2259 If the client has a cache [RFC7234] and the request can be satisfied
2260 by it, then the request is usually directed there first.
2262 If the request is not satisfied by a cache, then a typical client
2263 will check its configuration to determine whether a proxy is to be
2264 used to satisfy the request. Proxy configuration is implementation-
2265 dependent, but is often based on URI prefix matching, selective
2266 authority matching, or both, and the proxy itself is usually
2267 identified by an "http" or "https" URI. If a proxy is applicable,
2268 the client connects inbound by establishing (or reusing) a connection
2271 If no proxy is applicable, a typical client will invoke a handler
2272 routine, usually specific to the target URI's scheme, to connect
2273 directly to an authority for the target resource. How that is
2274 accomplished is dependent on the target URI scheme and defined by its
2275 associated specification, similar to how this specification defines
2276 origin server access for resolution of the "http" (Section 2.7.1) and
2277 "https" (Section 2.7.2) schemes.
2279 HTTP requirements regarding connection management are defined in
2284 Once an inbound connection is obtained, the client sends an HTTP
2285 request message (Section 3) with a request-target derived from the
2286 target URI. There are four distinct formats for the request-target,
2287 depending on both the method being requested and whether the request
2290 request-target = origin-form
2298Fielding & Reschke Standards Track [Page 41]
2300RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2305 The most common form of request-target is the origin-form.
2307 origin-form = absolute-path [ "?" query ]
2309 When making a request directly to an origin server, other than a
2310 CONNECT or server-wide OPTIONS request (as detailed below), a client
2311 MUST send only the absolute path and query components of the target
2312 URI as the request-target. If the target URI's path component is
2313 empty, the client MUST send "/" as the path within the origin-form of
2314 request-target. A Host header field is also sent, as defined in
2317 For example, a client wishing to retrieve a representation of the
2318 resource identified as
2320 http://www.example.org/where?q=now
2322 directly from the origin server would open (or reuse) a TCP
2323 connection to port 80 of the host "www.example.org" and send the
2326 GET /where?q=now HTTP/1.1
2327 Host: www.example.org
2329 followed by the remainder of the request message.
2333 When making a request to a proxy, other than a CONNECT or server-wide
2334 OPTIONS request (as detailed below), a client MUST send the target
2335 URI in absolute-form as the request-target.
2337 absolute-form = absolute-URI
2339 The proxy is requested to either service that request from a valid
2340 cache, if possible, or make the same request on the client's behalf
2341 to either the next inbound proxy server or directly to the origin
2342 server indicated by the request-target. Requirements on such
2343 "forwarding" of messages are defined in Section 5.7.
2345 An example absolute-form of request-line would be:
2347 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
2354Fielding & Reschke Standards Track [Page 42]
2356RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2359 To allow for transition to the absolute-form for all requests in some
2360 future version of HTTP, a server MUST accept the absolute-form in
2361 requests, even though HTTP/1.1 clients will only send them in
2362 requests to proxies.
23645.3.3. authority-form
2366 The authority-form of request-target is only used for CONNECT
2367 requests (Section 4.3.6 of [RFC7231]).
2369 authority-form = authority
2371 When making a CONNECT request to establish a tunnel through one or
2372 more proxies, a client MUST send only the target URI's authority
2373 component (excluding any userinfo and its "@" delimiter) as the
2374 request-target. For example,
2376 CONNECT www.example.com:80 HTTP/1.1
2380 The asterisk-form of request-target is only used for a server-wide
2381 OPTIONS request (Section 4.3.7 of [RFC7231]).
2385 When a client wishes to request OPTIONS for the server as a whole, as
2386 opposed to a specific named resource of that server, the client MUST
2387 send only "*" (%x2A) as the request-target. For example,
2391 If a proxy receives an OPTIONS request with an absolute-form of
2392 request-target in which the URI has an empty path and no query
2393 component, then the last proxy on the request chain MUST send a
2394 request-target of "*" when it forwards the request to the indicated
2397 For example, the request
2399 OPTIONS http://www.example.org:8001 HTTP/1.1
2401 would be forwarded by the final proxy as
2404 Host: www.example.org:8001
2406 after connecting to port 8001 of host "www.example.org".
2410Fielding & Reschke Standards Track [Page 43]
2412RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2417 The "Host" header field in a request provides the host and port
2418 information from the target URI, enabling the origin server to
2419 distinguish among resources while servicing requests for multiple
2420 host names on a single IP address.
2422 Host = uri-host [ ":" port ] ; Section 2.7.1
2424 A client MUST send a Host header field in all HTTP/1.1 request
2425 messages. If the target URI includes an authority component, then a
2426 client MUST send a field-value for Host that is identical to that
2427 authority component, excluding any userinfo subcomponent and its "@"
2428 delimiter (Section 2.7.1). If the authority component is missing or
2429 undefined for the target URI, then a client MUST send a Host header
2430 field with an empty field-value.
2432 Since the Host field-value is critical information for handling a
2433 request, a user agent SHOULD generate Host as the first header field
2434 following the request-line.
2436 For example, a GET request to the origin server for
2437 <http://www.example.org/pub/WWW/> would begin with:
2439 GET /pub/WWW/ HTTP/1.1
2440 Host: www.example.org
2442 A client MUST send a Host header field in an HTTP/1.1 request even if
2443 the request-target is in the absolute-form, since this allows the
2444 Host information to be forwarded through ancient HTTP/1.0 proxies
2445 that might not have implemented Host.
2447 When a proxy receives a request with an absolute-form of
2448 request-target, the proxy MUST ignore the received Host header field
2449 (if any) and instead replace it with the host information of the
2450 request-target. A proxy that forwards such a request MUST generate a
2451 new Host field-value based on the received request-target rather than
2452 forward the received Host field-value.
2454 Since the Host header field acts as an application-level routing
2455 mechanism, it is a frequent target for malware seeking to poison a
2456 shared cache or redirect a request to an unintended server. An
2457 interception proxy is particularly vulnerable if it relies on the
2458 Host field-value for redirecting requests to internal servers, or for
2459 use as a cache key in a shared cache, without first verifying that
2460 the intercepted connection is targeting a valid IP address for that
2466Fielding & Reschke Standards Track [Page 44]
2468RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2471 A server MUST respond with a 400 (Bad Request) status code to any
2472 HTTP/1.1 request message that lacks a Host header field and to any
2473 request message that contains more than one Host header field or a
2474 Host header field with an invalid field-value.
24765.5. Effective Request URI
2478 Since the request-target often contains only part of the user agent's
2479 target URI, a server reconstructs the intended target as an
2480 "effective request URI" to properly service the request. This
2481 reconstruction involves both the server's local configuration and
2482 information communicated in the request-target, Host header field,
2483 and connection context.
2485 For a user agent, the effective request URI is the target URI.
2487 If the request-target is in absolute-form, the effective request URI
2488 is the same as the request-target. Otherwise, the effective request
2489 URI is constructed as follows:
2491 If the server's configuration (or outbound gateway) provides a
2492 fixed URI scheme, that scheme is used for the effective request
2493 URI. Otherwise, if the request is received over a TLS-secured TCP
2494 connection, the effective request URI's scheme is "https"; if not,
2495 the scheme is "http".
2497 If the server's configuration (or outbound gateway) provides a
2498 fixed URI authority component, that authority is used for the
2499 effective request URI. If not, then if the request-target is in
2500 authority-form, the effective request URI's authority component is
2501 the same as the request-target. If not, then if a Host header
2502 field is supplied with a non-empty field-value, the authority
2503 component is the same as the Host field-value. Otherwise, the
2504 authority component is assigned the default name configured for
2505 the server and, if the connection's incoming TCP port number
2506 differs from the default port for the effective request URI's
2507 scheme, then a colon (":") and the incoming port number (in
2508 decimal form) are appended to the authority component.
2510 If the request-target is in authority-form or asterisk-form, the
2511 effective request URI's combined path and query component is
2512 empty. Otherwise, the combined path and query component is the
2513 same as the request-target.
2515 The components of the effective request URI, once determined as
2516 above, can be combined into absolute-URI form by concatenating the
2517 scheme, "://", authority, and combined path and query component.
2522Fielding & Reschke Standards Track [Page 45]
2524RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2527 Example 1: the following message received over an insecure TCP
2530 GET /pub/WWW/TheProject.html HTTP/1.1
2531 Host: www.example.org:8080
2533 has an effective request URI of
2535 http://www.example.org:8080/pub/WWW/TheProject.html
2537 Example 2: the following message received over a TLS-secured TCP
2541 Host: www.example.org
2543 has an effective request URI of
2545 https://www.example.org
2547 Recipients of an HTTP/1.0 request that lacks a Host header field
2548 might need to use heuristics (e.g., examination of the URI path for
2549 something unique to a particular host) in order to guess the
2550 effective request URI's authority component.
2552 Once the effective request URI has been constructed, an origin server
2553 needs to decide whether or not to provide service for that URI via
2554 the connection in which the request was received. For example, the
2555 request might have been misdirected, deliberately or accidentally,
2556 such that the information within a received request-target or Host
2557 header field differs from the host or port upon which the connection
2558 has been made. If the connection is from a trusted gateway, that
2559 inconsistency might be expected; otherwise, it might indicate an
2560 attempt to bypass security filters, trick the server into delivering
2561 non-public content, or poison a cache. See Section 9 for security
2562 considerations regarding message routing.
25645.6. Associating a Response to a Request
2566 HTTP does not include a request identifier for associating a given
2567 request message with its corresponding one or more response messages.
2568 Hence, it relies on the order of response arrival to correspond
2569 exactly to the order in which requests are made on the same
2570 connection. More than one response message per request only occurs
2571 when one or more informational responses (1xx, see Section 6.2 of
2572 [RFC7231]) precede a final response to the same request.
2578Fielding & Reschke Standards Track [Page 46]
2580RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2583 A client that has more than one outstanding request on a connection
2584 MUST maintain a list of outstanding requests in the order sent and
2585 MUST associate each received response message on that connection to
2586 the highest ordered request that has not yet received a final
25895.7. Message Forwarding
2591 As described in Section 2.3, intermediaries can serve a variety of
2592 roles in the processing of HTTP requests and responses. Some
2593 intermediaries are used to improve performance or availability.
2594 Others are used for access control or to filter content. Since an
2595 HTTP stream has characteristics similar to a pipe-and-filter
2596 architecture, there are no inherent limits to the extent an
2597 intermediary can enhance (or interfere) with either direction of the
2600 An intermediary not acting as a tunnel MUST implement the Connection
2601 header field, as specified in Section 6.1, and exclude fields from
2602 being forwarded that are only intended for the incoming connection.
2604 An intermediary MUST NOT forward a message to itself unless it is
2605 protected from an infinite request loop. In general, an intermediary
2606 ought to recognize its own server names, including any aliases, local
2607 variations, or literal IP addresses, and respond to such requests
2612 The "Via" header field indicates the presence of intermediate
2613 protocols and recipients between the user agent and the server (on
2614 requests) or between the origin server and the client (on responses),
2615 similar to the "Received" header field in email (Section 3.6.7 of
2616 [RFC5322]). Via can be used for tracking message forwards, avoiding
2617 request loops, and identifying the protocol capabilities of senders
2618 along the request/response chain.
2620 Via = 1#( received-protocol RWS received-by [ RWS comment ] )
2622 received-protocol = [ protocol-name "/" ] protocol-version
2624 received-by = ( uri-host [ ":" port ] ) / pseudonym
2627 Multiple Via field values represent each proxy or gateway that has
2628 forwarded the message. Each intermediary appends its own information
2629 about how the message was received, such that the end result is
2630 ordered according to the sequence of forwarding recipients.
2634Fielding & Reschke Standards Track [Page 47]
2636RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2639 A proxy MUST send an appropriate Via header field, as described
2640 below, in each message that it forwards. An HTTP-to-HTTP gateway
2641 MUST send an appropriate Via header field in each inbound request
2642 message and MAY send a Via header field in forwarded response
2645 For each intermediary, the received-protocol indicates the protocol
2646 and protocol version used by the upstream sender of the message.
2647 Hence, the Via field value records the advertised protocol
2648 capabilities of the request/response chain such that they remain
2649 visible to downstream recipients; this can be useful for determining
2650 what backwards-incompatible features might be safe to use in
2651 response, or within a later request, as described in Section 2.6.
2652 For brevity, the protocol-name is omitted when the received protocol
2655 The received-by portion of the field value is normally the host and
2656 optional port number of a recipient server or client that
2657 subsequently forwarded the message. However, if the real host is
2658 considered to be sensitive information, a sender MAY replace it with
2659 a pseudonym. If a port is not provided, a recipient MAY interpret
2660 that as meaning it was received on the default TCP port, if any, for
2661 the received-protocol.
2663 A sender MAY generate comments in the Via header field to identify
2664 the software of each recipient, analogous to the User-Agent and
2665 Server header fields. However, all comments in the Via field are
2666 optional, and a recipient MAY remove them prior to forwarding the
2669 For example, a request message could be sent from an HTTP/1.0 user
2670 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2671 forward the request to a public proxy at p.example.net, which
2672 completes the request by forwarding it to the origin server at
2673 www.example.com. The request received by www.example.com would then
2674 have the following Via header field:
2676 Via: 1.0 fred, 1.1 p.example.net
2678 An intermediary used as a portal through a network firewall SHOULD
2679 NOT forward the names and ports of hosts within the firewall region
2680 unless it is explicitly enabled to do so. If not enabled, such an
2681 intermediary SHOULD replace each received-by host of any host behind
2682 the firewall by an appropriate pseudonym for that host.
2690Fielding & Reschke Standards Track [Page 48]
2692RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2695 An intermediary MAY combine an ordered subsequence of Via header
2696 field entries into a single such entry if the entries have identical
2697 received-protocol values. For example,
2699 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2701 could be collapsed to
2703 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2705 A sender SHOULD NOT combine multiple entries unless they are all
2706 under the same organizational control and the hosts have already been
2707 replaced by pseudonyms. A sender MUST NOT combine entries that have
2708 different received-protocol values.
27105.7.2. Transformations
2712 Some intermediaries include features for transforming messages and
2713 their payloads. A proxy might, for example, convert between image
2714 formats in order to save cache space or to reduce the amount of
2715 traffic on a slow link. However, operational problems might occur
2716 when these transformations are applied to payloads intended for
2717 critical applications, such as medical imaging or scientific data
2718 analysis, particularly when integrity checks or digital signatures
2719 are used to ensure that the payload received is identical to the
2722 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
2723 designed or configured to modify messages in a semantically
2724 meaningful way (i.e., modifications, beyond those required by normal
2725 HTTP processing, that change the message in a way that would be
2726 significant to the original sender or potentially significant to
2727 downstream recipients). For example, a transforming proxy might be
2728 acting as a shared annotation server (modifying responses to include
2729 references to a local annotation database), a malware filter, a
2730 format transcoder, or a privacy filter. Such transformations are
2731 presumed to be desired by whichever client (or client organization)
2734 If a proxy receives a request-target with a host name that is not a
2735 fully qualified domain name, it MAY add its own domain to the host
2736 name it received when forwarding the request. A proxy MUST NOT
2737 change the host name if the request-target contains a fully qualified
2746Fielding & Reschke Standards Track [Page 49]
2748RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2751 A proxy MUST NOT modify the "absolute-path" and "query" parts of the
2752 received request-target when forwarding it to the next inbound
2753 server, except as noted above to replace an empty path with "/" or
2756 A proxy MAY modify the message body through application or removal of
2757 a transfer coding (Section 4).
2759 A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
2760 a message that contains a no-transform cache-control directive
2761 (Section 5.2 of [RFC7234]).
2763 A proxy MAY transform the payload of a message that does not contain
2764 a no-transform cache-control directive. A proxy that transforms a
2765 payload MUST add a Warning header field with the warn-code of 214
2766 ("Transformation Applied") if one is not already in the message (see
2767 Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
2768 200 (OK) response can further inform downstream recipients that a
2769 transformation has been applied by changing the response status code
2770 to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
2772 A proxy SHOULD NOT modify header fields that provide information
2773 about the endpoints of the communication chain, the resource state,
2774 or the selected representation (other than the payload) unless the
2775 field's definition specifically allows such modification or the
2776 modification is deemed necessary for privacy or security.
27786. Connection Management
2780 HTTP messaging is independent of the underlying transport- or
2781 session-layer connection protocol(s). HTTP only presumes a reliable
2782 transport with in-order delivery of requests and the corresponding
2783 in-order delivery of responses. The mapping of HTTP request and
2784 response structures onto the data units of an underlying transport
2785 protocol is outside the scope of this specification.
2787 As described in Section 5.2, the specific connection protocols to be
2788 used for an HTTP interaction are determined by client configuration
2789 and the target URI. For example, the "http" URI scheme
2790 (Section 2.7.1) indicates a default connection of TCP over IP, with a
2791 default TCP port of 80, but the client might be configured to use a
2792 proxy via some other connection, port, or protocol.
2802Fielding & Reschke Standards Track [Page 50]
2804RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2807 HTTP implementations are expected to engage in connection management,
2808 which includes maintaining the state of current connections,
2809 establishing a new connection or reusing an existing connection,
2810 processing messages received on a connection, detecting connection
2811 failures, and closing each connection. Most clients maintain
2812 multiple connections in parallel, including more than one connection
2813 per server endpoint. Most servers are designed to maintain thousands
2814 of concurrent connections, while controlling request queues to enable
2815 fair use and detect denial-of-service attacks.
2819 The "Connection" header field allows the sender to indicate desired
2820 control options for the current connection. In order to avoid
2821 confusing downstream recipients, a proxy or gateway MUST remove or
2822 replace any received connection options before forwarding the
2825 When a header field aside from Connection is used to supply control
2826 information for or about the current connection, the sender MUST list
2827 the corresponding field-name within the Connection header field. A
2828 proxy or gateway MUST parse a received Connection header field before
2829 a message is forwarded and, for each connection-option in this field,
2830 remove any header field(s) from the message with the same name as the
2831 connection-option, and then remove the Connection header field itself
2832 (or replace it with the intermediary's own connection options for the
2835 Hence, the Connection header field provides a declarative way of
2836 distinguishing header fields that are only intended for the immediate
2837 recipient ("hop-by-hop") from those fields that are intended for all
2838 recipients on the chain ("end-to-end"), enabling the message to be
2839 self-descriptive and allowing future connection-specific extensions
2840 to be deployed without fear that they will be blindly forwarded by
2841 older intermediaries.
2843 The Connection header field's value has the following grammar:
2845 Connection = 1#connection-option
2846 connection-option = token
2848 Connection options are case-insensitive.
2850 A sender MUST NOT send a connection option corresponding to a header
2851 field that is intended for all recipients of the payload. For
2852 example, Cache-Control is never appropriate as a connection option
2853 (Section 5.2 of [RFC7234]).
2858Fielding & Reschke Standards Track [Page 51]
2860RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2863 The connection options do not always correspond to a header field
2864 present in the message, since a connection-specific header field
2865 might not be needed if there are no parameters associated with a
2866 connection option. In contrast, a connection-specific header field
2867 that is received without a corresponding connection option usually
2868 indicates that the field has been improperly forwarded by an
2869 intermediary and ought to be ignored by the recipient.
2871 When defining new connection options, specification authors ought to
2872 survey existing header field names and ensure that the new connection
2873 option does not share the same name as an already deployed header
2874 field. Defining a new connection option essentially reserves that
2875 potential field-name for carrying additional information related to
2876 the connection option, since it would be unwise for senders to use
2877 that field-name for anything else.
2879 The "close" connection option is defined for a sender to signal that
2880 this connection will be closed after completion of the response. For
2885 in either the request or the response header fields indicates that
2886 the sender is going to close the connection after the current
2887 request/response is complete (Section 6.6).
2889 A client that does not support persistent connections MUST send the
2890 "close" connection option in every request message.
2892 A server that does not support persistent connections MUST send the
2893 "close" connection option in every response message that does not
2894 have a 1xx (Informational) status code.
2898 It is beyond the scope of this specification to describe how
2899 connections are established via various transport- or session-layer
2900 protocols. Each connection applies to only one transport link.
2904 HTTP/1.1 defaults to the use of "persistent connections", allowing
2905 multiple requests and responses to be carried over a single
2906 connection. The "close" connection option is used to signal that a
2907 connection will not persist after the current request/response. HTTP
2908 implementations SHOULD support persistent connections.
2914Fielding & Reschke Standards Track [Page 52]
2916RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2919 A recipient determines whether a connection is persistent or not
2920 based on the most recently received message's protocol version and
2921 Connection header field (if any):
2923 o If the "close" connection option is present, the connection will
2924 not persist after the current response; else,
2926 o If the received protocol is HTTP/1.1 (or later), the connection
2927 will persist after the current response; else,
2929 o If the received protocol is HTTP/1.0, the "keep-alive" connection
2930 option is present, the recipient is not a proxy, and the recipient
2931 wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
2932 connection will persist after the current response; otherwise,
2934 o The connection will close after the current response.
2936 A client MAY send additional requests on a persistent connection
2937 until it sends or receives a "close" connection option or receives an
2938 HTTP/1.0 response without a "keep-alive" connection option.
2940 In order to remain persistent, all messages on a connection need to
2941 have a self-defined message length (i.e., one not defined by closure
2942 of the connection), as described in Section 3.3. A server MUST read
2943 the entire request message body or close the connection after sending
2944 its response, since otherwise the remaining data on a persistent
2945 connection would be misinterpreted as the next request. Likewise, a
2946 client MUST read the entire response message body if it intends to
2947 reuse the same connection for a subsequent request.
2949 A proxy server MUST NOT maintain a persistent connection with an
2950 HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
2951 discussion of the problems with the Keep-Alive header field
2952 implemented by many HTTP/1.0 clients).
2954 See Appendix A.1.2 for more information on backwards compatibility
2955 with HTTP/1.0 clients.
29576.3.1. Retrying Requests
2959 Connections can be closed at any time, with or without intention.
2960 Implementations ought to anticipate the need to recover from
2961 asynchronous close events.
2970Fielding & Reschke Standards Track [Page 53]
2972RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2975 When an inbound connection is closed prematurely, a client MAY open a
2976 new connection and automatically retransmit an aborted sequence of
2977 requests if all of those requests have idempotent methods (Section
2978 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry
2979 non-idempotent requests.
2981 A user agent MUST NOT automatically retry a request with a non-
2982 idempotent method unless it has some means to know that the request
2983 semantics are actually idempotent, regardless of the method, or some
2984 means to detect that the original request was never applied. For
2985 example, a user agent that knows (through design or configuration)
2986 that a POST request to a given resource is safe can repeat that
2987 request automatically. Likewise, a user agent designed specifically
2988 to operate on a version control repository might be able to recover
2989 from partial failure conditions by checking the target resource
2990 revision(s) after a failed connection, reverting or fixing any
2991 changes that were partially applied, and then automatically retrying
2992 the requests that failed.
2994 A client SHOULD NOT automatically retry a failed automatic retry.
2998 A client that supports persistent connections MAY "pipeline" its
2999 requests (i.e., send multiple requests without waiting for each
3000 response). A server MAY process a sequence of pipelined requests in
3001 parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
3002 but it MUST send the corresponding responses in the same order that
3003 the requests were received.
3005 A client that pipelines requests SHOULD retry unanswered requests if
3006 the connection closes before it receives all of the corresponding
3007 responses. When retrying pipelined requests after a failed
3008 connection (a connection not explicitly closed by the server in its
3009 last complete response), a client MUST NOT pipeline immediately after
3010 connection establishment, since the first remaining request in the
3011 prior pipeline might have caused an error response that can be lost
3012 again if multiple requests are sent on a prematurely closed
3013 connection (see the TCP reset problem described in Section 6.6).
3015 Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to
3016 pipelining because they can be automatically retried after a
3017 connection failure. A user agent SHOULD NOT pipeline requests after
3018 a non-idempotent method, until the final response status code for
3019 that method has been received, unless the user agent has a means to
3020 detect and recover from partial failure conditions involving the
3026Fielding & Reschke Standards Track [Page 54]
3028RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3031 An intermediary that receives pipelined requests MAY pipeline those
3032 requests when forwarding them inbound, since it can rely on the
3033 outbound user agent(s) to determine what requests can be safely
3034 pipelined. If the inbound connection fails before receiving a
3035 response, the pipelining intermediary MAY attempt to retry a sequence
3036 of requests that have yet to receive a response if the requests all
3037 have idempotent methods; otherwise, the pipelining intermediary
3038 SHOULD forward any received responses and then close the
3039 corresponding outbound connection(s) so that the outbound user
3040 agent(s) can recover accordingly.
3044 A client ought to limit the number of simultaneous open connections
3045 that it maintains to a given server.
3047 Previous revisions of HTTP gave a specific number of connections as a
3048 ceiling, but this was found to be impractical for many applications.
3049 As a result, this specification does not mandate a particular maximum
3050 number of connections but, instead, encourages clients to be
3051 conservative when opening multiple connections.
3053 Multiple connections are typically used to avoid the "head-of-line
3054 blocking" problem, wherein a request that takes significant
3055 server-side processing and/or has a large payload blocks subsequent
3056 requests on the same connection. However, each connection consumes
3057 server resources. Furthermore, using multiple connections can cause
3058 undesirable side effects in congested networks.
3060 Note that a server might reject traffic that it deems abusive or
3061 characteristic of a denial-of-service attack, such as an excessive
3062 number of open connections from a single client.
30646.5. Failures and Timeouts
3066 Servers will usually have some timeout value beyond which they will
3067 no longer maintain an inactive connection. Proxy servers might make
3068 this a higher value since it is likely that the client will be making
3069 more connections through the same proxy server. The use of
3070 persistent connections places no requirements on the length (or
3071 existence) of this timeout for either the client or the server.
3073 A client or server that wishes to time out SHOULD issue a graceful
3074 close on the connection. Implementations SHOULD constantly monitor
3075 open connections for a received closure signal and respond to it as
3076 appropriate, since prompt closure of both sides of a connection
3077 enables allocated system resources to be reclaimed.
3082Fielding & Reschke Standards Track [Page 55]
3084RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3087 A client, server, or proxy MAY close the transport connection at any
3088 time. For example, a client might have started to send a new request
3089 at the same time that the server has decided to close the "idle"
3090 connection. From the server's point of view, the connection is being
3091 closed while it was idle, but from the client's point of view, a
3092 request is in progress.
3094 A server SHOULD sustain persistent connections, when possible, and
3095 allow the underlying transport's flow-control mechanisms to resolve
3096 temporary overloads, rather than terminate connections with the
3097 expectation that clients will retry. The latter technique can
3098 exacerbate network congestion.
3100 A client sending a message body SHOULD monitor the network connection
3101 for an error response while it is transmitting the request. If the
3102 client sees a response that indicates the server does not wish to
3103 receive the message body and is closing the connection, the client
3104 SHOULD immediately cease transmitting the body and close its side of
3109 The Connection header field (Section 6.1) provides a "close"
3110 connection option that a sender SHOULD send when it wishes to close
3111 the connection after the current request/response pair.
3113 A client that sends a "close" connection option MUST NOT send further
3114 requests on that connection (after the one containing "close") and
3115 MUST close the connection after reading the final response message
3116 corresponding to this request.
3118 A server that receives a "close" connection option MUST initiate a
3119 close of the connection (see below) after it sends the final response
3120 to the request that contained "close". The server SHOULD send a
3121 "close" connection option in its final response on that connection.
3122 The server MUST NOT process any further requests received on that
3125 A server that sends a "close" connection option MUST initiate a close
3126 of the connection (see below) after it sends the response containing
3127 "close". The server MUST NOT process any further requests received
3130 A client that receives a "close" connection option MUST cease sending
3131 requests on that connection and close the connection after reading
3132 the response message containing the "close"; if additional pipelined
3133 requests had been sent on the connection, the client SHOULD NOT
3134 assume that they will be processed by the server.
3138Fielding & Reschke Standards Track [Page 56]
3140RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3143 If a server performs an immediate close of a TCP connection, there is
3144 a significant risk that the client will not be able to read the last
3145 HTTP response. If the server receives additional data from the
3146 client on a fully closed connection, such as another request that was
3147 sent by the client before receiving the server's response, the
3148 server's TCP stack will send a reset packet to the client;
3149 unfortunately, the reset packet might erase the client's
3150 unacknowledged input buffers before they can be read and interpreted
3151 by the client's HTTP parser.
3153 To avoid the TCP reset problem, servers typically close a connection
3154 in stages. First, the server performs a half-close by closing only
3155 the write side of the read/write connection. The server then
3156 continues to read from the connection until it receives a
3157 corresponding close by the client, or until the server is reasonably
3158 certain that its own TCP stack has received the client's
3159 acknowledgement of the packet(s) containing the server's last
3160 response. Finally, the server fully closes the connection.
3162 It is unknown whether the reset problem is exclusive to TCP or might
3163 also be found in other transport connection protocols.
3167 The "Upgrade" header field is intended to provide a simple mechanism
3168 for transitioning from HTTP/1.1 to some other protocol on the same
3169 connection. A client MAY send a list of protocols in the Upgrade
3170 header field of a request to invite the server to switch to one or
3171 more of those protocols, in order of descending preference, before
3172 sending the final response. A server MAY ignore a received Upgrade
3173 header field if it wishes to continue using the current protocol on
3174 that connection. Upgrade cannot be used to insist on a protocol
3177 Upgrade = 1#protocol
3179 protocol = protocol-name ["/" protocol-version]
3180 protocol-name = token
3181 protocol-version = token
3183 A server that sends a 101 (Switching Protocols) response MUST send an
3184 Upgrade header field to indicate the new protocol(s) to which the
3185 connection is being switched; if multiple protocol layers are being
3186 switched, the sender MUST list the protocols in layer-ascending
3187 order. A server MUST NOT switch to a protocol that was not indicated
3188 by the client in the corresponding request's Upgrade header field. A
3194Fielding & Reschke Standards Track [Page 57]
3196RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3199 server MAY choose to ignore the order of preference indicated by the
3200 client and select the new protocol(s) based on other factors, such as
3201 the nature of the request or the current load on the server.
3203 A server that sends a 426 (Upgrade Required) response MUST send an
3204 Upgrade header field to indicate the acceptable protocols, in order
3205 of descending preference.
3207 A server MAY send an Upgrade header field in any other response to
3208 advertise that it implements support for upgrading to the listed
3209 protocols, in order of descending preference, when appropriate for a
3212 The following is a hypothetical example sent by a client:
3214 GET /hello.txt HTTP/1.1
3215 Host: www.example.com
3217 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3220 The capabilities and nature of the application-level communication
3221 after the protocol change is entirely dependent upon the new
3222 protocol(s) chosen. However, immediately after sending the 101
3223 (Switching Protocols) response, the server is expected to continue
3224 responding to the original request as if it had received its
3225 equivalent within the new protocol (i.e., the server still has an
3226 outstanding request to satisfy after the protocol has been changed,
3227 and is expected to do so without requiring the request to be
3230 For example, if the Upgrade header field is received in a GET request
3231 and the server decides to switch protocols, it first responds with a
3232 101 (Switching Protocols) message in HTTP/1.1 and then immediately
3233 follows that with the new protocol's equivalent of a response to a
3234 GET on the target resource. This allows a connection to be upgraded
3235 to protocols with the same semantics as HTTP without the latency cost
3236 of an additional round trip. A server MUST NOT switch protocols
3237 unless the received message semantics can be honored by the new
3238 protocol; an OPTIONS request can be honored by any protocol.
3250Fielding & Reschke Standards Track [Page 58]
3252RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3255 The following is an example response to the above hypothetical
3258 HTTP/1.1 101 Switching Protocols
3262 [... data stream switches to HTTP/2.0 with an appropriate response
3263 (as defined by new protocol) to the "GET /hello.txt" request ...]
3265 When Upgrade is sent, the sender MUST also send a Connection header
3266 field (Section 6.1) that contains an "upgrade" connection option, in
3267 order to prevent Upgrade from being accidentally forwarded by
3268 intermediaries that might not implement the listed protocols. A
3269 server MUST ignore an Upgrade header field that is received in an
3272 A client cannot begin using an upgraded protocol on the connection
3273 until it has completely sent the request message (i.e., the client
3274 can't change the protocol it is sending in the middle of a message).
3275 If a server receives both an Upgrade and an Expect header field with
3276 the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
3277 server MUST send a 100 (Continue) response before sending a 101
3278 (Switching Protocols) response.
3280 The Upgrade header field only applies to switching protocols on top
3281 of the existing connection; it cannot be used to switch the
3282 underlying connection (transport) protocol, nor to switch the
3283 existing communication to a different connection. For those
3284 purposes, it is more appropriate to use a 3xx (Redirection) response
3285 (Section 6.4 of [RFC7231]).
3287 This specification only defines the protocol name "HTTP" for use by
3288 the family of Hypertext Transfer Protocols, as defined by the HTTP
3289 version rules of Section 2.6 and future updates to this
3290 specification. Additional tokens ought to be registered with IANA
3291 using the registration procedure defined in Section 8.6.
32937. ABNF List Extension: #rule
3295 A #rule extension to the ABNF rules of [RFC5234] is used to improve
3296 readability in the definitions of some header field values.
3298 A construct "#" is defined, similar to "*", for defining
3299 comma-delimited lists of elements. The full form is "<n>#<m>element"
3300 indicating at least <n> and at most <m> elements, each separated by a
3301 single comma (",") and optional whitespace (OWS).
3306Fielding & Reschke Standards Track [Page 59]
3308RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3311 In any production that uses the list construct, a sender MUST NOT
3312 generate empty list elements. In other words, a sender MUST generate
3313 lists that satisfy the following syntax:
3315 1#element => element *( OWS "," OWS element )
3319 #element => [ 1#element ]
3321 and for n >= 1 and m > 1:
3323 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
3325 For compatibility with legacy list rules, a recipient MUST parse and
3326 ignore a reasonable number of empty list elements: enough to handle
3327 common mistakes by senders that merge values, but not so much that
3328 they could be used as a denial-of-service mechanism. In other words,
3329 a recipient MUST accept lists that satisfy the following syntax:
3331 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
3333 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
3335 Empty elements do not contribute to the count of elements present.
3336 For example, given these ABNF productions:
3338 example-list = 1#example-list-elmt
3339 example-list-elmt = token ; see Section 3.2.6
3341 Then the following are valid values for example-list (not including
3342 the double quotes, which are present for delimitation only):
3346 "foo , ,bar,charlie "
3348 In contrast, the following values would be invalid, since at least
3349 one non-empty element is required by the example-list production:
3355 Appendix B shows the collected ABNF for recipients after the list
3356 constructs have been expanded.
3362Fielding & Reschke Standards Track [Page 60]
3364RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
33678. IANA Considerations
33698.1. Header Field Registration
3371 HTTP header fields are registered within the "Message Headers"
3372 registry maintained at
3373 <http://www.iana.org/assignments/message-headers/>.
3375 This document defines the following HTTP header fields, so the
3376 "Permanent Message Header Field Names" registry has been updated
3377 accordingly (see [BCP90]).
3379 +-------------------+----------+----------+---------------+
3380 | Header Field Name | Protocol | Status | Reference |
3381 +-------------------+----------+----------+---------------+
3382 | Connection | http | standard | Section 6.1 |
3383 | Content-Length | http | standard | Section 3.3.2 |
3384 | Host | http | standard | Section 5.4 |
3385 | TE | http | standard | Section 4.3 |
3386 | Trailer | http | standard | Section 4.4 |
3387 | Transfer-Encoding | http | standard | Section 3.3.1 |
3388 | Upgrade | http | standard | Section 6.7 |
3389 | Via | http | standard | Section 5.7.1 |
3390 +-------------------+----------+----------+---------------+
3392 Furthermore, the header field-name "Close" has been registered as
3393 "reserved", since using that name as an HTTP header field might
3394 conflict with the "close" connection option of the Connection header
3395 field (Section 6.1).
3397 +-------------------+----------+----------+-------------+
3398 | Header Field Name | Protocol | Status | Reference |
3399 +-------------------+----------+----------+-------------+
3400 | Close | http | reserved | Section 8.1 |
3401 +-------------------+----------+----------+-------------+
3403 The change controller is: "IETF (iesg@ietf.org) - Internet
3404 Engineering Task Force".
3418Fielding & Reschke Standards Track [Page 61]
3420RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
34238.2. URI Scheme Registration
3425 IANA maintains the registry of URI Schemes [BCP115] at
3426 <http://www.iana.org/assignments/uri-schemes/>.
3428 This document defines the following URI schemes, so the "Permanent
3429 URI Schemes" registry has been updated accordingly.
3431 +------------+------------------------------------+---------------+
3432 | URI Scheme | Description | Reference |
3433 +------------+------------------------------------+---------------+
3434 | http | Hypertext Transfer Protocol | Section 2.7.1 |
3435 | https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
3436 +------------+------------------------------------+---------------+
34388.3. Internet Media Type Registration
3440 IANA maintains the registry of Internet media types [BCP13] at
3441 <http://www.iana.org/assignments/media-types>.
3443 This document serves as the specification for the Internet media
3444 types "message/http" and "application/http". The following has been
3445 registered with IANA.
34478.3.1. Internet Media Type message/http
3449 The message/http type can be used to enclose a single HTTP request or
3450 response message, provided that it obeys the MIME restrictions for
3451 all "message" types regarding line length and encodings.
3457 Required parameters: N/A
3459 Optional parameters: version, msgtype
3461 version: The HTTP-version number of the enclosed message (e.g.,
3462 "1.1"). If not present, the version can be determined from the
3463 first line of the body.
3465 msgtype: The message type -- "request" or "response". If not
3466 present, the type can be determined from the first line of the
3469 Encoding considerations: only "7bit", "8bit", or "binary" are
3474Fielding & Reschke Standards Track [Page 62]
3476RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3479 Security considerations: see Section 9
3481 Interoperability considerations: N/A
3483 Published specification: This specification (see Section 8.3.1).
3485 Applications that use this media type: N/A
3487 Fragment identifier considerations: N/A
3489 Additional information:
3491 Magic number(s): N/A
3493 Deprecated alias names for this type: N/A
3495 File extension(s): N/A
3497 Macintosh file type code(s): N/A
3499 Person and email address to contact for further information:
3500 See Authors' Addresses section.
3502 Intended usage: COMMON
3504 Restrictions on usage: N/A
3506 Author: See Authors' Addresses section.
3508 Change controller: IESG
35108.3.2. Internet Media Type application/http
3512 The application/http type can be used to enclose a pipeline of one or
3513 more HTTP request or response messages (not intermixed).
3515 Type name: application
3519 Required parameters: N/A
3521 Optional parameters: version, msgtype
3523 version: The HTTP-version number of the enclosed messages (e.g.,
3524 "1.1"). If not present, the version can be determined from the
3525 first line of the body.
3530Fielding & Reschke Standards Track [Page 63]
3532RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3535 msgtype: The message type -- "request" or "response". If not
3536 present, the type can be determined from the first line of the
3539 Encoding considerations: HTTP messages enclosed by this type are in
3540 "binary" format; use of an appropriate Content-Transfer-Encoding
3541 is required when transmitted via email.
3543 Security considerations: see Section 9
3545 Interoperability considerations: N/A
3547 Published specification: This specification (see Section 8.3.2).
3549 Applications that use this media type: N/A
3551 Fragment identifier considerations: N/A
3553 Additional information:
3555 Deprecated alias names for this type: N/A
3557 Magic number(s): N/A
3559 File extension(s): N/A
3561 Macintosh file type code(s): N/A
3563 Person and email address to contact for further information:
3564 See Authors' Addresses section.
3566 Intended usage: COMMON
3568 Restrictions on usage: N/A
3570 Author: See Authors' Addresses section.
3572 Change controller: IESG
35748.4. Transfer Coding Registry
3576 The "HTTP Transfer Coding Registry" defines the namespace for
3577 transfer coding names. It is maintained at
3578 <http://www.iana.org/assignments/http-parameters>.
3586Fielding & Reschke Standards Track [Page 64]
3588RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3593 Registrations MUST include the following fields:
3599 o Pointer to specification text
3601 Names of transfer codings MUST NOT overlap with names of content
3602 codings (Section 3.1.2.1 of [RFC7231]) unless the encoding
3603 transformation is identical, as is the case for the compression
3604 codings defined in Section 4.2.
3606 Values to be added to this namespace require IETF Review (see Section
3607 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
3608 defined in this specification.
3610 Use of program names for the identification of encoding formats is
3611 not desirable and is discouraged for future encodings.
3615 The "HTTP Transfer Coding Registry" has been updated with the
3616 registrations below:
3618 +------------+--------------------------------------+---------------+
3619 | Name | Description | Reference |
3620 +------------+--------------------------------------+---------------+
3621 | chunked | Transfer in a series of chunks | Section 4.1 |
3622 | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
3623 | deflate | "deflate" compressed data | Section 4.2.2 |
3624 | | ([RFC1951]) inside the "zlib" data | |
3625 | | format ([RFC1950]) | |
3626 | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
3627 | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
3628 | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
3629 +------------+--------------------------------------+---------------+
3642Fielding & Reschke Standards Track [Page 65]
3644RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
36478.5. Content Coding Registration
3649 IANA maintains the "HTTP Content Coding Registry" at
3650 <http://www.iana.org/assignments/http-parameters>.
3652 The "HTTP Content Coding Registry" has been updated with the
3653 registrations below:
3655 +------------+--------------------------------------+---------------+
3656 | Name | Description | Reference |
3657 +------------+--------------------------------------+---------------+
3658 | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
3659 | deflate | "deflate" compressed data | Section 4.2.2 |
3660 | | ([RFC1951]) inside the "zlib" data | |
3661 | | format ([RFC1950]) | |
3662 | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
3663 | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
3664 | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
3665 +------------+--------------------------------------+---------------+
36678.6. Upgrade Token Registry
3669 The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
3670 defines the namespace for protocol-name tokens used to identify
3671 protocols in the Upgrade header field. The registry is maintained at
3672 <http://www.iana.org/assignments/http-upgrade-tokens>.
3676 Each registered protocol name is associated with contact information
3677 and an optional set of specifications that details how the connection
3678 will be processed after it has been upgraded.
3680 Registrations happen on a "First Come First Served" basis (see
3681 Section 4.1 of [RFC5226]) and are subject to the following rules:
3683 1. A protocol-name token, once registered, stays registered forever.
3685 2. The registration MUST name a responsible party for the
3688 3. The registration MUST name a point of contact.
3690 4. The registration MAY name a set of specifications associated with
3691 that token. Such specifications need not be publicly available.
3693 5. The registration SHOULD name a set of expected "protocol-version"
3694 tokens associated with that token at the time of registration.
3698Fielding & Reschke Standards Track [Page 66]
3700RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3703 6. The responsible party MAY change the registration at any time.
3704 The IANA will keep a record of all such changes, and make them
3705 available upon request.
3707 7. The IESG MAY reassign responsibility for a protocol token. This
3708 will normally only be used in the case when a responsible party
3709 cannot be contacted.
3711 This registration procedure for HTTP Upgrade Tokens replaces that
3712 previously defined in Section 7.2 of [RFC2817].
37148.6.2. Upgrade Token Registration
3716 The "HTTP" entry in the upgrade token registry has been updated with
3717 the registration below:
3719 +-------+----------------------+----------------------+-------------+
3720 | Value | Description | Expected Version | Reference |
3722 +-------+----------------------+----------------------+-------------+
3723 | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
3724 | | Protocol | (e.g, "2.0") | |
3725 +-------+----------------------+----------------------+-------------+
3727 The responsible party is: "IETF (iesg@ietf.org) - Internet
3728 Engineering Task Force".
37309. Security Considerations
3732 This section is meant to inform developers, information providers,
3733 and users of known security considerations relevant to HTTP message
3734 syntax, parsing, and routing. Security considerations about HTTP
3735 semantics and payloads are addressed in [RFC7231].
37379.1. Establishing Authority
3739 HTTP relies on the notion of an authoritative response: a response
3740 that has been determined by (or at the direction of) the authority
3741 identified within the target URI to be the most appropriate response
3742 for that request given the state of the target resource at the time
3743 of response message origination. Providing a response from a
3744 non-authoritative source, such as a shared cache, is often useful to
3745 improve performance and availability, but only to the extent that the
3746 source can be trusted or the distrusted response can be safely used.
3748 Unfortunately, establishing authority can be difficult. For example,
3749 phishing is an attack on the user's perception of authority, where
3750 that perception can be misled by presenting similar branding in
3754Fielding & Reschke Standards Track [Page 67]
3756RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3759 hypertext, possibly aided by userinfo obfuscating the authority
3760 component (see Section 2.7.1). User agents can reduce the impact of
3761 phishing attacks by enabling users to easily inspect a target URI
3762 prior to making an action, by prominently distinguishing (or
3763 rejecting) userinfo when present, and by not sending stored
3764 credentials and cookies when the referring document is from an
3765 unknown or untrusted source.
3767 When a registered name is used in the authority component, the "http"
3768 URI scheme (Section 2.7.1) relies on the user's local name resolution
3769 service to determine where it can find authoritative responses. This
3770 means that any attack on a user's network host table, cached names,
3771 or name resolution libraries becomes an avenue for attack on
3772 establishing authority. Likewise, the user's choice of server for
3773 Domain Name Service (DNS), and the hierarchy of servers from which it
3774 obtains resolution results, could impact the authenticity of address
3775 mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
3776 improve authenticity.
3778 Furthermore, after an IP address is obtained, establishing authority
3779 for an "http" URI is vulnerable to attacks on Internet Protocol
3782 The "https" scheme (Section 2.7.2) is intended to prevent (or at
3783 least reveal) many of these potential attacks on establishing
3784 authority, provided that the negotiated TLS connection is secured and
3785 the client properly verifies that the communicating server's identity
3786 matches the target URI's authority component (see [RFC2818]).
3787 Correctly implementing such verification can be difficult (see
37909.2. Risks of Intermediaries
3792 By their very nature, HTTP intermediaries are men-in-the-middle and,
3793 thus, represent an opportunity for man-in-the-middle attacks.
3794 Compromise of the systems on which the intermediaries run can result
3795 in serious security and privacy problems. Intermediaries might have
3796 access to security-related information, personal information about
3797 individual users and organizations, and proprietary information
3798 belonging to users and content providers. A compromised
3799 intermediary, or an intermediary implemented or configured without
3800 regard to security and privacy considerations, might be used in the
3801 commission of a wide range of potential attacks.
3803 Intermediaries that contain a shared cache are especially vulnerable
3804 to cache poisoning attacks, as described in Section 8 of [RFC7234].
3810Fielding & Reschke Standards Track [Page 68]
3812RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3815 Implementers need to consider the privacy and security implications
3816 of their design and coding decisions, and of the configuration
3817 options they provide to operators (especially the default
3820 Users need to be aware that intermediaries are no more trustworthy
3821 than the people who run them; HTTP itself cannot solve this problem.
38239.3. Attacks via Protocol Element Length
3825 Because HTTP uses mostly textual, character-delimited fields, parsers
3826 are often vulnerable to attacks based on sending very long (or very
3827 slow) streams of data, particularly where an implementation is
3828 expecting a protocol element with no predefined length.
3830 To promote interoperability, specific recommendations are made for
3831 minimum size limits on request-line (Section 3.1.1) and header fields
3832 (Section 3.2). These are minimum recommendations, chosen to be
3833 supportable even by implementations with limited resources; it is
3834 expected that most implementations will choose substantially higher
3837 A server can reject a message that has a request-target that is too
3838 long (Section 6.5.12 of [RFC7231]) or a request payload that is too
3839 large (Section 6.5.11 of [RFC7231]). Additional status codes related
3840 to capacity limits have been defined by extensions to HTTP [RFC6585].
3842 Recipients ought to carefully limit the extent to which they process
3843 other protocol elements, including (but not limited to) request
3844 methods, response status phrases, header field-names, numeric values,
3845 and body chunks. Failure to limit such processing can result in
3846 buffer overflows, arithmetic overflows, or increased vulnerability to
3847 denial-of-service attacks.
38499.4. Response Splitting
3851 Response splitting (a.k.a, CRLF injection) is a common technique,
3852 used in various attacks on Web usage, that exploits the line-based
3853 nature of HTTP message framing and the ordered association of
3854 requests to responses on persistent connections [Klein]. This
3855 technique can be particularly damaging when the requests pass through
3858 Response splitting exploits a vulnerability in servers (usually
3859 within an application server) where an attacker can send encoded data
3860 within some parameter of the request that is later decoded and echoed
3861 within any of the response header fields of the response. If the
3862 decoded data is crafted to look like the response has ended and a
3866Fielding & Reschke Standards Track [Page 69]
3868RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3871 subsequent response has begun, the response has been split and the
3872 content within the apparent second response is controlled by the
3873 attacker. The attacker can then make any other request on the same
3874 persistent connection and trick the recipients (including
3875 intermediaries) into believing that the second half of the split is
3876 an authoritative answer to the second request.
3878 For example, a parameter within the request-target might be read by
3879 an application server and reused within a redirect, resulting in the
3880 same parameter being echoed in the Location header field of the
3881 response. If the parameter is decoded by the application and not
3882 properly encoded when placed in the response field, the attacker can
3883 send encoded CRLF octets and other content that will make the
3884 application's single response look like two or more responses.
3886 A common defense against response splitting is to filter requests for
3887 data that looks like encoded CR and LF (e.g., "%0D" and "%0A").
3888 However, that assumes the application server is only performing URI
3889 decoding, rather than more obscure data transformations like charset
3890 transcoding, XML entity translation, base64 decoding, sprintf
3891 reformatting, etc. A more effective mitigation is to prevent
3892 anything other than the server's core protocol libraries from sending
3893 a CR or LF within the header section, which means restricting the
3894 output of header fields to APIs that filter for bad octets and not
3895 allowing application servers to write directly to the protocol
38989.5. Request Smuggling
3900 Request smuggling ([Linhart]) is a technique that exploits
3901 differences in protocol parsing among various recipients to hide
3902 additional requests (which might otherwise be blocked or disabled by
3903 policy) within an apparently harmless request. Like response
3904 splitting, request smuggling can lead to a variety of attacks on HTTP
3907 This specification has introduced new requirements on request
3908 parsing, particularly with regard to message framing in
3909 Section 3.3.3, to reduce the effectiveness of request smuggling.
39119.6. Message Integrity
3913 HTTP does not define a specific mechanism for ensuring message
3914 integrity, instead relying on the error-detection ability of
3915 underlying transport protocols and the use of length or
3916 chunk-delimited framing to detect completeness. Additional integrity
3917 mechanisms, such as hash functions or digital signatures applied to
3918 the content, can be selectively added to messages via extensible
3922Fielding & Reschke Standards Track [Page 70]
3924RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3927 metadata header fields. Historically, the lack of a single integrity
3928 mechanism has been justified by the informal nature of most HTTP
3929 communication. However, the prevalence of HTTP as an information
3930 access mechanism has resulted in its increasing use within
3931 environments where verification of message integrity is crucial.
3933 User agents are encouraged to implement configurable means for
3934 detecting and reporting failures of message integrity such that those
3935 means can be enabled within environments for which integrity is
3936 necessary. For example, a browser being used to view medical history
3937 or drug interaction information needs to indicate to the user when
3938 such information is detected by the protocol to be incomplete,
3939 expired, or corrupted during transfer. Such mechanisms might be
3940 selectively enabled via user agent extensions or the presence of
3941 message integrity metadata in a response. At a minimum, user agents
3942 ought to provide some indication that allows a user to distinguish
3943 between a complete and incomplete response message (Section 3.4) when
3944 such verification is desired.
39469.7. Message Confidentiality
3948 HTTP relies on underlying transport protocols to provide message
3949 confidentiality when that is desired. HTTP has been specifically
3950 designed to be independent of the transport protocol, such that it
3951 can be used over many different forms of encrypted connection, with
3952 the selection of such transports being identified by the choice of
3953 URI scheme or within user agent configuration.
3955 The "https" scheme can be used to identify resources that require a
3956 confidential connection, as described in Section 2.7.2.
39589.8. Privacy of Server Log Information
3960 A server is in the position to save personal data about a user's
3961 requests over time, which might identify their reading patterns or
3962 subjects of interest. In particular, log information gathered at an
3963 intermediary often contains a history of user agent interaction,
3964 across a multitude of sites, that can be traced to individual users.
3966 HTTP log information is confidential in nature; its handling is often
3967 constrained by laws and regulations. Log information needs to be
3968 securely stored and appropriate guidelines followed for its analysis.
3969 Anonymization of personal information within individual entries
3970 helps, but it is generally not sufficient to prevent real log traces
3971 from being re-identified based on correlation with other access
3972 characteristics. As such, access traces that are keyed to a specific
3973 client are unsafe to publish even if the key is pseudonymous.
3978Fielding & Reschke Standards Track [Page 71]
3980RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3983 To minimize the risk of theft or accidental publication, log
3984 information ought to be purged of personally identifiable
3985 information, including user identifiers, IP addresses, and
3986 user-provided query parameters, as soon as that information is no
3987 longer necessary to support operational needs for security, auditing,
3992 This edition of HTTP/1.1 builds on the many contributions that went
3993 into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
3994 substantial contributions made by the previous authors, editors, and
3995 Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
3996 Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
3997 and Paul J. Leach. Mark Nottingham oversaw this effort as Working
4000 Since 1999, the following contributors have helped improve the HTTP
4001 specification by reporting bugs, asking smart questions, drafting or
4002 reviewing text, and evaluating open issues:
4004 Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,
4005 Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek
4006 Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
4007 Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
4008 Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
4009 Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander
4010 Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin
4011 Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern
4012 Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
4013 Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens,
4014 Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann,
4015 Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus
4016 Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg,
4017 Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave
4018 Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty,
4019 Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan
4020 Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D.
4021 Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik
4022 Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian
4023 Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser,
4024 Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham,
4025 Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz
4026 Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
4027 Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,
4028 Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido
4029 Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll,
4030 James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
4034Fielding & Reschke Standards Track [Page 72]
4036RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4039 Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with
4040 the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim
4041 Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel
4042 Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp,
4043 John Panzer, John Schneider, John Stracke, John Sullivan, Jonas
4044 Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore,
4045 Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien
4046 Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin
4047 James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith
4048 Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin
4049 Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault,
4050 Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark
4051 Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler,
4052 Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson,
4053 Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge,
4054 Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael
4055 Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen,
4056 Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin,
4057 Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
4058 Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater,
4059 Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.
4060 Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska,
4061 Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil
4062 Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-
4063 Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto
4064 Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby
4065 Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
4066 O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
4067 Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
4068 Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
4069 Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence
4070 (who maintained the original issues list), Sean B. Palmer, Sean
4071 Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon
4072 Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane
4073 Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart
4074 Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares,
4075 Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya
4076 Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas
4077 Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim
4078 Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent
4079 Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez
4080 Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang,
4081 Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang,
4082 Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
4083 editor team), Zed A. Shaw, and Zhong Yu.
4085 See Section 16 of [RFC2616] for additional acknowledgements from
4090Fielding & Reschke Standards Track [Page 73]
4092RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
409711.1. Normative References
4099 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
4100 RFC 793, September 1981.
4102 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
4103 Format Specification version 3.3", RFC 1950, May 1996.
4105 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
4106 Specification version 1.3", RFC 1951, May 1996.
4108 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
4109 G. Randers-Pehrson, "GZIP file format specification
4110 version 4.3", RFC 1952, May 1996.
4112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4113 Requirement Levels", BCP 14, RFC 2119, March 1997.
4115 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
4116 "Uniform Resource Identifier (URI): Generic Syntax",
4117 STD 66, RFC 3986, January 2005.
4119 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
4120 Syntax Specifications: ABNF", STD 68, RFC 5234,
4123 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4124 Transfer Protocol (HTTP/1.1): Semantics and Content",
4125 RFC 7231, June 2014.
4127 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4128 Transfer Protocol (HTTP/1.1): Conditional Requests",
4129 RFC 7232, June 2014.
4131 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
4132 "Hypertext Transfer Protocol (HTTP/1.1): Range
4133 Requests", RFC 7233, June 2014.
4135 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
4136 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
4137 RFC 7234, June 2014.
4139 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4140 Transfer Protocol (HTTP/1.1): Authentication",
4141 RFC 7235, June 2014.
4146Fielding & Reschke Standards Track [Page 74]
4148RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4151 [USASCII] American National Standards Institute, "Coded Character
4152 Set -- 7-bit American Standard Code for Information
4153 Interchange", ANSI X3.4, 1986.
4155 [Welch] Welch, T., "A Technique for High-Performance Data
4156 Compression", IEEE Computer 17(6), June 1984.
415811.2. Informative References
4160 [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
4161 and Registration Procedures for New URI Schemes",
4162 BCP 115, RFC 4395, February 2006.
4164 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
4165 Specifications and Registration Procedures", BCP 13,
4166 RFC 6838, January 2013.
4168 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
4169 Procedures for Message Header Fields", BCP 90,
4170 RFC 3864, September 2004.
4172 [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R.,
4173 Boneh, D., and V. Shmatikov, "The Most Dangerous Code
4174 in the World: Validating SSL Certificates in Non-
4175 browser Software", In Proceedings of the 2012 ACM
4176 Conference on Computer and Communications Security (CCS
4177 '12), pp. 38-49, October 2012,
4178 <http://doi.acm.org/10.1145/2382196.2382204>.
4180 [ISO-8859-1] International Organization for Standardization,
4181 "Information technology -- 8-bit single-byte coded
4182 graphic character sets -- Part 1: Latin alphabet No.
4183 1", ISO/IEC 8859-1:1998, 1998.
4185 [Klein] Klein, A., "Divide and Conquer - HTTP Response
4186 Splitting, Web Cache Poisoning Attacks, and Related
4187 Topics", March 2004, <http://packetstormsecurity.com/
4188 papers/general/whitepaper_httpresponse.pdf>.
4190 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
4191 Politics", ACM Transactions on Internet
4192 Technology 1(2), November 2001,
4193 <http://arxiv.org/abs/cs.SE/0105018>.
4195 [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
4196 Request Smuggling", June 2005,
4197 <http://www.watchfire.com/news/whitepapers.aspx>.
4202Fielding & Reschke Standards Track [Page 75]
4204RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4207 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
4208 RFC 1919, March 1996.
4210 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
4211 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
4214 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
4215 Mail Extensions (MIME) Part One: Format of Internet
4216 Message Bodies", RFC 2045, November 1996.
4218 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
4219 Extensions) Part Three: Message Header Extensions for
4220 Non-ASCII Text", RFC 2047, November 1996.
4222 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
4223 T. Berners-Lee, "Hypertext Transfer Protocol --
4224 HTTP/1.1", RFC 2068, January 1997.
4226 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
4227 "Use and Interpretation of HTTP Version Numbers",
4230 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
4231 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
4232 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
4234 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
4235 HTTP/1.1", RFC 2817, May 2000.
4237 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
4239 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
4240 Replication and Caching Taxonomy", RFC 3040,
4243 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
4244 Rose, "DNS Security Introduction and Requirements",
4245 RFC 4033, March 2005.
4247 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
4248 Kerberos and NTLM HTTP Authentication in Microsoft
4249 Windows", RFC 4559, June 2006.
4251 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
4252 an IANA Considerations Section in RFCs", BCP 26,
4258Fielding & Reschke Standards Track [Page 76]
4260RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4263 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
4264 Security (TLS) Protocol Version 1.2", RFC 5246,
4267 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
4270 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
4273 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
4274 Codes", RFC 6585, April 2012.
4314Fielding & Reschke Standards Track [Page 77]
4316RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4319Appendix A. HTTP Version History
4321 HTTP has been in use since 1990. The first version, later referred
4322 to as HTTP/0.9, was a simple protocol for hypertext data transfer
4323 across the Internet, using only a single request method (GET) and no
4324 metadata. HTTP/1.0, as defined by [RFC1945], added a range of
4325 request methods and MIME-like messaging, allowing for metadata to be
4326 transferred and modifiers placed on the request/response semantics.
4327 However, HTTP/1.0 did not sufficiently take into consideration the
4328 effects of hierarchical proxies, caching, the need for persistent
4329 connections, or name-based virtual hosts. The proliferation of
4330 incompletely implemented applications calling themselves "HTTP/1.0"
4331 further necessitated a protocol version change in order for two
4332 communicating applications to determine each other's true
4335 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
4336 requirements that enable reliable implementations, adding only those
4337 features that can either be safely ignored by an HTTP/1.0 recipient
4338 or only be sent when communicating with a party advertising
4339 conformance with HTTP/1.1.
4341 HTTP/1.1 has been designed to make supporting previous versions easy.
4342 A general-purpose HTTP/1.1 server ought to be able to understand any
4343 valid request in the format of HTTP/1.0, responding appropriately
4344 with an HTTP/1.1 message that only uses features understood (or
4345 safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client
4346 can be expected to understand any valid HTTP/1.0 response.
4348 Since HTTP/0.9 did not support header fields in a request, there is
4349 no mechanism for it to support name-based virtual hosts (selection of
4350 resource by inspection of the Host header field). Any server that
4351 implements name-based virtual hosts ought to disable support for
4352 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
4353 badly constructed HTTP/1.x requests caused by a client failing to
4354 properly encode the request-target.
4356A.1. Changes from HTTP/1.0
4358 This section summarizes major differences between versions HTTP/1.0
4361A.1.1. Multihomed Web Servers
4363 The requirements that clients and servers support the Host header
4364 field (Section 5.4), report an error if it is missing from an
4365 HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among
4366 the most important changes defined by HTTP/1.1.
4370Fielding & Reschke Standards Track [Page 78]
4372RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4375 Older HTTP/1.0 clients assumed a one-to-one relationship of IP
4376 addresses and servers; there was no other established mechanism for
4377 distinguishing the intended server of a request than the IP address
4378 to which that request was directed. The Host header field was
4379 introduced during the development of HTTP/1.1 and, though it was
4380 quickly implemented by most HTTP/1.0 browsers, additional
4381 requirements were placed on all HTTP/1.1 requests in order to ensure
4382 complete adoption. At the time of this writing, most HTTP-based
4383 services are dependent upon the Host header field for targeting
4386A.1.2. Keep-Alive Connections
4388 In HTTP/1.0, each connection is established by the client prior to
4389 the request and closed by the server after sending the response.
4390 However, some implementations implement the explicitly negotiated
4391 ("Keep-Alive") version of persistent connections described in Section
4392 19.7.1 of [RFC2068].
4394 Some clients and servers might wish to be compatible with these
4395 previous approaches to persistent connections, by explicitly
4396 negotiating for them with a "Connection: keep-alive" request header
4397 field. However, some experimental implementations of HTTP/1.0
4398 persistent connections are faulty; for example, if an HTTP/1.0 proxy
4399 server doesn't understand Connection, it will erroneously forward
4400 that header field to the next inbound server, which would result in a
4403 One attempted solution was the introduction of a Proxy-Connection
4404 header field, targeted specifically at proxies. In practice, this
4405 was also unworkable, because proxies are often deployed in multiple
4406 layers, bringing about the same problem discussed above.
4408 As a result, clients are encouraged not to send the Proxy-Connection
4409 header field in any requests.
4411 Clients are also encouraged to consider the use of Connection:
4412 keep-alive in requests carefully; while they can enable persistent
4413 connections with HTTP/1.0 servers, clients using them will need to
4414 monitor the connection for "hung" requests (which indicate that the
4415 client ought stop sending the header field), and this mechanism ought
4416 not be used by clients at all when a proxy is being used.
4418A.1.3. Introduction of Transfer-Encoding
4420 HTTP/1.1 introduces the Transfer-Encoding header field
4421 (Section 3.3.1). Transfer codings need to be decoded prior to
4422 forwarding an HTTP message over a MIME-compliant protocol.
4426Fielding & Reschke Standards Track [Page 79]
4428RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4431A.2. Changes from RFC 2616
4433 HTTP's approach to error handling has been explained. (Section 2.5)
4435 The HTTP-version ABNF production has been clarified to be case-
4436 sensitive. Additionally, version numbers have been restricted to
4437 single digits, due to the fact that implementations are known to
4438 handle multi-digit version numbers incorrectly. (Section 2.6)
4440 Userinfo (i.e., username and password) are now disallowed in HTTP and
4441 HTTPS URIs, because of security issues related to their transmission
4442 on the wire. (Section 2.7.1)
4444 The HTTPS URI scheme is now defined by this specification;
4445 previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it
4446 implies end-to-end security. (Section 2.7.2)
4448 HTTP messages can be (and often are) buffered by implementations;
4449 despite it sometimes being available as a stream, HTTP is
4450 fundamentally a message-oriented protocol. Minimum supported sizes
4451 for various protocol elements have been suggested, to improve
4452 interoperability. (Section 3)
4454 Invalid whitespace around field-names is now required to be rejected,
4455 because accepting it represents a security vulnerability. The ABNF
4456 productions defining header fields now only list the field value.
4459 Rules about implicit linear whitespace between certain grammar
4460 productions have been removed; now whitespace is only allowed where
4461 specifically defined in the ABNF. (Section 3.2.3)
4463 Header fields that span multiple lines ("line folding") are
4464 deprecated. (Section 3.2.4)
4466 The NUL octet is no longer allowed in comment and quoted-string text,
4467 and handling of backslash-escaping in them has been clarified. The
4468 quoted-pair rule no longer allows escaping control characters other
4469 than HTAB. Non-US-ASCII content in header fields and the reason
4470 phrase has been obsoleted and made opaque (the TEXT rule was
4471 removed). (Section 3.2.6)
4473 Bogus Content-Length header fields are now required to be handled as
4474 errors by recipients. (Section 3.3.2)
4476 The algorithm for determining the message body length has been
4477 clarified to indicate all of the special cases (e.g., driven by
4478 methods or status codes) that affect it, and that new protocol
4482Fielding & Reschke Standards Track [Page 80]
4484RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4487 elements cannot define such special cases. CONNECT is a new, special
4488 case in determining message body length. "multipart/byteranges" is no
4489 longer a way of determining message body length detection.
4492 The "identity" transfer coding token has been removed. (Sections 3.3
4495 Chunk length does not include the count of the octets in the chunk
4496 header and trailer. Line folding in chunk extensions is disallowed.
4499 The meaning of the "deflate" content coding has been clarified.
4502 The segment + query components of RFC 3986 have been used to define
4503 the request-target, instead of abs_path from RFC 1808. The
4504 asterisk-form of the request-target is only allowed with the OPTIONS
4505 method. (Section 5.3)
4507 The term "Effective Request URI" has been introduced. (Section 5.5)
4509 Gateways do not need to generate Via header fields anymore.
4512 Exactly when "close" connection options have to be sent has been
4513 clarified. Also, "hop-by-hop" header fields are required to appear
4514 in the Connection header field; just because they're defined as hop-
4515 by-hop in this specification doesn't exempt them. (Section 6.1)
4517 The limit of two connections per server has been removed. An
4518 idempotent sequence of requests is no longer required to be retried.
4519 The requirement to retry requests under certain circumstances when
4520 the server prematurely closes the connection has been removed. Also,
4521 some extraneous requirements about when servers are allowed to close
4522 connections prematurely have been removed. (Section 6.3)
4524 The semantics of the Upgrade header field is now defined in responses
4525 other than 101 (this was incorporated from [RFC2817]). Furthermore,
4526 the ordering in the field value is now significant. (Section 6.7)
4528 Empty list elements in list productions (e.g., a list header field
4529 containing ", ,") have been deprecated. (Section 7)
4531 Registration of Transfer Codings now requires IETF Review
4538Fielding & Reschke Standards Track [Page 81]
4540RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4543 This specification now defines the Upgrade Token Registry, previously
4544 defined in Section 7.2 of [RFC2817]. (Section 8.6)
4546 The expectation to support HTTP/0.9 requests has been removed.
4549 Issues with the Keep-Alive and Proxy-Connection header fields in
4550 requests are pointed out, with use of the latter being discouraged
4551 altogether. (Appendix A.1.2)
4553Appendix B. Collected ABNF
4557 Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
4558 connection-option ] )
4560 Content-Length = 1*DIGIT
4562 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4564 HTTP-name = %x48.54.54.50 ; HTTP
4565 HTTP-version = HTTP-name "/" DIGIT "." DIGIT
4566 Host = uri-host [ ":" port ]
4568 OWS = *( SP / HTAB )
4570 RWS = 1*( SP / HTAB )
4572 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4573 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4574 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4577 URI-reference = <URI-reference, see [RFC3986], Section 4.1>
4578 Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
4580 Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
4581 ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
4584 absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
4585 absolute-form = absolute-URI
4586 absolute-path = 1*( "/" segment )
4588 authority = <authority, see [RFC3986], Section 3.2>
4589 authority-form = authority
4594Fielding & Reschke Standards Track [Page 82]
4596RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4599 chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
4600 chunk-data = 1*OCTET
4601 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
4602 chunk-ext-name = token
4603 chunk-ext-val = token / quoted-string
4604 chunk-size = 1*HEXDIG
4605 chunked-body = *chunk last-chunk trailer-part CRLF
4606 comment = "(" *( ctext / quoted-pair / comment ) ")"
4607 connection-option = token
4608 ctext = HTAB / SP / %x21-27 ; '!'-'''
4613 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
4615 field-value = *( field-content / obs-fold )
4616 field-vchar = VCHAR / obs-text
4617 fragment = <fragment, see [RFC3986], Section 3.5>
4619 header-field = field-name ":" OWS field-value OWS
4620 http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
4622 https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
4625 last-chunk = 1*"0" [ chunk-ext ] CRLF
4627 message-body = *OCTET
4630 obs-fold = CRLF 1*( SP / HTAB )
4632 origin-form = absolute-path [ "?" query ]
4634 partial-URI = relative-part [ "?" query ]
4635 path-abempty = <path-abempty, see [RFC3986], Section 3.3>
4636 port = <port, see [RFC3986], Section 3.2.3>
4637 protocol = protocol-name [ "/" protocol-version ]
4638 protocol-name = token
4639 protocol-version = token
4642 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
4645 query = <query, see [RFC3986], Section 3.4>
4646 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
4650Fielding & Reschke Standards Track [Page 83]
4652RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4655 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4657 rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4658 reason-phrase = *( HTAB / SP / VCHAR / obs-text )
4659 received-by = ( uri-host [ ":" port ] ) / pseudonym
4660 received-protocol = [ protocol-name "/" ] protocol-version
4661 relative-part = <relative-part, see [RFC3986], Section 4.2>
4662 request-line = method SP request-target SP HTTP-version CRLF
4663 request-target = origin-form / absolute-form / authority-form /
4666 scheme = <scheme, see [RFC3986], Section 3.1>
4667 segment = <segment, see [RFC3986], Section 3.3>
4668 start-line = request-line / status-line
4669 status-code = 3DIGIT
4670 status-line = HTTP-version SP status-code SP reason-phrase CRLF
4672 t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
4673 t-ranking = OWS ";" OWS "q=" rank
4674 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4675 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4677 trailer-part = *( header-field CRLF )
4678 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4680 transfer-extension = token *( OWS ";" OWS transfer-parameter )
4681 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
4683 uri-host = <host, see [RFC3986], Section 3.2.2>
4706Fielding & Reschke Standards Track [Page 84]
4708RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4714 absolute-form (of request-target) 42
4716 application/http Media Type 63
4717 asterisk-form (of request-target) 43
4718 authoritative response 67
4719 authority-form (of request-target) 42-43
4728 chunked (Coding Format) 28, 32, 36
4731 compress (Coding Format) 38
4733 Connection header field 51, 56
4734 Content-Length header field 30
4737 deflate (Coding Format) 38
4742 effective request URI 45
4751 asterisk-form 41, 43
4753 authority-form 42-43
4762Fielding & Reschke Standards Track [Page 85]
4764RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4772 connection-option 51
4818Fielding & Reschke Standards Track [Page 86]
4820RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4823 received-protocol 47
4841 Transfer-Encoding 28
4842 transfer-extension 35
4843 transfer-parameter 35
4849 gzip (Coding Format) 39
4855 Host header field 44
4860 interception proxy 11
4868 message/http Media Type 62
4874Fielding & Reschke Standards Track [Page 87]
4876RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4880 non-transforming proxy 49
4884 origin-form (of request-target) 42
4908 Trailer header field 40
4909 Transfer-Encoding header field 28
4910 transforming proxy 49
4911 transparent proxy 11
4915 Upgrade header field 57
4930Fielding & Reschke Standards Track [Page 88]
4932RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4937 Roy T. Fielding (editor)
4938 Adobe Systems Incorporated
4943 EMail: fielding@gbiv.com
4944 URI: http://roy.gbiv.com/
4947 Julian F. Reschke (editor)
4953 EMail: julian.reschke@greenbytes.de
4954 URI: http://greenbytes.de/tech/webdav/
4986Fielding & Reschke Standards Track [Page 89]