anil.recoil.org
An OCaml webserver, but the allocating version (vs httpz which doesnt)
1
2
3
4
5
6
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
12ISSN: 2070-1721
13
14
15 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
16
17Abstract
18
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.
26
27Status of This Memo
28
29 This is an Internet Standards Track document.
30
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.
36
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.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Fielding & Reschke Standards Track [Page 1]
59
60RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
61
62
63Copyright Notice
64
65 Copyright (c) 2014 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
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.
77
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
88 than English.
89
90Table of Contents
91
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
111
112
113
114Fielding & Reschke Standards Track [Page 2]
115
116RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
117
118
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
167
168
169
170Fielding & Reschke Standards Track [Page 3]
171
172RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
173
174
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
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Fielding & Reschke Standards Track [Page 4]
227
228RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
229
230
2311. Introduction
232
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
238 specification:
239
240 1. "Message Syntax and Routing" (this document)
241
242 2. "Semantics and Content" [RFC7231]
243
244 3. "Conditional Requests" [RFC7232]
245
246 4. "Range Requests" [RFC7233]
247
248 5. "Caching" [RFC7234]
249
250 6. "Authentication" [RFC7235]
251
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.
256
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.
266
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.
273
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
279
280
281
282Fielding & Reschke Standards Track [Page 5]
283
284RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
285
286
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.
291
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.
300
3011.1. Requirements Notation
302
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].
306
307 Conformance criteria and considerations regarding error handling are
308 defined in Section 2.5.
309
3101.2. Syntax Notation
311
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.
318
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).
325
326 As a convention, ABNF rule names prefixed with "obs-" denote
327 "obsolete" grammar rules that appear for historical reasons.
328
3292. Architecture
330
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.
335
336
337
338Fielding & Reschke Standards Track [Page 6]
339
340RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
341
342
3432.1. Client/Server Messaging
344
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
351 HTTP responses.
352
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.
363
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).
370
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
375 server (O).
376
377 request >
378 UA ======================================= O
379 < response
380
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).
388
389
390
391
392
393
394Fielding & Reschke Standards Track [Page 7]
395
396RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
397
398
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
406 any, Section 3.3).
407
408 A connection might be used for multiple request/response exchanges,
409 as defined in Section 6.3.
410
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":
414
415 Client request:
416
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
421
422
423 Server response:
424
425 HTTP/1.1 200 OK
426 Date: Mon, 27 Jul 2009 12:28:53 GMT
427 Server: Apache
428 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
429 ETag: "34aa387-d-1568eb00"
430 Accept-Ranges: bytes
431 Content-Length: 51
432 Vary: Accept-Encoding
433 Content-Type: text/plain
434
435 Hello World! My payload includes a trailing CRLF.
436
4372.2. Implementation Diversity
438
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
446
447
448
449
450Fielding & Reschke Standards Track [Page 8]
451
452RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
453
454
455 units, configurable networking components, office machines,
456 autonomous robots, news feeds, traffic cameras, ad selectors, and
457 video-delivery platforms.
458
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
466 hypertext graph.
467
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.
479
4802.3. Intermediaries
481
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.
487
488 > > > >
489 UA =========== A =========== B =========== C =========== O
490 < < < <
491
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
502
503
504
505
506Fielding & Reschke Standards Track [Page 9]
507
508RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
509
510
511 request. Likewise, later requests might be sent through a different
512 path of connections, often based on dynamic configuration for load
513 balancing.
514
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.
521
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
533 Section 5.7.2.
534
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.
542
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.
550
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.
559
560
561
562Fielding & Reschke Standards Track [Page 10]
563
564RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
565
566
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.
575
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
584 usage policies.
585
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.
595
5962.4. Caches
597
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.
604
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.
610
611 > >
612 UA =========== A =========== B - - - - - - C - - - - - - O
613 < <
614
615
616
617
618Fielding & Reschke Standards Track [Page 11]
619
620RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
621
622
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
629 [RFC7234].
630
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.
637
6382.5. Conformance and Error Handling
639
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.
648
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.
652
653 An implementation is considered conformant if it complies with all of
654 the requirements associated with the roles it partakes in HTTP.
655
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).
664
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
670
671
672
673
674Fielding & Reschke Standards Track [Page 12]
675
676RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
677
678
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.
682
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.
692
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.
699
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.
709
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
718 be dangerous.
719
7202.6. Protocol Versioning
721
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.
727
728
729
730Fielding & Reschke Standards Track [Page 13]
731
732RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
733
734
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.
737
738 HTTP-version = HTTP-name "/" DIGIT "." DIGIT
739 HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
740
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).
751
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.
760
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.
768
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.
773
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
781
782
783
784
785
786Fielding & Reschke Standards Track [Page 14]
787
788RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
789
790
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.
794
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
799 conformant.
800
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.
806
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.
813
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.
824
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.
833
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
839
840
841
842Fielding & Reschke Standards Track [Page 15]
843
844RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
845
846
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.
851
8522.7. Uniform Resource Identifiers
853
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.
858
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
868 component.
869
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>
881
882 absolute-path = 1*( "/" segment )
883 partial-URI = relative-part [ "?" query ]
884
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).
891
892
893
894
895
896
897
898Fielding & Reschke Standards Track [Page 16]
899
900RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
901
902
9032.7.1. http URI Scheme
904
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.
909
910 http-URI = "http:" "//" authority path-abempty [ "?" query ]
911 [ "#" fragment ]
912
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
920 [RFC3986].
921
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.
925
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.
933
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.
943
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
950
951
952
953
954Fielding & Reschke Standards Track [Page 17]
955
956RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
957
958
959 HTTP response message, as described in Section 6 of [RFC7231], then
960 that response is considered an authoritative answer to the client's
961 request.
962
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.
972
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.
986
9872.7.2. https URI Scheme
988
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]).
993
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.
1000
1001 https-URI = "https:" "//" authority path-abempty [ "?" query ]
1002 [ "#" fragment ]
1003
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
1007
1008
1009
1010Fielding & Reschke Standards Track [Page 18]
1011
1012RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1013
1014
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
1021 of host domains.
1022
1023 The process for authoritative access to an "https" identified
1024 resource is defined in [RFC2818].
1025
10262.7.3. http and https URI Normalization and Comparison
1027
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.
1032
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]).
1043
1044 For example, the following three URIs are equivalent:
1045
1046 http://example.com:80/~smith/home.html
1047 http://EXAMPLE.com/%7Esmith/home.html
1048 http://EXAMPLE.com:/%7esmith/home.html
1049
10503. Message Format
1051
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.
1057
1058 HTTP-message = start-line
1059 *( header-field CRLF )
1060 CRLF
1061 [ message-body ]
1062
1063
1064
1065
1066Fielding & Reschke Standards Track [Page 19]
1067
1068RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1069
1070
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.
1077
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
1087 individual fields.
1088
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.
1094
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).
1102
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.
1110
11113.1. Start Line
1112
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).
1118
1119
1120
1121
1122Fielding & Reschke Standards Track [Page 20]
1123
1124RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1125
1126
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.
1132
1133 start-line = request-line / status-line
1134
11353.1.1. Request Line
1136
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.
1140
1141 request-line = method SP request-target SP HTTP-version CRLF
1142
1143 The method token indicates the request method to be performed on the
1144 target resource. The request method is case-sensitive.
1145
1146 method = token
1147
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.
1151
1152 The request-target identifies the target resource upon which to apply
1153 the request, as defined in Section 5.3.
1154
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
1160 request-target.
1161
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.
1168
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
1173
1174
1175
1176
1177
1178Fielding & Reschke Standards Track [Page 21]
1179
1180RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1181
1182
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
1185 [RFC7231]).
1186
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.
1190
11913.1.2. Status Line
1192
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.
1197
1198 status-line = HTTP-version SP status-code SP reason-phrase CRLF
1199
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
1208 registry.
1209
1210 status-code = 3DIGIT
1211
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.
1217
1218 reason-phrase = *( HTAB / SP / VCHAR / obs-text )
1219
12203.2. Header Fields
1221
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.
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234Fielding & Reschke Standards Track [Page 22]
1235
1236RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1237
1238
1239 header-field = field-name ":" OWS field-value OWS
1240
1241 field-name = token
1242 field-value = *( field-content / obs-fold )
1243 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
1244 field-vchar = VCHAR / obs-text
1245
1246 obs-fold = CRLF 1*( SP / HTAB )
1247 ; obsolete line folding
1248 ; see Section 3.2.4
1249
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.
1254
12553.2.1. Field Extensibility
1256
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
1262 set.
1263
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.
1268
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.
1275
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].
1278
12793.2.2. Field Order
1280
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
1287
1288
1289
1290Fielding & Reschke Standards Track [Page 23]
1291
1292RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1293
1294
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.
1298
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).
1303
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.
1312
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.)
1320
13213.2.3. Whitespace
1322
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).
1326
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.
1333
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
1336 single SP.
1337
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.
1342
1343
1344
1345
1346Fielding & Reschke Standards Track [Page 24]
1347
1348RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1349
1350
1351 OWS = *( SP / HTAB )
1352 ; optional whitespace
1353 RWS = 1*( SP / HTAB )
1354 ; required whitespace
1355 BWS = OWS
1356 ; "bad" whitespace
1357
13583.2.4. Field Parsing
1359
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).
1371
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.
1379
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.
1387
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.
1396
1397
1398
1399
1400
1401
1402Fielding & Reschke Standards Track [Page 25]
1403
1404RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1405
1406
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.
1413
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
1420 message downstream.
1421
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
1425 value.
1426
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.
1434
14353.2.5. Field Limits
1436
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
1441 field semantics.
1442
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
1447 (Section 9.5).
1448
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.
1453
1454
1455
1456
1457
1458Fielding & Reschke Standards Track [Page 26]
1459
1460RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1461
1462
14633.2.6. Field Value Components
1464
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 "(),/:;<=>?@[\]{}").
1470
1471 token = 1*tchar
1472
1473 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1474 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1475 / DIGIT / ALPHA
1476 ; any VCHAR, except delimiters
1477
1478 A string of text is parsed as a single value if it is quoted using
1479 double-quote marks.
1480
1481 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1482 qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
1483 obs-text = %x80-FF
1484
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.
1488
1489 comment = "(" *( ctext / quoted-pair / comment ) ")"
1490 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1491
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.
1496
1497 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1498
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.
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514Fielding & Reschke Standards Track [Page 27]
1515
1516RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1517
1518
15193.3. Message Body
1520
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.
1525
1526 message-body = *OCTET
1527
1528 The rules for when a message body is allowed in a message differ for
1529 requests and responses.
1530
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.
1535
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.
1548
15493.3.1. Transfer-Encoding
1550
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.
1555
1556 Transfer-Encoding = 1#transfer-coding
1557
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.
1566
1567
1568
1569
1570Fielding & Reschke Standards Track [Page 28]
1571
1572RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1573
1574
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.
1586
1587 For example,
1588
1589 Transfer-Encoding: gzip, chunked
1590
1591 indicates that the payload body has been compressed using the gzip
1592 coding and then chunked using the chunked coding while forming the
1593 message body.
1594
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.
1603
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
1611 are not needed.
1612
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
1617 [RFC7231]).
1618
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
1623
1624
1625
1626Fielding & Reschke Standards Track [Page 29]
1627
1628RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1629
1630
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).
1636
1637 A server that receives a request message with a transfer coding it
1638 does not understand SHOULD respond with 501 (Not Implemented).
1639
16403.3.2. Content-Length
1641
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]).
1650
1651 Content-Length = 1*DIGIT
1652
1653 An example is
1654
1655 Content-Length: 3495
1656
1657 A sender MUST NOT send a Content-Length header field in any message
1658 that contains a Transfer-Encoding header field.
1659
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
1667 body.
1668
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.
1674
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
1678
1679
1680
1681
1682Fielding & Reschke Standards Track [Page 30]
1683
1684RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1685
1686
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
1689 request.
1690
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
1695 [RFC7231]).
1696
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.
1703
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).
1709
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.
1720
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"
1724 media-type.
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738Fielding & Reschke Standards Track [Page 31]
1739
1740RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1741
1742
17433.3.3. Message Body Length
1744
1745 The length of a message body is determined by one of the following
1746 (in order of precedence):
1747
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.
1753
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
1758 such a message.
1759
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.
1764
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.
1773
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.
1781
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
1791
1792
1793
1794Fielding & Reschke Standards Track [Page 32]
1795
1796RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1797
1798
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.
1802
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.
1809
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).
1812
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
1816 connection.
1817
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.
1823
1824 A server MAY reject a request that contains a message body but not a
1825 Content-Length by responding with 411 (Length Required).
1826
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
1836 processing.
1837
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.
1843
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
1847
1848
1849
1850Fielding & Reschke Standards Track [Page 33]
1851
1852RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1853
1854
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
1859 poisoning.
1860
18613.4. Handling Incomplete Messages
1862
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.
1866
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].
1872
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.
1878
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
1887 received intact.
1888
18893.5. Message Parsing Robustness
1890
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.
1898
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.
1902
1903
1904
1905
1906Fielding & Reschke Standards Track [Page 34]
1907
1908RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1909
1910
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.
1914
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).
1925
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.
1931
19324. Transfer Codings
1933
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.
1940
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 )
1947
1948 Parameters are in the form of a name or name=value pair.
1949
1950 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
1951
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.
1956
1957
1958
1959
1960
1961
1962Fielding & Reschke Standards Track [Page 35]
1963
1964RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
1965
1966
19674.1. Chunked Transfer Coding
1968
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.
1976
1977 chunked-body = *chunk
1978 last-chunk
1979 trailer-part
1980 CRLF
1981
1982 chunk = chunk-size [ chunk-ext ] CRLF
1983 chunk-data CRLF
1984 chunk-size = 1*HEXDIG
1985 last-chunk = 1*("0") [ chunk-ext ] CRLF
1986
1987 chunk-data = 1*OCTET ; a sequence of chunk-size octets
1988
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.
1993
1994 A recipient MUST be able to parse and decode the chunked transfer
1995 coding.
1996
19974.1.1. Chunk Extensions
1998
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
2003 size.
2004
2005 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
2006
2007 chunk-ext-name = token
2008 chunk-ext-val = token / quoted-string
2009
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
2014
2015
2016
2017
2018Fielding & Reschke Standards Track [Page 36]
2019
2020RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2021
2022
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.
2026
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.
2033
20344.1.2. Chunked Trailer Part
2035
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
2042 section.
2043
2044 trailer-part = *( header-field CRLF )
2045
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).
2053
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
2060 filters.
2061
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.
2070
2071
2072
2073
2074Fielding & Reschke Standards Track [Page 37]
2075
2076RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2077
2078
20794.1.3. Decoding Chunked
2080
2081 A process for decoding the chunked transfer coding can be represented
2082 in pseudo-code as:
2083
2084 length := 0
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
2091 }
2092 read trailer field
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
2096 }
2097 read trailer-field
2098 }
2099 Content-Length := length
2100 Remove "chunked" from Transfer-Encoding
2101 Remove Trailer from existing header fields
2102
21034.2. Compression Codings
2104
2105 The codings defined below can be used to compress the payload of a
2106 message.
2107
21084.2.1. Compress Coding
2109
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".
2114
21154.2.2. Deflate Coding
2116
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.
2120
2121 Note: Some non-conformant implementations send the "deflate"
2122 compressed data without the zlib wrapper.
2123
2124
2125
2126
2127
2128
2129
2130Fielding & Reschke Standards Track [Page 38]
2131
2132RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2133
2134
21354.2.3. Gzip Coding
2136
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".
2141
21424.3. TE
2143
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.
2148
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.
2154
2155 TE = #t-codings
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") ] )
2160
2161 Three examples of TE use are below.
2162
2163 TE: deflate
2164 TE:
2165 TE: trailers, deflate;q=0.5
2166
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.
2177
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
2181
2182
2183
2184
2185
2186Fielding & Reschke Standards Track [Page 39]
2187
2188RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2189
2190
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".
2194
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.
2198
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
2203 semantics.
2204
22054.4. Trailer
2206
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.
2215
2216 Trailer = 1#field-name
2217
22185. Message Routing
2219
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
2224 client.
2225
22265.1. Identifying a Target Resource
2227
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
2233 browsers.
2234
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
2239
2240
2241
2242Fielding & Reschke Standards Track [Page 40]
2243
2244RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2245
2246
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).
2252
22535.2. Connecting Inbound
2254
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.
2258
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.
2261
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
2269 to that proxy.
2270
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.
2278
2279 HTTP requirements regarding connection management are defined in
2280 Section 6.
2281
22825.3. Request Target
2283
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
2288 is to a proxy.
2289
2290 request-target = origin-form
2291 / absolute-form
2292 / authority-form
2293 / asterisk-form
2294
2295
2296
2297
2298Fielding & Reschke Standards Track [Page 41]
2299
2300RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2301
2302
23035.3.1. origin-form
2304
2305 The most common form of request-target is the origin-form.
2306
2307 origin-form = absolute-path [ "?" query ]
2308
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
2315 Section 5.4.
2316
2317 For example, a client wishing to retrieve a representation of the
2318 resource identified as
2319
2320 http://www.example.org/where?q=now
2321
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
2324 lines:
2325
2326 GET /where?q=now HTTP/1.1
2327 Host: www.example.org
2328
2329 followed by the remainder of the request message.
2330
23315.3.2. absolute-form
2332
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.
2336
2337 absolute-form = absolute-URI
2338
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.
2344
2345 An example absolute-form of request-line would be:
2346
2347 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
2348
2349
2350
2351
2352
2353
2354Fielding & Reschke Standards Track [Page 42]
2355
2356RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2357
2358
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.
2363
23645.3.3. authority-form
2365
2366 The authority-form of request-target is only used for CONNECT
2367 requests (Section 4.3.6 of [RFC7231]).
2368
2369 authority-form = authority
2370
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,
2375
2376 CONNECT www.example.com:80 HTTP/1.1
2377
23785.3.4. asterisk-form
2379
2380 The asterisk-form of request-target is only used for a server-wide
2381 OPTIONS request (Section 4.3.7 of [RFC7231]).
2382
2383 asterisk-form = "*"
2384
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,
2388
2389 OPTIONS * HTTP/1.1
2390
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
2395 origin server.
2396
2397 For example, the request
2398
2399 OPTIONS http://www.example.org:8001 HTTP/1.1
2400
2401 would be forwarded by the final proxy as
2402
2403 OPTIONS * HTTP/1.1
2404 Host: www.example.org:8001
2405
2406 after connecting to port 8001 of host "www.example.org".
2407
2408
2409
2410Fielding & Reschke Standards Track [Page 43]
2411
2412RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2413
2414
24155.4. Host
2416
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.
2421
2422 Host = uri-host [ ":" port ] ; Section 2.7.1
2423
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.
2431
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.
2435
2436 For example, a GET request to the origin server for
2437 <http://www.example.org/pub/WWW/> would begin with:
2438
2439 GET /pub/WWW/ HTTP/1.1
2440 Host: www.example.org
2441
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.
2446
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.
2453
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
2461 host.
2462
2463
2464
2465
2466Fielding & Reschke Standards Track [Page 44]
2467
2468RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2469
2470
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.
2475
24765.5. Effective Request URI
2477
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.
2484
2485 For a user agent, the effective request URI is the target URI.
2486
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:
2490
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".
2496
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.
2509
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.
2514
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.
2518
2519
2520
2521
2522Fielding & Reschke Standards Track [Page 45]
2523
2524RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2525
2526
2527 Example 1: the following message received over an insecure TCP
2528 connection
2529
2530 GET /pub/WWW/TheProject.html HTTP/1.1
2531 Host: www.example.org:8080
2532
2533 has an effective request URI of
2534
2535 http://www.example.org:8080/pub/WWW/TheProject.html
2536
2537 Example 2: the following message received over a TLS-secured TCP
2538 connection
2539
2540 OPTIONS * HTTP/1.1
2541 Host: www.example.org
2542
2543 has an effective request URI of
2544
2545 https://www.example.org
2546
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.
2551
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.
2563
25645.6. Associating a Response to a Request
2565
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.
2573
2574
2575
2576
2577
2578Fielding & Reschke Standards Track [Page 46]
2579
2580RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2581
2582
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
2587 (non-1xx) response.
2588
25895.7. Message Forwarding
2590
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
2598 stream.
2599
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.
2603
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
2608 directly.
2609
26105.7.1. Via
2611
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.
2619
2620 Via = 1#( received-protocol RWS received-by [ RWS comment ] )
2621
2622 received-protocol = [ protocol-name "/" ] protocol-version
2623 ; see Section 6.7
2624 received-by = ( uri-host [ ":" port ] ) / pseudonym
2625 pseudonym = token
2626
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.
2631
2632
2633
2634Fielding & Reschke Standards Track [Page 47]
2635
2636RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2637
2638
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
2643 messages.
2644
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
2653 is HTTP.
2654
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.
2662
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
2667 message.
2668
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:
2675
2676 Via: 1.0 fred, 1.1 p.example.net
2677
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.
2683
2684
2685
2686
2687
2688
2689
2690Fielding & Reschke Standards Track [Page 48]
2691
2692RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2693
2694
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,
2698
2699 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2700
2701 could be collapsed to
2702
2703 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2704
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.
2709
27105.7.2. Transformations
2711
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
2720 original.
2721
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)
2732 selected the proxy.
2733
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
2738 domain name.
2739
2740
2741
2742
2743
2744
2745
2746Fielding & Reschke Standards Track [Page 49]
2747
2748RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2749
2750
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
2754 "*".
2755
2756 A proxy MAY modify the message body through application or removal of
2757 a transfer coding (Section 4).
2758
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]).
2762
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]).
2771
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.
2777
27786. Connection Management
2779
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.
2786
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.
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802Fielding & Reschke Standards Track [Page 50]
2803
2804RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2805
2806
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.
2816
28176.1. Connection
2818
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
2823 message.
2824
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
2833 forwarded message).
2834
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.
2842
2843 The Connection header field's value has the following grammar:
2844
2845 Connection = 1#connection-option
2846 connection-option = token
2847
2848 Connection options are case-insensitive.
2849
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]).
2854
2855
2856
2857
2858Fielding & Reschke Standards Track [Page 51]
2859
2860RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2861
2862
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.
2870
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.
2878
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
2881 example,
2882
2883 Connection: close
2884
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).
2888
2889 A client that does not support persistent connections MUST send the
2890 "close" connection option in every request message.
2891
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.
2895
28966.2. Establishment
2897
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.
2901
29026.3. Persistence
2903
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.
2909
2910
2911
2912
2913
2914Fielding & Reschke Standards Track [Page 52]
2915
2916RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2917
2918
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):
2922
2923 o If the "close" connection option is present, the connection will
2924 not persist after the current response; else,
2925
2926 o If the received protocol is HTTP/1.1 (or later), the connection
2927 will persist after the current response; else,
2928
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,
2933
2934 o The connection will close after the current response.
2935
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.
2939
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.
2948
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).
2953
2954 See Appendix A.1.2 for more information on backwards compatibility
2955 with HTTP/1.0 clients.
2956
29576.3.1. Retrying Requests
2958
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.
2962
2963
2964
2965
2966
2967
2968
2969
2970Fielding & Reschke Standards Track [Page 53]
2971
2972RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
2973
2974
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.
2980
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.
2993
2994 A client SHOULD NOT automatically retry a failed automatic retry.
2995
29966.3.2. Pipelining
2997
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.
3004
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).
3014
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
3021 pipelined sequence.
3022
3023
3024
3025
3026Fielding & Reschke Standards Track [Page 54]
3027
3028RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3029
3030
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.
3041
30426.4. Concurrency
3043
3044 A client ought to limit the number of simultaneous open connections
3045 that it maintains to a given server.
3046
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.
3052
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.
3059
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.
3063
30646.5. Failures and Timeouts
3065
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.
3072
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.
3078
3079
3080
3081
3082Fielding & Reschke Standards Track [Page 55]
3083
3084RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3085
3086
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.
3093
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.
3099
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
3105 the connection.
3106
31076.6. Tear-down
3108
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.
3112
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.
3117
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
3123 connection.
3124
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
3128 on that connection.
3129
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.
3135
3136
3137
3138Fielding & Reschke Standards Track [Page 56]
3139
3140RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3141
3142
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.
3152
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.
3161
3162 It is unknown whether the reset problem is exclusive to TCP or might
3163 also be found in other transport connection protocols.
3164
31656.7. Upgrade
3166
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
3175 change.
3176
3177 Upgrade = 1#protocol
3178
3179 protocol = protocol-name ["/" protocol-version]
3180 protocol-name = token
3181 protocol-version = token
3182
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
3189
3190
3191
3192
3193
3194Fielding & Reschke Standards Track [Page 57]
3195
3196RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3197
3198
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.
3202
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.
3206
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
3210 future request.
3211
3212 The following is a hypothetical example sent by a client:
3213
3214 GET /hello.txt HTTP/1.1
3215 Host: www.example.com
3216 Connection: upgrade
3217 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3218
3219
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
3228 repeated).
3229
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.
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250Fielding & Reschke Standards Track [Page 58]
3251
3252RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3253
3254
3255 The following is an example response to the above hypothetical
3256 request:
3257
3258 HTTP/1.1 101 Switching Protocols
3259 Connection: upgrade
3260 Upgrade: HTTP/2.0
3261
3262 [... data stream switches to HTTP/2.0 with an appropriate response
3263 (as defined by new protocol) to the "GET /hello.txt" request ...]
3264
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
3270 HTTP/1.0 request.
3271
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.
3279
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]).
3286
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.
3292
32937. ABNF List Extension: #rule
3294
3295 A #rule extension to the ABNF rules of [RFC5234] is used to improve
3296 readability in the definitions of some header field values.
3297
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).
3302
3303
3304
3305
3306Fielding & Reschke Standards Track [Page 59]
3307
3308RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3309
3310
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:
3314
3315 1#element => element *( OWS "," OWS element )
3316
3317 and:
3318
3319 #element => [ 1#element ]
3320
3321 and for n >= 1 and m > 1:
3322
3323 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
3324
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:
3330
3331 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
3332
3333 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
3334
3335 Empty elements do not contribute to the count of elements present.
3336 For example, given these ABNF productions:
3337
3338 example-list = 1#example-list-elmt
3339 example-list-elmt = token ; see Section 3.2.6
3340
3341 Then the following are valid values for example-list (not including
3342 the double quotes, which are present for delimitation only):
3343
3344 "foo,bar"
3345 "foo ,bar,"
3346 "foo , ,bar,charlie "
3347
3348 In contrast, the following values would be invalid, since at least
3349 one non-empty element is required by the example-list production:
3350
3351 ""
3352 ","
3353 ", ,"
3354
3355 Appendix B shows the collected ABNF for recipients after the list
3356 constructs have been expanded.
3357
3358
3359
3360
3361
3362Fielding & Reschke Standards Track [Page 60]
3363
3364RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3365
3366
33678. IANA Considerations
3368
33698.1. Header Field Registration
3370
3371 HTTP header fields are registered within the "Message Headers"
3372 registry maintained at
3373 <http://www.iana.org/assignments/message-headers/>.
3374
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]).
3378
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 +-------------------+----------+----------+---------------+
3391
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).
3396
3397 +-------------------+----------+----------+-------------+
3398 | Header Field Name | Protocol | Status | Reference |
3399 +-------------------+----------+----------+-------------+
3400 | Close | http | reserved | Section 8.1 |
3401 +-------------------+----------+----------+-------------+
3402
3403 The change controller is: "IETF (iesg@ietf.org) - Internet
3404 Engineering Task Force".
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418Fielding & Reschke Standards Track [Page 61]
3419
3420RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3421
3422
34238.2. URI Scheme Registration
3424
3425 IANA maintains the registry of URI Schemes [BCP115] at
3426 <http://www.iana.org/assignments/uri-schemes/>.
3427
3428 This document defines the following URI schemes, so the "Permanent
3429 URI Schemes" registry has been updated accordingly.
3430
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 +------------+------------------------------------+---------------+
3437
34388.3. Internet Media Type Registration
3439
3440 IANA maintains the registry of Internet media types [BCP13] at
3441 <http://www.iana.org/assignments/media-types>.
3442
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.
3446
34478.3.1. Internet Media Type message/http
3448
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.
3452
3453 Type name: message
3454
3455 Subtype name: http
3456
3457 Required parameters: N/A
3458
3459 Optional parameters: version, msgtype
3460
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.
3464
3465 msgtype: The message type -- "request" or "response". If not
3466 present, the type can be determined from the first line of the
3467 body.
3468
3469 Encoding considerations: only "7bit", "8bit", or "binary" are
3470 permitted
3471
3472
3473
3474Fielding & Reschke Standards Track [Page 62]
3475
3476RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3477
3478
3479 Security considerations: see Section 9
3480
3481 Interoperability considerations: N/A
3482
3483 Published specification: This specification (see Section 8.3.1).
3484
3485 Applications that use this media type: N/A
3486
3487 Fragment identifier considerations: N/A
3488
3489 Additional information:
3490
3491 Magic number(s): N/A
3492
3493 Deprecated alias names for this type: N/A
3494
3495 File extension(s): N/A
3496
3497 Macintosh file type code(s): N/A
3498
3499 Person and email address to contact for further information:
3500 See Authors' Addresses section.
3501
3502 Intended usage: COMMON
3503
3504 Restrictions on usage: N/A
3505
3506 Author: See Authors' Addresses section.
3507
3508 Change controller: IESG
3509
35108.3.2. Internet Media Type application/http
3511
3512 The application/http type can be used to enclose a pipeline of one or
3513 more HTTP request or response messages (not intermixed).
3514
3515 Type name: application
3516
3517 Subtype name: http
3518
3519 Required parameters: N/A
3520
3521 Optional parameters: version, msgtype
3522
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.
3526
3527
3528
3529
3530Fielding & Reschke Standards Track [Page 63]
3531
3532RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3533
3534
3535 msgtype: The message type -- "request" or "response". If not
3536 present, the type can be determined from the first line of the
3537 body.
3538
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.
3542
3543 Security considerations: see Section 9
3544
3545 Interoperability considerations: N/A
3546
3547 Published specification: This specification (see Section 8.3.2).
3548
3549 Applications that use this media type: N/A
3550
3551 Fragment identifier considerations: N/A
3552
3553 Additional information:
3554
3555 Deprecated alias names for this type: N/A
3556
3557 Magic number(s): N/A
3558
3559 File extension(s): N/A
3560
3561 Macintosh file type code(s): N/A
3562
3563 Person and email address to contact for further information:
3564 See Authors' Addresses section.
3565
3566 Intended usage: COMMON
3567
3568 Restrictions on usage: N/A
3569
3570 Author: See Authors' Addresses section.
3571
3572 Change controller: IESG
3573
35748.4. Transfer Coding Registry
3575
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>.
3579
3580
3581
3582
3583
3584
3585
3586Fielding & Reschke Standards Track [Page 64]
3587
3588RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3589
3590
35918.4.1. Procedure
3592
3593 Registrations MUST include the following fields:
3594
3595 o Name
3596
3597 o Description
3598
3599 o Pointer to specification text
3600
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.
3605
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.
3609
3610 Use of program names for the identification of encoding formats is
3611 not desirable and is discouraged for future encodings.
3612
36138.4.2. Registration
3614
3615 The "HTTP Transfer Coding Registry" has been updated with the
3616 registrations below:
3617
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 +------------+--------------------------------------+---------------+
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642Fielding & Reschke Standards Track [Page 65]
3643
3644RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3645
3646
36478.5. Content Coding Registration
3648
3649 IANA maintains the "HTTP Content Coding Registry" at
3650 <http://www.iana.org/assignments/http-parameters>.
3651
3652 The "HTTP Content Coding Registry" has been updated with the
3653 registrations below:
3654
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 +------------+--------------------------------------+---------------+
3666
36678.6. Upgrade Token Registry
3668
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>.
3673
36748.6.1. Procedure
3675
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.
3679
3680 Registrations happen on a "First Come First Served" basis (see
3681 Section 4.1 of [RFC5226]) and are subject to the following rules:
3682
3683 1. A protocol-name token, once registered, stays registered forever.
3684
3685 2. The registration MUST name a responsible party for the
3686 registration.
3687
3688 3. The registration MUST name a point of contact.
3689
3690 4. The registration MAY name a set of specifications associated with
3691 that token. Such specifications need not be publicly available.
3692
3693 5. The registration SHOULD name a set of expected "protocol-version"
3694 tokens associated with that token at the time of registration.
3695
3696
3697
3698Fielding & Reschke Standards Track [Page 66]
3699
3700RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3701
3702
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.
3706
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.
3710
3711 This registration procedure for HTTP Upgrade Tokens replaces that
3712 previously defined in Section 7.2 of [RFC2817].
3713
37148.6.2. Upgrade Token Registration
3715
3716 The "HTTP" entry in the upgrade token registry has been updated with
3717 the registration below:
3718
3719 +-------+----------------------+----------------------+-------------+
3720 | Value | Description | Expected Version | Reference |
3721 | | | Tokens | |
3722 +-------+----------------------+----------------------+-------------+
3723 | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
3724 | | Protocol | (e.g, "2.0") | |
3725 +-------+----------------------+----------------------+-------------+
3726
3727 The responsible party is: "IETF (iesg@ietf.org) - Internet
3728 Engineering Task Force".
3729
37309. Security Considerations
3731
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].
3736
37379.1. Establishing Authority
3738
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.
3747
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
3751
3752
3753
3754Fielding & Reschke Standards Track [Page 67]
3755
3756RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3757
3758
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.
3766
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.
3777
3778 Furthermore, after an IP address is obtained, establishing authority
3779 for an "http" URI is vulnerable to attacks on Internet Protocol
3780 routing.
3781
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
3788 [Georgiev]).
3789
37909.2. Risks of Intermediaries
3791
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.
3802
3803 Intermediaries that contain a shared cache are especially vulnerable
3804 to cache poisoning attacks, as described in Section 8 of [RFC7234].
3805
3806
3807
3808
3809
3810Fielding & Reschke Standards Track [Page 68]
3811
3812RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3813
3814
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
3818 configuration).
3819
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.
3822
38239.3. Attacks via Protocol Element Length
3824
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.
3829
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
3835 limits.
3836
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].
3841
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.
3848
38499.4. Response Splitting
3850
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
3856 a shared cache.
3857
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
3863
3864
3865
3866Fielding & Reschke Standards Track [Page 69]
3867
3868RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3869
3870
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.
3877
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.
3885
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
3896 stream.
3897
38989.5. Request Smuggling
3899
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
3905 usage.
3906
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.
3910
39119.6. Message Integrity
3912
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
3919
3920
3921
3922Fielding & Reschke Standards Track [Page 70]
3923
3924RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3925
3926
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.
3932
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.
3945
39469.7. Message Confidentiality
3947
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.
3954
3955 The "https" scheme can be used to identify resources that require a
3956 confidential connection, as described in Section 2.7.2.
3957
39589.8. Privacy of Server Log Information
3959
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.
3965
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.
3974
3975
3976
3977
3978Fielding & Reschke Standards Track [Page 71]
3979
3980RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
3981
3982
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,
3988 or fraud control.
3989
399010. Acknowledgments
3991
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
3998 Group Chair.
3999
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:
4003
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
4031
4032
4033
4034Fielding & Reschke Standards Track [Page 72]
4035
4036RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4037
4038
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.
4084
4085 See Section 16 of [RFC2616] for additional acknowledgements from
4086 prior revisions.
4087
4088
4089
4090Fielding & Reschke Standards Track [Page 73]
4091
4092RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4093
4094
409511. References
4096
409711.1. Normative References
4098
4099 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
4100 RFC 793, September 1981.
4101
4102 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
4103 Format Specification version 3.3", RFC 1950, May 1996.
4104
4105 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
4106 Specification version 1.3", RFC 1951, May 1996.
4107
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.
4111
4112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4113 Requirement Levels", BCP 14, RFC 2119, March 1997.
4114
4115 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
4116 "Uniform Resource Identifier (URI): Generic Syntax",
4117 STD 66, RFC 3986, January 2005.
4118
4119 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
4120 Syntax Specifications: ABNF", STD 68, RFC 5234,
4121 January 2008.
4122
4123 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4124 Transfer Protocol (HTTP/1.1): Semantics and Content",
4125 RFC 7231, June 2014.
4126
4127 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4128 Transfer Protocol (HTTP/1.1): Conditional Requests",
4129 RFC 7232, June 2014.
4130
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.
4134
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.
4138
4139 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4140 Transfer Protocol (HTTP/1.1): Authentication",
4141 RFC 7235, June 2014.
4142
4143
4144
4145
4146Fielding & Reschke Standards Track [Page 74]
4147
4148RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4149
4150
4151 [USASCII] American National Standards Institute, "Coded Character
4152 Set -- 7-bit American Standard Code for Information
4153 Interchange", ANSI X3.4, 1986.
4154
4155 [Welch] Welch, T., "A Technique for High-Performance Data
4156 Compression", IEEE Computer 17(6), June 1984.
4157
415811.2. Informative References
4159
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.
4163
4164 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
4165 Specifications and Registration Procedures", BCP 13,
4166 RFC 6838, January 2013.
4167
4168 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
4169 Procedures for Message Header Fields", BCP 90,
4170 RFC 3864, September 2004.
4171
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>.
4179
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.
4184
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>.
4189
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>.
4194
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>.
4198
4199
4200
4201
4202Fielding & Reschke Standards Track [Page 75]
4203
4204RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4205
4206
4207 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
4208 RFC 1919, March 1996.
4209
4210 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
4211 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
4212 May 1996.
4213
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.
4217
4218 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
4219 Extensions) Part Three: Message Header Extensions for
4220 Non-ASCII Text", RFC 2047, November 1996.
4221
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.
4225
4226 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
4227 "Use and Interpretation of HTTP Version Numbers",
4228 RFC 2145, May 1997.
4229
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.
4233
4234 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
4235 HTTP/1.1", RFC 2817, May 2000.
4236
4237 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
4238
4239 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
4240 Replication and Caching Taxonomy", RFC 3040,
4241 January 2001.
4242
4243 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
4244 Rose, "DNS Security Introduction and Requirements",
4245 RFC 4033, March 2005.
4246
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.
4250
4251 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
4252 an IANA Considerations Section in RFCs", BCP 26,
4253 RFC 5226, May 2008.
4254
4255
4256
4257
4258Fielding & Reschke Standards Track [Page 76]
4259
4260RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4261
4262
4263 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
4264 Security (TLS) Protocol Version 1.2", RFC 5246,
4265 August 2008.
4266
4267 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
4268 October 2008.
4269
4270 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
4271 April 2011.
4272
4273 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
4274 Codes", RFC 6585, April 2012.
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314Fielding & Reschke Standards Track [Page 77]
4315
4316RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4317
4318
4319Appendix A. HTTP Version History
4320
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
4333 capabilities.
4334
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.
4340
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.
4347
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.
4355
4356A.1. Changes from HTTP/1.0
4357
4358 This section summarizes major differences between versions HTTP/1.0
4359 and HTTP/1.1.
4360
4361A.1.1. Multihomed Web Servers
4362
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.
4367
4368
4369
4370Fielding & Reschke Standards Track [Page 78]
4371
4372RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4373
4374
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
4384 requests.
4385
4386A.1.2. Keep-Alive Connections
4387
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].
4393
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
4401 hung connection.
4402
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.
4407
4408 As a result, clients are encouraged not to send the Proxy-Connection
4409 header field in any requests.
4410
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.
4417
4418A.1.3. Introduction of Transfer-Encoding
4419
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.
4423
4424
4425
4426Fielding & Reschke Standards Track [Page 79]
4427
4428RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4429
4430
4431A.2. Changes from RFC 2616
4432
4433 HTTP's approach to error handling has been explained. (Section 2.5)
4434
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)
4439
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)
4443
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)
4447
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)
4453
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.
4457 (Section 3.2)
4458
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)
4462
4463 Header fields that span multiple lines ("line folding") are
4464 deprecated. (Section 3.2.4)
4465
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)
4472
4473 Bogus Content-Length header fields are now required to be handled as
4474 errors by recipients. (Section 3.3.2)
4475
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
4479
4480
4481
4482Fielding & Reschke Standards Track [Page 80]
4483
4484RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4485
4486
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.
4490 (Section 3.3.3)
4491
4492 The "identity" transfer coding token has been removed. (Sections 3.3
4493 and 4)
4494
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.
4497 (Section 4.1)
4498
4499 The meaning of the "deflate" content coding has been clarified.
4500 (Section 4.2.2)
4501
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)
4506
4507 The term "Effective Request URI" has been introduced. (Section 5.5)
4508
4509 Gateways do not need to generate Via header fields anymore.
4510 (Section 5.7.1)
4511
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)
4516
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)
4523
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)
4527
4528 Empty list elements in list productions (e.g., a list header field
4529 containing ", ,") have been deprecated. (Section 7)
4530
4531 Registration of Transfer Codings now requires IETF Review
4532 (Section 8.4)
4533
4534
4535
4536
4537
4538Fielding & Reschke Standards Track [Page 81]
4539
4540RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4541
4542
4543 This specification now defines the Upgrade Token Registry, previously
4544 defined in Section 7.2 of [RFC2817]. (Section 8.6)
4545
4546 The expectation to support HTTP/0.9 requests has been removed.
4547 (Appendix A)
4548
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)
4552
4553Appendix B. Collected ABNF
4554
4555 BWS = OWS
4556
4557 Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
4558 connection-option ] )
4559
4560 Content-Length = 1*DIGIT
4561
4562 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4563 ]
4564 HTTP-name = %x48.54.54.50 ; HTTP
4565 HTTP-version = HTTP-name "/" DIGIT "." DIGIT
4566 Host = uri-host [ ":" port ]
4567
4568 OWS = *( SP / HTAB )
4569
4570 RWS = 1*( SP / HTAB )
4571
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
4575 transfer-coding ] )
4576
4577 URI-reference = <URI-reference, see [RFC3986], Section 4.1>
4578 Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
4579
4580 Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
4581 ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
4582 comment ] ) ] )
4583
4584 absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
4585 absolute-form = absolute-URI
4586 absolute-path = 1*( "/" segment )
4587 asterisk-form = "*"
4588 authority = <authority, see [RFC3986], Section 3.2>
4589 authority-form = authority
4590
4591
4592
4593
4594Fielding & Reschke Standards Track [Page 82]
4595
4596RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4597
4598
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 ; '!'-'''
4609 / %x2A-5B ; '*'-'['
4610 / %x5D-7E ; ']'-'~'
4611 / obs-text
4612
4613 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
4614 field-name = token
4615 field-value = *( field-content / obs-fold )
4616 field-vchar = VCHAR / obs-text
4617 fragment = <fragment, see [RFC3986], Section 3.5>
4618
4619 header-field = field-name ":" OWS field-value OWS
4620 http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
4621 fragment ]
4622 https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
4623 fragment ]
4624
4625 last-chunk = 1*"0" [ chunk-ext ] CRLF
4626
4627 message-body = *OCTET
4628 method = token
4629
4630 obs-fold = CRLF 1*( SP / HTAB )
4631 obs-text = %x80-FF
4632 origin-form = absolute-path [ "?" query ]
4633
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
4640 pseudonym = token
4641
4642 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
4643 / %x5D-7E ; ']'-'~'
4644 / obs-text
4645 query = <query, see [RFC3986], Section 3.4>
4646 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
4647
4648
4649
4650Fielding & Reschke Standards Track [Page 83]
4651
4652RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4653
4654
4655 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4656
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 /
4664 asterisk-form
4665
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
4671
4672 t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
4673 t-ranking = OWS ";" OWS "q=" rank
4674 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4675 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4676 token = 1*tchar
4677 trailer-part = *( header-field CRLF )
4678 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4679 transfer-extension
4680 transfer-extension = token *( OWS ";" OWS transfer-parameter )
4681 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
4682
4683 uri-host = <host, see [RFC3986], Section 3.2.2>
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706Fielding & Reschke Standards Track [Page 84]
4707
4708RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4709
4710
4711Index
4712
4713 A
4714 absolute-form (of request-target) 42
4715 accelerator 10
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
4720
4721 B
4722 browser 7
4723
4724 C
4725 cache 11
4726 cacheable 12
4727 captive portal 11
4728 chunked (Coding Format) 28, 32, 36
4729 client 7
4730 close 51, 56
4731 compress (Coding Format) 38
4732 connection 7
4733 Connection header field 51, 56
4734 Content-Length header field 30
4735
4736 D
4737 deflate (Coding Format) 38
4738 Delimiters 27
4739 downstream 10
4740
4741 E
4742 effective request URI 45
4743
4744 G
4745 gateway 10
4746 Grammar
4747 absolute-form 42
4748 absolute-path 16
4749 absolute-URI 16
4750 ALPHA 6
4751 asterisk-form 41, 43
4752 authority 16
4753 authority-form 42-43
4754 BWS 25
4755 chunk 36
4756 chunk-data 36
4757 chunk-ext 36
4758 chunk-ext-name 36
4759
4760
4761
4762Fielding & Reschke Standards Track [Page 85]
4763
4764RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4765
4766
4767 chunk-ext-val 36
4768 chunk-size 36
4769 chunked-body 36
4770 comment 27
4771 Connection 51
4772 connection-option 51
4773 Content-Length 30
4774 CR 6
4775 CRLF 6
4776 ctext 27
4777 CTL 6
4778 DIGIT 6
4779 DQUOTE 6
4780 field-content 23
4781 field-name 23, 40
4782 field-value 23
4783 field-vchar 23
4784 fragment 16
4785 header-field 23, 37
4786 HEXDIG 6
4787 Host 44
4788 HTAB 6
4789 HTTP-message 19
4790 HTTP-name 14
4791 http-URI 17
4792 HTTP-version 14
4793 https-URI 18
4794 last-chunk 36
4795 LF 6
4796 message-body 28
4797 method 21
4798 obs-fold 23
4799 obs-text 27
4800 OCTET 6
4801 origin-form 42
4802 OWS 25
4803 partial-URI 16
4804 port 16
4805 protocol-name 47
4806 protocol-version 47
4807 pseudonym 47
4808 qdtext 27
4809 query 16
4810 quoted-pair 27
4811 quoted-string 27
4812 rank 39
4813 reason-phrase 22
4814 received-by 47
4815
4816
4817
4818Fielding & Reschke Standards Track [Page 86]
4819
4820RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4821
4822
4823 received-protocol 47
4824 request-line 21
4825 request-target 41
4826 RWS 25
4827 scheme 16
4828 segment 16
4829 SP 6
4830 start-line 21
4831 status-code 22
4832 status-line 22
4833 t-codings 39
4834 t-ranking 39
4835 tchar 27
4836 TE 39
4837 token 27
4838 Trailer 40
4839 trailer-part 37
4840 transfer-coding 35
4841 Transfer-Encoding 28
4842 transfer-extension 35
4843 transfer-parameter 35
4844 Upgrade 57
4845 uri-host 16
4846 URI-reference 16
4847 VCHAR 6
4848 Via 47
4849 gzip (Coding Format) 39
4850
4851 H
4852 header field 19
4853 header section 19
4854 headers 19
4855 Host header field 44
4856 http URI scheme 17
4857 https URI scheme 17
4858 I
4859 inbound 9
4860 interception proxy 11
4861 intermediary 9
4862
4863 M
4864 Media Type
4865 application/http 63
4866 message/http 62
4867 message 7
4868 message/http Media Type 62
4869 method 21
4870
4871
4872
4873
4874Fielding & Reschke Standards Track [Page 87]
4875
4876RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4877
4878
4879 N
4880 non-transforming proxy 49
4881
4882 O
4883 origin server 7
4884 origin-form (of request-target) 42
4885 outbound 10
4886
4887 P
4888 phishing 67
4889 proxy 10
4890
4891 R
4892 recipient 7
4893 request 7
4894 request-target 21
4895 resource 16
4896 response 7
4897 reverse proxy 10
4898
4899 S
4900 sender 7
4901 server 7
4902 spider 7
4903
4904 T
4905 target resource 40
4906 target URI 40
4907 TE header field 39
4908 Trailer header field 40
4909 Transfer-Encoding header field 28
4910 transforming proxy 49
4911 transparent proxy 11
4912 tunnel 10
4913
4914 U
4915 Upgrade header field 57
4916 upstream 9
4917 URI scheme
4918 http 17
4919 https 17
4920 user agent 7
4921
4922 V
4923 Via header field 47
4924
4925
4926
4927
4928
4929
4930Fielding & Reschke Standards Track [Page 88]
4931
4932RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
4933
4934
4935Authors' Addresses
4936
4937 Roy T. Fielding (editor)
4938 Adobe Systems Incorporated
4939 345 Park Ave
4940 San Jose, CA 95110
4941 USA
4942
4943 EMail: fielding@gbiv.com
4944 URI: http://roy.gbiv.com/
4945
4946
4947 Julian F. Reschke (editor)
4948 greenbytes GmbH
4949 Hafenweg 16
4950 Muenster, NW 48155
4951 Germany
4952
4953 EMail: julian.reschke@greenbytes.de
4954 URI: http://greenbytes.de/tech/webdav/
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986Fielding & Reschke Standards Track [Page 89]
4987