4 HTTPbis Working Group R. Fielding, Ed.
5 Internet-Draft Day Software
6 Obsoletes: 2616 (if approved) J. Gettys
7 Updates: 2817 (if approved) Alcatel-Lucent
8 Intended status: Standards Track J. Mogul
9 Expires: February 5, 2011 HP
25 HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26 draft-ietf-httpbis-p1-messaging-11
30 The Hypertext Transfer Protocol (HTTP) is an application-level
31 protocol for distributed, collaborative, hypertext information
32 systems. HTTP has been in use by the World Wide Web global
33 information initiative since 1990. This document is Part 1 of the
34 seven-part specification that defines the protocol referred to as
35 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
36 an overview of HTTP and its associated terminology, defines the
37 "http" and "https" Uniform Resource Identifier (URI) schemes, defines
38 the generic message syntax and parsing requirements for HTTP message
39 frames, and describes general security concerns for implementations.
41 Editorial Note (To be removed by RFC Editor)
43 Discussion of this draft should take place on the HTTPBIS working
44 group mailing list (ietf-http-wg@w3.org). The current issues list is
45 at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
46 documents (including fancy diffs) can be found at
47 <http://tools.ietf.org/wg/httpbis/>.
49 The changes in this draft are summarized in Appendix D.12.
55 Fielding, et al. Expires February 5, 2011 [Page 1]
57 Internet-Draft HTTP/1.1, Part 1 August 2010
60 This Internet-Draft is submitted in full conformance with the
61 provisions of BCP 78 and BCP 79.
63 Internet-Drafts are working documents of the Internet Engineering
64 Task Force (IETF). Note that other groups may also distribute
65 working documents as Internet-Drafts. The list of current Internet-
66 Drafts is at http://datatracker.ietf.org/drafts/current/.
68 Internet-Drafts are draft documents valid for a maximum of six months
69 and may be updated, replaced, or obsoleted by other documents at any
70 time. It is inappropriate to use Internet-Drafts as reference
71 material or to cite them other than as "work in progress."
73 This Internet-Draft will expire on February 5, 2011.
77 Copyright (c) 2010 IETF Trust and the persons identified as the
78 document authors. All rights reserved.
80 This document is subject to BCP 78 and the IETF Trust's Legal
81 Provisions Relating to IETF Documents
82 (http://trustee.ietf.org/license-info) in effect on the date of
83 publication of this document. Please review these documents
84 carefully, as they describe your rights and restrictions with respect
85 to this document. Code Components extracted from this document must
86 include Simplified BSD License text as described in Section 4.e of
87 the Trust Legal Provisions and are provided without warranty as
88 described in the Simplified BSD License.
90 This document may contain material from IETF Documents or IETF
91 Contributions published or made publicly available before November
92 10, 2008. The person(s) controlling the copyright in some of this
93 material may not have granted the IETF Trust the right to allow
94 modifications of such material outside the IETF Standards Process.
95 Without obtaining an adequate license from the person(s) controlling
96 the copyright in such materials, this document may not be modified
97 outside the IETF Standards Process, and derivative works of it may
98 not be created outside the IETF Standards Process, except to format
99 it for publication as an RFC or to translate it into languages other
104 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
105 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
106 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
107 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
111 Fielding, et al. Expires February 5, 2011 [Page 2]
113 Internet-Draft HTTP/1.1, Part 1 August 2010
116 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
117 1.2.3. ABNF Rules defined in other Parts of the
118 Specification . . . . . . . . . . . . . . . . . . . . 10
119 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10
120 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
121 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
122 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
123 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
124 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
125 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
126 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
127 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
128 2.6.3. http and https URI Normalization and Comparison . . . 18
129 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
130 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20
131 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
132 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
133 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25
134 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
135 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
136 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
137 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27
138 4.2. The Resource Identified by a Request . . . . . . . . . . . 29
139 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29
140 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
141 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
142 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
143 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32
144 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32
145 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34
146 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35
147 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37
148 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38
149 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
150 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39
151 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39
152 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39
153 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
154 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40
155 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
156 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44
157 7.2. Message Transmission Requirements . . . . . . . . . . . . 45
158 7.2.1. Persistent Connections and Flow Control . . . . . . . 45
159 7.2.2. Monitoring Connections for Error Status Messages . . . 45
160 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
161 7.2.4. Client Behavior if Server Prematurely Closes
162 Connection . . . . . . . . . . . . . . . . . . . . . . 48
163 8. Miscellaneous notes that might disappear . . . . . . . . . . . 49
167 Fielding, et al. Expires February 5, 2011 [Page 3]
169 Internet-Draft HTTP/1.1, Part 1 August 2010
172 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49
173 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
174 8.3. Interception of HTTP for access control . . . . . . . . . 49
175 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
176 8.5. Use of HTTP by media type specification . . . . . . . . . 49
177 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
178 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
179 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50
180 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
181 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52
182 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
183 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
184 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
185 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55
186 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
187 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
188 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
189 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
190 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59
191 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
192 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59
193 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59
194 10.3.2. Internet Media Type application/http . . . . . . . . . 61
195 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
196 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
197 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
198 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
199 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
200 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
201 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63
202 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
203 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
204 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
205 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
206 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
207 13.2. Informative References . . . . . . . . . . . . . . . . . . 68
208 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70
209 Appendix B. Compatibility with Previous Versions . . . . . . . . 71
210 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
211 B.1.1. Changes to Simplify Multi-homed Web Servers and
212 Conserve IP Addresses . . . . . . . . . . . . . . . . 72
213 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72
214 B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
215 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74
216 Appendix D. Change Log (to be removed by RFC Editor before
217 publication) . . . . . . . . . . . . . . . . . . . . 78
218 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78
219 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
223 Fielding, et al. Expires February 5, 2011 [Page 4]
225 Internet-Draft HTTP/1.1, Part 1 August 2010
228 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
229 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
230 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
231 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
232 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
233 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
234 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
235 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
236 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
237 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85
238 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
279 Fielding, et al. Expires February 5, 2011 [Page 5]
281 Internet-Draft HTTP/1.1, Part 1 August 2010
286 The Hypertext Transfer Protocol (HTTP) is an application-level
287 request/response protocol that uses extensible semantics and MIME-
288 like message payloads for flexible interaction with network-based
289 hypertext information systems. HTTP relies upon the Uniform Resource
290 Identifier (URI) standard [RFC3986] to indicate request targets and
291 relationships between resources. Messages are passed in a format
292 similar to that used by Internet mail [RFC5322] and the Multipurpose
293 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3]
294 for the differences between HTTP and MIME messages).
296 HTTP is a generic interface protocol for information systems. It is
297 designed to hide the details of how a service is implemented by
298 presenting a uniform interface to clients that is independent of the
299 types of resources provided. Likewise, servers do not need to be
300 aware of each client's purpose: an HTTP request can be considered in
301 isolation rather than being associated with a specific type of client
302 or a predetermined sequence of application steps. The result is a
303 protocol that can be used effectively in many different contexts and
304 for which implementations can evolve independently over time.
306 HTTP is also designed for use as an intermediation protocol for
307 translating communication to and from non-HTTP information systems.
308 HTTP proxies and gateways can provide access to alternative
309 information services by translating their diverse protocols into a
310 hypertext format that can be viewed and manipulated by clients in the
311 same way as HTTP services.
313 One consequence of HTTP flexibility is that the protocol cannot be
314 defined in terms of what occurs behind the interface. Instead, we
315 are limited to defining the syntax of communication, the intent of
316 received communication, and the expected behavior of recipients. If
317 the communication is considered in isolation, then successful actions
318 ought to be reflected in corresponding changes to the observable
319 interface provided by servers. However, since multiple clients might
320 act in parallel and perhaps at cross-purposes, we cannot require that
321 such changes be observable beyond the scope of a single response.
323 This document is Part 1 of the seven-part specification of HTTP,
324 defining the protocol referred to as "HTTP/1.1" and obsoleting
325 [RFC2616]. Part 1 describes the architectural elements that are used
326 or referred to in HTTP, defines the "http" and "https" URI schemes,
327 describes overall network operation and connection management, and
328 defines HTTP message framing and forwarding requirements. Our goal
329 is to define all of the mechanisms necessary for HTTP message
330 handling that are independent of message semantics, thereby defining
331 the complete set of requirements for message parsers and message-
335 Fielding, et al. Expires February 5, 2011 [Page 6]
337 Internet-Draft HTTP/1.1, Part 1 August 2010
340 forwarding intermediaries.
344 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
345 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
346 document are to be interpreted as described in [RFC2119].
348 An implementation is not compliant if it fails to satisfy one or more
349 of the "MUST" or "REQUIRED" level requirements for the protocols it
350 implements. An implementation that satisfies all the "MUST" or
351 "REQUIRED" level and all the "SHOULD" level requirements for its
352 protocols is said to be "unconditionally compliant"; one that
353 satisfies all the "MUST" level requirements but not all the "SHOULD"
354 level requirements for its protocols is said to be "conditionally
359 This specification uses the Augmented Backus-Naur Form (ABNF)
360 notation of [RFC5234].
362 The following core rules are included by reference, as defined in
363 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
364 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
365 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
366 sequence of data), SP (space), VCHAR (any visible [USASCII]
367 character), and WSP (whitespace).
369 As a syntactic convention, ABNF rule names prefixed with "obs-"
370 denote "obsolete" grammar rules that appear for historical reasons.
372 1.2.1. ABNF Extension: #rule
374 The #rule extension to the ABNF rules of [RFC5234] is used to improve
377 A construct "#" is defined, similar to "*", for defining comma-
378 delimited lists of elements. The full form is "<n>#<m>element"
379 indicating at least <n> and at most <m> elements, each separated by a
380 single comma (",") and optional whitespace (OWS, Section 1.2.2).
384 1#element => element *( OWS "," OWS element )
391 Fielding, et al. Expires February 5, 2011 [Page 7]
393 Internet-Draft HTTP/1.1, Part 1 August 2010
398 #element => [ 1#element ]
400 and for n >= 1 and m > 1:
402 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
404 For compatibility with legacy list rules, recipients SHOULD accept
405 empty list elements. In other words, consumers would follow the list
408 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
410 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
412 Note that empty elements do not contribute to the count of elements
415 For example, given these ABNF productions:
417 example-list = 1#example-list-elmt
418 example-list-elmt = token ; see Section 1.2.2
420 Then these are valid values for example-list (not including the
421 double quotes, which are present for delimitation only):
425 " foo , ,bar,charlie "
428 But these values would be invalid, as at least one non-empty element
435 Appendix C shows the collected ABNF, with the list rules expanded as
440 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
441 protocol elements other than the message-body (see Appendix A for
442 tolerant applications).
447 Fielding, et al. Expires February 5, 2011 [Page 8]
449 Internet-Draft HTTP/1.1, Part 1 August 2010
452 This specification uses three rules to denote the use of linear
453 whitespace: OWS (optional whitespace), RWS (required whitespace), and
454 BWS ("bad" whitespace).
456 The OWS rule is used where zero or more linear whitespace characters
457 might appear. OWS SHOULD either not be produced or be produced as a
458 single SP character. Multiple OWS characters that occur within
459 field-content SHOULD be replaced with a single SP before interpreting
460 the field value or forwarding the message downstream.
462 RWS is used when at least one linear whitespace character is required
463 to separate field tokens. RWS SHOULD be produced as a single SP
464 character. Multiple RWS characters that occur within field-content
465 SHOULD be replaced with a single SP before interpreting the field
466 value or forwarding the message downstream.
468 BWS is used where the grammar allows optional whitespace for
469 historical reasons but senders SHOULD NOT produce it in messages.
470 HTTP/1.1 recipients MUST accept such bad optional whitespace and
471 remove it before interpreting the field value or forwarding the
475 OWS = *( [ obs-fold ] WSP )
476 ; "optional" whitespace
477 RWS = 1*( [ obs-fold ] WSP )
478 ; "required" whitespace
484 Many HTTP/1.1 header field values consist of words (token or quoted-
485 string) separated by whitespace or special characters. These special
486 characters MUST be in a quoted string to be used within a parameter
487 value (as defined in Section 6.2).
489 word = token / quoted-string
493 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
494 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
496 ; any VCHAR, except special
498 special = "(" / ")" / "<" / ">" / "@" / ","
499 / ";" / ":" / "\" / DQUOTE / "/" / "["
503 Fielding, et al. Expires February 5, 2011 [Page 9]
505 Internet-Draft HTTP/1.1, Part 1 August 2010
508 / "]" / "?" / "=" / "{" / "}"
510 A string of text is parsed as a single word if it is quoted using
513 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
514 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
515 ; OWS / <VCHAR except DQUOTE and "\"> / obs-text
518 The backslash character ("\") can be used as a single-character
519 quoting mechanism within quoted-string constructs:
521 quoted-pair = "\" ( WSP / VCHAR / obs-text )
523 Producers SHOULD NOT escape characters that do not require escaping
524 (i.e., other than DQUOTE and the backslash character).
526 1.2.3. ABNF Rules defined in other Parts of the Specification
528 The ABNF rules below are defined in other parts:
530 request-header = <request-header, defined in [Part2], Section 3>
531 response-header = <response-header, defined in [Part2], Section 5>
534 MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1>
537 Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
538 Pragma = <Pragma, defined in [Part6], Section 3.4>
539 Warning = <Warning, defined in [Part6], Section 3.6>
541 2. HTTP-related architecture
543 HTTP was created for the World Wide Web architecture and has evolved
544 over time to support the scalability needs of a worldwide hypertext
545 system. Much of that architecture is reflected in the terminology
546 and syntax productions used to define HTTP.
548 2.1. Client/Server Messaging
550 HTTP is a stateless request/response protocol that operates by
551 exchanging messages across a reliable transport or session-layer
552 connection. An HTTP "client" is a program that establishes a
553 connection to a server for the purpose of sending one or more HTTP
554 requests. An HTTP "server" is a program that accepts connections in
555 order to service HTTP requests by sending HTTP responses.
559 Fielding, et al. Expires February 5, 2011 [Page 10]
561 Internet-Draft HTTP/1.1, Part 1 August 2010
564 Note that the terms client and server refer only to the roles that
565 these programs perform for a particular connection. The same program
566 might act as a client on some connections and a server on others. We
567 use the term "user agent" to refer to the program that initiates a
568 request, such as a WWW browser, editor, or spider (web-traversing
569 robot), and the term "origin server" to refer to the program that can
570 originate authoritative responses to a request. For general
571 requirements, we use the term "sender" to refer to whichever
572 component sent a given message and the term "recipient" to refer to
573 any component that receives the message.
575 Most HTTP communication consists of a retrieval request (GET) for a
576 representation of some resource identified by a URI. In the simplest
577 case, this might be accomplished via a single bidirectional
578 connection (===) between the user agent (UA) and the origin server
582 UA ======================================= O
585 A client sends an HTTP request to the server in the form of a request
586 message (Section 4), beginning with a method, URI, and protocol
587 version, followed by MIME-like header fields containing request
588 modifiers, client information, and payload metadata, an empty line to
589 indicate the end of the header section, and finally the payload body
592 A server responds to the client's request by sending an HTTP response
593 message (Section 5), beginning with a status line that includes the
594 protocol version, a success or error code, and textual reason phrase,
595 followed by MIME-like header fields containing server information,
596 resource metadata, and payload metadata, an empty line to indicate
597 the end of the header section, and finally the payload body (if any).
599 The following example illustrates a typical message exchange for a
600 GET request on the URI "http://www.example.com/hello.txt":
604 GET /hello.txt HTTP/1.1
605 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
606 Host: www.example.com
615 Fielding, et al. Expires February 5, 2011 [Page 11]
617 Internet-Draft HTTP/1.1, Part 1 August 2010
623 Date: Mon, 27 Jul 2009 12:28:53 GMT
625 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
626 ETag: "34aa387-d-1568eb00"
629 Vary: Accept-Encoding
630 Content-Type: text/plain
636 A more complicated situation occurs when one or more intermediaries
637 are present in the request/response chain. There are three common
638 forms of intermediary: proxy, gateway, and tunnel. In some cases, a
639 single intermediary might act as an origin server, proxy, gateway, or
640 tunnel, switching behavior based on the nature of each request.
643 UA =========== A =========== B =========== C =========== O
646 The figure above shows three intermediaries (A, B, and C) between the
647 user agent and origin server. A request or response message that
648 travels the whole chain will pass through four separate connections.
649 Some HTTP communication options might apply only to the connection
650 with the nearest, non-tunnel neighbor, only to the end-points of the
651 chain, or to all connections along the chain. Although the diagram
652 is linear, each participant might be engaged in multiple,
653 simultaneous communications. For example, B might be receiving
654 requests from many clients other than A, and/or forwarding requests
655 to servers other than C, at the same time that it is handling A's
658 We use the terms "upstream" and "downstream" to describe various
659 requirements in relation to the directional flow of a message: all
660 messages flow from upstream to downstream. Likewise, we use the
661 terms "inbound" and "outbound" to refer to directions in relation to
662 the request path: "inbound" means toward the origin server and
663 "outbound" means toward the user agent.
665 A "proxy" is a message forwarding agent that is selected by the
666 client, usually via local configuration rules, to receive requests
667 for some type(s) of absolute URI and attempt to satisfy those
671 Fielding, et al. Expires February 5, 2011 [Page 12]
673 Internet-Draft HTTP/1.1, Part 1 August 2010
676 requests via translation through the HTTP interface. Some
677 translations are minimal, such as for proxy requests for "http" URIs,
678 whereas other requests might require translation to and from entirely
679 different application-layer protocols. Proxies are often used to
680 group an organization's HTTP requests through a common intermediary
681 for the sake of security, annotation services, or shared caching.
683 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
684 as a layer above some other server(s) and translates the received
685 requests to the underlying server's protocol. Gateways are often
686 used for load balancing or partitioning HTTP services across multiple
687 machines. Unlike a proxy, a gateway receives requests as if it were
688 the origin server for the target resource; the requesting client will
689 not be aware that it is communicating with a gateway. A gateway
690 communicates with the client as if the gateway is the origin server
691 and thus is subject to all of the requirements on origin servers for
692 that connection. A gateway communicates with inbound servers using
693 any protocol it desires, including private extensions to HTTP that
694 are outside the scope of this specification.
696 A "tunnel" acts as a blind relay between two connections without
697 changing the messages. Once active, a tunnel is not considered a
698 party to the HTTP communication, though the tunnel might have been
699 initiated by an HTTP request. A tunnel ceases to exist when both
700 ends of the relayed connection are closed. Tunnels are used to
701 extend a virtual connection through an intermediary, such as when
702 transport-layer security is used to establish private communication
703 through a shared firewall proxy.
707 A "cache" is a local store of previous response messages and the
708 subsystem that controls its message storage, retrieval, and deletion.
709 A cache stores cacheable responses in order to reduce the response
710 time and network bandwidth consumption on future, equivalent
711 requests. Any client or server MAY employ a cache, though a cache
712 cannot be used by a server while it is acting as a tunnel.
714 The effect of a cache is that the request/response chain is shortened
715 if one of the participants along the chain has a cached response
716 applicable to that request. The following illustrates the resulting
717 chain if B has a cached copy of an earlier response from O (via C)
718 for a request which has not been cached by UA or A.
721 UA =========== A =========== B - - - - - - C - - - - - - O
727 Fielding, et al. Expires February 5, 2011 [Page 13]
729 Internet-Draft HTTP/1.1, Part 1 August 2010
732 A response is "cacheable" if a cache is allowed to store a copy of
733 the response message for use in answering subsequent requests. Even
734 when a response is cacheable, there might be additional constraints
735 placed by the client or by the origin server on when that cached
736 response can be used for a particular request. HTTP requirements for
737 cache behavior and cacheable responses are defined in Section 2 of
740 There are a wide variety of architectures and configurations of
741 caches and proxies deployed across the World Wide Web and inside
742 large organizations. These systems include national hierarchies of
743 proxy caches to save transoceanic bandwidth, systems that broadcast
744 or multicast cache entries, organizations that distribute subsets of
745 cached data via optical media, and so on.
747 2.4. Transport Independence
749 HTTP systems are used in a wide variety of environments, from
750 corporate intranets with high-bandwidth links to long-distance
751 communication over low-power radio links and intermittent
754 HTTP communication usually takes place over TCP/IP connections. The
755 default port is TCP 80
756 (<http://www.iana.org/assignments/port-numbers>), but other ports can
757 be used. This does not preclude HTTP from being implemented on top
758 of any other protocol on the Internet, or on other networks. HTTP
759 only presumes a reliable transport; any protocol that provides such
760 guarantees can be used; the mapping of the HTTP/1.1 request and
761 response structures onto the transport data units of the protocol in
762 question is outside the scope of this specification.
764 In HTTP/1.0, most implementations used a new connection for each
765 request/response exchange. In HTTP/1.1, a connection might be used
766 for one or more request/response exchanges, although connections
767 might be closed for a variety of reasons (see Section 7.1).
771 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
772 of the protocol. The protocol versioning policy is intended to allow
773 the sender to indicate the format of a message and its capacity for
774 understanding further HTTP communication, rather than the features
775 obtained via that communication. No change is made to the version
776 number for the addition of message components which do not affect
777 communication behavior or which only add to extensible field values.
778 The <minor> number is incremented when the changes made to the
779 protocol add features which do not change the general message parsing
783 Fielding, et al. Expires February 5, 2011 [Page 14]
785 Internet-Draft HTTP/1.1, Part 1 August 2010
788 algorithm, but which might add to the message semantics and imply
789 additional capabilities of the sender. The <major> number is
790 incremented when the format of a message within the protocol is
791 changed. See [RFC2145] for a fuller explanation.
793 The version of an HTTP message is indicated by an HTTP-Version field
794 in the first line of the message. HTTP-Version is case-sensitive.
796 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
797 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
799 Note that the major and minor numbers MUST be treated as separate
800 integers and that each MAY be incremented higher than a single digit.
801 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
802 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
803 and MUST NOT be sent.
805 An application that sends a request or response message that includes
806 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
807 with this specification. Applications that are at least
808 conditionally compliant with this specification SHOULD use an HTTP-
809 Version of "HTTP/1.1" in their messages, and MUST do so for any
810 message that is not compatible with HTTP/1.0. For more details on
811 when to send specific HTTP-Version values, see [RFC2145].
813 The HTTP version of an application is the highest HTTP version for
814 which the application is at least conditionally compliant.
816 Proxy and gateway applications need to be careful when forwarding
817 messages in protocol versions different from that of the application.
818 Since the protocol version indicates the protocol capability of the
819 sender, a proxy/gateway MUST NOT send a message with a version
820 indicator which is greater than its actual version. If a higher
821 version request is received, the proxy/gateway MUST either downgrade
822 the request version, or respond with an error, or switch to tunnel
825 Due to interoperability problems with HTTP/1.0 proxies discovered
826 since the publication of [RFC2068], caching proxies MUST, gateways
827 MAY, and tunnels MUST NOT upgrade the request to the highest version
828 they support. The proxy/gateway's response to that request MUST be
829 in the same major version as the request.
831 Note: Converting between versions of HTTP might involve
832 modification of header fields required or forbidden by the
839 Fielding, et al. Expires February 5, 2011 [Page 15]
841 Internet-Draft HTTP/1.1, Part 1 August 2010
844 2.6. Uniform Resource Identifiers
846 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
847 HTTP as the means for identifying resources. URI references are used
848 to target requests, indicate redirects, and define relationships.
849 HTTP does not limit what a resource might be; it merely defines an
850 interface that can be used to interact with a resource via HTTP.
851 More information on the scope of URIs and resources can be found in
854 This specification adopts the definitions of "URI-reference",
855 "absolute-URI", "relative-part", "port", "host", "path-abempty",
856 "path-absolute", "query", and "authority" from [RFC3986]. In
857 addition, we define a partial-URI rule for protocol elements that
858 allow a relative URI without a fragment.
860 URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
861 absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
862 relative-part = <relative-part, defined in [RFC3986], Section 4.2>
863 authority = <authority, defined in [RFC3986], Section 3.2>
864 path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
865 path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
866 port = <port, defined in [RFC3986], Section 3.2.3>
867 query = <query, defined in [RFC3986], Section 3.4>
868 uri-host = <host, defined in [RFC3986], Section 3.2.2>
870 partial-URI = relative-part [ "?" query ]
872 Each protocol element in HTTP that allows a URI reference will
873 indicate in its ABNF production whether the element allows only a URI
874 in absolute form (absolute-URI), any relative reference (relative-
875 ref), or some other subset of the URI-reference grammar. Unless
876 otherwise indicated, URI references are parsed relative to the
877 request target (the default base URI for both the request and its
878 corresponding response).
880 2.6.1. http URI scheme
882 The "http" URI scheme is hereby defined for the purpose of minting
883 identifiers according to their association with the hierarchical
884 namespace governed by a potential HTTP origin server listening for
885 TCP connections on a given port. The HTTP server is identified via
886 the generic syntax's authority component, which includes a host
887 identifier and optional TCP port, and the remainder of the URI is
888 considered to be identifying data corresponding to a resource for
889 which that server might provide an HTTP interface.
891 http-URI = "http:" "//" authority path-abempty [ "?" query ]
895 Fielding, et al. Expires February 5, 2011 [Page 16]
897 Internet-Draft HTTP/1.1, Part 1 August 2010
900 The host identifier within an authority component is defined in
901 [RFC3986], Section 3.2.2. If host is provided as an IP literal or
902 IPv4 address, then the HTTP server is any listener on the indicated
903 TCP port at that IP address. If host is a registered name, then that
904 name is considered an indirect identifier and the recipient might use
905 a name resolution service, such as DNS, to find the address of a
906 listener for that host. The host MUST NOT be empty; if an "http" URI
907 is received with an empty host, then it MUST be rejected as invalid.
908 If the port subcomponent is empty or not given, then TCP port 80 is
909 assumed (the default reserved port for WWW services).
911 Regardless of the form of host identifier, access to that host is not
912 implied by the mere presence of its name or address. The host might
913 or might not exist and, even when it does exist, might or might not
914 be running an HTTP server or listening to the indicated port. The
915 "http" URI scheme makes use of the delegated nature of Internet names
916 and addresses to establish a naming authority (whatever entity has
917 the ability to place an HTTP server at that Internet name or address)
918 and allows that authority to determine which names are valid and how
921 When an "http" URI is used within a context that calls for access to
922 the indicated resource, a client MAY attempt access by resolving the
923 host to an IP address, establishing a TCP connection to that address
924 on the indicated port, and sending an HTTP request message to the
925 server containing the URI's identifying data as described in
926 Section 4. If the server responds to that request with a non-interim
927 HTTP response message, as described in Section 5, then that response
928 is considered an authoritative answer to the client's request.
930 Although HTTP is independent of the transport protocol, the "http"
931 scheme is specific to TCP-based services because the name delegation
932 process depends on TCP for establishing authority. An HTTP service
933 based on some other underlying connection protocol would presumably
934 be identified using a different URI scheme, just as the "https"
935 scheme (below) is used for servers that require an SSL/TLS transport
936 layer on a connection. Other protocols might also be used to provide
937 access to "http" identified resources --- it is only the
938 authoritative interface used for mapping the namespace that is
941 The URI generic syntax for authority also includes a deprecated
942 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
943 authentication information in the URI. The userinfo subcomponent
944 (and its "@" delimiter) MUST NOT be used in an "http" URI. URI
945 reference recipients SHOULD parse for the existence of userinfo and
946 treat its presence as an error, likely indicating that the deprecated
947 subcomponent is being used to obscure the authority for the sake of
951 Fielding, et al. Expires February 5, 2011 [Page 17]
953 Internet-Draft HTTP/1.1, Part 1 August 2010
958 2.6.2. https URI scheme
960 The "https" URI scheme is hereby defined for the purpose of minting
961 identifiers according to their association with the hierarchical
962 namespace governed by a potential HTTP origin server listening for
963 SSL/TLS-secured connections on a given TCP port.
965 All of the requirements listed above for the "http" scheme are also
966 requirements for the "https" scheme, except that a default TCP port
967 of 443 is assumed if the port subcomponent is empty or not given, and
968 the TCP connection MUST be secured for privacy through the use of
969 strong encryption prior to sending the first HTTP request.
971 https-URI = "https:" "//" authority path-abempty [ "?" query ]
973 Unlike the "http" scheme, responses to "https" identified requests
974 are never "public" and thus are ineligible for shared caching. Their
975 default is "private" and might be further constrained via use of the
976 Cache-Control header field.
978 Resources made available via the "https" scheme have no shared
979 identity with the "http" scheme even if their resource identifiers
980 only differ by the single "s" in the scheme name. They are different
981 services governed by different authorities. However, some extensions
982 to HTTP that apply to entire host domains, such as the Cookie
983 protocol, do allow one service to effect communication with the other
984 services based on host domain matching.
986 The process for authoritative access to an "https" identified
987 resource is defined in [RFC2818].
989 2.6.3. http and https URI Normalization and Comparison
991 Since the "http" and "https" schemes conform to the URI generic
992 syntax, such URIs are normalized and compared according to the
993 algorithm defined in [RFC3986], Section 6, using the defaults
994 described above for each scheme.
996 If the port is equal to the default port for a scheme, the normal
997 form is to elide the port subcomponent. Likewise, an empty path
998 component is equivalent to an absolute path of "/", so the normal
999 form is to provide a path of "/" instead. The scheme and host are
1000 case-insensitive and normally provided in lowercase; all other
1001 components are compared in a case-sensitive manner. Characters other
1002 than those in the "reserved" set are equivalent to their percent-
1003 encoded octets (see [RFC3986], Section 2.1): the normal form is to
1007 Fielding, et al. Expires February 5, 2011 [Page 18]
1009 Internet-Draft HTTP/1.1, Part 1 August 2010
1014 For example, the following three URIs are equivalent:
1016 http://example.com:80/~smith/home.html
1017 http://EXAMPLE.com/%7Esmith/home.html
1018 http://EXAMPLE.com:/%7esmith/home.html
1020 [[TODO-not-here: This paragraph does not belong here. --roy]] If
1021 path-abempty is the empty string (i.e., there is no slash "/" path
1022 separator following the authority), then the "http" URI MUST be given
1023 as "/" when used as a request-target (Section 4.1.2). If a proxy
1024 receives a host name which is not a fully qualified domain name, it
1025 MAY add its domain to the host name it received. If a proxy receives
1026 a fully qualified domain name, the proxy MUST NOT change the host
1031 All HTTP/1.1 messages consist of a start-line followed by a sequence
1032 of characters in a format similar to the Internet Message Format
1033 [RFC5322]: zero or more header fields (collectively referred to as
1034 the "headers" or the "header section"), an empty line indicating the
1035 end of the header section, and an optional message-body.
1037 An HTTP message can either be a request from client to server or a
1038 response from server to client. Syntactically, the two types of
1039 message differ only in the start-line, which is either a Request-Line
1040 (for requests) or a Status-Line (for responses), and in the algorithm
1041 for determining the length of the message-body (Section 3.3). In
1042 theory, a client could receive requests and a server could receive
1043 responses, distinguishing them by their different start-line formats,
1044 but in practice servers are implemented to only expect a request (a
1045 response is interpreted as an unknown or invalid request method) and
1046 clients are implemented to only expect a response.
1048 HTTP-message = start-line
1049 *( header-field CRLF )
1052 start-line = Request-Line / Status-Line
1054 Whitespace (WSP) MUST NOT be sent between the start-line and the
1055 first header field. The presence of whitespace might be an attempt
1056 to trick a noncompliant implementation of HTTP into ignoring that
1057 field or processing the next line as a new request, either of which
1058 might result in security issues when implementations within the
1059 request chain interpret the same message differently. HTTP/1.1
1063 Fielding, et al. Expires February 5, 2011 [Page 19]
1065 Internet-Draft HTTP/1.1, Part 1 August 2010
1068 servers MUST reject such a message with a 400 (Bad Request) response.
1070 3.1. Message Parsing Robustness
1072 In the interest of robustness, servers SHOULD ignore at least one
1073 empty line received where a Request-Line is expected. In other
1074 words, if the server is reading the protocol stream at the beginning
1075 of a message and receives a CRLF first, it SHOULD ignore the CRLF.
1077 Some old HTTP/1.0 client implementations generate an extra CRLF after
1078 a POST request as a lame workaround for some early server
1079 applications that failed to read message-body content that was not
1080 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
1081 follow a request with an extra CRLF. If terminating the request
1082 message-body with a line-ending is desired, then the client MUST
1083 include the terminating CRLF octets as part of the message-body
1086 The normal procedure for parsing an HTTP message is to read the
1087 start-line into a structure, read each header field into a hash table
1088 by field name until the empty line, and then use the parsed data to
1089 determine if a message-body is expected. If a message-body has been
1090 indicated, then it is read as a stream until an amount of octets
1091 equal to the message-body length is read or the connection is closed.
1092 Care must be taken to parse an HTTP message as a sequence of octets
1093 in an encoding that is a superset of US-ASCII. Attempting to parse
1094 HTTP as a stream of Unicode characters in a character encoding like
1095 UTF-16 might introduce security flaws due to the differing ways that
1096 such parsers interpret invalid characters.
1098 HTTP allows the set of defined header fields to be extended without
1099 changing the protocol version (see Section 10.1). However, such
1100 fields might not be recognized by a downstream recipient and might be
1101 stripped by non-transparent intermediaries. Unrecognized header
1102 fields MUST be forwarded by transparent proxies and SHOULD be ignored
1107 Each HTTP header field consists of a case-insensitive field name
1108 followed by a colon (":"), optional whitespace, and the field value.
1110 header-field = field-name ":" OWS [ field-value ] OWS
1112 field-value = *( field-content / OWS )
1113 field-content = *( WSP / VCHAR / obs-text )
1115 No whitespace is allowed between the header field name and colon.
1119 Fielding, et al. Expires February 5, 2011 [Page 20]
1121 Internet-Draft HTTP/1.1, Part 1 August 2010
1124 For security reasons, any request message received containing such
1125 whitespace MUST be rejected with a response code of 400 (Bad
1126 Request). A proxy MUST remove any such whitespace from a response
1127 message before forwarding the message downstream.
1129 A field value MAY be preceded by optional whitespace (OWS); a single
1130 SP is preferred. The field value does not include any leading or
1131 trailing white space: OWS occurring before the first non-whitespace
1132 character of the field value or after the last non-whitespace
1133 character of the field value is ignored and SHOULD be removed before
1134 further processing (as this does not change the meaning of the header
1137 The order in which header fields with differing field names are
1138 received is not significant. However, it is "good practice" to send
1139 header fields that contain control data first, such as Host on
1140 requests and Date on responses, so that implementations can decide
1141 when not to handle a message as early as possible. A server MUST
1142 wait until the entire header section is received before interpreting
1143 a request message, since later header fields might include
1144 conditionals, authentication credentials, or deliberately misleading
1145 duplicate header fields that would impact request processing.
1147 Multiple header fields with the same field name MUST NOT be sent in a
1148 message unless the entire field value for that header field is
1149 defined as a comma-separated list [i.e., #(values)]. Multiple header
1150 fields with the same field name can be combined into one "field-name:
1151 field-value" pair, without changing the semantics of the message, by
1152 appending each subsequent field value to the combined field value in
1153 order, separated by a comma. The order in which header fields with
1154 the same field name are received is therefore significant to the
1155 interpretation of the combined field value; a proxy MUST NOT change
1156 the order of these field values when forwarding a message.
1158 Note: The "Set-Cookie" header as implemented in practice (as
1159 opposed to how it is specified in [RFC2109]) can occur multiple
1160 times, but does not use the list syntax, and thus cannot be
1161 combined into a single line. (See Appendix A.2.3 of [Kri2001] for
1162 details.) Also note that the Set-Cookie2 header specified in
1163 [RFC2965] does not share this problem.
1165 Historically, HTTP header field values could be extended over
1166 multiple lines by preceding each extra line with at least one space
1167 or horizontal tab character (line folding). This specification
1168 deprecates such line folding except within the message/http media
1169 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages
1170 that include line folding (i.e., that contain any field-content that
1171 matches the obs-fold rule) unless the message is intended for
1175 Fielding, et al. Expires February 5, 2011 [Page 21]
1177 Internet-Draft HTTP/1.1, Part 1 August 2010
1180 packaging within the message/http media type. HTTP/1.1 recipients
1181 SHOULD accept line folding and replace any embedded obs-fold
1182 whitespace with a single SP prior to interpreting the field value or
1183 forwarding the message downstream.
1185 Historically, HTTP has allowed field content with text in the ISO-
1186 8859-1 [ISO-8859-1] character encoding and supported other character
1187 sets only through use of [RFC2047] encoding. In practice, most HTTP
1188 header field values use only a subset of the US-ASCII character
1189 encoding [USASCII]. Newly defined header fields SHOULD limit their
1190 field values to US-ASCII characters. Recipients SHOULD treat other
1191 (obs-text) octets in field content as opaque data.
1193 Comments can be included in some HTTP header fields by surrounding
1194 the comment text with parentheses. Comments are only allowed in
1195 fields containing "comment" as part of their field value definition.
1197 comment = "(" *( ctext / quoted-cpair / comment ) ")"
1198 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1199 ; OWS / <VCHAR except "(", ")", and "\"> / obs-text
1201 The backslash character ("\") can be used as a single-character
1202 quoting mechanism within comment constructs:
1204 quoted-cpair = "\" ( WSP / VCHAR / obs-text )
1206 Producers SHOULD NOT escape characters that do not require escaping
1207 (i.e., other than the backslash character "\" and the parentheses "("
1212 The message-body (if any) of an HTTP message is used to carry the
1213 payload body associated with the request or response.
1215 message-body = *OCTET
1217 The message-body differs from the payload body only when a transfer-
1218 coding has been applied, as indicated by the Transfer-Encoding header
1219 field (Section 9.7). When one or more transfer-codings are applied
1220 to a payload in order to form the message-body, the Transfer-Encoding
1221 header field MUST contain the list of transfer-codings applied.
1222 Transfer-Encoding is a property of the message, not of the payload,
1223 and thus MAY be added or removed by any implementation along the
1224 request/response chain under the constraints found in Section 6.2.
1226 The rules for when a message-body is allowed in a message differ for
1227 requests and responses.
1231 Fielding, et al. Expires February 5, 2011 [Page 22]
1233 Internet-Draft HTTP/1.1, Part 1 August 2010
1236 The presence of a message-body in a request is signaled by the
1237 inclusion of a Content-Length or Transfer-Encoding header field in
1238 the request's header fields, even if the request method does not
1239 define any use for a message-body. This allows the request message
1240 framing algorithm to be independent of method semantics.
1242 For response messages, whether or not a message-body is included with
1243 a message is dependent on both the request method and the response
1244 status code (Section 5.1.1). Responses to the HEAD request method
1245 never include a message-body because the associated response header
1246 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
1247 what their values would have been if the method had been GET. All
1248 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1249 responses MUST NOT include a message-body. All other responses do
1250 include a message-body, although the body MAY be of zero length.
1252 The length of the message-body is determined by one of the following
1253 (in order of precedence):
1255 1. Any response to a HEAD request and any response with a status
1256 code of 100-199, 204, or 304 is always terminated by the first
1257 empty line after the header fields, regardless of the header
1258 fields present in the message, and thus cannot contain a message-
1261 2. If a Transfer-Encoding header field (Section 9.7) is present and
1262 the "chunked" transfer-coding (Section 6.2) is the final
1263 encoding, the message-body length is determined by reading and
1264 decoding the chunked data until the transfer-coding indicates the
1267 If a Transfer-Encoding header field is present in a response and
1268 the "chunked" transfer-coding is not the final encoding, the
1269 message-body length is determined by reading the connection until
1270 it is closed by the server. If a Transfer-Encoding header field
1271 is present in a request and the "chunked" transfer-coding is not
1272 the final encoding, the message-body length cannot be determined
1273 reliably; the server MUST respond with the 400 (Bad Request)
1274 status code and then close the connection.
1276 If a message is received with both a Transfer-Encoding header
1277 field and a Content-Length header field, the Transfer-Encoding
1278 overrides the Content-Length. Such a message might indicate an
1279 attempt to perform request or response smuggling (bypass of
1280 security-related checks on message routing or content) and thus
1281 ought to be handled as an error. The provided Content-Length
1282 MUST be removed, prior to forwarding the message downstream, or
1283 replaced with the real message-body length after the transfer-
1287 Fielding, et al. Expires February 5, 2011 [Page 23]
1289 Internet-Draft HTTP/1.1, Part 1 August 2010
1294 3. If a message is received without Transfer-Encoding and with
1295 either multiple Content-Length header fields or a single Content-
1296 Length header field with an invalid value, then the message
1297 framing is invalid and MUST be treated as an error to prevent
1298 request or response smuggling. If this is a request message, the
1299 server MUST respond with a 400 (Bad Request) status code and then
1300 close the connection. If this is a response message received by
1301 a proxy or gateway, the proxy or gateway MUST discard the
1302 received response, send a 502 (Bad Gateway) status code as its
1303 downstream response, and then close the connection. If this is a
1304 response message received by a user-agent, the message-body
1305 length is determined by reading the connection until it is
1306 closed; an error SHOULD be indicated to the user.
1308 4. If a valid Content-Length header field (Section 9.2) is present
1309 without Transfer-Encoding, its decimal value defines the message-
1310 body length in octets. If the actual number of octets sent in
1311 the message is less than the indicated Content-Length, the
1312 recipient MUST consider the message to be incomplete and treat
1313 the connection as no longer usable. If the actual number of
1314 octets sent in the message is more than the indicated Content-
1315 Length, the recipient MUST only process the message-body up to
1316 the field value's number of octets; the remainder of the message
1317 MUST either be discarded or treated as the next message in a
1318 pipeline. For the sake of robustness, a user-agent MAY attempt
1319 to detect and correct such an error in message framing if it is
1320 parsing the response to the last request on on a connection and
1321 the connection has been closed by the server.
1323 5. If this is a request message and none of the above are true, then
1324 the message-body length is zero (no message-body is present).
1326 6. Otherwise, this is a response message without a declared message-
1327 body length, so the message-body length is determined by the
1328 number of octets received prior to the server closing the
1331 Since there is no way to distinguish a successfully completed, close-
1332 delimited message from a partially-received message interrupted by
1333 network failure, implementations SHOULD use encoding or length-
1334 delimited messages whenever possible. The close-delimiting feature
1335 exists primarily for backwards compatibility with HTTP/1.0.
1337 A server MAY reject a request that contains a message-body but not a
1338 Content-Length by responding with 411 (Length Required).
1343 Fielding, et al. Expires February 5, 2011 [Page 24]
1345 Internet-Draft HTTP/1.1, Part 1 August 2010
1348 Unless a transfer-coding other than "chunked" has been applied, a
1349 client that sends a request containing a message-body SHOULD use a
1350 valid Content-Length header field if the message-body length is known
1351 in advance, rather than the "chunked" encoding, since some existing
1352 services respond to "chunked" with a 411 (Length Required) status
1353 code even though they understand the chunked encoding. This is
1354 typically because such services are implemented via a gateway that
1355 requires a content-length in advance of being called and the server
1356 is unable or unwilling to buffer the entire request before
1359 A client that sends a request containing a message-body MUST include
1360 a valid Content-Length header field if it does not know the server
1361 will handle HTTP/1.1 (or later) requests; such knowledge can be in
1362 the form of specific user configuration or by remembering the version
1363 of a prior received response.
1365 Request messages that are prematurely terminated, possibly due to a
1366 cancelled connection or a server-imposed time-out exception, MUST
1367 result in closure of the connection; sending an HTTP/1.1 error
1368 response prior to closing the connection is OPTIONAL. Response
1369 messages that are prematurely terminated, usually by closure of the
1370 connection prior to receiving the expected number of octets or by
1371 failure to decode a transfer-encoded message-body, MUST be recorded
1372 as incomplete. A user agent MUST NOT render an incomplete response
1373 message-body as if it were complete (i.e., some indication must be
1374 given to the user that an error occurred). Cache requirements for
1375 incomplete responses are defined in Section 2.1.1 of [Part6].
1377 A server MUST read the entire request message-body or close the
1378 connection after sending its response, since otherwise the remaining
1379 data on a persistent connection would be misinterpreted as the next
1380 request. Likewise, a client MUST read the entire response message-
1381 body if it intends to reuse the same connection for a subsequent
1382 request. Pipelining multiple requests on a connection is described
1385 3.4. General Header Fields
1387 There are a few header fields which have general applicability for
1388 both request and response messages, but which do not apply to the
1389 payload being transferred. These header fields apply only to the
1390 message being transmitted.
1399 Fielding, et al. Expires February 5, 2011 [Page 25]
1401 Internet-Draft HTTP/1.1, Part 1 August 2010
1404 general-header = Cache-Control ; [Part6], Section 3.2
1405 / Connection ; Section 9.1
1406 / Date ; Section 9.3
1407 / Pragma ; [Part6], Section 3.4
1408 / Trailer ; Section 9.6
1409 / Transfer-Encoding ; Section 9.7
1410 / Upgrade ; Section 9.8
1412 / Warning ; [Part6], Section 3.6
1413 / MIME-Version ; [Part3], Appendix A.1
1415 General-header field names can be extended reliably only in
1416 combination with a change in the protocol version. However, new or
1417 experimental header fields might be given the semantics of general
1418 header fields if all parties in the communication recognize them to
1419 be general-header fields.
1423 A request message from a client to a server includes, within the
1424 first line of that message, the method to be applied to the resource,
1425 the identifier of the resource, and the protocol version in use.
1427 Request = Request-Line ; Section 4.1
1428 *( header-field CRLF ) ; Section 3.2
1430 [ message-body ] ; Section 3.3
1434 The Request-Line begins with a method token, followed by the request-
1435 target and the protocol version, and ending with CRLF. The elements
1436 are separated by SP characters. No CR or LF is allowed except in the
1437 final CRLF sequence.
1439 Request-Line = Method SP request-target SP HTTP-Version CRLF
1443 The Method token indicates the method to be performed on the resource
1444 identified by the request-target. The method is case-sensitive.
1455 Fielding, et al. Expires February 5, 2011 [Page 26]
1457 Internet-Draft HTTP/1.1, Part 1 August 2010
1460 4.1.2. request-target
1462 The request-target identifies the resource upon which to apply the
1465 request-target = "*"
1467 / ( path-absolute [ "?" query ] )
1470 The four options for request-target are dependent on the nature of
1473 The asterisk "*" means that the request does not apply to a
1474 particular resource, but to the server itself, and is only allowed
1475 when the method used does not necessarily apply to a resource. One
1480 The absolute-URI form is REQUIRED when the request is being made to a
1481 proxy. The proxy is requested to forward the request or service it
1482 from a valid cache, and return the response. Note that the proxy MAY
1483 forward the request on to another proxy or directly to the server
1484 specified by the absolute-URI. In order to avoid request loops, a
1485 proxy MUST be able to recognize all of its server names, including
1486 any aliases, local variations, and the numeric IP address. An
1487 example Request-Line would be:
1489 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1491 To allow for transition to absolute-URIs in all requests in future
1492 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1493 form in requests, even though HTTP/1.1 clients will only generate
1494 them in requests to proxies.
1496 The authority form is only used by the CONNECT method (Section 7.9 of
1499 The most common form of request-target is that used to identify a
1500 resource on an origin server or gateway. In this case the absolute
1501 path of the URI MUST be transmitted (see Section 2.6.1, path-
1502 absolute) as the request-target, and the network location of the URI
1503 (authority) MUST be transmitted in a Host header field. For example,
1504 a client wishing to retrieve the resource above directly from the
1505 origin server would create a TCP connection to port 80 of the host
1506 "www.example.org" and send the lines:
1511 Fielding, et al. Expires February 5, 2011 [Page 27]
1513 Internet-Draft HTTP/1.1, Part 1 August 2010
1516 GET /pub/WWW/TheProject.html HTTP/1.1
1517 Host: www.example.org
1519 followed by the remainder of the Request. Note that the absolute
1520 path cannot be empty; if none is present in the original URI, it MUST
1521 be given as "/" (the server root).
1523 If a proxy receives a request without any path in the request-target
1524 and the method specified is capable of supporting the asterisk form
1525 of request-target, then the last proxy on the request chain MUST
1526 forward the request with "*" as the final request-target.
1528 For example, the request
1530 OPTIONS http://www.example.org:8001 HTTP/1.1
1532 would be forwarded by the proxy as
1535 Host: www.example.org:8001
1537 after connecting to port 8001 of host "www.example.org".
1539 The request-target is transmitted in the format specified in
1540 Section 2.6.1. If the request-target is percent-encoded ([RFC3986],
1541 Section 2.1), the origin server MUST decode the request-target in
1542 order to properly interpret the request. Servers SHOULD respond to
1543 invalid request-targets with an appropriate status code.
1545 A transparent proxy MUST NOT rewrite the "path-absolute" part of the
1546 received request-target when forwarding it to the next inbound
1547 server, except as noted above to replace a null path-absolute with
1550 Note: The "no rewrite" rule prevents the proxy from changing the
1551 meaning of the request when the origin server is improperly using
1552 a non-reserved URI character for a reserved purpose. Implementors
1553 need to be aware that some pre-HTTP/1.1 proxies have been known to
1554 rewrite the request-target.
1556 HTTP does not place a pre-defined limit on the length of a request-
1557 target. A server MUST be prepared to receive URIs of unbounded
1558 length and respond with the 414 (URI Too Long) status code if the
1559 received request-target would be longer than the server wishes to
1560 handle (see Section 8.4.15 of [Part2]).
1562 Various ad-hoc limitations on request-target length are found in
1563 practice. It is RECOMMENDED that all HTTP senders and recipients
1567 Fielding, et al. Expires February 5, 2011 [Page 28]
1569 Internet-Draft HTTP/1.1, Part 1 August 2010
1572 support request-target lengths of 8000 or more octets.
1574 Note: Fragments ([RFC3986], Section 3.5) are not part of the
1575 request-target and thus will not be transmitted in an HTTP
1578 4.2. The Resource Identified by a Request
1580 The exact resource identified by an Internet request is determined by
1581 examining both the request-target and the Host header field.
1583 An origin server that does not allow resources to differ by the
1584 requested host MAY ignore the Host header field value when
1585 determining the resource identified by an HTTP/1.1 request. (But see
1586 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.)
1588 An origin server that does differentiate resources based on the host
1589 requested (sometimes referred to as virtual hosts or vanity host
1590 names) MUST use the following rules for determining the requested
1591 resource on an HTTP/1.1 request:
1593 1. If request-target is an absolute-URI, the host is part of the
1594 request-target. Any Host header field value in the request MUST
1597 2. If the request-target is not an absolute-URI, and the request
1598 includes a Host header field, the host is determined by the Host
1601 3. If the host as determined by rule 1 or 2 is not a valid host on
1602 the server, the response MUST be a 400 (Bad Request) error
1605 Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1606 attempt to use heuristics (e.g., examination of the URI path for
1607 something unique to a particular host) in order to determine what
1608 exact resource is being requested.
1610 4.3. Effective Request URI
1612 HTTP requests often do not carry the absolute URI ([RFC3986], Section
1613 4.3) for the target resource; instead, the URI needs to be inferred
1614 from the request-target, Host header field, and connection context.
1615 The result of this process is called the "effective request URI".
1616 The "target resource" is the resource identified by the effective
1619 If the request-target is an absolute-URI, then the effective request
1623 Fielding, et al. Expires February 5, 2011 [Page 29]
1625 Internet-Draft HTTP/1.1, Part 1 August 2010
1628 URI is the request-target.
1630 If the request-target uses the path-absolute (plus optional query)
1631 syntax or if it is just the asterisk "*", then the effective request
1632 URI is constructed by concatenating
1634 o the scheme name: "http" if the request was received over an
1635 insecure TCP connection, or "https" when received over a SSL/
1636 TLS-secured TCP connection,
1638 o the character sequence "://",
1640 o the authority component, as specified in the Host header
1641 (Section 9.4) and determined by the rules in Section 4.2,
1642 [[effrequri-nohost: Do we need to include the handling of missing
1643 hosts in HTTP/1.0 messages, as described in Section 4.2? -- See
1644 <http://tools.ietf.org/wg/httpbis/trac/ticket/221> --jre]] and
1646 o the request-target obtained from the Request-Line, unless the
1647 request-target is just the asterisk "*".
1649 Otherwise, when request-target uses the authority form, the effective
1650 Request URI is undefined.
1652 Example 1: the effective request URI for the message
1654 GET /pub/WWW/TheProject.html HTTP/1.1
1655 Host: www.example.org:8080
1657 (received over an insecure TCP connection) is "http", plus "://",
1658 plus the authority component "www.example.org:8080", plus the
1659 request-target "/pub/WWW/TheProject.html", thus
1660 "http://www.example.org:8080/pub/WWW/TheProject.html".
1662 Example 2: the effective request URI for the message
1665 Host: www.example.org
1667 (received over an SSL/TLS secured TCP connection) is "https", plus
1668 "://", plus the authority component "www.example.org", thus
1669 "https://www.example.org".
1671 Effective request URIs are compared using the rules described in
1672 Section 2.6.3, except that empty path components MUST NOT be treated
1673 as equivalent to an absolute path of "/".
1679 Fielding, et al. Expires February 5, 2011 [Page 30]
1681 Internet-Draft HTTP/1.1, Part 1 August 2010
1686 After receiving and interpreting a request message, a server responds
1687 with an HTTP response message.
1689 Response = Status-Line ; Section 5.1
1690 *( header-field CRLF ) ; Section 3.2
1692 [ message-body ] ; Section 3.3
1696 The first line of a Response message is the Status-Line, consisting
1697 of the protocol version followed by a numeric status code and its
1698 associated textual phrase, with each element separated by SP
1699 characters. No CR or LF is allowed except in the final CRLF
1702 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1704 5.1.1. Status Code and Reason Phrase
1706 The Status-Code element is a 3-digit integer result code of the
1707 attempt to understand and satisfy the request. These codes are fully
1708 defined in Section 8 of [Part2]. The Reason Phrase exists for the
1709 sole purpose of providing a textual description associated with the
1710 numeric status code, out of deference to earlier Internet application
1711 protocols that were more frequently used with interactive text
1712 clients. A client SHOULD ignore the content of the Reason Phrase.
1714 The first digit of the Status-Code defines the class of response.
1715 The last two digits do not have any categorization role. There are 5
1716 values for the first digit:
1718 o 1xx: Informational - Request received, continuing process
1720 o 2xx: Success - The action was successfully received, understood,
1723 o 3xx: Redirection - Further action must be taken in order to
1724 complete the request
1726 o 4xx: Client Error - The request contains bad syntax or cannot be
1729 o 5xx: Server Error - The server failed to fulfill an apparently
1735 Fielding, et al. Expires February 5, 2011 [Page 31]
1737 Internet-Draft HTTP/1.1, Part 1 August 2010
1740 Status-Code = 3DIGIT
1741 Reason-Phrase = *( WSP / VCHAR / obs-text )
1743 6. Protocol Parameters
1745 6.1. Date/Time Formats: Full Date
1747 HTTP applications have historically allowed three different formats
1748 for date/time stamps. However, the preferred format is a fixed-
1749 length subset of that defined by [RFC1123]:
1751 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
1753 The other formats are described here only for compatibility with
1754 obsolete implementations.
1756 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1757 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1759 HTTP/1.1 clients and servers that parse a date value MUST accept all
1760 three formats (for compatibility with HTTP/1.0), though they MUST
1761 only generate the RFC 1123 format for representing HTTP-date values
1762 in header fields. See Appendix A for further information.
1764 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1765 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1766 equal to UTC (Coordinated Universal Time). This is indicated in the
1767 first two formats by the inclusion of "GMT" as the three-letter
1768 abbreviation for time zone, and MUST be assumed when reading the
1769 asctime format. HTTP-date is case sensitive and MUST NOT include
1770 additional whitespace beyond that specifically included as SP in the
1773 HTTP-date = rfc1123-date / obs-date
1791 Fielding, et al. Expires February 5, 2011 [Page 32]
1793 Internet-Draft HTTP/1.1, Part 1 August 2010
1796 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
1798 day-name = %x4D.6F.6E ; "Mon", case-sensitive
1799 / %x54.75.65 ; "Tue", case-sensitive
1800 / %x57.65.64 ; "Wed", case-sensitive
1801 / %x54.68.75 ; "Thu", case-sensitive
1802 / %x46.72.69 ; "Fri", case-sensitive
1803 / %x53.61.74 ; "Sat", case-sensitive
1804 / %x53.75.6E ; "Sun", case-sensitive
1806 date1 = day SP month SP year
1810 month = %x4A.61.6E ; "Jan", case-sensitive
1811 / %x46.65.62 ; "Feb", case-sensitive
1812 / %x4D.61.72 ; "Mar", case-sensitive
1813 / %x41.70.72 ; "Apr", case-sensitive
1814 / %x4D.61.79 ; "May", case-sensitive
1815 / %x4A.75.6E ; "Jun", case-sensitive
1816 / %x4A.75.6C ; "Jul", case-sensitive
1817 / %x41.75.67 ; "Aug", case-sensitive
1818 / %x53.65.70 ; "Sep", case-sensitive
1819 / %x4F.63.74 ; "Oct", case-sensitive
1820 / %x4E.6F.76 ; "Nov", case-sensitive
1821 / %x44.65.63 ; "Dec", case-sensitive
1824 GMT = %x47.4D.54 ; "GMT", case-sensitive
1826 time-of-day = hour ":" minute ":" second
1827 ; 00:00:00 - 23:59:59
1833 The semantics of day-name, day, month, year, and time-of-day are the
1834 same as those defined for the RFC 5322 constructs with the
1835 corresponding name ([RFC5322], Section 3.3).
1839 obs-date = rfc850-date / asctime-date
1847 Fielding, et al. Expires February 5, 2011 [Page 33]
1849 Internet-Draft HTTP/1.1, Part 1 August 2010
1852 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
1853 date2 = day "-" month "-" 2DIGIT
1854 ; day-month-year (e.g., 02-Jun-82)
1856 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
1857 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
1858 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1859 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
1860 / %x46.72.69.64.61.79 ; "Friday", case-sensitive
1861 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
1862 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
1865 asctime-date = day-name SP date3 SP time-of-day SP year
1866 date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
1867 ; month day (e.g., Jun 2)
1869 Note: Recipients of date values are encouraged to be robust in
1870 accepting date values that might have been sent by non-HTTP
1871 applications, as is sometimes the case when retrieving or posting
1872 messages via proxies/gateways to SMTP or NNTP.
1874 Note: HTTP requirements for the date/time stamp format apply only
1875 to their usage within the protocol stream. Clients and servers
1876 are not required to use these formats for user presentation,
1877 request logging, etc.
1879 6.2. Transfer Codings
1881 Transfer-coding values are used to indicate an encoding
1882 transformation that has been, can be, or might need to be applied to
1883 a payload body in order to ensure "safe transport" through the
1884 network. This differs from a content coding in that the transfer-
1885 coding is a property of the message rather than a property of the
1886 representation that is being transferred.
1888 transfer-coding = "chunked" ; Section 6.2.1
1889 / "compress" ; Section 6.2.2.1
1890 / "deflate" ; Section 6.2.2.2
1891 / "gzip" ; Section 6.2.2.3
1892 / transfer-extension
1893 transfer-extension = token *( OWS ";" OWS transfer-parameter )
1895 Parameters are in the form of attribute/value pairs.
1897 transfer-parameter = attribute BWS "=" BWS value
1903 Fielding, et al. Expires February 5, 2011 [Page 34]
1905 Internet-Draft HTTP/1.1, Part 1 August 2010
1908 All transfer-coding values are case-insensitive. HTTP/1.1 uses
1909 transfer-coding values in the TE header field (Section 9.5) and in
1910 the Transfer-Encoding header field (Section 9.7).
1912 Transfer-codings are analogous to the Content-Transfer-Encoding
1913 values of MIME, which were designed to enable safe transport of
1914 binary data over a 7-bit transport service ([RFC2045], Section 6).
1915 However, safe transport has a different focus for an 8bit-clean
1916 transfer protocol. In HTTP, the only unsafe characteristic of
1917 message-bodies is the difficulty in determining the exact message
1918 body length (Section 3.3), or the desire to encrypt data over a
1921 A server that receives a request message with a transfer-coding it
1922 does not understand SHOULD respond with 501 (Not Implemented) and
1923 then close the connection. A server MUST NOT send transfer-codings
1924 to an HTTP/1.0 client.
1926 6.2.1. Chunked Transfer Coding
1928 The chunked encoding modifies the body of a message in order to
1929 transfer it as a series of chunks, each with its own size indicator,
1930 followed by an OPTIONAL trailer containing header fields. This
1931 allows dynamically produced content to be transferred along with the
1932 information necessary for the recipient to verify that it has
1933 received the full message.
1935 Chunked-Body = *chunk
1940 chunk = chunk-size *WSP [ chunk-ext ] CRLF
1942 chunk-size = 1*HEXDIG
1943 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
1945 chunk-ext = *( ";" *WSP chunk-ext-name
1946 [ "=" chunk-ext-val ] *WSP )
1947 chunk-ext-name = token
1948 chunk-ext-val = token / quoted-str-nf
1949 chunk-data = 1*OCTET ; a sequence of chunk-size octets
1950 trailer-part = *( header-field CRLF )
1952 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
1953 ; like quoted-string, but disallowing line folding
1954 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text
1955 ; WSP / <VCHAR except DQUOTE and "\"> / obs-text
1959 Fielding, et al. Expires February 5, 2011 [Page 35]
1961 Internet-Draft HTTP/1.1, Part 1 August 2010
1964 The chunk-size field is a string of hex digits indicating the size of
1965 the chunk-data in octets. The chunked encoding is ended by any chunk
1966 whose size is zero, followed by the trailer, which is terminated by
1969 The trailer allows the sender to include additional HTTP header
1970 fields at the end of the message. The Trailer header field can be
1971 used to indicate which header fields are included in a trailer (see
1974 A server using chunked transfer-coding in a response MUST NOT use the
1975 trailer for any header fields unless at least one of the following is
1978 1. the request included a TE header field that indicates "trailers"
1979 is acceptable in the transfer-coding of the response, as
1980 described in Section 9.5; or,
1982 2. the server is the origin server for the response, the trailer
1983 fields consist entirely of optional metadata, and the recipient
1984 could use the message (in a manner acceptable to the origin
1985 server) without receiving this metadata. In other words, the
1986 origin server is willing to accept the possibility that the
1987 trailer fields might be silently discarded along the path to the
1990 This requirement prevents an interoperability failure when the
1991 message is being received by an HTTP/1.1 (or later) proxy and
1992 forwarded to an HTTP/1.0 recipient. It avoids a situation where
1993 compliance with the protocol would have necessitated a possibly
1994 infinite buffer on the proxy.
1996 A process for decoding the "chunked" transfer-coding can be
1997 represented in pseudo-code as:
2015 Fielding, et al. Expires February 5, 2011 [Page 36]
2017 Internet-Draft HTTP/1.1, Part 1 August 2010
2021 read chunk-size, chunk-ext (if any) and CRLF
2022 while (chunk-size > 0) {
2023 read chunk-data and CRLF
2024 append chunk-data to decoded-body
2025 length := length + chunk-size
2026 read chunk-size and CRLF
2029 while (header-field not empty) {
2030 append header-field to existing header fields
2033 Content-Length := length
2034 Remove "chunked" from Transfer-Encoding
2036 All HTTP/1.1 applications MUST be able to receive and decode the
2037 "chunked" transfer-coding and MUST ignore chunk-ext extensions they
2040 Since "chunked" is the only transfer-coding required to be understood
2041 by HTTP/1.1 recipients, it plays a crucial role in delimiting
2042 messages on a persistent connection. Whenever a transfer-coding is
2043 applied to a payload body in a request, the final transfer-coding
2044 applied MUST be "chunked". If a transfer-coding is applied to a
2045 response payload body, then either the final transfer-coding applied
2046 MUST be "chunked" or the message MUST be terminated by closing the
2047 connection. When the "chunked" transfer-coding is used, it MUST be
2048 the last transfer-coding applied to form the message-body. The
2049 "chunked" transfer-coding MUST NOT be applied more than once in a
2052 6.2.2. Compression Codings
2054 The codings defined below can be used to compress the payload of a
2057 Note: Use of program names for the identification of encoding
2058 formats is not desirable and is discouraged for future encodings.
2059 Their use here is representative of historical practice, not good
2062 Note: For compatibility with previous implementations of HTTP,
2063 applications SHOULD consider "x-gzip" and "x-compress" to be
2064 equivalent to "gzip" and "compress" respectively.
2071 Fielding, et al. Expires February 5, 2011 [Page 37]
2073 Internet-Draft HTTP/1.1, Part 1 August 2010
2076 6.2.2.1. Compress Coding
2078 The "compress" format is produced by the common UNIX file compression
2079 program "compress". This format is an adaptive Lempel-Ziv-Welch
2082 6.2.2.2. Deflate Coding
2084 The "deflate" format is defined as the "deflate" compression
2085 mechanism (described in [RFC1951]) used inside the "zlib" data format
2088 Note: Some incorrect implementations send the "deflate" compressed
2089 data without the zlib wrapper.
2091 6.2.2.3. Gzip Coding
2093 The "gzip" format is produced by the file compression program "gzip"
2094 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv
2095 coding (LZ77) with a 32 bit CRC.
2097 6.2.3. Transfer Coding Registry
2099 The HTTP Transfer Coding Registry defines the name space for the
2100 transfer coding names.
2102 Registrations MUST include the following fields:
2108 o Pointer to specification text
2110 Names of transfer codings MUST NOT overlap with names of content
2111 codings (Section 2.2 of [Part3]), unless the encoding transformation
2112 is identical (as it is the case for the compression codings defined
2115 Values to be added to this name space require a specification (see
2116 "Specification Required" in Section 4.1 of [RFC5226]), and MUST
2117 conform to the purpose of transfer coding defined in this section.
2119 The registry itself is maintained at
2120 <http://www.iana.org/assignments/http-parameters>.
2127 Fielding, et al. Expires February 5, 2011 [Page 38]
2129 Internet-Draft HTTP/1.1, Part 1 August 2010
2134 Product tokens are used to allow communicating applications to
2135 identify themselves by software name and version. Most fields using
2136 product tokens also allow sub-products which form a significant part
2137 of the application to be listed, separated by whitespace. By
2138 convention, the products are listed in order of their significance
2139 for identifying the application.
2141 product = token ["/" product-version]
2142 product-version = token
2146 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2147 Server: Apache/0.8.4
2149 Product tokens SHOULD be short and to the point. They MUST NOT be
2150 used for advertising or other non-essential information. Although
2151 any token character MAY appear in a product-version, this token
2152 SHOULD only be used for a version identifier (i.e., successive
2153 versions of the same product SHOULD only differ in the product-
2154 version portion of the product value).
2158 Both transfer codings (TE request header, Section 9.5) and content
2159 negotiation (Section 5 of [Part3]) use short "floating point" numbers
2160 to indicate the relative importance ("weight") of various negotiable
2161 parameters. A weight is normalized to a real number in the range 0
2162 through 1, where 0 is the minimum and 1 the maximum value. If a
2163 parameter has a quality value of 0, then content with this parameter
2164 is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
2165 generate more than three digits after the decimal point. User
2166 configuration of these values SHOULD also be limited in this fashion.
2168 qvalue = ( "0" [ "." 0*3DIGIT ] )
2169 / ( "1" [ "." 0*3("0") ] )
2171 Note: "Quality values" is a misnomer, since these values merely
2172 represent relative degradation in desired quality.
2176 7.1. Persistent Connections
2183 Fielding, et al. Expires February 5, 2011 [Page 39]
2185 Internet-Draft HTTP/1.1, Part 1 August 2010
2190 Prior to persistent connections, a separate TCP connection was
2191 established to fetch each URL, increasing the load on HTTP servers
2192 and causing congestion on the Internet. The use of inline images and
2193 other associated data often requires a client to make multiple
2194 requests of the same server in a short amount of time. Analysis of
2195 these performance problems and results from a prototype
2196 implementation are available [Pad1995] [Spe]. Implementation
2197 experience and measurements of actual HTTP/1.1 implementations show
2198 good results [Nie1997]. Alternatives have also been explored, for
2199 example, T/TCP [Tou1998].
2201 Persistent HTTP connections have a number of advantages:
2203 o By opening and closing fewer TCP connections, CPU time is saved in
2204 routers and hosts (clients, servers, proxies, gateways, tunnels,
2205 or caches), and memory used for TCP protocol control blocks can be
2208 o HTTP requests and responses can be pipelined on a connection.
2209 Pipelining allows a client to make multiple requests without
2210 waiting for each response, allowing a single TCP connection to be
2211 used much more efficiently, with much lower elapsed time.
2213 o Network congestion is reduced by reducing the number of packets
2214 caused by TCP opens, and by allowing TCP sufficient time to
2215 determine the congestion state of the network.
2217 o Latency on subsequent requests is reduced since there is no time
2218 spent in TCP's connection opening handshake.
2220 o HTTP can evolve more gracefully, since errors can be reported
2221 without the penalty of closing the TCP connection. Clients using
2222 future versions of HTTP might optimistically try a new feature,
2223 but if communicating with an older server, retry with old
2224 semantics after an error is reported.
2226 HTTP implementations SHOULD implement persistent connections.
2228 7.1.2. Overall Operation
2230 A significant difference between HTTP/1.1 and earlier versions of
2231 HTTP is that persistent connections are the default behavior of any
2232 HTTP connection. That is, unless otherwise indicated, the client
2233 SHOULD assume that the server will maintain a persistent connection,
2234 even after error responses from the server.
2239 Fielding, et al. Expires February 5, 2011 [Page 40]
2241 Internet-Draft HTTP/1.1, Part 1 August 2010
2244 Persistent connections provide a mechanism by which a client and a
2245 server can signal the close of a TCP connection. This signaling
2246 takes place using the Connection header field (Section 9.1). Once a
2247 close has been signaled, the client MUST NOT send any more requests
2250 7.1.2.1. Negotiation
2252 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2253 maintain a persistent connection unless a Connection header including
2254 the connection-token "close" was sent in the request. If the server
2255 chooses to close the connection immediately after sending the
2256 response, it SHOULD send a Connection header including the
2257 connection-token "close".
2259 An HTTP/1.1 client MAY expect a connection to remain open, but would
2260 decide to keep it open based on whether the response from a server
2261 contains a Connection header with the connection-token close. In
2262 case the client does not want to maintain a connection for more than
2263 that request, it SHOULD send a Connection header including the
2264 connection-token close.
2266 If either the client or the server sends the close token in the
2267 Connection header, that request becomes the last one for the
2270 Clients and servers SHOULD NOT assume that a persistent connection is
2271 maintained for HTTP versions less than 1.1 unless it is explicitly
2272 signaled. See Appendix B.2 for more information on backward
2273 compatibility with HTTP/1.0 clients.
2275 In order to remain persistent, all messages on the connection MUST
2276 have a self-defined message length (i.e., one not defined by closure
2277 of the connection), as described in Section 3.3.
2281 A client that supports persistent connections MAY "pipeline" its
2282 requests (i.e., send multiple requests without waiting for each
2283 response). A server MUST send its responses to those requests in the
2284 same order that the requests were received.
2286 Clients which assume persistent connections and pipeline immediately
2287 after connection establishment SHOULD be prepared to retry their
2288 connection if the first pipelined attempt fails. If a client does
2289 such a retry, it MUST NOT pipeline before it knows the connection is
2290 persistent. Clients MUST also be prepared to resend their requests
2291 if the server closes the connection before sending all of the
2295 Fielding, et al. Expires February 5, 2011 [Page 41]
2297 Internet-Draft HTTP/1.1, Part 1 August 2010
2300 corresponding responses.
2302 Clients SHOULD NOT pipeline requests using non-idempotent methods or
2303 non-idempotent sequences of methods (see Section 7.1.2 of [Part2]).
2304 Otherwise, a premature termination of the transport connection could
2305 lead to indeterminate results. A client wishing to send a non-
2306 idempotent request SHOULD wait to send that request until it has
2307 received the response status line for the previous request.
2309 7.1.3. Proxy Servers
2311 It is especially important that proxies correctly implement the
2312 properties of the Connection header field as specified in
2315 The proxy server MUST signal persistent connections separately with
2316 its clients and the origin servers (or other proxy servers) that it
2317 connects to. Each persistent connection applies to only one
2320 A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2321 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
2322 information and discussion of the problems with the Keep-Alive header
2323 implemented by many HTTP/1.0 clients).
2325 7.1.3.1. End-to-end and Hop-by-hop Headers
2327 For the purpose of defining the behavior of caches and non-caching
2328 proxies, we divide HTTP headers into two categories:
2330 o End-to-end headers, which are transmitted to the ultimate
2331 recipient of a request or response. End-to-end headers in
2332 responses MUST be stored as part of a cache entry and MUST be
2333 transmitted in any response formed from a cache entry.
2335 o Hop-by-hop headers, which are meaningful only for a single
2336 transport-level connection, and are not stored by caches or
2337 forwarded by proxies.
2339 The following HTTP/1.1 headers are hop-by-hop headers:
2345 o Proxy-Authenticate
2351 Fielding, et al. Expires February 5, 2011 [Page 42]
2353 Internet-Draft HTTP/1.1, Part 1 August 2010
2356 o Proxy-Authorization
2366 All other headers defined by HTTP/1.1 are end-to-end headers.
2368 Other hop-by-hop headers MUST be listed in a Connection header
2371 7.1.3.2. Non-modifiable Headers
2373 Some features of HTTP/1.1, such as Digest Authentication, depend on
2374 the value of certain end-to-end headers. A transparent proxy SHOULD
2375 NOT modify an end-to-end header unless the definition of that header
2376 requires or specifically allows that.
2378 A transparent proxy MUST NOT modify any of the following fields in a
2379 request or response, and it MUST NOT add any of these fields if not
2390 A transparent proxy MUST NOT modify any of the following fields in a
2395 but it MAY add any of these fields if not already present. If an
2396 Expires header is added, it MUST be given a field-value identical to
2397 that of the Date header in that response.
2399 A proxy MUST NOT modify or add any of the following fields in a
2400 message that contains the no-transform cache-control directive, or in
2407 Fielding, et al. Expires February 5, 2011 [Page 43]
2409 Internet-Draft HTTP/1.1, Part 1 August 2010
2418 A non-transparent proxy MAY modify or add these fields to a message
2419 that does not include no-transform, but if it does so, it MUST add a
2420 Warning 214 (Transformation applied) if one does not already appear
2421 in the message (see Section 3.6 of [Part6]).
2423 Warning: Unnecessary modification of end-to-end headers might
2424 cause authentication failures if stronger authentication
2425 mechanisms are introduced in later versions of HTTP. Such
2426 authentication mechanisms MAY rely on the values of header fields
2429 A transparent proxy MUST preserve the message payload ([Part3]),
2430 though it MAY change the message-body through application or removal
2431 of a transfer-coding (Section 6.2).
2433 7.1.4. Practical Considerations
2435 Servers will usually have some time-out value beyond which they will
2436 no longer maintain an inactive connection. Proxy servers might make
2437 this a higher value since it is likely that the client will be making
2438 more connections through the same server. The use of persistent
2439 connections places no requirements on the length (or existence) of
2440 this time-out for either the client or the server.
2442 When a client or server wishes to time-out it SHOULD issue a graceful
2443 close on the transport connection. Clients and servers SHOULD both
2444 constantly watch for the other side of the transport close, and
2445 respond to it as appropriate. If a client or server does not detect
2446 the other side's close promptly it could cause unnecessary resource
2447 drain on the network.
2449 A client, server, or proxy MAY close the transport connection at any
2450 time. For example, a client might have started to send a new request
2451 at the same time that the server has decided to close the "idle"
2452 connection. From the server's point of view, the connection is being
2453 closed while it was idle, but from the client's point of view, a
2454 request is in progress.
2456 This means that clients, servers, and proxies MUST be able to recover
2457 from asynchronous close events. Client software SHOULD reopen the
2458 transport connection and retransmit the aborted sequence of requests
2459 without user interaction so long as the request sequence is
2463 Fielding, et al. Expires February 5, 2011 [Page 44]
2465 Internet-Draft HTTP/1.1, Part 1 August 2010
2468 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or
2469 sequences MUST NOT be automatically retried, although user agents MAY
2470 offer a human operator the choice of retrying the request(s).
2471 Confirmation by user-agent software with semantic understanding of
2472 the application MAY substitute for user confirmation. The automatic
2473 retry SHOULD NOT be repeated if the second sequence of requests
2476 Servers SHOULD always respond to at least one request per connection,
2477 if at all possible. Servers SHOULD NOT close a connection in the
2478 middle of transmitting a response, unless a network or client failure
2481 Clients (including proxies) SHOULD limit the number of simultaneous
2482 connections that they maintain to a given server (including proxies).
2484 Previous revisions of HTTP gave a specific number of connections as a
2485 ceiling, but this was found to be impractical for many applications.
2486 As a result, this specification does not mandate a particular maximum
2487 number of connections, but instead encourages clients to be
2488 conservative when opening multiple connections.
2490 In particular, while using multiple connections avoids the "head-of-
2491 line blocking" problem (whereby a request that takes significant
2492 server-side processing and/or has a large payload can block
2493 subsequent requests on the same connection), each connection used
2494 consumes server resources (sometimes significantly), and furthermore
2495 using multiple connections can cause undesirable side effects in
2498 Note that servers might reject traffic that they deem abusive,
2499 including an excessive number of connections from a client.
2501 7.2. Message Transmission Requirements
2503 7.2.1. Persistent Connections and Flow Control
2505 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2506 flow control mechanisms to resolve temporary overloads, rather than
2507 terminating connections with the expectation that clients will retry.
2508 The latter technique can exacerbate network congestion.
2510 7.2.2. Monitoring Connections for Error Status Messages
2512 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2513 the network connection for an error status code while it is
2514 transmitting the request. If the client sees an error status code,
2515 it SHOULD immediately cease transmitting the body. If the body is
2519 Fielding, et al. Expires February 5, 2011 [Page 45]
2521 Internet-Draft HTTP/1.1, Part 1 August 2010
2524 being sent using a "chunked" encoding (Section 6.2), a zero length
2525 chunk and empty trailer MAY be used to prematurely mark the end of
2526 the message. If the body was preceded by a Content-Length header,
2527 the client MUST close the connection.
2529 7.2.3. Use of the 100 (Continue) Status
2531 The purpose of the 100 (Continue) status code (see Section 8.1.1 of
2532 [Part2]) is to allow a client that is sending a request message with
2533 a request body to determine if the origin server is willing to accept
2534 the request (based on the request headers) before the client sends
2535 the request body. In some cases, it might either be inappropriate or
2536 highly inefficient for the client to send the body if the server will
2537 reject the message without looking at the body.
2539 Requirements for HTTP/1.1 clients:
2541 o If a client will wait for a 100 (Continue) response before sending
2542 the request body, it MUST send an Expect request-header field
2543 (Section 9.2 of [Part2]) with the "100-continue" expectation.
2545 o A client MUST NOT send an Expect request-header field (Section 9.2
2546 of [Part2]) with the "100-continue" expectation if it does not
2547 intend to send a request body.
2549 Because of the presence of older implementations, the protocol allows
2550 ambiguous situations in which a client might send "Expect: 100-
2551 continue" without receiving either a 417 (Expectation Failed) or a
2552 100 (Continue) status code. Therefore, when a client sends this
2553 header field to an origin server (possibly via a proxy) from which it
2554 has never seen a 100 (Continue) status code, the client SHOULD NOT
2555 wait for an indefinite period before sending the request body.
2557 Requirements for HTTP/1.1 origin servers:
2559 o Upon receiving a request which includes an Expect request-header
2560 field with the "100-continue" expectation, an origin server MUST
2561 either respond with 100 (Continue) status code and continue to
2562 read from the input stream, or respond with a final status code.
2563 The origin server MUST NOT wait for the request body before
2564 sending the 100 (Continue) response. If it responds with a final
2565 status code, it MAY close the transport connection or it MAY
2566 continue to read and discard the rest of the request. It MUST NOT
2567 perform the requested method if it returns a final status code.
2569 o An origin server SHOULD NOT send a 100 (Continue) response if the
2570 request message does not include an Expect request-header field
2571 with the "100-continue" expectation, and MUST NOT send a 100
2575 Fielding, et al. Expires February 5, 2011 [Page 46]
2577 Internet-Draft HTTP/1.1, Part 1 August 2010
2580 (Continue) response if such a request comes from an HTTP/1.0 (or
2581 earlier) client. There is an exception to this rule: for
2582 compatibility with [RFC2068], a server MAY send a 100 (Continue)
2583 status code in response to an HTTP/1.1 PUT or POST request that
2584 does not include an Expect request-header field with the "100-
2585 continue" expectation. This exception, the purpose of which is to
2586 minimize any client processing delays associated with an
2587 undeclared wait for 100 (Continue) status code, applies only to
2588 HTTP/1.1 requests, and not to requests with any other HTTP-version
2591 o An origin server MAY omit a 100 (Continue) response if it has
2592 already received some or all of the request body for the
2593 corresponding request.
2595 o An origin server that sends a 100 (Continue) response MUST
2596 ultimately send a final status code, once the request body is
2597 received and processed, unless it terminates the transport
2598 connection prematurely.
2600 o If an origin server receives a request that does not include an
2601 Expect request-header field with the "100-continue" expectation,
2602 the request includes a request body, and the server responds with
2603 a final status code before reading the entire request body from
2604 the transport connection, then the server SHOULD NOT close the
2605 transport connection until it has read the entire request, or
2606 until the client closes the connection. Otherwise, the client
2607 might not reliably receive the response message. However, this
2608 requirement is not be construed as preventing a server from
2609 defending itself against denial-of-service attacks, or from badly
2610 broken client implementations.
2612 Requirements for HTTP/1.1 proxies:
2614 o If a proxy receives a request that includes an Expect request-
2615 header field with the "100-continue" expectation, and the proxy
2616 either knows that the next-hop server complies with HTTP/1.1 or
2617 higher, or does not know the HTTP version of the next-hop server,
2618 it MUST forward the request, including the Expect header field.
2620 o If the proxy knows that the version of the next-hop server is
2621 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2622 respond with a 417 (Expectation Failed) status code.
2624 o Proxies SHOULD maintain a cache recording the HTTP version numbers
2625 received from recently-referenced next-hop servers.
2631 Fielding, et al. Expires February 5, 2011 [Page 47]
2633 Internet-Draft HTTP/1.1, Part 1 August 2010
2636 o A proxy MUST NOT forward a 100 (Continue) response if the request
2637 message was received from an HTTP/1.0 (or earlier) client and did
2638 not include an Expect request-header field with the "100-continue"
2639 expectation. This requirement overrides the general rule for
2640 forwarding of 1xx responses (see Section 8.1 of [Part2]).
2642 7.2.4. Client Behavior if Server Prematurely Closes Connection
2644 If an HTTP/1.1 client sends a request which includes a request body,
2645 but which does not include an Expect request-header field with the
2646 "100-continue" expectation, and if the client is not directly
2647 connected to an HTTP/1.1 origin server, and if the client sees the
2648 connection close before receiving a status line from the server, the
2649 client SHOULD retry the request. If the client does retry this
2650 request, it MAY use the following "binary exponential backoff"
2651 algorithm to be assured of obtaining a reliable response:
2653 1. Initiate a new connection to the server
2655 2. Transmit the request-headers
2657 3. Initialize a variable R to the estimated round-trip time to the
2658 server (e.g., based on the time it took to establish the
2659 connection), or to a constant value of 5 seconds if the round-
2660 trip time is not available.
2662 4. Compute T = R * (2**N), where N is the number of previous retries
2665 5. Wait either for an error response from the server, or for T
2666 seconds (whichever comes first)
2668 6. If no error response is received, after T seconds transmit the
2669 body of the request.
2671 7. If client sees that the connection is closed prematurely, repeat
2672 from step 1 until the request is accepted, an error response is
2673 received, or the user becomes impatient and terminates the retry
2676 If at any point an error status code is received, the client
2678 o SHOULD NOT continue and
2680 o SHOULD close the connection if it has not completed sending the
2687 Fielding, et al. Expires February 5, 2011 [Page 48]
2689 Internet-Draft HTTP/1.1, Part 1 August 2010
2692 8. Miscellaneous notes that might disappear
2694 8.1. Scheme aliases considered harmful
2696 [[TBD-aliases-harmful: describe why aliases like webcal are
2699 8.2. Use of HTTP for proxy communication
2701 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
2704 8.3. Interception of HTTP for access control
2706 [[TBD-intercept: Interception of HTTP traffic for initiating access
2709 8.4. Use of HTTP by other protocols
2711 [[TBD-profiles: Profiles of HTTP defined by other protocol.
2712 Extensions of HTTP like WebDAV.]]
2714 8.5. Use of HTTP by media type specification
2716 [[TBD-hypertext: Instructions on composing HTTP requests via
2717 hypertext formats.]]
2719 9. Header Field Definitions
2721 This section defines the syntax and semantics of HTTP/1.1 header
2722 fields related to message framing and transport protocols.
2726 The "Connection" general-header field allows the sender to specify
2727 options that are desired for that particular connection and MUST NOT
2728 be communicated by proxies over further connections.
2730 The Connection header's value has the following grammar:
2732 Connection = "Connection" ":" OWS Connection-v
2733 Connection-v = 1#connection-token
2734 connection-token = token
2736 HTTP/1.1 proxies MUST parse the Connection header field before a
2737 message is forwarded and, for each connection-token in this field,
2738 remove any header field(s) from the message with the same name as the
2739 connection-token. Connection options are signaled by the presence of
2743 Fielding, et al. Expires February 5, 2011 [Page 49]
2745 Internet-Draft HTTP/1.1, Part 1 August 2010
2748 a connection-token in the Connection header field, not by any
2749 corresponding additional header field(s), since the additional header
2750 field might not be sent if there are no parameters associated with
2751 that connection option.
2753 Message headers listed in the Connection header MUST NOT include end-
2754 to-end headers, such as Cache-Control.
2756 HTTP/1.1 defines the "close" connection option for the sender to
2757 signal that the connection will be closed after completion of the
2758 response. For example,
2762 in either the request or the response header fields indicates that
2763 the connection SHOULD NOT be considered "persistent" (Section 7.1)
2764 after the current request/response is complete.
2766 An HTTP/1.1 client that does not support persistent connections MUST
2767 include the "close" connection option in every request message.
2769 An HTTP/1.1 server that does not support persistent connections MUST
2770 include the "close" connection option in every response message that
2771 does not have a 1xx (Informational) status code.
2773 A system receiving an HTTP/1.0 (or lower-version) message that
2774 includes a Connection header MUST, for each connection-token in this
2775 field, remove and ignore any header field(s) from the message with
2776 the same name as the connection-token. This protects against
2777 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
2782 The "Content-Length" header field indicates the size of the message-
2783 body, in decimal number of octets, for any message other than a
2784 response to the HEAD method or a response with a status code of 304.
2785 In the case of responses to the HEAD method, it indicates the size of
2786 the payload body (not including any potential transfer-coding) that
2787 would have been sent had the request been a GET. In the case of the
2788 304 (Not Modified) response, it indicates the size of the payload
2789 body (not including any potential transfer-coding) that would have
2790 been sent in a 200 (OK) response.
2792 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v
2793 Content-Length-v = 1*DIGIT
2799 Fielding, et al. Expires February 5, 2011 [Page 50]
2801 Internet-Draft HTTP/1.1, Part 1 August 2010
2804 Content-Length: 3495
2806 Implementations SHOULD use this field to indicate the message-body
2807 length when no transfer-coding is being applied and the payload's
2808 body length can be determined prior to being transferred.
2809 Section 3.3 describes how recipients determine the length of a
2812 Any Content-Length greater than or equal to zero is a valid value.
2814 Note that the use of this field in HTTP is significantly different
2815 from the corresponding definition in MIME, where it is an optional
2816 field used within the "message/external-body" content-type.
2820 The "Date" general-header field represents the date and time at which
2821 the message was originated, having the same semantics as the
2822 Origination Date Field (orig-date) defined in Section 3.6.1 of
2823 [RFC5322]. The field value is an HTTP-date, as described in
2824 Section 6.1; it MUST be sent in rfc1123-date format.
2826 Date = "Date" ":" OWS Date-v
2831 Date: Tue, 15 Nov 1994 08:12:31 GMT
2833 Origin servers MUST include a Date header field in all responses,
2834 except in these cases:
2836 1. If the response status code is 100 (Continue) or 101 (Switching
2837 Protocols), the response MAY include a Date header field, at the
2840 2. If the response status code conveys a server error, e.g., 500
2841 (Internal Server Error) or 503 (Service Unavailable), and it is
2842 inconvenient or impossible to generate a valid Date.
2844 3. If the server does not have a clock that can provide a reasonable
2845 approximation of the current time, its responses MUST NOT include
2846 a Date header field. In this case, the rules in Section 9.3.1
2849 A received message that does not have a Date header field MUST be
2850 assigned one by the recipient if the message will be cached by that
2851 recipient or gatewayed via a protocol which requires a Date. An HTTP
2855 Fielding, et al. Expires February 5, 2011 [Page 51]
2857 Internet-Draft HTTP/1.1, Part 1 August 2010
2860 implementation without a clock MUST NOT cache responses without
2861 revalidating them on every use. An HTTP cache, especially a shared
2862 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
2863 its clock with a reliable external standard.
2865 Clients SHOULD only send a Date header field in messages that include
2866 a payload, as is usually the case for PUT and POST requests, and even
2867 then it is optional. A client without a clock MUST NOT send a Date
2868 header field in a request.
2870 The HTTP-date sent in a Date header SHOULD NOT represent a date and
2871 time subsequent to the generation of the message. It SHOULD
2872 represent the best available approximation of the date and time of
2873 message generation, unless the implementation has no means of
2874 generating a reasonably accurate date and time. In theory, the date
2875 ought to represent the moment just before the payload is generated.
2876 In practice, the date can be generated at any time during the message
2877 origination without affecting its semantic value.
2879 9.3.1. Clockless Origin Server Operation
2881 Some origin server implementations might not have a clock available.
2882 An origin server without a clock MUST NOT assign Expires or Last-
2883 Modified values to a response, unless these values were associated
2884 with the resource by a system or user with a reliable clock. It MAY
2885 assign an Expires value that is known, at or before server
2886 configuration time, to be in the past (this allows "pre-expiration"
2887 of responses without storing separate Expires values for each
2892 The "Host" request-header field specifies the Internet host and port
2893 number of the resource being requested, allowing the origin server or
2894 gateway to differentiate between internally-ambiguous URLs, such as
2895 the root "/" URL of a server for multiple host names on a single IP
2898 The Host field value MUST represent the naming authority of the
2899 origin server or gateway given by the original URL obtained from the
2900 user or referring resource (generally an http URI, as described in
2903 Host = "Host" ":" OWS Host-v
2904 Host-v = uri-host [ ":" port ] ; Section 2.6.1
2906 A "host" without any trailing port information implies the default
2907 port for the service requested (e.g., "80" for an HTTP URL). For
2911 Fielding, et al. Expires February 5, 2011 [Page 52]
2913 Internet-Draft HTTP/1.1, Part 1 August 2010
2916 example, a request on the origin server for
2917 <http://www.example.org/pub/WWW/> would properly include:
2919 GET /pub/WWW/ HTTP/1.1
2920 Host: www.example.org
2922 A client MUST include a Host header field in all HTTP/1.1 request
2923 messages. If the requested URI does not include an Internet host
2924 name for the service being requested, then the Host header field MUST
2925 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
2926 request message it forwards does contain an appropriate Host header
2927 field that identifies the service being requested by the proxy. All
2928 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
2929 status code to any HTTP/1.1 request message which lacks a Host header
2932 See Sections 4.2 and B.1.1 for other requirements relating to Host.
2936 The "TE" request-header field indicates what extension transfer-
2937 codings it is willing to accept in the response, and whether or not
2938 it is willing to accept trailer fields in a chunked transfer-coding.
2940 Its value consists of the keyword "trailers" and/or a comma-separated
2941 list of extension transfer-coding names with optional accept
2942 parameters (as described in Section 6.2).
2944 TE = "TE" ":" OWS TE-v
2946 t-codings = "trailers" / ( transfer-extension [ te-params ] )
2947 te-params = OWS ";" OWS "q=" qvalue *( te-ext )
2948 te-ext = OWS ";" OWS token [ "=" word ]
2950 The presence of the keyword "trailers" indicates that the client is
2951 willing to accept trailer fields in a chunked transfer-coding, as
2952 defined in Section 6.2.1. This keyword is reserved for use with
2953 transfer-coding values even though it does not itself represent a
2956 Examples of its use are:
2960 TE: trailers, deflate;q=0.5
2962 The TE header field only applies to the immediate connection.
2963 Therefore, the keyword MUST be supplied within a Connection header
2967 Fielding, et al. Expires February 5, 2011 [Page 53]
2969 Internet-Draft HTTP/1.1, Part 1 August 2010
2972 field (Section 9.1) whenever TE is present in an HTTP/1.1 message.
2974 A server tests whether a transfer-coding is acceptable, according to
2975 a TE field, using these rules:
2977 1. The "chunked" transfer-coding is always acceptable. If the
2978 keyword "trailers" is listed, the client indicates that it is
2979 willing to accept trailer fields in the chunked response on
2980 behalf of itself and any downstream clients. The implication is
2981 that, if given, the client is stating that either all downstream
2982 clients are willing to accept trailer fields in the forwarded
2983 response, or that it will attempt to buffer the response on
2984 behalf of downstream recipients.
2986 Note: HTTP/1.1 does not define any means to limit the size of a
2987 chunked response such that a client can be assured of buffering
2988 the entire response.
2990 2. If the transfer-coding being tested is one of the transfer-
2991 codings listed in the TE field, then it is acceptable unless it
2992 is accompanied by a qvalue of 0. (As defined in Section 6.4, a
2993 qvalue of 0 means "not acceptable".)
2995 3. If multiple transfer-codings are acceptable, then the acceptable
2996 transfer-coding with the highest non-zero qvalue is preferred.
2997 The "chunked" transfer-coding always has a qvalue of 1.
2999 If the TE field-value is empty or if no TE field is present, the only
3000 transfer-coding is "chunked". A message with no transfer-coding is
3005 The "Trailer" general-header field indicates that the given set of
3006 header fields is present in the trailer of a message encoded with
3007 chunked transfer-coding.
3009 Trailer = "Trailer" ":" OWS Trailer-v
3010 Trailer-v = 1#field-name
3012 An HTTP/1.1 message SHOULD include a Trailer header field in a
3013 message using chunked transfer-coding with a non-empty trailer.
3014 Doing so allows the recipient to know which header fields to expect
3017 If no Trailer header field is present, the trailer SHOULD NOT include
3018 any header fields. See Section 6.2.1 for restrictions on the use of
3019 trailer fields in a "chunked" transfer-coding.
3023 Fielding, et al. Expires February 5, 2011 [Page 54]
3025 Internet-Draft HTTP/1.1, Part 1 August 2010
3028 Message header fields listed in the Trailer header field MUST NOT
3029 include the following header fields:
3037 9.7. Transfer-Encoding
3039 The "Transfer-Encoding" general-header field indicates what transfer-
3040 codings (if any) have been applied to the message body. It differs
3041 from Content-Encoding (Section 2.2 of [Part3]) in that transfer-
3042 codings are a property of the message (and therefore are removed by
3043 intermediaries), whereas content-codings are not.
3045 Transfer-Encoding = "Transfer-Encoding" ":" OWS
3047 Transfer-Encoding-v = 1#transfer-coding
3049 Transfer-codings are defined in Section 6.2. An example is:
3051 Transfer-Encoding: chunked
3053 If multiple encodings have been applied to a representation, the
3054 transfer-codings MUST be listed in the order in which they were
3055 applied. Additional information about the encoding parameters MAY be
3056 provided by other header fields not defined by this specification.
3058 Many older HTTP/1.0 applications do not understand the Transfer-
3063 The "Upgrade" general-header field allows the client to specify what
3064 additional communication protocols it would like to use, if the
3065 server chooses to switch protocols. Additionally, the server MUST
3066 use the Upgrade header field within a 101 (Switching Protocols)
3067 response to indicate which protocol(s) are being switched to.
3069 Upgrade = "Upgrade" ":" OWS Upgrade-v
3070 Upgrade-v = 1#product
3074 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3079 Fielding, et al. Expires February 5, 2011 [Page 55]
3081 Internet-Draft HTTP/1.1, Part 1 August 2010
3084 The Upgrade header field is intended to provide a simple mechanism
3085 for transition from HTTP/1.1 to some other, incompatible protocol.
3086 It does so by allowing the client to advertise its desire to use
3087 another protocol, such as a later version of HTTP with a higher major
3088 version number, even though the current request has been made using
3089 HTTP/1.1. This eases the difficult transition between incompatible
3090 protocols by allowing the client to initiate a request in the more
3091 commonly supported protocol while indicating to the server that it
3092 would like to use a "better" protocol if available (where "better" is
3093 determined by the server, possibly according to the nature of the
3094 method and/or resource being requested).
3096 The Upgrade header field only applies to switching application-layer
3097 protocols upon the existing transport-layer connection. Upgrade
3098 cannot be used to insist on a protocol change; its acceptance and use
3099 by the server is optional. The capabilities and nature of the
3100 application-layer communication after the protocol change is entirely
3101 dependent upon the new protocol chosen, although the first action
3102 after changing the protocol MUST be a response to the initial HTTP
3103 request containing the Upgrade header field.
3105 The Upgrade header field only applies to the immediate connection.
3106 Therefore, the upgrade keyword MUST be supplied within a Connection
3107 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1
3110 The Upgrade header field cannot be used to indicate a switch to a
3111 protocol on a different connection. For that purpose, it is more
3112 appropriate to use a 301, 302, 303, or 305 redirection response.
3114 This specification only defines the protocol name "HTTP" for use by
3115 the family of Hypertext Transfer Protocols, as defined by the HTTP
3116 version rules of Section 2.5 and future updates to this
3117 specification. Additional tokens can be registered with IANA using
3118 the registration procedure defined below.
3120 9.8.1. Upgrade Token Registry
3122 The HTTP Upgrade Token Registry defines the name space for product
3123 tokens used to identify protocols in the Upgrade header field. Each
3124 registered token is associated with contact information and an
3125 optional set of specifications that details how the connection will
3126 be processed after it has been upgraded.
3128 Registrations are allowed on a First Come First Served basis as
3129 described in Section 4.1 of [RFC5226]. The specifications need not
3130 be IETF documents or be subject to IESG review. Registrations are
3131 subject to the following rules:
3135 Fielding, et al. Expires February 5, 2011 [Page 56]
3137 Internet-Draft HTTP/1.1, Part 1 August 2010
3140 1. A token, once registered, stays registered forever.
3142 2. The registration MUST name a responsible party for the
3145 3. The registration MUST name a point of contact.
3147 4. The registration MAY name a set of specifications associated with
3148 that token. Such specifications need not be publicly available.
3150 5. The responsible party MAY change the registration at any time.
3151 The IANA will keep a record of all such changes, and make them
3152 available upon request.
3154 6. The responsible party for the first registration of a "product"
3155 token MUST approve later registrations of a "version" token
3156 together with that "product" token before they can be registered.
3158 7. If absolutely required, the IESG MAY reassign the responsibility
3159 for a token. This will normally only be used in the case when a
3160 responsible party cannot be contacted.
3164 The "Via" general-header field MUST be used by gateways and proxies
3165 to indicate the intermediate protocols and recipients between the
3166 user agent and the server on requests, and between the origin server
3167 and the client on responses. It is analogous to the "Received" field
3168 defined in Section 3.6.7 of [RFC5322] and is intended to be used for
3169 tracking message forwards, avoiding request loops, and identifying
3170 the protocol capabilities of all senders along the request/response
3173 Via = "Via" ":" OWS Via-v
3174 Via-v = 1#( received-protocol RWS received-by
3176 received-protocol = [ protocol-name "/" ] protocol-version
3177 protocol-name = token
3178 protocol-version = token
3179 received-by = ( uri-host [ ":" port ] ) / pseudonym
3182 The received-protocol indicates the protocol version of the message
3183 received by the server or client along each segment of the request/
3184 response chain. The received-protocol version is appended to the Via
3185 field value when the message is forwarded so that information about
3186 the protocol capabilities of upstream applications remains visible to
3191 Fielding, et al. Expires February 5, 2011 [Page 57]
3193 Internet-Draft HTTP/1.1, Part 1 August 2010
3196 The protocol-name is optional if and only if it would be "HTTP". The
3197 received-by field is normally the host and optional port number of a
3198 recipient server or client that subsequently forwarded the message.
3199 However, if the real host is considered to be sensitive information,
3200 it MAY be replaced by a pseudonym. If the port is not given, it MAY
3201 be assumed to be the default port of the received-protocol.
3203 Multiple Via field values represent each proxy or gateway that has
3204 forwarded the message. Each recipient MUST append its information
3205 such that the end result is ordered according to the sequence of
3206 forwarding applications.
3208 Comments MAY be used in the Via header field to identify the software
3209 of the recipient proxy or gateway, analogous to the User-Agent and
3210 Server header fields. However, all comments in the Via field are
3211 optional and MAY be removed by any recipient prior to forwarding the
3214 For example, a request message could be sent from an HTTP/1.0 user
3215 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
3216 forward the request to a public proxy at p.example.net, which
3217 completes the request by forwarding it to the origin server at
3218 www.example.com. The request received by www.example.com would then
3219 have the following Via header field:
3221 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
3223 Proxies and gateways used as a portal through a network firewall
3224 SHOULD NOT, by default, forward the names and ports of hosts within
3225 the firewall region. This information SHOULD only be propagated if
3226 explicitly enabled. If not enabled, the received-by host of any host
3227 behind the firewall SHOULD be replaced by an appropriate pseudonym
3230 For organizations that have strong privacy requirements for hiding
3231 internal structures, a proxy MAY combine an ordered subsequence of
3232 Via header field entries with identical received-protocol values into
3233 a single such entry. For example,
3235 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
3237 could be collapsed to
3239 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
3241 Applications SHOULD NOT combine multiple entries unless they are all
3242 under the same organizational control and the hosts have already been
3243 replaced by pseudonyms. Applications MUST NOT combine entries which
3247 Fielding, et al. Expires February 5, 2011 [Page 58]
3249 Internet-Draft HTTP/1.1, Part 1 August 2010
3252 have different received-protocol values.
3254 10. IANA Considerations
3256 10.1. Header Field Registration
3258 The Message Header Field Registry located at <http://www.iana.org/
3259 assignments/message-headers/message-header-index.html> shall be
3260 updated with the permanent registrations below (see [RFC3864]):
3262 +-------------------+----------+----------+-------------+
3263 | Header Field Name | Protocol | Status | Reference |
3264 +-------------------+----------+----------+-------------+
3265 | Connection | http | standard | Section 9.1 |
3266 | Content-Length | http | standard | Section 9.2 |
3267 | Date | http | standard | Section 9.3 |
3268 | Host | http | standard | Section 9.4 |
3269 | TE | http | standard | Section 9.5 |
3270 | Trailer | http | standard | Section 9.6 |
3271 | Transfer-Encoding | http | standard | Section 9.7 |
3272 | Upgrade | http | standard | Section 9.8 |
3273 | Via | http | standard | Section 9.9 |
3274 +-------------------+----------+----------+-------------+
3276 The change controller is: "IETF (iesg@ietf.org) - Internet
3277 Engineering Task Force".
3279 10.2. URI Scheme Registration
3281 The entries for the "http" and "https" URI Schemes in the registry
3282 located at <http://www.iana.org/assignments/uri-schemes.html> shall
3283 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see
3286 10.3. Internet Media Type Registrations
3288 This document serves as the specification for the Internet media
3289 types "message/http" and "application/http". The following is to be
3290 registered with IANA (see [RFC4288]).
3292 10.3.1. Internet Media Type message/http
3294 The message/http type can be used to enclose a single HTTP request or
3295 response message, provided that it obeys the MIME restrictions for
3296 all "message" types regarding line length and encodings.
3303 Fielding, et al. Expires February 5, 2011 [Page 59]
3305 Internet-Draft HTTP/1.1, Part 1 August 2010
3312 Required parameters: none
3314 Optional parameters: version, msgtype
3316 version: The HTTP-Version number of the enclosed message (e.g.,
3317 "1.1"). If not present, the version can be determined from the
3318 first line of the body.
3320 msgtype: The message type -- "request" or "response". If not
3321 present, the type can be determined from the first line of the
3324 Encoding considerations: only "7bit", "8bit", or "binary" are
3327 Security considerations: none
3329 Interoperability considerations: none
3331 Published specification: This specification (see Section 10.3.1).
3333 Applications that use this media type:
3335 Additional information:
3337 Magic number(s): none
3339 File extension(s): none
3341 Macintosh file type code(s): none
3343 Person and email address to contact for further information: See
3346 Intended usage: COMMON
3348 Restrictions on usage: none
3350 Author/Change controller: IESG
3359 Fielding, et al. Expires February 5, 2011 [Page 60]
3361 Internet-Draft HTTP/1.1, Part 1 August 2010
3364 10.3.2. Internet Media Type application/http
3366 The application/http type can be used to enclose a pipeline of one or
3367 more HTTP request or response messages (not intermixed).
3369 Type name: application
3373 Required parameters: none
3375 Optional parameters: version, msgtype
3377 version: The HTTP-Version number of the enclosed messages (e.g.,
3378 "1.1"). If not present, the version can be determined from the
3379 first line of the body.
3381 msgtype: The message type -- "request" or "response". If not
3382 present, the type can be determined from the first line of the
3385 Encoding considerations: HTTP messages enclosed by this type are in
3386 "binary" format; use of an appropriate Content-Transfer-Encoding
3387 is required when transmitted via E-mail.
3389 Security considerations: none
3391 Interoperability considerations: none
3393 Published specification: This specification (see Section 10.3.2).
3395 Applications that use this media type:
3397 Additional information:
3399 Magic number(s): none
3401 File extension(s): none
3403 Macintosh file type code(s): none
3405 Person and email address to contact for further information: See
3408 Intended usage: COMMON
3415 Fielding, et al. Expires February 5, 2011 [Page 61]
3417 Internet-Draft HTTP/1.1, Part 1 August 2010
3420 Restrictions on usage: none
3422 Author/Change controller: IESG
3424 10.4. Transfer Coding Registry
3426 The registration procedure for HTTP Transfer Codings is now defined
3427 by Section 6.2.3 of this document.
3429 The HTTP Transfer Codings Registry located at
3430 <http://www.iana.org/assignments/http-parameters> shall be updated
3431 with the registrations below:
3433 +----------+--------------------------------------+-----------------+
3434 | Name | Description | Reference |
3435 +----------+--------------------------------------+-----------------+
3436 | chunked | Transfer in a series of chunks | Section 6.2.1 |
3437 | compress | UNIX "compress" program method | Section 6.2.2.1 |
3438 | deflate | "deflate" compression mechanism | Section 6.2.2.2 |
3439 | | ([RFC1951]) used inside the "zlib" | |
3440 | | data format ([RFC1950]) | |
3441 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 |
3442 +----------+--------------------------------------+-----------------+
3444 10.5. Upgrade Token Registration
3446 The registration procedure for HTTP Upgrade Tokens -- previously
3447 defined in Section 7.2 of [RFC2817] -- is now defined by
3448 Section 9.8.1 of this document.
3450 The HTTP Status Code Registry located at
3451 <http://www.iana.org/assignments/http-upgrade-tokens/> shall be
3452 updated with the registration below:
3454 +-------+---------------------------+-------------------------------+
3455 | Value | Description | Reference |
3456 +-------+---------------------------+-------------------------------+
3457 | HTTP | Hypertext Transfer | Section 2.5 of this |
3458 | | Protocol | specification |
3459 +-------+---------------------------+-------------------------------+
3461 11. Security Considerations
3463 This section is meant to inform application developers, information
3464 providers, and users of the security limitations in HTTP/1.1 as
3465 described by this document. The discussion does not include
3466 definitive solutions to the problems revealed, though it does make
3467 some suggestions for reducing security risks.
3471 Fielding, et al. Expires February 5, 2011 [Page 62]
3473 Internet-Draft HTTP/1.1, Part 1 August 2010
3476 11.1. Personal Information
3478 HTTP clients are often privy to large amounts of personal information
3479 (e.g., the user's name, location, mail address, passwords, encryption
3480 keys, etc.), and SHOULD be very careful to prevent unintentional
3481 leakage of this information. We very strongly recommend that a
3482 convenient interface be provided for the user to control
3483 dissemination of such information, and that designers and
3484 implementors be particularly careful in this area. History shows
3485 that errors in this area often create serious security and/or privacy
3486 problems and generate highly adverse publicity for the implementor's
3489 11.2. Abuse of Server Log Information
3491 A server is in the position to save personal data about a user's
3492 requests which might identify their reading patterns or subjects of
3493 interest. This information is clearly confidential in nature and its
3494 handling can be constrained by law in certain countries. People
3495 using HTTP to provide data are responsible for ensuring that such
3496 material is not distributed without the permission of any individuals
3497 that are identifiable by the published results.
3499 11.3. Attacks Based On File and Path Names
3501 Implementations of HTTP origin servers SHOULD be careful to restrict
3502 the documents returned by HTTP requests to be only those that were
3503 intended by the server administrators. If an HTTP server translates
3504 HTTP URIs directly into file system calls, the server MUST take
3505 special care not to serve files that were not intended to be
3506 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
3507 other operating systems use ".." as a path component to indicate a
3508 directory level above the current one. On such a system, an HTTP
3509 server MUST disallow any such construct in the request-target if it
3510 would otherwise allow access to a resource outside those intended to
3511 be accessible via the HTTP server. Similarly, files intended for
3512 reference only internally to the server (such as access control
3513 files, configuration files, and script code) MUST be protected from
3514 inappropriate retrieval, since they might contain sensitive
3515 information. Experience has shown that minor bugs in such HTTP
3516 server implementations have turned into security risks.
3520 Clients using HTTP rely heavily on the Domain Name Service, and are
3521 thus generally prone to security attacks based on the deliberate mis-
3522 association of IP addresses and DNS names. Clients need to be
3523 cautious in assuming the continuing validity of an IP number/DNS name
3527 Fielding, et al. Expires February 5, 2011 [Page 63]
3529 Internet-Draft HTTP/1.1, Part 1 August 2010
3534 In particular, HTTP clients SHOULD rely on their name resolver for
3535 confirmation of an IP number/DNS name association, rather than
3536 caching the result of previous host name lookups. Many platforms
3537 already can cache host name lookups locally when appropriate, and
3538 they SHOULD be configured to do so. It is proper for these lookups
3539 to be cached, however, only when the TTL (Time To Live) information
3540 reported by the name server makes it likely that the cached
3541 information will remain useful.
3543 If HTTP clients cache the results of host name lookups in order to
3544 achieve a performance improvement, they MUST observe the TTL
3545 information reported by DNS.
3547 If HTTP clients do not observe this rule, they could be spoofed when
3548 a previously-accessed server's IP address changes. As network
3549 renumbering is expected to become increasingly common [RFC1900], the
3550 possibility of this form of attack will grow. Observing this
3551 requirement thus reduces this potential security vulnerability.
3553 This requirement also improves the load-balancing behavior of clients
3554 for replicated servers using the same DNS name and reduces the
3555 likelihood of a user's experiencing failure in accessing sites which
3558 11.5. Proxies and Caching
3560 By their very nature, HTTP proxies are men-in-the-middle, and
3561 represent an opportunity for man-in-the-middle attacks. Compromise
3562 of the systems on which the proxies run can result in serious
3563 security and privacy problems. Proxies have access to security-
3564 related information, personal information about individual users and
3565 organizations, and proprietary information belonging to users and
3566 content providers. A compromised proxy, or a proxy implemented or
3567 configured without regard to security and privacy considerations,
3568 might be used in the commission of a wide range of potential attacks.
3570 Proxy operators need to protect the systems on which proxies run as
3571 they would protect any system that contains or transports sensitive
3572 information. In particular, log information gathered at proxies
3573 often contains highly sensitive personal information, and/or
3574 information about organizations. Log information needs to be
3575 carefully guarded, and appropriate guidelines for use need to be
3576 developed and followed. (Section 11.2).
3578 Proxy implementors need to consider the privacy and security
3579 implications of their design and coding decisions, and of the
3583 Fielding, et al. Expires February 5, 2011 [Page 64]
3585 Internet-Draft HTTP/1.1, Part 1 August 2010
3588 configuration options they provide to proxy operators (especially the
3589 default configuration).
3591 Users of a proxy need to be aware that proxies are no trustworthier
3592 than the people who run them; HTTP itself cannot solve this problem.
3594 The judicious use of cryptography, when appropriate, might suffice to
3595 protect against a broad range of security and privacy attacks. Such
3596 cryptography is beyond the scope of the HTTP/1.1 specification.
3598 11.6. Denial of Service Attacks on Proxies
3600 They exist. They are hard to defend against. Research continues.
3605 HTTP has evolved considerably over the years. It has benefited from
3606 a large and active developer community--the many people who have
3607 participated on the www-talk mailing list--and it is that community
3608 which has been most responsible for the success of HTTP and of the
3609 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
3610 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
3611 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
3612 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
3613 recognition for their efforts in defining early aspects of the
3616 This document has benefited greatly from the comments of all those
3617 participating in the HTTP-WG. In addition to those already
3618 mentioned, the following individuals have contributed to this
3621 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
3622 Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman
3623 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan
3624 Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob
3625 Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster,
3626 Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J.
3627 Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin,
3628 Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey
3629 Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc
3630 Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton,
3631 Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill
3632 (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko.
3634 Thanks to the "cave men" of Palo Alto. You know who you are.
3639 Fielding, et al. Expires February 5, 2011 [Page 65]
3641 Internet-Draft HTTP/1.1, Part 1 August 2010
3644 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
3645 Fielding, the editor of [RFC2068], along with John Klensin, Jeff
3646 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
3647 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
3648 help. And thanks go particularly to Jeff Mogul and Scott Lawrence
3649 for performing the "MUST/MAY/SHOULD" audit.
3651 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
3652 Frystyk implemented RFC 2068 early, and we wish to thank them for the
3653 discovery of many of the problems that this document attempts to
3656 This specification makes heavy use of the augmented BNF and generic
3657 constructs defined by David H. Crocker for [RFC5234]. Similarly, it
3658 reuses many of the definitions provided by Nathaniel Borenstein and
3659 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
3660 specification will help reduce past confusion over the relationship
3661 between HTTP and Internet mail message formats.
3665 13.1. Normative References
3667 [ISO-8859-1] International Organization for Standardization,
3668 "Information technology -- 8-bit single-byte coded
3669 graphic character sets -- Part 1: Latin alphabet No.
3670 1", ISO/IEC 8859-1:1998, 1998.
3672 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3673 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3674 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
3675 Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
3676 progress), August 2010.
3678 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3679 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3680 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
3681 Payload and Content Negotiation",
3682 draft-ietf-httpbis-p3-payload-11 (work in progress),
3685 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3686 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3687 Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
3688 "HTTP/1.1, part 6: Caching",
3689 draft-ietf-httpbis-p6-cache-11 (work in progress),
3695 Fielding, et al. Expires February 5, 2011 [Page 66]
3697 Internet-Draft HTTP/1.1, Part 1 August 2010
3700 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
3701 Format Specification version 3.3", RFC 1950, May 1996.
3703 RFC 1950 is an Informational RFC, thus it might be less
3704 stable than this specification. On the other hand,
3705 this downward reference was present since the
3706 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3707 it is unlikely to cause problems in practice. See also
3710 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
3711 Specification version 1.3", RFC 1951, May 1996.
3713 RFC 1951 is an Informational RFC, thus it might be less
3714 stable than this specification. On the other hand,
3715 this downward reference was present since the
3716 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3717 it is unlikely to cause problems in practice. See also
3720 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
3721 G. Randers-Pehrson, "GZIP file format specification
3722 version 4.3", RFC 1952, May 1996.
3724 RFC 1952 is an Informational RFC, thus it might be less
3725 stable than this specification. On the other hand,
3726 this downward reference was present since the
3727 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3728 it is unlikely to cause problems in practice. See also
3731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3732 Requirement Levels", BCP 14, RFC 2119, March 1997.
3734 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
3735 "Uniform Resource Identifier (URI): Generic Syntax",
3736 RFC 3986, STD 66, January 2005.
3738 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
3739 Syntax Specifications: ABNF", STD 68, RFC 5234,
3742 [USASCII] American National Standards Institute, "Coded Character
3743 Set -- 7-bit American Standard Code for Information
3744 Interchange", ANSI X3.4, 1986.
3751 Fielding, et al. Expires February 5, 2011 [Page 67]
3753 Internet-Draft HTTP/1.1, Part 1 August 2010
3756 13.2. Informative References
3758 [BCP97] Klensin, J. and S. Hartman, "Handling Normative
3759 References to Standards-Track Documents", BCP 97,
3760 RFC 4897, June 2007.
3762 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
3763 Politics", ACM Transactions on Internet Technology Vol.
3764 1, #2, November 2001,
3765 <http://arxiv.org/abs/cs.SE/0105018>.
3767 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
3768 and C. Lilley, "Network Performance Effects of
3769 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
3770 SIGCOMM '97 conference on Applications, technologies,
3771 architectures, and protocols for computer communication
3772 SIGCOMM '97, September 1997,
3773 <http://doi.acm.org/10.1145/263105.263157>.
3775 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
3776 Computer Networks and ISDN Systems v. 28, pp. 25-35,
3778 <http://portal.acm.org/citation.cfm?id=219094>.
3780 [RFC1123] Braden, R., "Requirements for Internet Hosts -
3781 Application and Support", STD 3, RFC 1123,
3784 [RFC1305] Mills, D., "Network Time Protocol (Version 3)
3785 Specification, Implementation", RFC 1305, March 1992.
3787 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
3788 RFC 1900, February 1996.
3790 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
3791 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
3794 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
3795 Mail Extensions (MIME) Part One: Format of Internet
3796 Message Bodies", RFC 2045, November 1996.
3798 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
3799 Extensions) Part Three: Message Header Extensions for
3800 Non-ASCII Text", RFC 2047, November 1996.
3802 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
3803 T. Berners-Lee, "Hypertext Transfer Protocol --
3807 Fielding, et al. Expires February 5, 2011 [Page 68]
3809 Internet-Draft HTTP/1.1, Part 1 August 2010
3812 HTTP/1.1", RFC 2068, January 1997.
3814 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
3815 Mechanism", RFC 2109, February 1997.
3817 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
3818 "Use and Interpretation of HTTP Version Numbers",
3821 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3822 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3823 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3825 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
3826 HTTP/1.1", RFC 2817, May 2000.
3828 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3830 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
3831 Mechanism", RFC 2965, October 2000.
3833 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
3834 Procedures for Message Header Fields", BCP 90,
3835 RFC 3864, September 2004.
3837 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
3838 and Registration Procedures", BCP 13, RFC 4288,
3841 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
3842 and Registration Procedures for New URI Schemes",
3843 BCP 115, RFC 4395, February 2006.
3845 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
3846 an IANA Considerations Section in RFCs", BCP 26,
3849 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
3852 [Spe] Spero, S., "Analysis of HTTP Performance Problems",
3853 <http://sunsite.unc.edu/mdma-release/http-prob.html>.
3855 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
3856 HTTP Performance", ISI Research Report ISI/RR-98-463,
3857 Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
3859 (original report dated Aug. 1996)
3863 Fielding, et al. Expires February 5, 2011 [Page 69]
3865 Internet-Draft HTTP/1.1, Part 1 August 2010
3868 Appendix A. Tolerant Applications
3870 Although this document specifies the requirements for the generation
3871 of HTTP/1.1 messages, not all applications will be correct in their
3872 implementation. We therefore recommend that operational applications
3873 be tolerant of deviations whenever those deviations can be
3874 interpreted unambiguously.
3876 Clients SHOULD be tolerant in parsing the Status-Line and servers
3877 SHOULD be tolerant when parsing the Request-Line. In particular,
3878 they SHOULD accept any amount of WSP characters between fields, even
3879 though only a single SP is required.
3881 The line terminator for header fields is the sequence CRLF. However,
3882 we recommend that applications, when parsing such headers, recognize
3883 a single LF as a line terminator and ignore the leading CR.
3885 The character set of a representation SHOULD be labeled as the lowest
3886 common denominator of the character codes used within that
3887 representation, with the exception that not labeling the
3888 representation is preferred over labeling the representation with the
3889 labels US-ASCII or ISO-8859-1. See [Part3].
3891 Additional rules for requirements on parsing and encoding of dates
3892 and other potential problems with date encodings include:
3894 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
3895 which appears to be more than 50 years in the future is in fact in
3896 the past (this helps solve the "year 2000" problem).
3898 o Although all date formats are specified to be case-sensitive,
3899 recipients SHOULD match day, week and timezone names case-
3902 o An HTTP/1.1 implementation MAY internally represent a parsed
3903 Expires date as earlier than the proper value, but MUST NOT
3904 internally represent a parsed Expires date as later than the
3907 o All expiration-related calculations MUST be done in GMT. The
3908 local time zone MUST NOT influence the calculation or comparison
3909 of an age or expiration time.
3911 o If an HTTP header incorrectly carries a date value with a time
3912 zone other than GMT, it MUST be converted into GMT using the most
3913 conservative possible conversion.
3919 Fielding, et al. Expires February 5, 2011 [Page 70]
3921 Internet-Draft HTTP/1.1, Part 1 August 2010
3924 Appendix B. Compatibility with Previous Versions
3926 HTTP has been in use by the World-Wide Web global information
3927 initiative since 1990. The first version of HTTP, later referred to
3928 as HTTP/0.9, was a simple protocol for hypertext data transfer across
3929 the Internet with only a single method and no metadata. HTTP/1.0, as
3930 defined by [RFC1945], added a range of request methods and MIME-like
3931 messaging that could include metadata about the data transferred and
3932 modifiers on the request/response semantics. However, HTTP/1.0 did
3933 not sufficiently take into consideration the effects of hierarchical
3934 proxies, caching, the need for persistent connections, or name-based
3935 virtual hosts. The proliferation of incompletely-implemented
3936 applications calling themselves "HTTP/1.0" further necessitated a
3937 protocol version change in order for two communicating applications
3938 to determine each other's true capabilities.
3940 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
3941 requirements that enable reliable implementations, adding only those
3942 new features that will either be safely ignored by an HTTP/1.0
3943 recipient or only sent when communicating with a party advertising
3944 compliance with HTTP/1.1.
3946 It is beyond the scope of a protocol specification to mandate
3947 compliance with previous versions. HTTP/1.1 was deliberately
3948 designed, however, to make supporting previous versions easy. It is
3949 worth noting that, at the time of composing this specification, we
3950 would expect general-purpose HTTP/1.1 servers to:
3952 o understand any valid request in the format of HTTP/1.0 and 1.1;
3954 o respond appropriately with a message in the same major version
3957 And we would expect HTTP/1.1 clients to:
3959 o understand any valid response in the format of HTTP/1.0 or 1.1.
3961 For most implementations of HTTP/1.0, each connection is established
3962 by the client prior to the request and closed by the server after
3963 sending the response. Some implementations implement the Keep-Alive
3964 version of persistent connections described in Section 19.7.1 of
3967 B.1. Changes from HTTP/1.0
3969 This section summarizes major differences between versions HTTP/1.0
3975 Fielding, et al. Expires February 5, 2011 [Page 71]
3977 Internet-Draft HTTP/1.1, Part 1 August 2010
3980 B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
3983 The requirements that clients and servers support the Host request-
3984 header, report an error if the Host request-header (Section 9.4) is
3985 missing from an HTTP/1.1 request, and accept absolute URIs
3986 (Section 4.1.2) are among the most important changes defined by this
3989 Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3990 addresses and servers; there was no other established mechanism for
3991 distinguishing the intended server of a request than the IP address
3992 to which that request was directed. The changes outlined above will
3993 allow the Internet, once older HTTP clients are no longer common, to
3994 support multiple Web sites from a single IP address, greatly
3995 simplifying large operational Web servers, where allocation of many
3996 IP addresses to a single host has created serious problems. The
3997 Internet will also be able to recover the IP addresses that have been
3998 allocated for the sole purpose of allowing special-purpose domain
3999 names to be used in root-level HTTP URLs. Given the rate of growth
4000 of the Web, and the number of servers already deployed, it is
4001 extremely important that all implementations of HTTP (including
4002 updates to existing HTTP/1.0 applications) correctly implement these
4005 o Both clients and servers MUST support the Host request-header.
4007 o A client that sends an HTTP/1.1 request MUST send a Host header.
4009 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
4010 request does not include a Host request-header.
4012 o Servers MUST accept absolute URIs.
4014 B.2. Compatibility with HTTP/1.0 Persistent Connections
4016 Some clients and servers might wish to be compatible with some
4017 previous implementations of persistent connections in HTTP/1.0
4018 clients and servers. Persistent connections in HTTP/1.0 are
4019 explicitly negotiated as they are not the default behavior. HTTP/1.0
4020 experimental implementations of persistent connections are faulty,
4021 and the new facilities in HTTP/1.1 are designed to rectify these
4022 problems. The problem was that some existing HTTP/1.0 clients might
4023 send Keep-Alive to a proxy server that doesn't understand Connection,
4024 which would then erroneously forward it to the next inbound server,
4025 which would establish the Keep-Alive connection and result in a hung
4026 HTTP/1.0 proxy waiting for the close on the response. The result is
4027 that HTTP/1.0 clients must be prevented from using Keep-Alive when
4031 Fielding, et al. Expires February 5, 2011 [Page 72]
4033 Internet-Draft HTTP/1.1, Part 1 August 2010
4038 However, talking to proxies is the most important use of persistent
4039 connections, so that prohibition is clearly unacceptable. Therefore,
4040 we need some other mechanism for indicating a persistent connection
4041 is desired, which is safe to use even when talking to an old proxy
4042 that ignores Connection. Persistent connections are the default for
4043 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
4044 declaring non-persistence. See Section 9.1.
4046 The original HTTP/1.0 form of persistent connections (the Connection:
4047 Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of
4050 B.3. Changes from RFC 2616
4052 Empty list elements in list productions have been deprecated.
4055 Rules about implicit linear whitespace between certain grammar
4056 productions have been removed; now it's only allowed when
4057 specifically pointed out in the ABNF. The NUL character is no longer
4058 allowed in comment and quoted-string text. The quoted-pair rule no
4059 longer allows escaping control characters other than HTAB. Non-ASCII
4060 content in header fields and reason phrase has been obsoleted and
4061 made opaque (the TEXT rule was removed) (Section 1.2.2)
4063 Clarify that HTTP-Version is case sensitive. (Section 2.5)
4065 Remove reference to non-existent identity transfer-coding value
4066 tokens. (Sections 6.2 and 3.3)
4068 Require that invalid whitespace around field-names be rejected.
4071 Update use of abs_path production from RFC1808 to the path-absolute +
4072 query components of RFC3986. (Section 4.1.2)
4074 Clarification that the chunk length does not include the count of the
4075 octets in the chunk header and trailer. Furthermore disallowed line
4076 folding in chunk extensions. (Section 6.2.1)
4078 Remove hard limit of two connections per server. (Section 7.1.4)
4080 Clarify exactly when close connection options must be sent.
4083 Appendix C. Collected ABNF
4087 Fielding, et al. Expires February 5, 2011 [Page 73]
4089 Internet-Draft HTTP/1.1, Part 1 August 2010
4094 Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
4095 Chunked-Body = *chunk last-chunk trailer-part CRLF
4096 Connection = "Connection:" OWS Connection-v
4097 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
4098 connection-token ] )
4099 Content-Length = "Content-Length:" OWS 1*Content-Length-v
4100 Content-Length-v = 1*DIGIT
4102 Date = "Date:" OWS Date-v
4105 GMT = %x47.4D.54 ; GMT
4107 HTTP-Prot-Name = %x48.54.54.50 ; HTTP
4108 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
4109 HTTP-date = rfc1123-date / obs-date
4110 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4112 Host = "Host:" OWS Host-v
4113 Host-v = uri-host [ ":" port ]
4115 MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1>
4118 OWS = *( [ obs-fold ] WSP )
4120 Pragma = <Pragma, defined in [Part6], Section 3.4>
4122 RWS = 1*( [ obs-fold ] WSP )
4123 Reason-Phrase = *( WSP / VCHAR / obs-text )
4124 Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
4125 Request-Line = Method SP request-target SP HTTP-Version CRLF
4126 Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
4128 Status-Code = 3DIGIT
4129 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
4132 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4133 Trailer = "Trailer:" OWS Trailer-v
4134 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4135 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
4136 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4139 URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
4143 Fielding, et al. Expires February 5, 2011 [Page 74]
4145 Internet-Draft HTTP/1.1, Part 1 August 2010
4148 Upgrade = "Upgrade:" OWS Upgrade-v
4149 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
4151 Via = "Via:" OWS Via-v
4152 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
4153 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
4156 Warning = <Warning, defined in [Part6], Section 3.6>
4158 absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
4159 asctime-date = day-name SP date3 SP time-of-day SP year
4161 authority = <authority, defined in [RFC3986], Section 3.2>
4163 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
4164 chunk-data = 1*OCTET
4165 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
4166 chunk-ext-name = token
4167 chunk-ext-val = token / quoted-str-nf
4168 chunk-size = 1*HEXDIG
4169 comment = "(" *( ctext / quoted-cpair / comment ) ")"
4170 connection-token = token
4171 ctext = OWS / %x21-27 ; '!'-'''
4176 date1 = day SP month SP year
4177 date2 = day "-" month "-" 2DIGIT
4178 date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
4180 day-name = %x4D.6F.6E ; Mon
4187 day-name-l = %x4D.6F.6E.64.61.79 ; Monday
4188 / %x54.75.65.73.64.61.79 ; Tuesday
4189 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
4190 / %x54.68.75.72.73.64.61.79 ; Thursday
4191 / %x46.72.69.64.61.79 ; Friday
4192 / %x53.61.74.75.72.64.61.79 ; Saturday
4193 / %x53.75.6E.64.61.79 ; Sunday
4195 field-content = *( WSP / VCHAR / obs-text )
4199 Fielding, et al. Expires February 5, 2011 [Page 75]
4201 Internet-Draft HTTP/1.1, Part 1 August 2010
4205 field-value = *( field-content / OWS )
4207 general-header = Cache-Control / Connection / Date / Pragma / Trailer
4208 / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version
4210 header-field = field-name ":" OWS [ field-value ] OWS
4212 http-URI = "http://" authority path-abempty [ "?" query ]
4213 https-URI = "https://" authority path-abempty [ "?" query ]
4215 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
4217 message-body = *OCTET
4219 month = %x4A.61.6E ; Jan
4232 obs-date = rfc850-date / asctime-date
4236 partial-URI = relative-part [ "?" query ]
4237 path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
4238 path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
4239 port = <port, defined in [RFC3986], Section 3.2.3>
4240 product = token [ "/" product-version ]
4241 product-version = token
4242 protocol-name = token
4243 protocol-version = token
4246 qdtext = OWS / "!" / %x23-5B ; '#'-'['
4249 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'['
4255 Fielding, et al. Expires February 5, 2011 [Page 76]
4257 Internet-Draft HTTP/1.1, Part 1 August 2010
4260 query = <query, defined in [RFC3986], Section 3.4>
4261 quoted-cpair = "\" ( WSP / VCHAR / obs-text )
4262 quoted-pair = "\" ( WSP / VCHAR / obs-text )
4263 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
4264 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4265 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4267 received-by = ( uri-host [ ":" port ] ) / pseudonym
4268 received-protocol = [ protocol-name "/" ] protocol-version
4269 relative-part = <relative-part, defined in [RFC3986], Section 4.2>
4270 request-header = <request-header, defined in [Part2], Section 3>
4271 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
4273 response-header = <response-header, defined in [Part2], Section 5>
4274 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
4275 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
4278 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
4279 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
4280 start-line = Request-Line / Status-Line
4282 t-codings = "trailers" / ( transfer-extension [ te-params ] )
4283 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4284 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4285 te-ext = OWS ";" OWS token [ "=" word ]
4286 te-params = OWS ";" OWS "q=" qvalue *te-ext
4287 time-of-day = hour ":" minute ":" second
4289 trailer-part = *( header-field CRLF )
4290 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4292 transfer-extension = token *( OWS ";" OWS transfer-parameter )
4293 transfer-parameter = attribute BWS "=" BWS value
4295 uri-host = <host, defined in [RFC3986], Section 3.2.2>
4299 word = token / quoted-string
4311 Fielding, et al. Expires February 5, 2011 [Page 77]
4313 Internet-Draft HTTP/1.1, Part 1 August 2010
4318 ; Chunked-Body defined but not used
4319 ; Content-Length defined but not used
4320 ; HTTP-message defined but not used
4321 ; Host defined but not used
4322 ; Request defined but not used
4323 ; Response defined but not used
4324 ; TE defined but not used
4325 ; URI-reference defined but not used
4326 ; general-header defined but not used
4327 ; http-URI defined but not used
4328 ; https-URI defined but not used
4329 ; partial-URI defined but not used
4330 ; request-header defined but not used
4331 ; response-header defined but not used
4332 ; special defined but not used
4334 Appendix D. Change Log (to be removed by RFC Editor before publication)
4338 Extracted relevant partitions from [RFC2616].
4340 D.2. Since draft-ietf-httpbis-p1-messaging-00
4344 o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
4345 should be case sensitive"
4346 (<http://purl.org/NET/http-errata#verscase>)
4348 o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
4349 characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
4351 o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
4352 Definition" (<http://purl.org/NET/http-errata#chunk-size>)
4354 o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
4355 (<http://purl.org/NET/http-errata#msg-len-chars>)
4357 o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
4358 Registrations" (<http://purl.org/NET/http-errata#media-reg>)
4360 o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
4361 query" (<http://purl.org/NET/http-errata#uriquery>)
4367 Fielding, et al. Expires February 5, 2011 [Page 78]
4369 Internet-Draft HTTP/1.1, Part 1 August 2010
4372 o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
4373 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
4375 o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
4376 'identity' token references"
4377 (<http://purl.org/NET/http-errata#identity>)
4379 o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
4382 o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
4384 o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
4385 Informative references"
4387 o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
4390 o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
4393 o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
4396 o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
4397 in date format explanation"
4399 o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
4402 o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
4405 o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
4408 o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
4413 o Update media type registrations to use RFC4288 template.
4415 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
4416 for chunk-data (work in progress on
4417 <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
4423 Fielding, et al. Expires February 5, 2011 [Page 79]
4425 Internet-Draft HTTP/1.1, Part 1 August 2010
4428 D.3. Since draft-ietf-httpbis-p1-messaging-01
4432 o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
4433 (and other) requests"
4435 o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
4438 o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
4441 o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
4444 Ongoing work on ABNF conversion
4445 (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4447 o Get rid of duplicate BNF rule names ("host" -> "uri-host",
4448 "trailer" -> "trailer-part").
4450 o Avoid underscore character in rule names ("http_URL" -> "http-
4451 URL", "abs_path" -> "path-absolute").
4453 o Add rules for terms imported from URI spec ("absoluteURI",
4454 "authority", "path-absolute", "port", "query", "relativeURI",
4455 "host) -- these will have to be updated when switching over to
4458 o Synchronize core rules with RFC5234.
4460 o Get rid of prose rules that span multiple lines.
4462 o Get rid of unused rules LOALPHA and UPALPHA.
4464 o Move "Product Tokens" section (back) into Part 1, as "token" is
4465 used in the definition of the Upgrade header.
4467 o Add explicit references to BNF syntax and rules imported from
4468 other parts of the specification.
4470 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
4479 Fielding, et al. Expires February 5, 2011 [Page 80]
4481 Internet-Draft HTTP/1.1, Part 1 August 2010
4484 D.4. Since draft-ietf-httpbis-p1-messaging-02
4488 o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
4491 o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
4494 Ongoing work on IANA Message Header Registration
4495 (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
4497 o Reference RFC 3984, and update header registrations for headers
4498 defined in this document.
4500 Ongoing work on ABNF conversion
4501 (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4503 o Replace string literals when the string really is case-sensitive
4506 D.5. Since draft-ietf-httpbis-p1-messaging-03
4510 o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4513 o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
4514 registrations and registry information to IANA Considerations"
4516 o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
4517 for PAD1995 reference"
4519 o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
4520 Considerations: update HTTP URI scheme registration"
4522 o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
4523 URI scheme definition"
4525 o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
4526 headers vs Set-Cookie"
4528 Ongoing work on ABNF conversion
4529 (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4535 Fielding, et al. Expires February 5, 2011 [Page 81]
4537 Internet-Draft HTTP/1.1, Part 1 August 2010
4540 o Replace string literals when the string really is case-sensitive
4543 o Replace HEX by HEXDIG for future consistence with RFC 5234's core
4546 D.6. Since draft-ietf-httpbis-p1-messaging-04
4550 o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
4553 o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
4554 updated by RFC 5322"
4556 Ongoing work on ABNF conversion
4557 (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4559 o Use "/" instead of "|" for alternatives.
4561 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4563 o Only reference RFC 5234's core rules.
4565 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4566 whitespace ("OWS") and required whitespace ("RWS").
4568 o Rewrite ABNFs to spell out whitespace rules, factor out header
4569 value format definitions.
4571 D.7. Since draft-ietf-httpbis-p1-messaging-05
4575 o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
4577 o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
4580 o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
4583 o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
4586 o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
4591 Fielding, et al. Expires February 5, 2011 [Page 82]
4593 Internet-Draft HTTP/1.1, Part 1 August 2010
4596 o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4599 o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
4602 o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
4604 o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
4605 "Differences Between HTTP Entities and RFC 2045 Entities"?"
4607 o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
4608 reference left in discussion of date formats"
4610 Final work on ABNF conversion
4611 (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4613 o Rewrite definition of list rules, deprecate empty list elements.
4615 o Add appendix containing collected and expanded ABNF.
4619 o Rewrite introduction; add mostly new Architecture Section.
4621 o Move definition of quality values from Part 3 into Part 1; make TE
4622 request header grammar independent of accept-params (defined in
4625 D.8. Since draft-ietf-httpbis-p1-messaging-06
4629 o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
4630 numeric protocol elements"
4632 o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
4634 Partly resolved issues:
4636 o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
4637 (took out language that implied that there might be methods for
4638 which a request body MUST NOT be included)
4640 o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
4641 improvements around HTTP-date"
4647 Fielding, et al. Expires February 5, 2011 [Page 83]
4649 Internet-Draft HTTP/1.1, Part 1 August 2010
4652 D.9. Since draft-ietf-httpbis-p1-messaging-07
4656 o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
4657 single-value headers"
4659 o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
4662 o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
4665 o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over
4666 HTTP Upgrade Token Registry"
4668 o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in
4669 chunk extension values"
4671 o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9
4674 o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
4675 policy (RFC5226) for Transfer Coding / Content Coding"
4677 o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
4678 definitions of gzip/deflate/compress to part 1"
4680 o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
4681 control characters in quoted-pair"
4683 Partly resolved issues:
4685 o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
4686 requirements wrt Transfer-Coding values" (add the IANA
4687 Considerations subsection)
4689 D.10. Since draft-ietf-httpbis-p1-messaging-08
4693 o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
4694 parsing, treatment of leading and trailing OWS"
4696 Partly resolved issues:
4698 o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
4703 Fielding, et al. Expires February 5, 2011 [Page 84]
4705 Internet-Draft HTTP/1.1, Part 1 August 2010
4708 o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4709 "word" when talking about header structure"
4711 D.11. Since draft-ietf-httpbis-p1-messaging-09
4715 o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
4716 of the term 'deflate'"
4718 o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4721 o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
4722 not listed in P1, general header fields"
4724 o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
4725 for content/transfer encodings"
4727 o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
4728 sensitivity of HTTP-date"
4730 o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4731 "word" when talking about header structure"
4733 Partly resolved issues:
4735 o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
4736 requested resource's URI"
4738 D.12. Since draft-ietf-httpbis-p1-messaging-10
4742 o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4745 o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
4746 messages with multipart/byteranges"
4748 o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4749 multiple Content-Length headers"
4751 o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
4752 entity / representation / variant terminology"
4754 o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
4755 removing the 'changes from 2068' sections"
4759 Fielding, et al. Expires February 5, 2011 [Page 85]
4761 Internet-Draft HTTP/1.1, Part 1 August 2010
4764 Partly resolved issues:
4766 o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4772 application/http Media Type 61
4780 chunked (Coding Format) 35
4787 compress (Coding Format) 38
4789 Connection header 49
4790 Content-Length header 50
4794 deflate (Coding Format) 38
4798 effective request URI 29
4815 Fielding, et al. Expires February 5, 2011 [Page 86]
4817 Internet-Draft HTTP/1.1, Part 1 August 2010
4871 Fielding, et al. Expires February 5, 2011 [Page 87]
4873 Internet-Draft HTTP/1.1, Part 1 August 2010
4897 received-protocol 57
4922 Transfer-Encoding 55
4923 Transfer-Encoding-v 55
4927 Fielding, et al. Expires February 5, 2011 [Page 88]
4929 Internet-Draft HTTP/1.1, Part 1 August 2010
4932 transfer-extension 34
4933 transfer-parameter 34
4945 gzip (Coding Format) 38
4957 Transfer-Encoding 55
4974 message/http Media Type 59
4983 Fielding, et al. Expires February 5, 2011 [Page 89]
4985 Internet-Draft HTTP/1.1, Part 1 August 2010
5005 Transfer-Encoding header 55
5021 Roy T. Fielding (editor)
5023 23 Corporate Plaza DR, Suite 280
5024 Newport Beach, CA 92660
5027 Phone: +1-949-706-5300
5028 Fax: +1-949-706-5305
5029 EMail: fielding@gbiv.com
5030 URI: http://roy.gbiv.com/
5039 Fielding, et al. Expires February 5, 2011 [Page 90]
5041 Internet-Draft HTTP/1.1, Part 1 August 2010
5045 Alcatel-Lucent Bell Labs
5050 EMail: jg@freedesktop.org
5051 URI: http://gettys.wordpress.com/
5055 Hewlett-Packard Company
5056 HP Labs, Large Scale Systems Group
5057 1501 Page Mill Road, MS 1177
5061 EMail: JeffMogul@acm.org
5064 Henrik Frystyk Nielsen
5065 Microsoft Corporation
5070 EMail: henrikn@microsoft.com
5074 Adobe Systems, Incorporated
5080 URI: http://larry.masinter.net/
5084 Microsoft Corporation
5088 EMail: paulle@microsoft.com
5095 Fielding, et al. Expires February 5, 2011 [Page 91]
5097 Internet-Draft HTTP/1.1, Part 1 August 2010
5101 World Wide Web Consortium
5102 MIT Computer Science and Artificial Intelligence Laboratory
5103 The Stata Center, Building 32
5109 URI: http://www.w3.org/People/Berners-Lee/
5113 World Wide Web Consortium
5115 2004, rte des Lucioles
5116 Sophia-Antipolis, AM 06902
5119 EMail: ylafon@w3.org
5120 URI: http://www.raubacapeu.net/people/yves/
5123 Julian F. Reschke (editor)
5129 Phone: +49 251 2807760
5130 Fax: +49 251 2807761
5131 EMail: julian.reschke@greenbytes.de
5132 URI: http://greenbytes.de/tech/webdav/
5151 Fielding, et al. Expires February 5, 2011 [Page 92]
projects / friendica-addons.git / blob