1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
8 | Request for Comments: 7230 Adobe |
9 | Obsoletes: 2145, 2616 J. Reschke, Ed. |
10 | Updates: 2817, 2818 greenbytes |
11 | Category: Standards Track June 2014 |
12 | ISSN: 2070-1721 |
13 | |
14 | |
15 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
16 | |
17 | Abstract |
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 | |
27 | Status 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 | |
58 | Fielding & Reschke Standards Track [Page 1] |
60 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
61 | |
62 | |
63 | Copyright 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 | |
90 | Table 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 | |
114 | Fielding & Reschke Standards Track [Page 2] |
116 | RFC 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 | |
170 | Fielding & Reschke Standards Track [Page 3] |
172 | RFC 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 | |
226 | Fielding & Reschke Standards Track [Page 4] |
228 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
229 | |
230 | |
231 | 1. 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 | |
282 | Fielding & Reschke Standards Track [Page 5] |
284 | RFC 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 | |
301 | 1.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 | |
310 | 1.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 | |
329 | 2. 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 | |
338 | Fielding & Reschke Standards Track [Page 6] |
340 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
341 | |
342 | |
343 | 2.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 | |
394 | Fielding & Reschke Standards Track [Page 7] |
396 | RFC 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 | |
437 | 2.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 | |
450 | Fielding & Reschke Standards Track [Page 8] |
452 | RFC 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 | |
480 | 2.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 | |
506 | Fielding & Reschke Standards Track [Page 9] |
508 | RFC 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 | |
562 | Fielding & Reschke Standards Track [Page 10] |
564 | RFC 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 | |
596 | 2.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 | |
618 | Fielding & Reschke Standards Track [Page 11] |
620 | RFC 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 | |
638 | 2.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 | |
674 | Fielding & Reschke Standards Track [Page 12] |
676 | RFC 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 | |
720 | 2.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 | |
730 | Fielding & Reschke Standards Track [Page 13] |
732 | RFC 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 | |
786 | Fielding & Reschke Standards Track [Page 14] |
788 | RFC 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 | |
842 | Fielding & Reschke Standards Track [Page 15] |
844 | RFC 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 | |
852 | 2.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 | |
898 | Fielding & Reschke Standards Track [Page 16] |
900 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
901 | |
902 | |
903 | 2.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 | |
954 | Fielding & Reschke Standards Track [Page 17] |
956 | RFC 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 | |
987 | 2.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 | |
1010 | Fielding & Reschke Standards Track [Page 18] |
1012 | RFC 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 | |
1026 | 2.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 |
.../cache/cache.h 688 |
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 | |
1050 | 3. 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 | |
1066 | Fielding & Reschke Standards Track [Page 19] |
1068 | RFC 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 | |
1111 | 3.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 | |
1122 | Fielding & Reschke Standards Track [Page 20] |
1124 | RFC 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 | |
1135 | 3.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. |
.../cache/cache.h 691 |
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 | |
1178 | Fielding & Reschke Standards Track [Page 21] |
1180 | RFC 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 | |
1191 | 3.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 | |
1220 | 3.2. Header Fields |
1221 | |
1222 | Each header field consists of a case-insensitive field name followed |
.../cache/cache.h 695 |
1223 | by a colon (":"), optional leading whitespace, the field value, and |
1224 | optional trailing whitespace. |
1225 | |
1226 | |
1227 | |
1228 | |
1229 | |
1230 | |
1231 | |
1232 | |
1233 | |
1234 | Fielding & Reschke Standards Track [Page 22] |
1236 | RFC 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 ] |
.../cache/cache_vrt.c 542 |
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 | |
1255 | 3.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 | |
1279 | 3.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 | |
1290 | Fielding & Reschke Standards Track [Page 23] |
1292 | RFC 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 | |
1321 | 3.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 | |
1346 | Fielding & Reschke Standards Track [Page 24] |
1348 | RFC 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 | |
1358 | 3.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 | |
1402 | Fielding & Reschke Standards Track [Page 25] |
1404 | RFC 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 | |
1435 | 3.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 | |
1458 | Fielding & Reschke Standards Track [Page 26] |
1460 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
1461 | |
1462 | |
1463 | 3.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 | |
1514 | Fielding & Reschke Standards Track [Page 27] |
1516 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
1517 | |
1518 | |
1519 | 3.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 | |
1549 | 3.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 | |
1570 | Fielding & Reschke Standards Track [Page 28] |
1572 | RFC 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 | |
1626 | Fielding & Reschke Standards Track [Page 29] |
1628 | RFC 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 | |
1640 | 3.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 |
.../cache/cache_req_fsm.c 477 |
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 | |
1682 | Fielding & Reschke Standards Track [Page 30] |
1684 | RFC 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 |
.../cache/cache_req_fsm.c 474 |
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 | |
1738 | Fielding & Reschke Standards Track [Page 31] |
1740 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
1741 | |
1742 | |
1743 | 3.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 |
.../cache/cache_req_fsm.c 457 |
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 | |
1794 | Fielding & Reschke Standards Track [Page 32] |
1796 | RFC 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 | |
1850 | Fielding & Reschke Standards Track [Page 33] |
1852 | RFC 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 | |
1861 | 3.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 | |
1889 | 3.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 | |
1906 | Fielding & Reschke Standards Track [Page 34] |
1908 | RFC 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 | |
1932 | 4. 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 |
.../cache/cache.h 703 |
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 | |
1962 | Fielding & Reschke Standards Track [Page 35] |
1964 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
1965 | |
1966 | |
1967 | 4.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 | |
1997 | 4.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 | |
2018 | Fielding & Reschke Standards Track [Page 36] |
2020 | RFC 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 | |
2034 | 4.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 | |
2074 | Fielding & Reschke Standards Track [Page 37] |
2132 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
2133 | |
2134 | |
2135 | 4.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 | |
2142 | 4.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 | |
2186 | Fielding & Reschke Standards Track [Page 39] |
2188 | RFC 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 | |
2205 | 4.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 | |
2218 | 5. 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 | |
2226 | 5.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 | |
2242 | Fielding & Reschke Standards Track [Page 40] |
2244 | RFC 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 | |
2253 | 5.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 | |
2282 | 5.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 | |
2298 | Fielding & Reschke Standards Track [Page 41] |
2300 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
2301 | |
2302 | |
2303 | 5.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 | |
2331 | 5.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 | |
2354 | Fielding & Reschke Standards Track [Page 42] |
2356 | RFC 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 | |
2364 | 5.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 | |
2378 | 5.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 | |
2410 | Fielding & Reschke Standards Track [Page 43] |
2412 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
2413 | |
2414 | |
2415 | 5.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 | |
2466 | Fielding & Reschke Standards Track [Page 44] |
2468 | RFC 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 | |
2476 | 5.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 | |
2522 | Fielding & Reschke Standards Track [Page 45] |
2524 | RFC 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 | |
2564 | 5.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 | |
2578 | Fielding & Reschke Standards Track [Page 46] |
2580 | RFC 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 | |
2589 | 5.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 | |
2610 | 5.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 | |
2634 | Fielding & Reschke Standards Track [Page 47] |
2636 | RFC 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 | |
2690 | Fielding & Reschke Standards Track [Page 48] |
2692 | RFC 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 | |
2710 | 5.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 | |
2746 | Fielding & Reschke Standards Track [Page 49] |
2748 | RFC 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 | |
2778 | 6. 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 | |
2802 | Fielding & Reschke Standards Track [Page 50] |
2804 | RFC 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 | |
2817 | 6.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. |
.../cache/cache.h 696 |
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 | |
2858 | Fielding & Reschke Standards Track [Page 51] |
2860 | RFC 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 | |
2896 | 6.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 | |
2902 | 6.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 | |
2914 | Fielding & Reschke Standards Track [Page 52] |
2916 | RFC 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 | |
2957 | 6.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 | |
2970 | Fielding & Reschke Standards Track [Page 53] |
2972 | RFC 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 | |
2996 | 6.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 | |
3026 | Fielding & Reschke Standards Track [Page 54] |
3028 | RFC 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 | |
3042 | 6.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 | |
3064 | 6.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 | |
3082 | Fielding & Reschke Standards Track [Page 55] |
3084 | RFC 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 | |
3107 | 6.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 | |
3138 | Fielding & Reschke Standards Track [Page 56] |
3140 | RFC 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 | |
3165 | 6.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 | |
3194 | Fielding & Reschke Standards Track [Page 57] |
3196 | RFC 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 | |
3250 | Fielding & Reschke Standards Track [Page 58] |
3252 | RFC 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 | |
3293 | 7. 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 | |
3306 | Fielding & Reschke Standards Track [Page 59] |
3308 | RFC 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 | |
3362 | Fielding & Reschke Standards Track [Page 60] |
3364 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
3365 | |
3366 | |
3367 | 8. IANA Considerations |
3368 | |
3369 | 8.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 | |
3418 | Fielding & Reschke Standards Track [Page 61] |
3420 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
3421 | |
3422 | |
3423 | 8.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 | |
3438 | 8.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 | |
3447 | 8.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 | |
3474 | Fielding & Reschke Standards Track [Page 62] |
3588 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
3589 | |
3590 | |
3591 | 8.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 | |
3613 | 8.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 | |
3642 | Fielding & Reschke Standards Track [Page 65] |
3644 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
3645 | |
3646 | |
3647 | 8.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 | |
3667 | 8.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 | |
3674 | 8.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 | |
3698 | Fielding & Reschke Standards Track [Page 66] |
3700 | RFC 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 | |
3714 | 8.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 | |
3730 | 9. 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 | |
3737 | 9.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 | |
3754 | Fielding & Reschke Standards Track [Page 67] |
3756 | RFC 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 | |
3790 | 9.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 | |
3810 | Fielding & Reschke Standards Track [Page 68] |
3812 | RFC 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 | |
3823 | 9.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 | |
3849 | 9.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 | |
3866 | Fielding & Reschke Standards Track [Page 69] |
3868 | RFC 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 | |
3898 | 9.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 | |
3911 | 9.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 | |
3922 | Fielding & Reschke Standards Track [Page 70] |
3924 | RFC 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 | |
3946 | 9.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 | |
3958 | 9.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 | |
3978 | Fielding & Reschke Standards Track [Page 71] |
3980 | RFC 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 | |
3990 | 10. 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 | |
4034 | Fielding & Reschke Standards Track [Page 72] |
4036 | RFC 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 | |
4090 | Fielding & Reschke Standards Track [Page 73] |
4092 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
4093 | |
4094 | |
4095 | 11. References |
4096 | |
4097 | 11.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 | |
4146 | Fielding & Reschke Standards Track [Page 74] |
4148 | RFC 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 | |
4158 | 11.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 | |
4202 | Fielding & Reschke Standards Track [Page 75] |
4204 | RFC 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 | |
4258 | Fielding & Reschke Standards Track [Page 76] |
4316 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
4317 | |
4318 | |
4319 | Appendix 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 | |
4356 | A.1. Changes from HTTP/1.0 |
4357 | |
4358 | This section summarizes major differences between versions HTTP/1.0 |
4359 | and HTTP/1.1. |
4360 | |
4361 | A.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 | |
4370 | Fielding & Reschke Standards Track [Page 78] |
4372 | RFC 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 | |
4386 | A.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 | |
4418 | A.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 | |
4426 | Fielding & Reschke Standards Track [Page 79] |
4428 | RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 |
4429 | |
4430 | |
4431 | A.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 | |
4482 | Fielding & Reschke Standards Track [Page 80] |
4484 | RFC 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 | |
4538 | Fielding & Reschke Standards Track [Page 81] |
4540 | RFC 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 | |
4553 | Appendix 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 | |
4594 | Fielding & Reschke Standards Track [Page 82] |
4596 | RFC 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 | |
4650 | Fielding & Reschke Standards Track [Page 83] |
4652 | RFC 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 | |
4706 | Fielding & Reschke Standards Track [Page 84] |