source: draft-ietf-httpbis/16/draft-ietf-httpbis-p1-messaging-16.txt @ 1831

Last change on this file since 1831 was 1401, checked in by julian.reschke@…, 9 years ago

prepare for publication of -16 on Aug 24.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 205.8 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2145,2616 (if approved)                             J. Gettys
7Updates: 2817 (if approved)                               Alcatel-Lucent
8Intended status: Standards Track                                J. Mogul
9Expires: February 25, 2012                                            HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                         August 24, 2011
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-16
27
28Abstract
29
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 and moves it to
36   historic status, along with its predecessor RFC 2068.
37
38   Part 1 provides an overview of HTTP and its associated terminology,
39   defines the "http" and "https" Uniform Resource Identifier (URI)
40   schemes, defines the generic message syntax and parsing requirements
41   for HTTP message frames, and describes general security concerns for
42   implementations.
43
44   This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817
45   (on using CONNECT for TLS upgrades) and moves them to historic
46   status.
47
48Editorial Note (To be removed by RFC Editor)
49
50   Discussion of this draft should take place on the HTTPBIS working
51   group mailing list (ietf-http-wg@w3.org), which is archived at
52
53
54
55Fielding, et al.        Expires February 25, 2012               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1                 August 2011
58
59
60   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
61
62   The current issues list is at
63   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
64   documents (including fancy diffs) can be found at
65   <http://tools.ietf.org/wg/httpbis/>.
66
67   The changes in this draft are summarized in Appendix C.17.
68
69Status of This Memo
70
71   This Internet-Draft is submitted in full conformance with the
72   provisions of BCP 78 and BCP 79.
73
74   Internet-Drafts are working documents of the Internet Engineering
75   Task Force (IETF).  Note that other groups may also distribute
76   working documents as Internet-Drafts.  The list of current Internet-
77   Drafts is at http://datatracker.ietf.org/drafts/current/.
78
79   Internet-Drafts are draft documents valid for a maximum of six months
80   and may be updated, replaced, or obsoleted by other documents at any
81   time.  It is inappropriate to use Internet-Drafts as reference
82   material or to cite them other than as "work in progress."
83
84   This Internet-Draft will expire on February 25, 2012.
85
86Copyright Notice
87
88   Copyright (c) 2011 IETF Trust and the persons identified as the
89   document authors.  All rights reserved.
90
91   This document is subject to BCP 78 and the IETF Trust's Legal
92   Provisions Relating to IETF Documents
93   (http://trustee.ietf.org/license-info) in effect on the date of
94   publication of this document.  Please review these documents
95   carefully, as they describe your rights and restrictions with respect
96   to this document.  Code Components extracted from this document must
97   include Simplified BSD License text as described in Section 4.e of
98   the Trust Legal Provisions and are provided without warranty as
99   described in the Simplified BSD License.
100
101   This document may contain material from IETF Documents or IETF
102   Contributions published or made publicly available before November
103   10, 2008.  The person(s) controlling the copyright in some of this
104   material may not have granted the IETF Trust the right to allow
105   modifications of such material outside the IETF Standards Process.
106   Without obtaining an adequate license from the person(s) controlling
107   the copyright in such materials, this document may not be modified
108
109
110
111Fielding, et al.        Expires February 25, 2012               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1                 August 2011
114
115
116   outside the IETF Standards Process, and derivative works of it may
117   not be created outside the IETF Standards Process, except to format
118   it for publication as an RFC or to translate it into languages other
119   than English.
120
121Table of Contents
122
123   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
124     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  7
125     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  7
126       1.2.1.  ABNF Extension: #rule  . . . . . . . . . . . . . . . .  7
127       1.2.2.  Basic Rules  . . . . . . . . . . . . . . . . . . . . .  8
128   2.  HTTP-related architecture  . . . . . . . . . . . . . . . . . .  9
129     2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  9
130     2.2.  Message Orientation and Buffering  . . . . . . . . . . . . 11
131     2.3.  Connections and Transport Independence . . . . . . . . . . 11
132     2.4.  Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
133     2.5.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
134     2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 15
135     2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
136       2.7.1.  http URI scheme  . . . . . . . . . . . . . . . . . . . 18
137       2.7.2.  https URI scheme . . . . . . . . . . . . . . . . . . . 19
138       2.7.3.  http and https URI Normalization and Comparison  . . . 20
139   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20
140     3.1.  Message Parsing and Robustness . . . . . . . . . . . . . . 21
141     3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
142       3.2.1.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 23
143       3.2.2.  Field Length . . . . . . . . . . . . . . . . . . . . . 24
144       3.2.3.  Common Field ABNF Rules  . . . . . . . . . . . . . . . 24
145     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 25
146     3.4.  Incomplete Messages  . . . . . . . . . . . . . . . . . . . 28
147     3.5.  General Header Fields  . . . . . . . . . . . . . . . . . . 29
148   4.  Request  . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
149     4.1.  Request-Line . . . . . . . . . . . . . . . . . . . . . . . 30
150       4.1.1.  Method . . . . . . . . . . . . . . . . . . . . . . . . 30
151       4.1.2.  request-target . . . . . . . . . . . . . . . . . . . . 30
152     4.2.  The Resource Identified by a Request . . . . . . . . . . . 32
153     4.3.  Effective Request URI  . . . . . . . . . . . . . . . . . . 33
154   5.  Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
155     5.1.  Status-Line  . . . . . . . . . . . . . . . . . . . . . . . 34
156       5.1.1.  Status Code and Reason Phrase  . . . . . . . . . . . . 35
157   6.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 35
158     6.1.  Date/Time Formats: Full Date . . . . . . . . . . . . . . . 35
159     6.2.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . 38
160       6.2.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . 39
161       6.2.2.  Compression Codings  . . . . . . . . . . . . . . . . . 41
162       6.2.3.  Transfer Coding Registry . . . . . . . . . . . . . . . 42
163     6.3.  Product Tokens . . . . . . . . . . . . . . . . . . . . . . 43
164
165
166
167Fielding, et al.        Expires February 25, 2012               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1                 August 2011
170
171
172     6.4.  Quality Values . . . . . . . . . . . . . . . . . . . . . . 43
173   7.  Connections  . . . . . . . . . . . . . . . . . . . . . . . . . 43
174     7.1.  Persistent Connections . . . . . . . . . . . . . . . . . . 44
175       7.1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . 44
176       7.1.2.  Overall Operation  . . . . . . . . . . . . . . . . . . 44
177       7.1.3.  Proxy Servers  . . . . . . . . . . . . . . . . . . . . 46
178       7.1.4.  Practical Considerations . . . . . . . . . . . . . . . 48
179     7.2.  Message Transmission Requirements  . . . . . . . . . . . . 49
180       7.2.1.  Persistent Connections and Flow Control  . . . . . . . 49
181       7.2.2.  Monitoring Connections for Error Status Messages . . . 50
182       7.2.3.  Use of the 100 (Continue) Status . . . . . . . . . . . 50
183       7.2.4.  Client Behavior if Server Prematurely Closes
184               Connection . . . . . . . . . . . . . . . . . . . . . . 52
185   8.  Miscellaneous notes that might disappear . . . . . . . . . . . 53
186     8.1.  Scheme aliases considered harmful  . . . . . . . . . . . . 53
187     8.2.  Use of HTTP for proxy communication  . . . . . . . . . . . 53
188     8.3.  Interception of HTTP for access control  . . . . . . . . . 53
189     8.4.  Use of HTTP by other protocols . . . . . . . . . . . . . . 53
190     8.5.  Use of HTTP by media type specification  . . . . . . . . . 53
191   9.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 53
192     9.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 53
193     9.2.  Content-Length . . . . . . . . . . . . . . . . . . . . . . 55
194     9.3.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
195       9.3.1.  Clockless Origin Server Operation  . . . . . . . . . . 56
196     9.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
197     9.5.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
198     9.6.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 59
199     9.7.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . . . 59
200     9.8.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 60
201       9.8.1.  Upgrade Token Registry . . . . . . . . . . . . . . . . 61
202     9.9.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
203   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 63
204     10.1. Header Field Registration  . . . . . . . . . . . . . . . . 63
205     10.2. URI Scheme Registration  . . . . . . . . . . . . . . . . . 64
206     10.3. Internet Media Type Registrations  . . . . . . . . . . . . 64
207       10.3.1. Internet Media Type message/http . . . . . . . . . . . 64
208       10.3.2. Internet Media Type application/http . . . . . . . . . 66
209     10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 67
210     10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 67
211   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 67
212     11.1. Personal Information . . . . . . . . . . . . . . . . . . . 68
213     11.2. Abuse of Server Log Information  . . . . . . . . . . . . . 68
214     11.3. Attacks Based On File and Path Names . . . . . . . . . . . 68
215     11.4. DNS-related Attacks  . . . . . . . . . . . . . . . . . . . 68
216     11.5. Proxies and Caching  . . . . . . . . . . . . . . . . . . . 69
217     11.6. Protocol Element Size Overflows  . . . . . . . . . . . . . 69
218     11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 70
219   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
220
221
222
223Fielding, et al.        Expires February 25, 2012               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1                 August 2011
226
227
228   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
229     13.1. Normative References . . . . . . . . . . . . . . . . . . . 70
230     13.2. Informative References . . . . . . . . . . . . . . . . . . 72
231   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 74
232     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 75
233       A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 75
234       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 75
235     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 76
236   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 77
237   Appendix C.  Change Log (to be removed by RFC Editor before
238                publication)  . . . . . . . . . . . . . . . . . . . . 81
239     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81
240     C.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81
241     C.3.  Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83
242     C.4.  Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84
243     C.5.  Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84
244     C.6.  Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85
245     C.7.  Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85
246     C.8.  Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86
247     C.9.  Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87
248     C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87
249     C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88
250     C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88
251     C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89
252     C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89
253     C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90
254     C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 90
255     C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 90
256   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279Fielding, et al.        Expires February 25, 2012               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1                 August 2011
282
283
2841.  Introduction
285
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 the target resource
291   and 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).
295
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.
305
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.
312
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.
322
323   This document is Part 1 of the seven-part specification of HTTP,
324   defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]
325   and [RFC2145].  Part 1 describes the architectural elements that are
326   used or referred to in HTTP, defines the "http" and "https" URI
327   schemes, describes overall network operation and connection
328   management, and defines HTTP message framing and forwarding
329   requirements.  Our goal is to define all of the mechanisms necessary
330   for HTTP message handling that are independent of message semantics,
331   thereby defining the complete set of requirements for message parsers
332
333
334
335Fielding, et al.        Expires February 25, 2012               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1                 August 2011
338
339
340   and message-forwarding intermediaries.
341
3421.1.  Requirements
343
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].
347
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
355   compliant".
356
3571.2.  Syntax Notation
358
359   This specification uses the Augmented Backus-Naur Form (ABNF)
360   notation of [RFC5234].
361
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).
368
369   As a syntactic convention, ABNF rule names prefixed with "obs-"
370   denote "obsolete" grammar rules that appear for historical reasons.
371
3721.2.1.  ABNF Extension: #rule
373
374   The #rule extension to the ABNF rules of [RFC5234] is used to improve
375   readability.
376
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).
381
382   Thus,
383
384     1#element => element *( OWS "," OWS element )
385
386
387
388
389
390
391Fielding, et al.        Expires February 25, 2012               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1                 August 2011
394
395
396   and:
397
398     #element => [ 1#element ]
399
400   and for n >= 1 and m > 1:
401
402     <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
403
404   For compatibility with legacy list rules, recipients SHOULD accept
405   empty list elements.  In other words, consumers would follow the list
406   productions:
407
408     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
409
410     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
411
412   Note that empty elements do not contribute to the count of elements
413   present, though.
414
415   For example, given these ABNF productions:
416
417     example-list      = 1#example-list-elmt
418     example-list-elmt = token ; see Section 3.2.3
419
420   Then these are valid values for example-list (not including the
421   double quotes, which are present for delimitation only):
422
423     "foo,bar"
424     " foo ,bar,"
425     "  foo , ,bar,charlie   "
426     "foo ,bar,   charlie "
427
428   But these values would be invalid, as at least one non-empty element
429   is required:
430
431     ""
432     ","
433     ",   ,"
434
435   Appendix B shows the collected ABNF, with the list rules expanded as
436   explained above.
437
4381.2.2.  Basic Rules
439
440   This specification uses three rules to denote the use of linear
441   whitespace: OWS (optional whitespace), RWS (required whitespace), and
442   BWS ("bad" whitespace).
443
444
445
446
447Fielding, et al.        Expires February 25, 2012               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1                 August 2011
450
451
452   The OWS rule is used where zero or more linear whitespace octets
453   might appear.  OWS SHOULD either not be produced or be produced as a
454   single SP.  Multiple OWS octets that occur within field-content
455   SHOULD either be replaced with a single SP or transformed to all SP
456   octets (each WSP octet other than SP replaced with SP) before
457   interpreting the field value or forwarding the message downstream.
458
459   RWS is used when at least one linear whitespace octet is required to
460   separate field tokens.  RWS SHOULD be produced as a single SP.
461   Multiple RWS octets octets that occur within field-content SHOULD
462   either be replaced with a single SP or transformed to all SP octets
463   (each WSP octet other than SP replaced with SP) before interpreting
464   the field value or forwarding the message downstream.
465
466   BWS is used where the grammar allows optional whitespace for
467   historical reasons but senders SHOULD NOT produce it in messages.
468   HTTP/1.1 recipients MUST accept such bad optional whitespace and
469   remove it before interpreting the field value or forwarding the
470   message downstream.
471
472
473     OWS            = *( [ obs-fold ] WSP )
474                    ; "optional" whitespace
475     RWS            = 1*( [ obs-fold ] WSP )
476                    ; "required" whitespace
477     BWS            = OWS
478                    ; "bad" whitespace
479     obs-fold       = CRLF
480                    ; see Section 3.2
481
4822.  HTTP-related architecture
483
484   HTTP was created for the World Wide Web architecture and has evolved
485   over time to support the scalability needs of a worldwide hypertext
486   system.  Much of that architecture is reflected in the terminology
487   and syntax productions used to define HTTP.
488
4892.1.  Client/Server Messaging
490
491   HTTP is a stateless request/response protocol that operates by
492   exchanging messages across a reliable transport or session-layer
493   "connection".  An HTTP "client" is a program that establishes a
494   connection to a server for the purpose of sending one or more HTTP
495   requests.  An HTTP "server" is a program that accepts connections in
496   order to service HTTP requests by sending HTTP responses.
497
498   Note that the terms client and server refer only to the roles that
499   these programs perform for a particular connection.  The same program
500
501
502
503Fielding, et al.        Expires February 25, 2012               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1                 August 2011
506
507
508   might act as a client on some connections and a server on others.  We
509   use the term "user agent" to refer to the program that initiates a
510   request, such as a WWW browser, editor, or spider (web-traversing
511   robot), and the term "origin server" to refer to the program that can
512   originate authoritative responses to a request.  For general
513   requirements, we use the term "sender" to refer to whichever
514   component sent a given message and the term "recipient" to refer to
515   any component that receives the message.
516
517   Most HTTP communication consists of a retrieval request (GET) for a
518   representation of some resource identified by a URI.  In the simplest
519   case, this might be accomplished via a single bidirectional
520   connection (===) between the user agent (UA) and the origin server
521   (O).
522
523            request   >
524       UA ======================================= O
525                                   <   response
526
527   A client sends an HTTP request to the server in the form of a request
528   message (Section 4), beginning with a method, URI, and protocol
529   version, followed by MIME-like header fields containing request
530   modifiers, client information, and payload metadata, an empty line to
531   indicate the end of the header section, and finally the payload body
532   (if any).
533
534   A server responds to the client's request by sending an HTTP response
535   message (Section 5), beginning with a status line that includes the
536   protocol version, a success or error code, and textual reason phrase,
537   followed by MIME-like header fields containing server information,
538   resource metadata, and payload metadata, an empty line to indicate
539   the end of the header section, and finally the payload body (if any).
540
541   The following example illustrates a typical message exchange for a
542   GET request on the URI "http://www.example.com/hello.txt":
543
544   client request:
545
546     GET /hello.txt HTTP/1.1
547     User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
548     Host: www.example.com
549     Accept: */*
550
551
552
553
554
555
556
557
558
559Fielding, et al.        Expires February 25, 2012              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1                 August 2011
562
563
564   server response:
565
566     HTTP/1.1 200 OK
567     Date: Mon, 27 Jul 2009 12:28:53 GMT
568     Server: Apache
569     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
570     ETag: "34aa387-d-1568eb00"
571     Accept-Ranges: bytes
572     Content-Length: 14
573     Vary: Accept-Encoding
574     Content-Type: text/plain
575
576     Hello World!
577
5782.2.  Message Orientation and Buffering
579
580   Fundamentally, HTTP is a message-based protocol.  Although message
581   bodies can be chunked (Section 6.2.1) and implementations often make
582   parts of a message available progressively, this is not required, and
583   some widely-used implementations only make a message available when
584   it is complete.  Furthermore, while most proxies will progressively
585   stream messages, some amount of buffering will take place, and some
586   proxies might buffer messages to perform transformations, check
587   content or provide other services.
588
589   Therefore, extensions to and uses of HTTP cannot rely on the
590   availability of a partial message, or assume that messages will not
591   be buffered.  There are strategies that can be used to test for
592   buffering in a given connection, but it should be understood that
593   behaviors can differ across connections, and between requests and
594   responses.
595
596   Recipients MUST consider every message in a connection in isolation;
597   because HTTP is a stateless protocol, it cannot be assumed that two
598   requests on the same connection are from the same client or share any
599   other common attributes.  In particular, intermediaries might mix
600   requests from different clients into a single server connection.
601   Note that some existing HTTP extensions (e.g., [RFC4559]) violate
602   this requirement, thereby potentially causing interoperability and
603   security problems.
604
6052.3.  Connections and Transport Independence
606
607   HTTP messaging is independent of the underlying transport or session-
608   layer connection protocol(s).  HTTP only presumes a reliable
609   transport with in-order delivery of requests and the corresponding
610   in-order delivery of responses.  The mapping of HTTP request and
611   response structures onto the data units of the underlying transport
612
613
614
615Fielding, et al.        Expires February 25, 2012              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1                 August 2011
618
619
620   protocol is outside the scope of this specification.
621
622   The specific connection protocols to be used for an interaction are
623   determined by client configuration and the target resource's URI.
624   For example, the "http" URI scheme (Section 2.7.1) indicates a
625   default connection of TCP over IP, with a default TCP port of 80, but
626   the client might be configured to use a proxy via some other
627   connection port or protocol instead of using the defaults.
628
629   A connection might be used for multiple HTTP request/response
630   exchanges, as defined in Section 7.1.
631
6322.4.  Intermediaries
633
634   HTTP enables the use of intermediaries to satisfy requests through a
635   chain of connections.  There are three common forms of HTTP
636   intermediary: proxy, gateway, and tunnel.  In some cases, a single
637   intermediary might act as an origin server, proxy, gateway, or
638   tunnel, switching behavior based on the nature of each request.
639
640            >             >             >             >
641       UA =========== A =========== B =========== C =========== O
642                  <             <             <             <
643
644   The figure above shows three intermediaries (A, B, and C) between the
645   user agent and origin server.  A request or response message that
646   travels the whole chain will pass through four separate connections.
647   Some HTTP communication options might apply only to the connection
648   with the nearest, non-tunnel neighbor, only to the end-points of the
649   chain, or to all connections along the chain.  Although the diagram
650   is linear, each participant might be engaged in multiple,
651   simultaneous communications.  For example, B might be receiving
652   requests from many clients other than A, and/or forwarding requests
653   to servers other than C, at the same time that it is handling A's
654   request.
655
656   We use the terms "upstream" and "downstream" to describe various
657   requirements in relation to the directional flow of a message: all
658   messages flow from upstream to downstream.  Likewise, we use the
659   terms inbound and outbound to refer to directions in relation to the
660   request path: "inbound" means toward the origin server and "outbound"
661   means toward the user agent.
662
663   A "proxy" is a message forwarding agent that is selected by the
664   client, usually via local configuration rules, to receive requests
665   for some type(s) of absolute URI and attempt to satisfy those
666   requests via translation through the HTTP interface.  Some
667   translations are minimal, such as for proxy requests for "http" URIs,
668
669
670
671Fielding, et al.        Expires February 25, 2012              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1                 August 2011
674
675
676   whereas other requests might require translation to and from entirely
677   different application-layer protocols.  Proxies are often used to
678   group an organization's HTTP requests through a common intermediary
679   for the sake of security, annotation services, or shared caching.
680
681   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
682   designed or configured to modify request or response messages in a
683   semantically meaningful way (i.e., modifications, beyond those
684   required by normal HTTP processing, that change the message in a way
685   that would be significant to the original sender or potentially
686   significant to downstream recipients).  For example, a transforming
687   proxy might be acting as a shared annotation server (modifying
688   responses to include references to a local annotation database), a
689   malware filter, a format transcoder, or an intranet-to-Internet
690   privacy filter.  Such transformations are presumed to be desired by
691   the client (or client organization) that selected the proxy and are
692   beyond the scope of this specification.  However, when a proxy is not
693   intended to transform a given message, we use the term "non-
694   transforming proxy" to target requirements that preserve HTTP message
695   semantics.  See Section 8.2.4 of [Part2] and Section 3.6 of [Part6]
696   for status and warning codes related to transformations.
697
698   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
699   as a layer above some other server(s) and translates the received
700   requests to the underlying server's protocol.  Gateways are often
701   used to encapsulate legacy or untrusted information services, to
702   improve server performance through "accelerator" caching, and to
703   enable partitioning or load-balancing of HTTP services across
704   multiple machines.
705
706   A gateway behaves as an origin server on its outbound connection and
707   as a user agent on its inbound connection.  All HTTP requirements
708   applicable to an origin server also apply to the outbound
709   communication of a gateway.  A gateway communicates with inbound
710   servers using any protocol that it desires, including private
711   extensions to HTTP that are outside the scope of this specification.
712   However, an HTTP-to-HTTP gateway that wishes to interoperate with
713   third-party HTTP servers MUST comply with HTTP user agent
714   requirements on the gateway's inbound connection and MUST implement
715   the Connection (Section 9.1) and Via (Section 9.9) header fields for
716   both connections.
717
718   A "tunnel" acts as a blind relay between two connections without
719   changing the messages.  Once active, a tunnel is not considered a
720   party to the HTTP communication, though the tunnel might have been
721   initiated by an HTTP request.  A tunnel ceases to exist when both
722   ends of the relayed connection are closed.  Tunnels are used to
723   extend a virtual connection through an intermediary, such as when
724
725
726
727Fielding, et al.        Expires February 25, 2012              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1                 August 2011
730
731
732   transport-layer security is used to establish private communication
733   through a shared firewall proxy.
734
735   In addition, there may exist network intermediaries that are not
736   considered part of the HTTP communication but nevertheless act as
737   filters or redirecting agents (usually violating HTTP semantics,
738   causing security problems, and otherwise making a mess of things).
739   Such a network intermediary, often referred to as an "interception
740   proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal",
741   differs from an HTTP proxy because it has not been selected by the
742   client.  Instead, the network intermediary redirects outgoing TCP
743   port 80 packets (and occasionally other common port traffic) to an
744   internal HTTP server.  Interception proxies are commonly found on
745   public network access points, as a means of enforcing account
746   subscription prior to allowing use of non-local Internet services,
747   and within corporate firewalls to enforce network usage policies.
748   They are indistinguishable from a man-in-the-middle attack.
749
7502.5.  Caches
751
752   A "cache" is a local store of previous response messages and the
753   subsystem that controls its message storage, retrieval, and deletion.
754   A cache stores cacheable responses in order to reduce the response
755   time and network bandwidth consumption on future, equivalent
756   requests.  Any client or server MAY employ a cache, though a cache
757   cannot be used by a server while it is acting as a tunnel.
758
759   The effect of a cache is that the request/response chain is shortened
760   if one of the participants along the chain has a cached response
761   applicable to that request.  The following illustrates the resulting
762   chain if B has a cached copy of an earlier response from O (via C)
763   for a request which has not been cached by UA or A.
764
765               >             >
766          UA =========== A =========== B - - - - - - C - - - - - - O
767                     <             <
768
769   A response is "cacheable" if a cache is allowed to store a copy of
770   the response message for use in answering subsequent requests.  Even
771   when a response is cacheable, there might be additional constraints
772   placed by the client or by the origin server on when that cached
773   response can be used for a particular request.  HTTP requirements for
774   cache behavior and cacheable responses are defined in Section 2 of
775   [Part6].
776
777   There are a wide variety of architectures and configurations of
778   caches and proxies deployed across the World Wide Web and inside
779   large organizations.  These systems include national hierarchies of
780
781
782
783Fielding, et al.        Expires February 25, 2012              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1                 August 2011
786
787
788   proxy caches to save transoceanic bandwidth, systems that broadcast
789   or multicast cache entries, organizations that distribute subsets of
790   cached data via optical media, and so on.
791
7922.6.  Protocol Versioning
793
794   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
795   of the protocol.  This specification defines version "1.1".  The
796   protocol version as a whole indicates the sender's compliance with
797   the set of requirements laid out in that version's corresponding
798   specification of HTTP.
799
800   The version of an HTTP message is indicated by an HTTP-Version field
801   in the first line of the message.  HTTP-Version is case-sensitive.
802
803     HTTP-Version   = HTTP-Prot-Name "/" DIGIT "." DIGIT
804     HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
805
806   The HTTP version number consists of two decimal digits separated by a
807   "." (period or decimal point).  The first digit ("major version")
808   indicates the HTTP messaging syntax, whereas the second digit ("minor
809   version") indicates the highest minor version to which the sender is
810   at least conditionally compliant and able to understand for future
811   communication.  The minor version advertises the sender's
812   communication capabilities even when the sender is only using a
813   backwards-compatible subset of the protocol, thereby letting the
814   recipient know that more advanced features can be used in response
815   (by servers) or in future requests (by clients).
816
817   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
818   or a recipient whose version is unknown, the HTTP/1.1 message is
819   constructed such that it can be interpreted as a valid HTTP/1.0
820   message if all of the newer features are ignored.  This specification
821   places recipient-version requirements on some new features so that a
822   compliant sender will only use compatible features until it has
823   determined, through configuration or the receipt of a message, that
824   the recipient supports HTTP/1.1.
825
826   The interpretation of an HTTP header field does not change between
827   minor versions of the same major version, though the default behavior
828   of a recipient in the absence of such a field can change.  Unless
829   specified otherwise, header fields defined in HTTP/1.1 are defined
830   for all versions of HTTP/1.x.  In particular, the Host and Connection
831   header fields ought to be implemented by all HTTP/1.x implementations
832   whether or not they advertise compliance with HTTP/1.1.
833
834   New header fields can be defined such that, when they are understood
835   by a recipient, they might override or enhance the interpretation of
836
837
838
839Fielding, et al.        Expires February 25, 2012              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1                 August 2011
842
843
844   previously defined header fields.  When an implementation receives an
845   unrecognized header field, the recipient MUST ignore that header
846   field for local processing regardless of the message's HTTP version.
847   An unrecognized header field received by a proxy MUST be forwarded
848   downstream unless the header field's field-name is listed in the
849   message's Connection header-field (see Section 9.1).  These
850   requirements allow HTTP's functionality to be enhanced without
851   requiring prior update of all compliant intermediaries.
852
853   Intermediaries that process HTTP messages (i.e., all intermediaries
854   other than those acting as a tunnel) MUST send their own HTTP-Version
855   in forwarded messages.  In other words, they MUST NOT blindly forward
856   the first line of an HTTP message without ensuring that the protocol
857   version matches what the intermediary understands, and is at least
858   conditionally compliant to, for both the receiving and sending of
859   messages.  Forwarding an HTTP message without rewriting the HTTP-
860   Version might result in communication errors when downstream
861   recipients use the message sender's version to determine what
862   features are safe to use for later communication with that sender.
863
864   An HTTP client SHOULD send a request version equal to the highest
865   version for which the client is at least conditionally compliant and
866   whose major version is no higher than the highest version supported
867   by the server, if this is known.  An HTTP client MUST NOT send a
868   version for which it is not at least conditionally compliant.
869
870   An HTTP client MAY send a lower request version if it is known that
871   the server incorrectly implements the HTTP specification, but only
872   after the client has attempted at least one normal request and
873   determined from the response status or header fields (e.g., Server)
874   that the server improperly handles higher request versions.
875
876   An HTTP server SHOULD send a response version equal to the highest
877   version for which the server is at least conditionally compliant and
878   whose major version is less than or equal to the one received in the
879   request.  An HTTP server MUST NOT send a version for which it is not
880   at least conditionally compliant.  A server MAY send a 505 (HTTP
881   Version Not Supported) response if it cannot send a response using
882   the major version used in the client's request.
883
884   An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
885   if it is known or suspected that the client incorrectly implements
886   the HTTP specification and is incapable of correctly processing later
887   version responses, such as when a client fails to parse the version
888   number correctly or when an intermediary is known to blindly forward
889   the HTTP-Version even when it doesn't comply with the given minor
890   version of the protocol.  Such protocol downgrades SHOULD NOT be
891   performed unless triggered by specific client attributes, such as
892
893
894
895Fielding, et al.        Expires February 25, 2012              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1                 August 2011
898
899
900   when one or more of the request header fields (e.g., User-Agent)
901   uniquely match the values sent by a client known to be in error.
902
903   The intention of HTTP's versioning design is that the major number
904   will only be incremented if an incompatible message syntax is
905   introduced, and that the minor number will only be incremented when
906   changes made to the protocol have the effect of adding to the message
907   semantics or implying additional capabilities of the sender.
908   However, the minor version was not incremented for the changes
909   introduced between [RFC2068] and [RFC2616], and this revision is
910   specifically avoiding any such changes to the protocol.
911
9122.7.  Uniform Resource Identifiers
913
914   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
915   HTTP as the means for identifying resources.  URI references are used
916   to target requests, indicate redirects, and define relationships.
917   HTTP does not limit what a resource might be; it merely defines an
918   interface that can be used to interact with a resource via HTTP.
919   More information on the scope of URIs and resources can be found in
920   [RFC3986].
921
922   This specification adopts the definitions of "URI-reference",
923   "absolute-URI", "relative-part", "port", "host", "path-abempty",
924   "path-absolute", "query", and "authority" from the URI generic syntax
925   [RFC3986].  In addition, we define a partial-URI rule for protocol
926   elements that allow a relative URI but not a fragment.
927
928     URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
929     absolute-URI  = <absolute-URI, defined in [RFC3986], Section 4.3>
930     relative-part = <relative-part, defined in [RFC3986], Section 4.2>
931     authority     = <authority, defined in [RFC3986], Section 3.2>
932     path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
933     path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
934     port          = <port, defined in [RFC3986], Section 3.2.3>
935     query         = <query, defined in [RFC3986], Section 3.4>
936     uri-host      = <host, defined in [RFC3986], Section 3.2.2>
937
938     partial-URI   = relative-part [ "?" query ]
939
940   Each protocol element in HTTP that allows a URI reference will
941   indicate in its ABNF production whether the element allows any form
942   of reference (URI-reference), only a URI in absolute form (absolute-
943   URI), only the path and optional query components, or some
944   combination of the above.  Unless otherwise indicated, URI references
945   are parsed relative to the effective request URI, which defines the
946   default base URI for references in both the request and its
947   corresponding response.
948
949
950
951Fielding, et al.        Expires February 25, 2012              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1                 August 2011
954
955
9562.7.1.  http URI scheme
957
958   The "http" URI scheme is hereby defined for the purpose of minting
959   identifiers according to their association with the hierarchical
960   namespace governed by a potential HTTP origin server listening for
961   TCP connections on a given port.
962
963     http-URI = "http:" "//" authority path-abempty [ "?" query ]
964
965   The HTTP origin server is identified by the generic syntax's
966   authority component, which includes a host identifier and optional
967   TCP port ([RFC3986], Section 3.2.2).  The remainder of the URI,
968   consisting of both the hierarchical path component and optional query
969   component, serves as an identifier for a potential resource within
970   that origin server's name space.
971
972   If the host identifier is provided as an IP literal or IPv4 address,
973   then the origin server is any listener on the indicated TCP port at
974   that IP address.  If host is a registered name, then that name is
975   considered an indirect identifier and the recipient might use a name
976   resolution service, such as DNS, to find the address of a listener
977   for that host.  The host MUST NOT be empty; if an "http" URI is
978   received with an empty host, then it MUST be rejected as invalid.  If
979   the port subcomponent is empty or not given, then TCP port 80 is
980   assumed (the default reserved port for WWW services).
981
982   Regardless of the form of host identifier, access to that host is not
983   implied by the mere presence of its name or address.  The host might
984   or might not exist and, even when it does exist, might or might not
985   be running an HTTP server or listening to the indicated port.  The
986   "http" URI scheme makes use of the delegated nature of Internet names
987   and addresses to establish a naming authority (whatever entity has
988   the ability to place an HTTP server at that Internet name or address)
989   and allows that authority to determine which names are valid and how
990   they might be used.
991
992   When an "http" URI is used within a context that calls for access to
993   the indicated resource, a client MAY attempt access by resolving the
994   host to an IP address, establishing a TCP connection to that address
995   on the indicated port, and sending an HTTP request message to the
996   server containing the URI's identifying data as described in
997   Section 4.  If the server responds to that request with a non-interim
998   HTTP response message, as described in Section 5, then that response
999   is considered an authoritative answer to the client's request.
1000
1001   Although HTTP is independent of the transport protocol, the "http"
1002   scheme is specific to TCP-based services because the name delegation
1003   process depends on TCP for establishing authority.  An HTTP service
1004
1005
1006
1007Fielding, et al.        Expires February 25, 2012              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1                 August 2011
1010
1011
1012   based on some other underlying connection protocol would presumably
1013   be identified using a different URI scheme, just as the "https"
1014   scheme (below) is used for servers that require an SSL/TLS transport
1015   layer on a connection.  Other protocols might also be used to provide
1016   access to "http" identified resources -- it is only the authoritative
1017   interface used for mapping the namespace that is specific to TCP.
1018
1019   The URI generic syntax for authority also includes a deprecated
1020   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
1021   authentication information in the URI.  Some implementations make use
1022   of the userinfo component for internal configuration of
1023   authentication information, such as within command invocation
1024   options, configuration files, or bookmark lists, even though such
1025   usage might expose a user identifier or password.  Senders MUST NOT
1026   include a userinfo subcomponent (and its "@" delimiter) when
1027   transmitting an "http" URI in a message.  Recipients of HTTP messages
1028   that contain a URI reference SHOULD parse for the existence of
1029   userinfo and treat its presence as an error, likely indicating that
1030   the deprecated subcomponent is being used to obscure the authority
1031   for the sake of phishing attacks.
1032
10332.7.2.  https URI scheme
1034
1035   The "https" URI scheme is hereby defined for the purpose of minting
1036   identifiers according to their association with the hierarchical
1037   namespace governed by a potential HTTP origin server listening for
1038   SSL/TLS-secured connections on a given TCP port.
1039
1040   All of the requirements listed above for the "http" scheme are also
1041   requirements for the "https" scheme, except that a default TCP port
1042   of 443 is assumed if the port subcomponent is empty or not given, and
1043   the TCP connection MUST be secured for privacy through the use of
1044   strong encryption prior to sending the first HTTP request.
1045
1046     https-URI = "https:" "//" authority path-abempty [ "?" query ]
1047
1048   Unlike the "http" scheme, responses to "https" identified requests
1049   are never "public" and thus MUST NOT be reused for shared caching.
1050   They can, however, be reused in a private cache if the message is
1051   cacheable by default in HTTP or specifically indicated as such by the
1052   Cache-Control header field (Section 3.2 of [Part6]).
1053
1054   Resources made available via the "https" scheme have no shared
1055   identity with the "http" scheme even if their resource identifiers
1056   indicate the same authority (the same host listening to the same TCP
1057   port).  They are distinct name spaces and are considered to be
1058   distinct origin servers.  However, an extension to HTTP that is
1059   defined to apply to entire host domains, such as the Cookie protocol
1060
1061
1062
1063Fielding, et al.        Expires February 25, 2012              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1                 August 2011
1066
1067
1068   [RFC6265], can allow information set by one service to impact
1069   communication with other services within a matching group of host
1070   domains.
1071
1072   The process for authoritative access to an "https" identified
1073   resource is defined in [RFC2818].
1074
10752.7.3.  http and https URI Normalization and Comparison
1076
1077   Since the "http" and "https" schemes conform to the URI generic
1078   syntax, such URIs are normalized and compared according to the
1079   algorithm defined in [RFC3986], Section 6, using the defaults
1080   described above for each scheme.
1081
1082   If the port is equal to the default port for a scheme, the normal
1083   form is to elide the port subcomponent.  Likewise, an empty path
1084   component is equivalent to an absolute path of "/", so the normal
1085   form is to provide a path of "/" instead.  The scheme and host are
1086   case-insensitive and normally provided in lowercase; all other
1087   components are compared in a case-sensitive manner.  Characters other
1088   than those in the "reserved" set are equivalent to their percent-
1089   encoded octets (see [RFC3986], Section 2.1): the normal form is to
1090   not encode them.
1091
1092   For example, the following three URIs are equivalent:
1093
1094      http://example.com:80/~smith/home.html
1095      http://EXAMPLE.com/%7Esmith/home.html
1096      http://EXAMPLE.com:/%7esmith/home.html
1097
10983.  Message Format
1099
1100   All HTTP/1.1 messages consist of a start-line followed by a sequence
1101   of octets in a format similar to the Internet Message Format
1102   [RFC5322]: zero or more header fields (collectively referred to as
1103   the "headers" or the "header section"), an empty line indicating the
1104   end of the header section, and an optional message-body.
1105
1106   An HTTP message can either be a request from client to server or a
1107   response from server to client.  Syntactically, the two types of
1108   message differ only in the start-line, which is either a Request-Line
1109   (for requests) or a Status-Line (for responses), and in the algorithm
1110   for determining the length of the message-body (Section 3.3).  In
1111   theory, a client could receive requests and a server could receive
1112   responses, distinguishing them by their different start-line formats,
1113   but in practice servers are implemented to only expect a request (a
1114   response is interpreted as an unknown or invalid request method) and
1115   clients are implemented to only expect a response.
1116
1117
1118
1119Fielding, et al.        Expires February 25, 2012              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1                 August 2011
1122
1123
1124     HTTP-message    = start-line
1125                       *( header-field CRLF )
1126                       CRLF
1127                       [ message-body ]
1128     start-line      = Request-Line / Status-Line
1129
1130   Implementations MUST NOT send whitespace between the start-line and
1131   the first header field.  The presence of such whitespace in a request
1132   might be an attempt to trick a server into ignoring that field or
1133   processing the line after it as a new request, either of which might
1134   result in a security vulnerability if other implementations within
1135   the request chain interpret the same message differently.  Likewise,
1136   the presence of such whitespace in a response might be ignored by
1137   some clients or cause others to cease parsing.
1138
11393.1.  Message Parsing and Robustness
1140
1141   The normal procedure for parsing an HTTP message is to read the
1142   start-line into a structure, read each header field into a hash table
1143   by field name until the empty line, and then use the parsed data to
1144   determine if a message-body is expected.  If a message-body has been
1145   indicated, then it is read as a stream until an amount of octets
1146   equal to the message-body length is read or the connection is closed.
1147
1148   Care must be taken to parse an HTTP message as a sequence of octets
1149   in an encoding that is a superset of US-ASCII.  Attempting to parse
1150   HTTP as a stream of Unicode characters in a character encoding like
1151   UTF-16 might introduce security flaws due to the differing ways that
1152   such parsers interpret invalid characters.
1153
1154   Older HTTP/1.0 client implementations might send an extra CRLF after
1155   a POST request as a lame workaround for some early server
1156   applications that failed to read message-body content that was not
1157   terminated by a line-ending.  An HTTP/1.1 client MUST NOT preface or
1158   follow a request with an extra CRLF.  If terminating the request
1159   message-body with a line-ending is desired, then the client MUST
1160   include the terminating CRLF octets as part of the message-body
1161   length.
1162
1163   In the interest of robustness, servers SHOULD ignore at least one
1164   empty line received where a Request-Line is expected.  In other
1165   words, if the server is reading the protocol stream at the beginning
1166   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
1167   Likewise, although the line terminator for the start-line and header
1168   fields is the sequence CRLF, we recommend that recipients recognize a
1169   single LF as a line terminator and ignore any CR.
1170
1171   When a server listening only for HTTP request messages, or processing
1172
1173
1174
1175Fielding, et al.        Expires February 25, 2012              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1                 August 2011
1178
1179
1180   what appears from the start-line to be an HTTP request message,
1181   receives a sequence of octets that does not match the HTTP-message
1182   grammar aside from the robustness exceptions listed above, the server
1183   MUST respond with an HTTP/1.1 400 (Bad Request) response.
1184
11853.2.  Header Fields
1186
1187   Each HTTP header field consists of a case-insensitive field name
1188   followed by a colon (":"), optional whitespace, and the field value.
1189
1190     header-field   = field-name ":" OWS [ field-value ] OWS
1191     field-name     = token
1192     field-value    = *( field-content / OWS )
1193     field-content  = *( WSP / VCHAR / obs-text )
1194
1195   The field-name token labels the corresponding field-value as having
1196   the semantics defined by that header field.  For example, the Date
1197   header field is defined in Section 9.3 as containing the origination
1198   timestamp for the message in which it appears.
1199
1200   HTTP header fields are fully extensible: there is no limit on the
1201   introduction of new field names, each presumably defining new
1202   semantics, or on the number of header fields used in a given message.
1203   Existing fields are defined in each part of this specification and in
1204   many other specifications outside the standards process.  New header
1205   fields can be introduced without changing the protocol version if
1206   their defined semantics allow them to be safely ignored by recipients
1207   that do not recognize them.
1208
1209   New HTTP header fields SHOULD be registered with IANA according to
1210   the procedures in Section 10.1.  Unrecognized header fields MUST be
1211   forwarded by a proxy unless the field-name is listed in the
1212   Connection header field (Section 9.1) or the proxy is specifically
1213   configured to block or otherwise transform such fields.  Unrecognized
1214   header fields SHOULD be ignored by other recipients.
1215
1216   The order in which header fields with differing field names are
1217   received is not significant.  However, it is "good practice" to send
1218   header fields that contain control data first, such as Host on
1219   requests and Date on responses, so that implementations can decide
1220   when not to handle a message as early as possible.  A server MUST
1221   wait until the entire header section is received before interpreting
1222   a request message, since later header fields might include
1223   conditionals, authentication credentials, or deliberately misleading
1224   duplicate header fields that would impact request processing.
1225
1226   Multiple header fields with the same field name MUST NOT be sent in a
1227   message unless the entire field value for that header field is
1228
1229
1230
1231Fielding, et al.        Expires February 25, 2012              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1                 August 2011
1234
1235
1236   defined as a comma-separated list [i.e., #(values)].  Multiple header
1237   fields with the same field name can be combined into one "field-name:
1238   field-value" pair, without changing the semantics of the message, by
1239   appending each subsequent field value to the combined field value in
1240   order, separated by a comma.  The order in which header fields with
1241   the same field name are received is therefore significant to the
1242   interpretation of the combined field value; a proxy MUST NOT change
1243   the order of these field values when forwarding a message.
1244
1245      Note: The "Set-Cookie" header field as implemented in practice can
1246      occur multiple times, but does not use the list syntax, and thus
1247      cannot be combined into a single line ([RFC6265]).  (See Appendix
1248      A.2.3 of [Kri2001] for details.)  Also note that the Set-Cookie2
1249      header field specified in [RFC2965] does not share this problem.
1250
12513.2.1.  Field Parsing
1252
1253   No whitespace is allowed between the header field-name and colon.  In
1254   the past, differences in the handling of such whitespace have led to
1255   security vulnerabilities in request routing and response handling.
1256   Any received request message that contains whitespace between a
1257   header field-name and colon MUST be rejected with a response code of
1258   400 (Bad Request).  A proxy MUST remove any such whitespace from a
1259   response message before forwarding the message downstream.
1260
1261   A field value MAY be preceded by optional whitespace (OWS); a single
1262   SP is preferred.  The field value does not include any leading or
1263   trailing white space: OWS occurring before the first non-whitespace
1264   octet of the field value or after the last non-whitespace octet of
1265   the field value is ignored and SHOULD be removed before further
1266   processing (as this does not change the meaning of the header field).
1267
1268   Historically, HTTP header field values could be extended over
1269   multiple lines by preceding each extra line with at least one space
1270   or horizontal tab octet (line folding).  This specification
1271   deprecates such line folding except within the message/http media
1272   type (Section 10.3.1).  HTTP senders MUST NOT produce messages that
1273   include line folding (i.e., that contain any field-content that
1274   matches the obs-fold rule) unless the message is intended for
1275   packaging within the message/http media type.  HTTP recipients SHOULD
1276   accept line folding and replace any embedded obs-fold whitespace with
1277   either a single SP or a matching number of SP octets (to avoid buffer
1278   copying) prior to interpreting the field value or forwarding the
1279   message downstream.
1280
1281   Historically, HTTP has allowed field content with text in the ISO-
1282   8859-1 [ISO-8859-1] character encoding and supported other character
1283   sets only through use of [RFC2047] encoding.  In practice, most HTTP
1284
1285
1286
1287Fielding, et al.        Expires February 25, 2012              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1                 August 2011
1290
1291
1292   header field values use only a subset of the US-ASCII character
1293   encoding [USASCII].  Newly defined header fields SHOULD limit their
1294   field values to US-ASCII octets.  Recipients SHOULD treat other (obs-
1295   text) octets in field content as opaque data.
1296
12973.2.2.  Field Length
1298
1299   HTTP does not place a pre-defined limit on the length of header
1300   fields, either in isolation or as a set.  A server MUST be prepared
1301   to receive request header fields of unbounded length and respond with
1302   a 4xx status code if the received header field(s) would be longer
1303   than the server wishes to handle.
1304
1305   A client that receives response headers that are longer than it
1306   wishes to handle can only treat it as a server error.
1307
1308   Various ad-hoc limitations on header length are found in practice.
1309   It is RECOMMENDED that all HTTP senders and recipients support
1310   messages whose combined header fields have 4000 or more octets.
1311
13123.2.3.  Common Field ABNF Rules
1313
1314   Many HTTP/1.1 header field values consist of words (token or quoted-
1315   string) separated by whitespace or special characters.  These special
1316   characters MUST be in a quoted string to be used within a parameter
1317   value (as defined in Section 6.2).
1318
1319     word           = token / quoted-string
1320
1321     token          = 1*tchar
1322
1323     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1324                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1325                    / DIGIT / ALPHA
1326                    ; any VCHAR, except special
1327
1328     special        = "(" / ")" / "<" / ">" / "@" / ","
1329                    / ";" / ":" / "\" / DQUOTE / "/" / "["
1330                    / "]" / "?" / "=" / "{" / "}"
1331
1332   A string of text is parsed as a single word if it is quoted using
1333   double-quote marks.
1334
1335     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1336     qdtext         = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
1337     obs-text       = %x80-FF
1338
1339   The backslash octet ("\") can be used as a single-octet quoting
1340
1341
1342
1343Fielding, et al.        Expires February 25, 2012              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1                 August 2011
1346
1347
1348   mechanism within quoted-string constructs:
1349
1350     quoted-pair    = "\" ( WSP / VCHAR / obs-text )
1351
1352   Recipients that process the value of the quoted-string MUST handle a
1353   quoted-pair as if it were replaced by the octet following the
1354   backslash.
1355
1356   Senders SHOULD NOT escape octets in quoted-strings that do not
1357   require escaping (i.e., other than DQUOTE and the backslash octet).
1358
1359   Comments can be included in some HTTP header fields by surrounding
1360   the comment text with parentheses.  Comments are only allowed in
1361   fields containing "comment" as part of their field value definition.
1362
1363     comment        = "(" *( ctext / quoted-cpair / comment ) ")"
1364     ctext          = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1365
1366   The backslash octet ("\") can be used as a single-octet quoting
1367   mechanism within comment constructs:
1368
1369     quoted-cpair    = "\" ( WSP / VCHAR / obs-text )
1370
1371   Senders SHOULD NOT escape octets in comments that do not require
1372   escaping (i.e., other than the backslash octet "\" and the
1373   parentheses "(" and ")").
1374
13753.3.  Message Body
1376
1377   The message-body (if any) of an HTTP message is used to carry the
1378   payload body associated with the request or response.
1379
1380     message-body = *OCTET
1381
1382   The message-body differs from the payload body only when a transfer-
1383   coding has been applied, as indicated by the Transfer-Encoding header
1384   field (Section 9.7).  If more than one Transfer-Encoding header field
1385   is present in a message, the multiple field-values MUST be combined
1386   into one field-value, according to the algorithm defined in
1387   Section 3.2, before determining the message-body length.
1388
1389   When one or more transfer-codings are applied to a payload in order
1390   to form the message-body, the Transfer-Encoding header field MUST
1391   contain the list of transfer-codings applied.  Transfer-Encoding is a
1392   property of the message, not of the payload, and thus MAY be added or
1393   removed by any implementation along the request/response chain under
1394   the constraints found in Section 6.2.
1395
1396
1397
1398
1399Fielding, et al.        Expires February 25, 2012              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1                 August 2011
1402
1403
1404   If a message is received that has multiple Content-Length header
1405   fields (Section 9.2) with field-values consisting of the same decimal
1406   value, or a single Content-Length header field with a field value
1407   containing a list of identical decimal values (e.g., "Content-Length:
1408   42, 42"), indicating that duplicate Content-Length header fields have
1409   been generated or combined by an upstream message processor, then the
1410   recipient MUST either reject the message as invalid or replace the
1411   duplicated field-values with a single valid Content-Length field
1412   containing that decimal value prior to determining the message-body
1413   length.
1414
1415   The rules for when a message-body is allowed in a message differ for
1416   requests and responses.
1417
1418   The presence of a message-body in a request is signaled by the
1419   inclusion of a Content-Length or Transfer-Encoding header field in
1420   the request's header fields, even if the request method does not
1421   define any use for a message-body.  This allows the request message
1422   framing algorithm to be independent of method semantics.
1423
1424   For response messages, whether or not a message-body is included with
1425   a message is dependent on both the request method and the response
1426   status code (Section 5.1.1).  Responses to the HEAD request method
1427   never include a message-body because the associated response header
1428   fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
1429   what their values would have been if the request method had been GET.
1430   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1431   responses MUST NOT include a message-body.  All other responses do
1432   include a message-body, although the body MAY be of zero length.
1433
1434   The length of the message-body is determined by one of the following
1435   (in order of precedence):
1436
1437   1.  Any response to a HEAD request and any response with a status
1438       code of 100-199, 204, or 304 is always terminated by the first
1439       empty line after the header fields, regardless of the header
1440       fields present in the message, and thus cannot contain a message-
1441       body.
1442
1443   2.  If a Transfer-Encoding header field is present and the "chunked"
1444       transfer-coding (Section 6.2) is the final encoding, the message-
1445       body length is determined by reading and decoding the chunked
1446       data until the transfer-coding indicates the data is complete.
1447
1448       If a Transfer-Encoding header field is present in a response and
1449       the "chunked" transfer-coding is not the final encoding, the
1450       message-body length is determined by reading the connection until
1451       it is closed by the server.  If a Transfer-Encoding header field
1452
1453
1454
1455Fielding, et al.        Expires February 25, 2012              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1                 August 2011
1458
1459
1460       is present in a request and the "chunked" transfer-coding is not
1461       the final encoding, the message-body length cannot be determined
1462       reliably; the server MUST respond with the 400 (Bad Request)
1463       status code and then close the connection.
1464
1465       If a message is received with both a Transfer-Encoding header
1466       field and a Content-Length header field, the Transfer-Encoding
1467       overrides the Content-Length.  Such a message might indicate an
1468       attempt to perform request or response smuggling (bypass of
1469       security-related checks on message routing or content) and thus
1470       ought to be handled as an error.  The provided Content-Length
1471       MUST be removed, prior to forwarding the message downstream, or
1472       replaced with the real message-body length after the transfer-
1473       coding is decoded.
1474
1475   3.  If a message is received without Transfer-Encoding and with
1476       either multiple Content-Length header fields having differing
1477       field-values or a single Content-Length header field having an
1478       invalid value, then the message framing is invalid and MUST be
1479       treated as an error to prevent request or response smuggling.  If
1480       this is a request message, the server MUST respond with a 400
1481       (Bad Request) status code and then close the connection.  If this
1482       is a response message received by a proxy, the proxy MUST discard
1483       the received response, send a 502 (Bad Gateway) status code as
1484       its downstream response, and then close the connection.  If this
1485       is a response message received by a user-agent, it MUST be
1486       treated as an error by discarding the message and closing the
1487       connection.
1488
1489   4.  If a valid Content-Length header field is present without
1490       Transfer-Encoding, its decimal value defines the message-body
1491       length in octets.  If the actual number of octets sent in the
1492       message is less than the indicated Content-Length, the recipient
1493       MUST consider the message to be incomplete and treat the
1494       connection as no longer usable.  If the actual number of octets
1495       sent in the message is more than the indicated Content-Length,
1496       the recipient MUST only process the message-body up to the field
1497       value's number of octets; the remainder of the message MUST
1498       either be discarded or treated as the next message in a pipeline.
1499       For the sake of robustness, a user-agent MAY attempt to detect
1500       and correct such an error in message framing if it is parsing the
1501       response to the last request on a connection and the connection
1502       has been closed by the server.
1503
1504   5.  If this is a request message and none of the above are true, then
1505       the message-body length is zero (no message-body is present).
1506
1507
1508
1509
1510
1511Fielding, et al.        Expires February 25, 2012              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1                 August 2011
1514
1515
1516   6.  Otherwise, this is a response message without a declared message-
1517       body length, so the message-body length is determined by the
1518       number of octets received prior to the server closing the
1519       connection.
1520
1521   Since there is no way to distinguish a successfully completed, close-
1522   delimited message from a partially-received message interrupted by
1523   network failure, implementations SHOULD use encoding or length-
1524   delimited messages whenever possible.  The close-delimiting feature
1525   exists primarily for backwards compatibility with HTTP/1.0.
1526
1527   A server MAY reject a request that contains a message-body but not a
1528   Content-Length by responding with 411 (Length Required).
1529
1530   Unless a transfer-coding other than "chunked" has been applied, a
1531   client that sends a request containing a message-body SHOULD use a
1532   valid Content-Length header field if the message-body length is known
1533   in advance, rather than the "chunked" encoding, since some existing
1534   services respond to "chunked" with a 411 (Length Required) status
1535   code even though they understand the chunked encoding.  This is
1536   typically because such services are implemented via a gateway that
1537   requires a content-length in advance of being called and the server
1538   is unable or unwilling to buffer the entire request before
1539   processing.
1540
1541   A client that sends a request containing a message-body MUST include
1542   a valid Content-Length header field if it does not know the server
1543   will handle HTTP/1.1 (or later) requests; such knowledge can be in
1544   the form of specific user configuration or by remembering the version
1545   of a prior received response.
1546
15473.4.  Incomplete Messages
1548
1549   Request messages that are prematurely terminated, possibly due to a
1550   cancelled connection or a server-imposed time-out exception, MUST
1551   result in closure of the connection; sending an HTTP/1.1 error
1552   response prior to closing the connection is OPTIONAL.
1553
1554   Response messages that are prematurely terminated, usually by closure
1555   of the connection prior to receiving the expected number of octets or
1556   by failure to decode a transfer-encoded message-body, MUST be
1557   recorded as incomplete.  A response that terminates in the middle of
1558   the header block (before the empty line is received) cannot be
1559   assumed to convey the full semantics of the response and MUST be
1560   treated as an error.
1561
1562   A message-body that uses the chunked transfer encoding is incomplete
1563   if the zero-sized chunk that terminates the encoding has not been
1564
1565
1566
1567Fielding, et al.        Expires February 25, 2012              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1                 August 2011
1570
1571
1572   received.  A message that uses a valid Content-Length is incomplete
1573   if the size of the message-body received (in octets) is less than the
1574   value given by Content-Length.  A response that has neither chunked
1575   transfer encoding nor Content-Length is terminated by closure of the
1576   connection, and thus is considered complete regardless of the number
1577   of message-body octets received, provided that the header block was
1578   received intact.
1579
1580   A user agent MUST NOT render an incomplete response message-body as
1581   if it were complete (i.e., some indication must be given to the user
1582   that an error occurred).  Cache requirements for incomplete responses
1583   are defined in Section 2.1 of [Part6].
1584
1585   A server MUST read the entire request message-body or close the
1586   connection after sending its response, since otherwise the remaining
1587   data on a persistent connection would be misinterpreted as the next
1588   request.  Likewise, a client MUST read the entire response message-
1589   body if it intends to reuse the same connection for a subsequent
1590   request.  Pipelining multiple requests on a connection is described
1591   in Section 7.1.2.2.
1592
15933.5.  General Header Fields
1594
1595   There are a few header fields which have general applicability for
1596   both request and response messages, but which do not apply to the
1597   payload being transferred.  These header fields apply only to the
1598   message being transmitted.
1599
1600   +-------------------+---------------+
1601   | Header Field Name | Defined in... |
1602   +-------------------+---------------+
1603   | Connection        | Section 9.1   |
1604   | Date              | Section 9.3   |
1605   | Trailer           | Section 9.6   |
1606   | Transfer-Encoding | Section 9.7   |
1607   | Upgrade           | Section 9.8   |
1608   | Via               | Section 9.9   |
1609   +-------------------+---------------+
1610
16114.  Request
1612
1613   A request message from a client to a server begins with a Request-
1614   Line, followed by zero or more header fields, an empty line
1615   signifying the end of the header block, and an optional message body.
1616
1617     Request       = Request-Line              ; Section 4.1
1618                     *( header-field CRLF )    ; Section 3.2
1619                     CRLF
1620
1621
1622
1623Fielding, et al.        Expires February 25, 2012              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1                 August 2011
1626
1627
1628                     [ message-body ]          ; Section 3.3
1629
16304.1.  Request-Line
1631
1632   The Request-Line begins with a method token, followed by a single
1633   space (SP), the request-target, another single space (SP), the
1634   protocol version, and ending with CRLF.
1635
1636     Request-Line   = Method SP request-target SP HTTP-Version CRLF
1637
16384.1.1.  Method
1639
1640   The Method token indicates the request method to be performed on the
1641   target resource.  The request method is case-sensitive.
1642
1643     Method         = token
1644
16454.1.2.  request-target
1646
1647   The request-target identifies the target resource upon which to apply
1648   the request.  In most cases, the user agent is provided a URI
1649   reference from which it determines an absolute URI for identifying
1650   the target resource.  When a request to the resource is initiated,
1651   all or part of that URI is used to construct the HTTP request-target.
1652
1653     request-target = "*"
1654                    / absolute-URI
1655                    / ( path-absolute [ "?" query ] )
1656                    / authority
1657
1658   The four options for request-target are dependent on the nature of
1659   the request.
1660
1661   The asterisk "*" form of request-target, which MUST NOT be used with
1662   any request method other than OPTIONS, means that the request applies
1663   to the server as a whole (the listening process) rather than to a
1664   specific named resource at that server.  For example,
1665
1666     OPTIONS * HTTP/1.1
1667
1668   The "absolute-URI" form is REQUIRED when the request is being made to
1669   a proxy.  The proxy is requested to either forward the request or
1670   service it from a valid cache, and then return the response.  Note
1671   that the proxy MAY forward the request on to another proxy or
1672   directly to the server specified by the absolute-URI.  In order to
1673   avoid request loops, a proxy that forwards requests to other proxies
1674   MUST be able to recognize and exclude all of its own server names,
1675   including any aliases, local variations, and the numeric IP address.
1676
1677
1678
1679Fielding, et al.        Expires February 25, 2012              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1                 August 2011
1682
1683
1684   An example Request-Line would be:
1685
1686     GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1687
1688   To allow for transition to absolute-URIs in all requests in future
1689   versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1690   form in requests, even though HTTP/1.1 clients will only generate
1691   them in requests to proxies.
1692
1693   If a proxy receives a host name that is not a fully qualified domain
1694   name, it MAY add its domain to the host name it received.  If a proxy
1695   receives a fully qualified domain name, the proxy MUST NOT change the
1696   host name.
1697
1698   The "authority form" is only used by the CONNECT request method
1699   (Section 7.9 of [Part2]).
1700
1701   The most common form of request-target is that used when making a
1702   request to an origin server ("origin form").  In this case, the
1703   absolute path and query components of the URI MUST be transmitted as
1704   the request-target, and the authority component MUST be transmitted
1705   in a Host header field.  For example, a client wishing to retrieve a
1706   representation of the resource, as identified above, directly from
1707   the origin server would open (or reuse) a TCP connection to port 80
1708   of the host "www.example.org" and send the lines:
1709
1710     GET /pub/WWW/TheProject.html HTTP/1.1
1711     Host: www.example.org
1712
1713   followed by the remainder of the Request.  Note that the origin form
1714   of request-target always starts with an absolute path; if the target
1715   resource's URI path is empty, then an absolute path of "/" MUST be
1716   provided in the request-target.
1717
1718   If a proxy receives an OPTIONS request with an absolute-URI form of
1719   request-target in which the URI has an empty path and no query
1720   component, then the last proxy on the request chain MUST use a
1721   request-target of "*" when it forwards the request to the indicated
1722   origin server.
1723
1724   For example, the request
1725
1726     OPTIONS http://www.example.org:8001 HTTP/1.1
1727
1728
1729
1730
1731
1732
1733
1734
1735Fielding, et al.        Expires February 25, 2012              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1                 August 2011
1738
1739
1740   would be forwarded by the final proxy as
1741
1742     OPTIONS * HTTP/1.1
1743     Host: www.example.org:8001
1744
1745   after connecting to port 8001 of host "www.example.org".
1746
1747   The request-target is transmitted in the format specified in
1748   Section 2.7.1.  If the request-target is percent-encoded ([RFC3986],
1749   Section 2.1), the origin server MUST decode the request-target in
1750   order to properly interpret the request.  Servers SHOULD respond to
1751   invalid request-targets with an appropriate status code.
1752
1753   A non-transforming proxy MUST NOT rewrite the "path-absolute" part of
1754   the received request-target when forwarding it to the next inbound
1755   server, except as noted above to replace a null path-absolute with
1756   "/" or "*".
1757
1758      Note: The "no rewrite" rule prevents the proxy from changing the
1759      meaning of the request when the origin server is improperly using
1760      a non-reserved URI character for a reserved purpose.  Implementors
1761      need to be aware that some pre-HTTP/1.1 proxies have been known to
1762      rewrite the request-target.
1763
1764   HTTP does not place a pre-defined limit on the length of a request-
1765   target.  A server MUST be prepared to receive URIs of unbounded
1766   length and respond with the 414 (URI Too Long) status code if the
1767   received request-target would be longer than the server wishes to
1768   handle (see Section 8.4.15 of [Part2]).
1769
1770   Various ad-hoc limitations on request-target length are found in
1771   practice.  It is RECOMMENDED that all HTTP senders and recipients
1772   support request-target lengths of 8000 or more octets.
1773
1774      Note: Fragments ([RFC3986], Section 3.5) are not part of the
1775      request-target and thus will not be transmitted in an HTTP
1776      request.
1777
17784.2.  The Resource Identified by a Request
1779
1780   The exact resource identified by an Internet request is determined by
1781   examining both the request-target and the Host header field.
1782
1783   An origin server that does not allow resources to differ by the
1784   requested host MAY ignore the Host header field value when
1785   determining the resource identified by an HTTP/1.1 request.  (But see
1786   Appendix A.1.1 for other requirements on Host support in HTTP/1.1.)
1787
1788
1789
1790
1791Fielding, et al.        Expires February 25, 2012              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1                 August 2011
1794
1795
1796   An origin server that does differentiate resources based on the host
1797   requested (sometimes referred to as virtual hosts or vanity host
1798   names) MUST use the following rules for determining the requested
1799   resource on an HTTP/1.1 request:
1800
1801   1.  If request-target is an absolute-URI, the host is part of the
1802       request-target.  Any Host header field value in the request MUST
1803       be ignored.
1804
1805   2.  If the request-target is not an absolute-URI, and the request
1806       includes a Host header field, the host is determined by the Host
1807       header field value.
1808
1809   3.  If the host as determined by rule 1 or 2 is not a valid host on
1810       the server, the response MUST be a 400 (Bad Request) error
1811       message.
1812
1813   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1814   attempt to use heuristics (e.g., examination of the URI path for
1815   something unique to a particular host) in order to determine what
1816   exact resource is being requested.
1817
18184.3.  Effective Request URI
1819
1820   HTTP requests often do not carry the absolute URI ([RFC3986], Section
1821   4.3) for the target resource; instead, the URI needs to be inferred
1822   from the request-target, Host header field, and connection context.
1823   The result of this process is called the "effective request URI".
1824   The "target resource" is the resource identified by the effective
1825   request URI.
1826
1827   If the request-target is an absolute-URI, then the effective request
1828   URI is the request-target.
1829
1830   If the request-target uses the path-absolute form or the asterisk
1831   form, and the Host header field is present, then the effective
1832   request URI is constructed by concatenating
1833
1834   o  the scheme name: "http" if the request was received over an
1835      insecure TCP connection, or "https" when received over a SSL/
1836      TLS-secured TCP connection,
1837
1838   o  the octet sequence "://",
1839
1840   o  the authority component, as specified in the Host header field
1841      (Section 9.4), and
1842
1843
1844
1845
1846
1847Fielding, et al.        Expires February 25, 2012              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1                 August 2011
1850
1851
1852   o  the request-target obtained from the Request-Line, unless the
1853      request-target is just the asterisk "*".
1854
1855   If the request-target uses the path-absolute form or the asterisk
1856   form, and the Host header field is not present, then the effective
1857   request URI is undefined.
1858
1859   Otherwise, when request-target uses the authority form, the effective
1860   request URI is undefined.
1861
1862   Example 1: the effective request URI for the message
1863
1864     GET /pub/WWW/TheProject.html HTTP/1.1
1865     Host: www.example.org:8080
1866
1867   (received over an insecure TCP connection) is "http", plus "://",
1868   plus the authority component "www.example.org:8080", plus the
1869   request-target "/pub/WWW/TheProject.html", thus
1870   "http://www.example.org:8080/pub/WWW/TheProject.html".
1871
1872   Example 2: the effective request URI for the message
1873
1874     OPTIONS * HTTP/1.1
1875     Host: www.example.org
1876
1877   (received over an SSL/TLS secured TCP connection) is "https", plus
1878   "://", plus the authority component "www.example.org", thus
1879   "https://www.example.org".
1880
1881   Effective request URIs are compared using the rules described in
1882   Section 2.7.3, except that empty path components MUST NOT be treated
1883   as equivalent to an absolute path of "/".
1884
18855.  Response
1886
1887   After receiving and interpreting a request message, a server responds
1888   with an HTTP response message.
1889
1890     Response      = Status-Line               ; Section 5.1
1891                     *( header-field CRLF )    ; Section 3.2
1892                     CRLF
1893                     [ message-body ]          ; Section 3.3
1894
18955.1.  Status-Line
1896
1897   The first line of a Response message is the Status-Line, consisting
1898   of the protocol version, a space (SP), the status code, another
1899   space, a possibly-empty textual phrase describing the status code,
1900
1901
1902
1903Fielding, et al.        Expires February 25, 2012              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1                 August 2011
1906
1907
1908   and ending with CRLF.
1909
1910     Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1911
19125.1.1.  Status Code and Reason Phrase
1913
1914   The Status-Code element is a 3-digit integer result code of the
1915   attempt to understand and satisfy the request.  These codes are fully
1916   defined in Section 8 of [Part2].  The Reason Phrase exists for the
1917   sole purpose of providing a textual description associated with the
1918   numeric status code, out of deference to earlier Internet application
1919   protocols that were more frequently used with interactive text
1920   clients.  A client SHOULD ignore the content of the Reason Phrase.
1921
1922   The first digit of the Status-Code defines the class of response.
1923   The last two digits do not have any categorization role.  There are 5
1924   values for the first digit:
1925
1926   o  1xx: Informational - Request received, continuing process
1927
1928   o  2xx: Success - The action was successfully received, understood,
1929      and accepted
1930
1931   o  3xx: Redirection - Further action must be taken in order to
1932      complete the request
1933
1934   o  4xx: Client Error - The request contains bad syntax or cannot be
1935      fulfilled
1936
1937   o  5xx: Server Error - The server failed to fulfill an apparently
1938      valid request
1939
1940
1941     Status-Code    = 3DIGIT
1942     Reason-Phrase  = *( WSP / VCHAR / obs-text )
1943
19446.  Protocol Parameters
1945
19466.1.  Date/Time Formats: Full Date
1947
1948   HTTP applications have historically allowed three different formats
1949   for date/time stamps.  However, the preferred format is a fixed-
1950   length subset of that defined by [RFC1123]:
1951
1952     Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
1953
1954   The other formats are described here only for compatibility with
1955   obsolete implementations.
1956
1957
1958
1959Fielding, et al.        Expires February 25, 2012              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1                 August 2011
1962
1963
1964     Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1965     Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
1966
1967   HTTP/1.1 clients and servers that parse a date value MUST accept all
1968   three formats (for compatibility with HTTP/1.0), though they MUST
1969   only generate the RFC 1123 format for representing HTTP-date values
1970   in header fields.
1971
1972   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1973   (GMT), without exception.  For the purposes of HTTP, GMT is exactly
1974   equal to UTC (Coordinated Universal Time).  This is indicated in the
1975   first two formats by the inclusion of "GMT" as the three-letter
1976   abbreviation for time zone, and MUST be assumed when reading the
1977   asctime format.  HTTP-date is case sensitive and MUST NOT include
1978   additional whitespace beyond that specifically included as SP in the
1979   grammar.
1980
1981     HTTP-date    = rfc1123-date / obs-date
1982
1983   Preferred format:
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015Fielding, et al.        Expires February 25, 2012              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1                 August 2011
2018
2019
2020     rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
2021     ; fixed length subset of the format defined in
2022     ; Section 5.2.14 of [RFC1123]
2023
2024     day-name     = %x4D.6F.6E ; "Mon", case-sensitive
2025                  / %x54.75.65 ; "Tue", case-sensitive
2026                  / %x57.65.64 ; "Wed", case-sensitive
2027                  / %x54.68.75 ; "Thu", case-sensitive
2028                  / %x46.72.69 ; "Fri", case-sensitive
2029                  / %x53.61.74 ; "Sat", case-sensitive
2030                  / %x53.75.6E ; "Sun", case-sensitive
2031
2032     date1        = day SP month SP year
2033                  ; e.g., 02 Jun 1982
2034
2035     day          = 2DIGIT
2036     month        = %x4A.61.6E ; "Jan", case-sensitive
2037                  / %x46.65.62 ; "Feb", case-sensitive
2038                  / %x4D.61.72 ; "Mar", case-sensitive
2039                  / %x41.70.72 ; "Apr", case-sensitive
2040                  / %x4D.61.79 ; "May", case-sensitive
2041                  / %x4A.75.6E ; "Jun", case-sensitive
2042                  / %x4A.75.6C ; "Jul", case-sensitive
2043                  / %x41.75.67 ; "Aug", case-sensitive
2044                  / %x53.65.70 ; "Sep", case-sensitive
2045                  / %x4F.63.74 ; "Oct", case-sensitive
2046                  / %x4E.6F.76 ; "Nov", case-sensitive
2047                  / %x44.65.63 ; "Dec", case-sensitive
2048     year         = 4DIGIT
2049
2050     GMT   = %x47.4D.54 ; "GMT", case-sensitive
2051
2052     time-of-day  = hour ":" minute ":" second
2053                    ; 00:00:00 - 23:59:59
2054
2055     hour         = 2DIGIT
2056     minute       = 2DIGIT
2057     second       = 2DIGIT
2058
2059   The semantics of day-name, day, month, year, and time-of-day are the
2060   same as those defined for the RFC 5322 constructs with the
2061   corresponding name ([RFC5322], Section 3.3).
2062
2063   Obsolete formats:
2064
2065     obs-date     = rfc850-date / asctime-date
2066
2067
2068
2069
2070
2071Fielding, et al.        Expires February 25, 2012              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1                 August 2011
2074
2075
2076     rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
2077     date2        = day "-" month "-" 2DIGIT
2078                    ; day-month-year (e.g., 02-Jun-82)
2079
2080     day-name-l   = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
2081            / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
2082            / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
2083            / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
2084            / %x46.72.69.64.61.79 ; "Friday", case-sensitive
2085            / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
2086            / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
2087
2088
2089     asctime-date = day-name SP date3 SP time-of-day SP year
2090     date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
2091                    ; month day (e.g., Jun  2)
2092
2093      Note: Recipients of date values are encouraged to be robust in
2094      accepting date values that might have been sent by non-HTTP
2095      applications, as is sometimes the case when retrieving or posting
2096      messages via proxies/gateways to SMTP or NNTP.
2097
2098      Note: HTTP requirements for the date/time stamp format apply only
2099      to their usage within the protocol stream.  Clients and servers
2100      are not required to use these formats for user presentation,
2101      request logging, etc.
2102
21036.2.  Transfer Codings
2104
2105   Transfer-coding values are used to indicate an encoding
2106   transformation that has been, can be, or might need to be applied to
2107   a payload body in order to ensure "safe transport" through the
2108   network.  This differs from a content coding in that the transfer-
2109   coding is a property of the message rather than a property of the
2110   representation that is being transferred.
2111
2112     transfer-coding         = "chunked" ; Section 6.2.1
2113                             / "compress" ; Section 6.2.2.1
2114                             / "deflate" ; Section 6.2.2.2
2115                             / "gzip" ; Section 6.2.2.3
2116                             / transfer-extension
2117     transfer-extension      = token *( OWS ";" OWS transfer-parameter )
2118
2119   Parameters are in the form of attribute/value pairs.
2120
2121     transfer-parameter      = attribute BWS "=" BWS value
2122     attribute               = token
2123     value                   = word
2124
2125
2126
2127Fielding, et al.        Expires February 25, 2012              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1                 August 2011
2130
2131
2132   All transfer-coding values are case-insensitive.  HTTP/1.1 uses
2133   transfer-coding values in the TE header field (Section 9.5) and in
2134   the Transfer-Encoding header field (Section 9.7).
2135
2136   Transfer-codings are analogous to the Content-Transfer-Encoding
2137   values of MIME, which were designed to enable safe transport of
2138   binary data over a 7-bit transport service ([RFC2045], Section 6).
2139   However, safe transport has a different focus for an 8bit-clean
2140   transfer protocol.  In HTTP, the only unsafe characteristic of
2141   message-bodies is the difficulty in determining the exact message
2142   body length (Section 3.3), or the desire to encrypt data over a
2143   shared transport.
2144
2145   A server that receives a request message with a transfer-coding it
2146   does not understand SHOULD respond with 501 (Not Implemented) and
2147   then close the connection.  A server MUST NOT send transfer-codings
2148   to an HTTP/1.0 client.
2149
21506.2.1.  Chunked Transfer Coding
2151
2152   The chunked encoding modifies the body of a message in order to
2153   transfer it as a series of chunks, each with its own size indicator,
2154   followed by an OPTIONAL trailer containing header fields.  This
2155   allows dynamically produced content to be transferred along with the
2156   information necessary for the recipient to verify that it has
2157   received the full message.
2158
2159     Chunked-Body   = *chunk
2160                      last-chunk
2161                      trailer-part
2162                      CRLF
2163
2164     chunk          = chunk-size *WSP [ chunk-ext ] CRLF
2165                      chunk-data CRLF
2166     chunk-size     = 1*HEXDIG
2167     last-chunk     = 1*("0") *WSP [ chunk-ext ] CRLF
2168
2169     chunk-ext      = *( ";" *WSP chunk-ext-name
2170                         [ "=" chunk-ext-val ] *WSP )
2171     chunk-ext-name = token
2172     chunk-ext-val  = token / quoted-str-nf
2173     chunk-data     = 1*OCTET ; a sequence of chunk-size octets
2174     trailer-part   = *( header-field CRLF )
2175
2176     quoted-str-nf  = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
2177                    ; like quoted-string, but disallowing line folding
2178     qdtext-nf      = WSP / %x21 / %x23-5B / %x5D-7E / obs-text
2179                    ; WSP / <VCHAR except DQUOTE and "\"> / obs-text
2180
2181
2182
2183Fielding, et al.        Expires February 25, 2012              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1                 August 2011
2186
2187
2188   The chunk-size field is a string of hex digits indicating the size of
2189   the chunk-data in octets.  The chunked encoding is ended by any chunk
2190   whose size is zero, followed by the trailer, which is terminated by
2191   an empty line.
2192
2193   The trailer allows the sender to include additional HTTP header
2194   fields at the end of the message.  The Trailer header field can be
2195   used to indicate which header fields are included in a trailer (see
2196   Section 9.6).
2197
2198   A server using chunked transfer-coding in a response MUST NOT use the
2199   trailer for any header fields unless at least one of the following is
2200   true:
2201
2202   1.  the request included a TE header field that indicates "trailers"
2203       is acceptable in the transfer-coding of the response, as
2204       described in Section 9.5; or,
2205
2206   2.  the trailer fields consist entirely of optional metadata, and the
2207       recipient could use the message (in a manner acceptable to the
2208       server where the field originated) without receiving it.  In
2209       other words, the server that generated the header (often but not
2210       always the origin server) is willing to accept the possibility
2211       that the trailer fields might be silently discarded along the
2212       path to the client.
2213
2214   This requirement prevents an interoperability failure when the
2215   message is being received by an HTTP/1.1 (or later) proxy and
2216   forwarded to an HTTP/1.0 recipient.  It avoids a situation where
2217   compliance with the protocol would have necessitated a possibly
2218   infinite buffer on the proxy.
2219
2220   A process for decoding the "chunked" transfer-coding can be
2221   represented in pseudo-code as:
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239Fielding, et al.        Expires February 25, 2012              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1                 August 2011
2242
2243
2244     length := 0
2245     read chunk-size, chunk-ext (if any) and CRLF
2246     while (chunk-size > 0) {
2247        read chunk-data and CRLF
2248        append chunk-data to decoded-body
2249        length := length + chunk-size
2250        read chunk-size and CRLF
2251     }
2252     read header-field
2253     while (header-field not empty) {
2254        append header-field to existing header fields
2255        read header-field
2256     }
2257     Content-Length := length
2258     Remove "chunked" from Transfer-Encoding
2259
2260   All HTTP/1.1 applications MUST be able to receive and decode the
2261   "chunked" transfer-coding and MUST ignore chunk-ext extensions they
2262   do not understand.
2263
2264   Since "chunked" is the only transfer-coding required to be understood
2265   by HTTP/1.1 recipients, it plays a crucial role in delimiting
2266   messages on a persistent connection.  Whenever a transfer-coding is
2267   applied to a payload body in a request, the final transfer-coding
2268   applied MUST be "chunked".  If a transfer-coding is applied to a
2269   response payload body, then either the final transfer-coding applied
2270   MUST be "chunked" or the message MUST be terminated by closing the
2271   connection.  When the "chunked" transfer-coding is used, it MUST be
2272   the last transfer-coding applied to form the message-body.  The
2273   "chunked" transfer-coding MUST NOT be applied more than once in a
2274   message-body.
2275
22766.2.2.  Compression Codings
2277
2278   The codings defined below can be used to compress the payload of a
2279   message.
2280
2281      Note: Use of program names for the identification of encoding
2282      formats is not desirable and is discouraged for future encodings.
2283      Their use here is representative of historical practice, not good
2284      design.
2285
2286      Note: For compatibility with previous implementations of HTTP,
2287      applications SHOULD consider "x-gzip" and "x-compress" to be
2288      equivalent to "gzip" and "compress" respectively.
2289
2290
2291
2292
2293
2294
2295Fielding, et al.        Expires February 25, 2012              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1                 August 2011
2298
2299
23006.2.2.1.  Compress Coding
2301
2302   The "compress" format is produced by the common UNIX file compression
2303   program "compress".  This format is an adaptive Lempel-Ziv-Welch
2304   coding (LZW).
2305
23066.2.2.2.  Deflate Coding
2307
2308   The "deflate" format is defined as the "deflate" compression
2309   mechanism (described in [RFC1951]) used inside the "zlib" data format
2310   ([RFC1950]).
2311
2312      Note: Some incorrect implementations send the "deflate" compressed
2313      data without the zlib wrapper.
2314
23156.2.2.3.  Gzip Coding
2316
2317   The "gzip" format is produced by the file compression program "gzip"
2318   (GNU zip), as described in [RFC1952].  This format is a Lempel-Ziv
2319   coding (LZ77) with a 32 bit CRC.
2320
23216.2.3.  Transfer Coding Registry
2322
2323   The HTTP Transfer Coding Registry defines the name space for the
2324   transfer coding names.
2325
2326   Registrations MUST include the following fields:
2327
2328   o  Name
2329
2330   o  Description
2331
2332   o  Pointer to specification text
2333
2334   Names of transfer codings MUST NOT overlap with names of content
2335   codings (Section 2.2 of [Part3]), unless the encoding transformation
2336   is identical (as it is the case for the compression codings defined
2337   in Section 6.2.2).
2338
2339   Values to be added to this name space require a specification (see
2340   "Specification Required" in Section 4.1 of [RFC5226]), and MUST
2341   conform to the purpose of transfer coding defined in this section.
2342
2343   The registry itself is maintained at
2344   <http://www.iana.org/assignments/http-parameters>.
2345
2346
2347
2348
2349
2350
2351Fielding, et al.        Expires February 25, 2012              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1                 August 2011
2354
2355
23566.3.  Product Tokens
2357
2358   Product tokens are used to allow communicating applications to
2359   identify themselves by software name and version.  Most fields using
2360   product tokens also allow sub-products which form a significant part
2361   of the application to be listed, separated by whitespace.  By
2362   convention, the products are listed in order of their significance
2363   for identifying the application.
2364
2365     product         = token ["/" product-version]
2366     product-version = token
2367
2368   Examples:
2369
2370     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2371     Server: Apache/0.8.4
2372
2373   Product tokens SHOULD be short and to the point.  They MUST NOT be
2374   used for advertising or other non-essential information.  Although
2375   any token octet MAY appear in a product-version, this token SHOULD
2376   only be used for a version identifier (i.e., successive versions of
2377   the same product SHOULD only differ in the product-version portion of
2378   the product value).
2379
23806.4.  Quality Values
2381
2382   Both transfer codings (TE request header field, Section 9.5) and
2383   content negotiation (Section 5 of [Part3]) use short "floating point"
2384   numbers to indicate the relative importance ("weight") of various
2385   negotiable parameters.  A weight is normalized to a real number in
2386   the range 0 through 1, where 0 is the minimum and 1 the maximum
2387   value.  If a parameter has a quality value of 0, then content with
2388   this parameter is "not acceptable" for the client.  HTTP/1.1
2389   applications MUST NOT generate more than three digits after the
2390   decimal point.  User configuration of these values SHOULD also be
2391   limited in this fashion.
2392
2393     qvalue         = ( "0" [ "." 0*3DIGIT ] )
2394                    / ( "1" [ "." 0*3("0") ] )
2395
2396      Note: "Quality values" is a misnomer, since these values merely
2397      represent relative degradation in desired quality.
2398
23997.  Connections
2400
2401
2402
2403
2404
2405
2406
2407Fielding, et al.        Expires February 25, 2012              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1                 August 2011
2410
2411
24127.1.  Persistent Connections
2413
24147.1.1.  Purpose
2415
2416   Prior to persistent connections, a separate TCP connection was
2417   established for each request, increasing the load on HTTP servers and
2418   causing congestion on the Internet.  The use of inline images and
2419   other associated data often requires a client to make multiple
2420   requests of the same server in a short amount of time.  Analysis of
2421   these performance problems and results from a prototype
2422   implementation are available [Pad1995] [Spe].  Implementation
2423   experience and measurements of actual HTTP/1.1 implementations show
2424   good results [Nie1997].  Alternatives have also been explored, for
2425   example, T/TCP [Tou1998].
2426
2427   Persistent HTTP connections have a number of advantages:
2428
2429   o  By opening and closing fewer TCP connections, CPU time is saved in
2430      routers and hosts (clients, servers, proxies, gateways, tunnels,
2431      or caches), and memory used for TCP protocol control blocks can be
2432      saved in hosts.
2433
2434   o  HTTP requests and responses can be pipelined on a connection.
2435      Pipelining allows a client to make multiple requests without
2436      waiting for each response, allowing a single TCP connection to be
2437      used much more efficiently, with much lower elapsed time.
2438
2439   o  Network congestion is reduced by reducing the number of packets
2440      caused by TCP opens, and by allowing TCP sufficient time to
2441      determine the congestion state of the network.
2442
2443   o  Latency on subsequent requests is reduced since there is no time
2444      spent in TCP's connection opening handshake.
2445
2446   o  HTTP can evolve more gracefully, since errors can be reported
2447      without the penalty of closing the TCP connection.  Clients using
2448      future versions of HTTP might optimistically try a new feature,
2449      but if communicating with an older server, retry with old
2450      semantics after an error is reported.
2451
2452   HTTP implementations SHOULD implement persistent connections.
2453
24547.1.2.  Overall Operation
2455
2456   A significant difference between HTTP/1.1 and earlier versions of
2457   HTTP is that persistent connections are the default behavior of any
2458   HTTP connection.  That is, unless otherwise indicated, the client
2459   SHOULD assume that the server will maintain a persistent connection,
2460
2461
2462
2463Fielding, et al.        Expires February 25, 2012              [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1                 August 2011
2466
2467
2468   even after error responses from the server.
2469
2470   Persistent connections provide a mechanism by which a client and a
2471   server can signal the close of a TCP connection.  This signaling
2472   takes place using the Connection header field (Section 9.1).  Once a
2473   close has been signaled, the client MUST NOT send any more requests
2474   on that connection.
2475
24767.1.2.1.  Negotiation
2477
2478   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2479   maintain a persistent connection unless a Connection header field
2480   including the connection-token "close" was sent in the request.  If
2481   the server chooses to close the connection immediately after sending
2482   the response, it SHOULD send a Connection header field including the
2483   connection-token "close".
2484
2485   An HTTP/1.1 client MAY expect a connection to remain open, but would
2486   decide to keep it open based on whether the response from a server
2487   contains a Connection header field with the connection-token close.
2488   In case the client does not want to maintain a connection for more
2489   than that request, it SHOULD send a Connection header field including
2490   the connection-token close.
2491
2492   If either the client or the server sends the close token in the
2493   Connection header field, that request becomes the last one for the
2494   connection.
2495
2496   Clients and servers SHOULD NOT assume that a persistent connection is
2497   maintained for HTTP versions less than 1.1 unless it is explicitly
2498   signaled.  See Appendix A.1.2 for more information on backward
2499   compatibility with HTTP/1.0 clients.
2500
2501   In order to remain persistent, all messages on the connection MUST
2502   have a self-defined message length (i.e., one not defined by closure
2503   of the connection), as described in Section 3.3.
2504
25057.1.2.2.  Pipelining
2506
2507   A client that supports persistent connections MAY "pipeline" its
2508   requests (i.e., send multiple requests without waiting for each
2509   response).  A server MUST send its responses to those requests in the
2510   same order that the requests were received.
2511
2512   Clients which assume persistent connections and pipeline immediately
2513   after connection establishment SHOULD be prepared to retry their
2514   connection if the first pipelined attempt fails.  If a client does
2515   such a retry, it MUST NOT pipeline before it knows the connection is
2516
2517
2518
2519Fielding, et al.        Expires February 25, 2012              [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1                 August 2011
2522
2523
2524   persistent.  Clients MUST also be prepared to resend their requests
2525   if the server closes the connection before sending all of the
2526   corresponding responses.
2527
2528   Clients SHOULD NOT pipeline requests using non-idempotent request
2529   methods or non-idempotent sequences of request methods (see Section
2530   7.1.2 of [Part2]).  Otherwise, a premature termination of the
2531   transport connection could lead to indeterminate results.  A client
2532   wishing to send a non-idempotent request SHOULD wait to send that
2533   request until it has received the response status line for the
2534   previous request.
2535
25367.1.3.  Proxy Servers
2537
2538   It is especially important that proxies correctly implement the
2539   properties of the Connection header field as specified in
2540   Section 9.1.
2541
2542   The proxy server MUST signal persistent connections separately with
2543   its clients and the origin servers (or other proxy servers) that it
2544   connects to.  Each persistent connection applies to only one
2545   transport link.
2546
2547   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2548   with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
2549   information and discussion of the problems with the Keep-Alive header
2550   field implemented by many HTTP/1.0 clients).
2551
25527.1.3.1.  End-to-end and Hop-by-hop Header Fields
2553
2554   For the purpose of defining the behavior of caches and non-caching
2555   proxies, we divide HTTP header fields into two categories:
2556
2557   o  End-to-end header fields, which are transmitted to the ultimate
2558      recipient of a request or response.  End-to-end header fields in
2559      responses MUST be stored as part of a cache entry and MUST be
2560      transmitted in any response formed from a cache entry.
2561
2562   o  Hop-by-hop header fields, which are meaningful only for a single
2563      transport-level connection, and are not stored by caches or
2564      forwarded by proxies.
2565
2566   The following HTTP/1.1 header fields are hop-by-hop header fields:
2567
2568   o  Connection
2569
2570   o  Keep-Alive
2571
2572
2573
2574
2575Fielding, et al.        Expires February 25, 2012              [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1                 August 2011
2578
2579
2580   o  Proxy-Authenticate
2581
2582   o  Proxy-Authorization
2583
2584   o  TE
2585
2586   o  Trailer
2587
2588   o  Transfer-Encoding
2589
2590   o  Upgrade
2591
2592   All other header fields defined by HTTP/1.1 are end-to-end header
2593   fields.
2594
2595   Other hop-by-hop header fields MUST be listed in a Connection header
2596   field (Section 9.1).
2597
25987.1.3.2.  Non-modifiable Header Fields
2599
2600   Some features of HTTP/1.1, such as Digest Authentication, depend on
2601   the value of certain end-to-end header fields.  A non-transforming
2602   proxy SHOULD NOT modify an end-to-end header field unless the
2603   definition of that header field requires or specifically allows that.
2604
2605   A non-transforming proxy MUST NOT modify any of the following fields
2606   in a request or response, and it MUST NOT add any of these fields if
2607   not already present:
2608
2609   o  Allow
2610
2611   o  Content-Location
2612
2613   o  Content-MD5
2614
2615   o  ETag
2616
2617   o  Last-Modified
2618
2619   o  Server
2620
2621   A non-transforming proxy MUST NOT modify any of the following fields
2622   in a response:
2623
2624   o  Expires
2625
2626   but it MAY add any of these fields if not already present.  If an
2627   Expires header field is added, it MUST be given a field-value
2628
2629
2630
2631Fielding, et al.        Expires February 25, 2012              [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1                 August 2011
2634
2635
2636   identical to that of the Date header field in that response.
2637
2638   A proxy MUST NOT modify or add any of the following fields in a
2639   message that contains the no-transform cache-control directive, or in
2640   any request:
2641
2642   o  Content-Encoding
2643
2644   o  Content-Range
2645
2646   o  Content-Type
2647
2648   A transforming proxy MAY modify or add these fields to a message that
2649   does not include no-transform, but if it does so, it MUST add a
2650   Warning 214 (Transformation applied) if one does not already appear
2651   in the message (see Section 3.6 of [Part6]).
2652
2653      Warning: Unnecessary modification of end-to-end header fields
2654      might cause authentication failures if stronger authentication
2655      mechanisms are introduced in later versions of HTTP.  Such
2656      authentication mechanisms MAY rely on the values of header fields
2657      not listed here.
2658
2659   A non-transforming proxy MUST preserve the message payload ([Part3]),
2660   though it MAY change the message-body through application or removal
2661   of a transfer-coding (Section 6.2).
2662
26637.1.4.  Practical Considerations
2664
2665   Servers will usually have some time-out value beyond which they will
2666   no longer maintain an inactive connection.  Proxy servers might make
2667   this a higher value since it is likely that the client will be making
2668   more connections through the same server.  The use of persistent
2669   connections places no requirements on the length (or existence) of
2670   this time-out for either the client or the server.
2671
2672   When a client or server wishes to time-out it SHOULD issue a graceful
2673   close on the transport connection.  Clients and servers SHOULD both
2674   constantly watch for the other side of the transport close, and
2675   respond to it as appropriate.  If a client or server does not detect
2676   the other side's close promptly it could cause unnecessary resource
2677   drain on the network.
2678
2679   A client, server, or proxy MAY close the transport connection at any
2680   time.  For example, a client might have started to send a new request
2681   at the same time that the server has decided to close the "idle"
2682   connection.  From the server's point of view, the connection is being
2683   closed while it was idle, but from the client's point of view, a
2684
2685
2686
2687Fielding, et al.        Expires February 25, 2012              [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1                 August 2011
2690
2691
2692   request is in progress.
2693
2694   This means that clients, servers, and proxies MUST be able to recover
2695   from asynchronous close events.  Client software SHOULD reopen the
2696   transport connection and retransmit the aborted sequence of requests
2697   without user interaction so long as the request sequence is
2698   idempotent (see Section 7.1.2 of [Part2]).  Non-idempotent request
2699   methods or sequences MUST NOT be automatically retried, although user
2700   agents MAY offer a human operator the choice of retrying the
2701   request(s).  Confirmation by user-agent software with semantic
2702   understanding of the application MAY substitute for user
2703   confirmation.  The automatic retry SHOULD NOT be repeated if the
2704   second sequence of requests fails.
2705
2706   Servers SHOULD always respond to at least one request per connection,
2707   if at all possible.  Servers SHOULD NOT close a connection in the
2708   middle of transmitting a response, unless a network or client failure
2709   is suspected.
2710
2711   Clients (including proxies) SHOULD limit the number of simultaneous
2712   connections that they maintain to a given server (including proxies).
2713
2714   Previous revisions of HTTP gave a specific number of connections as a
2715   ceiling, but this was found to be impractical for many applications.
2716   As a result, this specification does not mandate a particular maximum
2717   number of connections, but instead encourages clients to be
2718   conservative when opening multiple connections.
2719
2720   In particular, while using multiple connections avoids the "head-of-
2721   line blocking" problem (whereby a request that takes significant
2722   server-side processing and/or has a large payload can block
2723   subsequent requests on the same connection), each connection used
2724   consumes server resources (sometimes significantly), and furthermore
2725   using multiple connections can cause undesirable side effects in
2726   congested networks.
2727
2728   Note that servers might reject traffic that they deem abusive,
2729   including an excessive number of connections from a client.
2730
27317.2.  Message Transmission Requirements
2732
27337.2.1.  Persistent Connections and Flow Control
2734
2735   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2736   flow control mechanisms to resolve temporary overloads, rather than
2737   terminating connections with the expectation that clients will retry.
2738   The latter technique can exacerbate network congestion.
2739
2740
2741
2742
2743Fielding, et al.        Expires February 25, 2012              [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1                 August 2011
2746
2747
27487.2.2.  Monitoring Connections for Error Status Messages
2749
2750   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2751   the network connection for an error status code while it is
2752   transmitting the request.  If the client sees an error status code,
2753   it SHOULD immediately cease transmitting the body.  If the body is
2754   being sent using a "chunked" encoding (Section 6.2), a zero length
2755   chunk and empty trailer MAY be used to prematurely mark the end of
2756   the message.  If the body was preceded by a Content-Length header
2757   field, the client MUST close the connection.
2758
27597.2.3.  Use of the 100 (Continue) Status
2760
2761   The purpose of the 100 (Continue) status code (see Section 8.1.1 of
2762   [Part2]) is to allow a client that is sending a request message with
2763   a request body to determine if the origin server is willing to accept
2764   the request (based on the request header fields) before the client
2765   sends the request body.  In some cases, it might either be
2766   inappropriate or highly inefficient for the client to send the body
2767   if the server will reject the message without looking at the body.
2768
2769   Requirements for HTTP/1.1 clients:
2770
2771   o  If a client will wait for a 100 (Continue) response before sending
2772      the request body, it MUST send an Expect header field (Section 9.2
2773      of [Part2]) with the "100-continue" expectation.
2774
2775   o  A client MUST NOT send an Expect header field (Section 9.2 of
2776      [Part2]) with the "100-continue" expectation if it does not intend
2777      to send a request body.
2778
2779   Because of the presence of older implementations, the protocol allows
2780   ambiguous situations in which a client might send "Expect: 100-
2781   continue" without receiving either a 417 (Expectation Failed) or a
2782   100 (Continue) status code.  Therefore, when a client sends this
2783   header field to an origin server (possibly via a proxy) from which it
2784   has never seen a 100 (Continue) status code, the client SHOULD NOT
2785   wait for an indefinite period before sending the request body.
2786
2787   Requirements for HTTP/1.1 origin servers:
2788
2789   o  Upon receiving a request which includes an Expect header field
2790      with the "100-continue" expectation, an origin server MUST either
2791      respond with 100 (Continue) status code and continue to read from
2792      the input stream, or respond with a final status code.  The origin
2793      server MUST NOT wait for the request body before sending the 100
2794      (Continue) response.  If it responds with a final status code, it
2795      MAY close the transport connection or it MAY continue to read and
2796
2797
2798
2799Fielding, et al.        Expires February 25, 2012              [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1                 August 2011
2802
2803
2804      discard the rest of the request.  It MUST NOT perform the request
2805      method if it returns a final status code.
2806
2807   o  An origin server SHOULD NOT send a 100 (Continue) response if the
2808      request message does not include an Expect header field with the
2809      "100-continue" expectation, and MUST NOT send a 100 (Continue)
2810      response if such a request comes from an HTTP/1.0 (or earlier)
2811      client.  There is an exception to this rule: for compatibility
2812      with [RFC2068], a server MAY send a 100 (Continue) status code in
2813      response to an HTTP/1.1 PUT or POST request that does not include
2814      an Expect header field with the "100-continue" expectation.  This
2815      exception, the purpose of which is to minimize any client
2816      processing delays associated with an undeclared wait for 100
2817      (Continue) status code, applies only to HTTP/1.1 requests, and not
2818      to requests with any other HTTP-version value.
2819
2820   o  An origin server MAY omit a 100 (Continue) response if it has
2821      already received some or all of the request body for the
2822      corresponding request.
2823
2824   o  An origin server that sends a 100 (Continue) response MUST
2825      ultimately send a final status code, once the request body is
2826      received and processed, unless it terminates the transport
2827      connection prematurely.
2828
2829   o  If an origin server receives a request that does not include an
2830      Expect header field with the "100-continue" expectation, the
2831      request includes a request body, and the server responds with a
2832      final status code before reading the entire request body from the
2833      transport connection, then the server SHOULD NOT close the
2834      transport connection until it has read the entire request, or
2835      until the client closes the connection.  Otherwise, the client
2836      might not reliably receive the response message.  However, this
2837      requirement is not be construed as preventing a server from
2838      defending itself against denial-of-service attacks, or from badly
2839      broken client implementations.
2840
2841   Requirements for HTTP/1.1 proxies:
2842
2843   o  If a proxy receives a request that includes an Expect header field
2844      with the "100-continue" expectation, and the proxy either knows
2845      that the next-hop server complies with HTTP/1.1 or higher, or does
2846      not know the HTTP version of the next-hop server, it MUST forward
2847      the request, including the Expect header field.
2848
2849   o  If the proxy knows that the version of the next-hop server is
2850      HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2851      respond with a 417 (Expectation Failed) status code.
2852
2853
2854
2855Fielding, et al.        Expires February 25, 2012              [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1                 August 2011
2858
2859
2860   o  Proxies SHOULD maintain a record of the HTTP version numbers
2861      received from recently-referenced next-hop servers.
2862
2863   o  A proxy MUST NOT forward a 100 (Continue) response if the request
2864      message was received from an HTTP/1.0 (or earlier) client and did
2865      not include an Expect header field with the "100-continue"
2866      expectation.  This requirement overrides the general rule for
2867      forwarding of 1xx responses (see Section 8.1 of [Part2]).
2868
28697.2.4.  Client Behavior if Server Prematurely Closes Connection
2870
2871   If an HTTP/1.1 client sends a request which includes a request body,
2872   but which does not include an Expect header field with the "100-
2873   continue" expectation, and if the client is not directly connected to
2874   an HTTP/1.1 origin server, and if the client sees the connection
2875   close before receiving a status line from the server, the client
2876   SHOULD retry the request.  If the client does retry this request, it
2877   MAY use the following "binary exponential backoff" algorithm to be
2878   assured of obtaining a reliable response:
2879
2880   1.  Initiate a new connection to the server
2881
2882   2.  Transmit the request-line, header fields, and the CRLF that
2883       indicates the end of header fields.
2884
2885   3.  Initialize a variable R to the estimated round-trip time to the
2886       server (e.g., based on the time it took to establish the
2887       connection), or to a constant value of 5 seconds if the round-
2888       trip time is not available.
2889
2890   4.  Compute T = R * (2**N), where N is the number of previous retries
2891       of this request.
2892
2893   5.  Wait either for an error response from the server, or for T
2894       seconds (whichever comes first)
2895
2896   6.  If no error response is received, after T seconds transmit the
2897       body of the request.
2898
2899   7.  If client sees that the connection is closed prematurely, repeat
2900       from step 1 until the request is accepted, an error response is
2901       received, or the user becomes impatient and terminates the retry
2902       process.
2903
2904   If at any point an error status code is received, the client
2905
2906   o  SHOULD NOT continue and
2907
2908
2909
2910
2911Fielding, et al.        Expires February 25, 2012              [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1                 August 2011
2914
2915
2916   o  SHOULD close the connection if it has not completed sending the
2917      request message.
2918
29198.  Miscellaneous notes that might disappear
2920
29218.1.  Scheme aliases considered harmful
2922
2923   [[TBD-aliases-harmful: describe why aliases like webcal are
2924   harmful.]]
2925
29268.2.  Use of HTTP for proxy communication
2927
2928   [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
2929   protocols.]]
2930
29318.3.  Interception of HTTP for access control
2932
2933   [[TBD-intercept: Interception of HTTP traffic for initiating access
2934   control.]]
2935
29368.4.  Use of HTTP by other protocols
2937
2938   [[TBD-profiles: Profiles of HTTP defined by other protocol.
2939   Extensions of HTTP like WebDAV.]]
2940
29418.5.  Use of HTTP by media type specification
2942
2943   [[TBD-hypertext: Instructions on composing HTTP requests via
2944   hypertext formats.]]
2945
29469.  Header Field Definitions
2947
2948   This section defines the syntax and semantics of HTTP header fields
2949   related to message framing and transport protocols.
2950
29519.1.  Connection
2952
2953   The "Connection" header field allows the sender to specify options
2954   that are desired only for that particular connection.  Such
2955   connection options MUST be removed or replaced before the message can
2956   be forwarded downstream by a proxy or gateway.  This mechanism also
2957   allows the sender to indicate which HTTP header fields used in the
2958   message are only intended for the immediate recipient ("hop-by-hop"),
2959   as opposed to all recipients on the chain ("end-to-end"), enabling
2960   the message to be self-descriptive and allowing future connection-
2961   specific extensions to be deployed in HTTP without fear that they
2962   will be blindly forwarded by previously deployed intermediaries.
2963
2964
2965
2966
2967Fielding, et al.        Expires February 25, 2012              [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1                 August 2011
2970
2971
2972   The Connection header field's value has the following grammar:
2973
2974     Connection       = 1#connection-token
2975     connection-token = token
2976
2977   A proxy or gateway MUST parse a received Connection header field
2978   before a message is forwarded and, for each connection-token in this
2979   field, remove any header field(s) from the message with the same name
2980   as the connection-token, and then remove the Connection header field
2981   itself or replace it with the sender's own connection options for the
2982   forwarded message.
2983
2984   A sender MUST NOT include field-names in the Connection header field-
2985   value for fields that are defined as expressing constraints for all
2986   recipients in the request or response chain, such as the Cache-
2987   Control header field (Section 3.2 of [Part6]).
2988
2989   The connection options do not have to correspond to a header field
2990   present in the message, since a connection-specific header field
2991   might not be needed if there are no parameters associated with that
2992   connection option.  Recipients that trigger certain connection
2993   behavior based on the presence of connection options MUST do so based
2994   on the presence of the connection-token rather than only the presence
2995   of the optional header field.  In other words, if the connection
2996   option is received as a header field but not indicated within the
2997   Connection field-value, then the recipient MUST ignore the
2998   connection-specific header field because it has likely been forwarded
2999   by an intermediary that is only partially compliant.
3000
3001   When defining new connection options, specifications ought to
3002   carefully consider existing deployed header fields and ensure that
3003   the new connection-token does not share the same name as an unrelated
3004   header field that might already be deployed.  Defining a new
3005   connection-token essentially reserves that potential field-name for
3006   carrying additional information related to the connection option,
3007   since it would be unwise for senders to use that field-name for
3008   anything else.
3009
3010   HTTP/1.1 defines the "close" connection option for the sender to
3011   signal that the connection will be closed after completion of the
3012   response.  For example,
3013
3014     Connection: close
3015
3016   in either the request or the response header fields indicates that
3017   the connection SHOULD NOT be considered "persistent" (Section 7.1)
3018   after the current request/response is complete.
3019
3020
3021
3022
3023Fielding, et al.        Expires February 25, 2012              [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1                 August 2011
3026
3027
3028   An HTTP/1.1 client that does not support persistent connections MUST
3029   include the "close" connection option in every request message.
3030
3031   An HTTP/1.1 server that does not support persistent connections MUST
3032   include the "close" connection option in every response message that
3033   does not have a 1xx (Informational) status code.
3034
30359.2.  Content-Length
3036
3037   The "Content-Length" header field indicates the size of the message-
3038   body, in decimal number of octets, for any message other than a
3039   response to a HEAD request or a response with a status code of 304.
3040   In the case of a response to a HEAD request, Content-Length indicates
3041   the size of the payload body (not including any potential transfer-
3042   coding) that would have been sent had the request been a GET.  In the
3043   case of a 304 (Not Modified) response to a GET request, Content-
3044   Length indicates the size of the payload body (not including any
3045   potential transfer-coding) that would have been sent in a 200 (OK)
3046   response.
3047
3048     Content-Length = 1*DIGIT
3049
3050   An example is
3051
3052     Content-Length: 3495
3053
3054   Implementations SHOULD use this field to indicate the message-body
3055   length when no transfer-coding is being applied and the payload's
3056   body length can be determined prior to being transferred.
3057   Section 3.3 describes how recipients determine the length of a
3058   message-body.
3059
3060   Any Content-Length greater than or equal to zero is a valid value.
3061
3062   Note that the use of this field in HTTP is significantly different
3063   from the corresponding definition in MIME, where it is an optional
3064   field used within the "message/external-body" content-type.
3065
30669.3.  Date
3067
3068   The "Date" header field represents the date and time at which the
3069   message was originated, having the same semantics as the Origination
3070   Date Field (orig-date) defined in Section 3.6.1 of [RFC5322].  The
3071   field value is an HTTP-date, as described in Section 6.1; it MUST be
3072   sent in rfc1123-date format.
3073
3074     Date = HTTP-date
3075
3076
3077
3078
3079Fielding, et al.        Expires February 25, 2012              [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1                 August 2011
3082
3083
3084   An example is
3085
3086     Date: Tue, 15 Nov 1994 08:12:31 GMT
3087
3088   Origin servers MUST include a Date header field in all responses,
3089   except in these cases:
3090
3091   1.  If the response status code is 100 (Continue) or 101 (Switching
3092       Protocols), the response MAY include a Date header field, at the
3093       server's option.
3094
3095   2.  If the response status code conveys a server error, e.g., 500
3096       (Internal Server Error) or 503 (Service Unavailable), and it is
3097       inconvenient or impossible to generate a valid Date.
3098
3099   3.  If the server does not have a clock that can provide a reasonable
3100       approximation of the current time, its responses MUST NOT include
3101       a Date header field.  In this case, the rules in Section 9.3.1
3102       MUST be followed.
3103
3104   A received message that does not have a Date header field MUST be
3105   assigned one by the recipient if the message will be cached by that
3106   recipient.
3107
3108   Clients can use the Date header field as well; in order to keep
3109   request messages small, they are advised not to include it when it
3110   doesn't convey any useful information (as it is usually the case for
3111   requests that do not contain a payload).
3112
3113   The HTTP-date sent in a Date header field SHOULD NOT represent a date
3114   and time subsequent to the generation of the message.  It SHOULD
3115   represent the best available approximation of the date and time of
3116   message generation, unless the implementation has no means of
3117   generating a reasonably accurate date and time.  In theory, the date
3118   ought to represent the moment just before the payload is generated.
3119   In practice, the date can be generated at any time during the message
3120   origination without affecting its semantic value.
3121
31229.3.1.  Clockless Origin Server Operation
3123
3124   Some origin server implementations might not have a clock available.
3125   An origin server without a clock MUST NOT assign Expires or Last-
3126   Modified values to a response, unless these values were associated
3127   with the resource by a system or user with a reliable clock.  It MAY
3128   assign an Expires value that is known, at or before server
3129   configuration time, to be in the past (this allows "pre-expiration"
3130   of responses without storing separate Expires values for each
3131   resource).
3132
3133
3134
3135Fielding, et al.        Expires February 25, 2012              [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1                 August 2011
3138
3139
31409.4.  Host
3141
3142   The "Host" header field in a request provides the host and port
3143   information from the target resource's URI, enabling the origin
3144   server to distinguish between resources while servicing requests for
3145   multiple host names on a single IP address.  Since the Host field-
3146   value is critical information for handling a request, it SHOULD be
3147   sent as the first header field following the Request-Line.
3148
3149     Host = uri-host [ ":" port ] ; Section 2.7.1
3150
3151   A client MUST send a Host header field in all HTTP/1.1 request
3152   messages.  If the target resource's URI includes an authority
3153   component, then the Host field-value MUST be identical to that
3154   authority component after excluding any userinfo (Section 2.7.1).  If
3155   the authority component is missing or undefined for the target
3156   resource's URI, then the Host header field MUST be sent with an empty
3157   field-value.
3158
3159   For example, a GET request to the origin server for
3160   <http://www.example.org/pub/WWW/> would begin with:
3161
3162     GET /pub/WWW/ HTTP/1.1
3163     Host: www.example.org
3164
3165   The Host header field MUST be sent in an HTTP/1.1 request even if the
3166   request-target is in the form of an absolute-URI, since this allows
3167   the Host information to be forwarded through ancient HTTP/1.0 proxies
3168   that might not have implemented Host.
3169
3170   When an HTTP/1.1 proxy receives a request with a request-target in
3171   the form of an absolute-URI, the proxy MUST ignore the received Host
3172   header field (if any) and instead replace it with the host
3173   information of the request-target.  When a proxy forwards a request,
3174   it MUST generate the Host header field based on the received
3175   absolute-URI rather than the received Host.
3176
3177   Since the Host header field acts as an application-level routing
3178   mechanism, it is a frequent target for malware seeking to poison a
3179   shared cache or redirect a request to an unintended server.  An
3180   interception proxy is particularly vulnerable if it relies on the
3181   Host header field value for redirecting requests to internal servers,
3182   or for use as a cache key in a shared cache, without first verifying
3183   that the intercepted connection is targeting a valid IP address for
3184   that host.
3185
3186   A server MUST respond with a 400 (Bad Request) status code to any
3187   HTTP/1.1 request message that lacks a Host header field and to any
3188
3189
3190
3191Fielding, et al.        Expires February 25, 2012              [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1                 August 2011
3194
3195
3196   request message that contains more than one Host header field or a
3197   Host header field with an invalid field-value.
3198
3199   See Sections 4.2 and A.1.1 for other requirements relating to Host.
3200
32019.5.  TE
3202
3203   The "TE" header field indicates what extension transfer-codings it is
3204   willing to accept in the response, and whether or not it is willing
3205   to accept trailer fields in a chunked transfer-coding.
3206
3207   Its value consists of the keyword "trailers" and/or a comma-separated
3208   list of extension transfer-coding names with optional accept
3209   parameters (as described in Section 6.2).
3210
3211     TE        = #t-codings
3212     t-codings = "trailers" / ( transfer-extension [ te-params ] )
3213     te-params = OWS ";" OWS "q=" qvalue *( te-ext )
3214     te-ext    = OWS ";" OWS token [ "=" word ]
3215
3216   The presence of the keyword "trailers" indicates that the client is
3217   willing to accept trailer fields in a chunked transfer-coding, as
3218   defined in Section 6.2.1.  This keyword is reserved for use with
3219   transfer-coding values even though it does not itself represent a
3220   transfer-coding.
3221
3222   Examples of its use are:
3223
3224     TE: deflate
3225     TE:
3226     TE: trailers, deflate;q=0.5
3227
3228   The TE header field only applies to the immediate connection.
3229   Therefore, the keyword MUST be supplied within a Connection header
3230   field (Section 9.1) whenever TE is present in an HTTP/1.1 message.
3231
3232   A server tests whether a transfer-coding is acceptable, according to
3233   a TE field, using these rules:
3234
3235   1.  The "chunked" transfer-coding is always acceptable.  If the
3236       keyword "trailers" is listed, the client indicates that it is
3237       willing to accept trailer fields in the chunked response on
3238       behalf of itself and any downstream clients.  The implication is
3239       that, if given, the client is stating that either all downstream
3240       clients are willing to accept trailer fields in the forwarded
3241       response, or that it will attempt to buffer the response on
3242       behalf of downstream recipients.
3243
3244
3245
3246
3247Fielding, et al.        Expires February 25, 2012              [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1                 August 2011
3250
3251
3252       Note: HTTP/1.1 does not define any means to limit the size of a
3253       chunked response such that a client can be assured of buffering
3254       the entire response.
3255
3256   2.  If the transfer-coding being tested is one of the transfer-
3257       codings listed in the TE field, then it is acceptable unless it
3258       is accompanied by a qvalue of 0.  (As defined in Section 6.4, a
3259       qvalue of 0 means "not acceptable".)
3260
3261   3.  If multiple transfer-codings are acceptable, then the acceptable
3262       transfer-coding with the highest non-zero qvalue is preferred.
3263       The "chunked" transfer-coding always has a qvalue of 1.
3264
3265   If the TE field-value is empty or if no TE field is present, the only
3266   transfer-coding is "chunked".  A message with no transfer-coding is
3267   always acceptable.
3268
32699.6.  Trailer
3270
3271   The "Trailer" header field indicates that the given set of header
3272   fields is present in the trailer of a message encoded with chunked
3273   transfer-coding.
3274
3275     Trailer = 1#field-name
3276
3277   An HTTP/1.1 message SHOULD include a Trailer header field in a
3278   message using chunked transfer-coding with a non-empty trailer.
3279   Doing so allows the recipient to know which header fields to expect
3280   in the trailer.
3281
3282   If no Trailer header field is present, the trailer SHOULD NOT include
3283   any header fields.  See Section 6.2.1 for restrictions on the use of
3284   trailer fields in a "chunked" transfer-coding.
3285
3286   Message header fields listed in the Trailer header field MUST NOT
3287   include the following header fields:
3288
3289   o  Transfer-Encoding
3290
3291   o  Content-Length
3292
3293   o  Trailer
3294
32959.7.  Transfer-Encoding
3296
3297   The "Transfer-Encoding" header field indicates what transfer-codings
3298   (if any) have been applied to the message body.  It differs from
3299   Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings
3300
3301
3302
3303Fielding, et al.        Expires February 25, 2012              [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1                 August 2011
3306
3307
3308   are a property of the message (and therefore are removed by
3309   intermediaries), whereas content-codings are not.
3310
3311     Transfer-Encoding = 1#transfer-coding
3312
3313   Transfer-codings are defined in Section 6.2.  An example is:
3314
3315     Transfer-Encoding: chunked
3316
3317   If multiple encodings have been applied to a representation, the
3318   transfer-codings MUST be listed in the order in which they were
3319   applied.  Additional information about the encoding parameters MAY be
3320   provided by other header fields not defined by this specification.
3321
3322   Many older HTTP/1.0 applications do not understand the Transfer-
3323   Encoding header field.
3324
33259.8.  Upgrade
3326
3327   The "Upgrade" header field allows the client to specify what
3328   additional communication protocols it would like to use, if the
3329   server chooses to switch protocols.  Servers can use it to indicate
3330   what protocols they are willing to switch to.
3331
3332     Upgrade = 1#product
3333
3334   For example,
3335
3336     Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3337
3338   The Upgrade header field is intended to provide a simple mechanism
3339   for transition from HTTP/1.1 to some other, incompatible protocol.
3340   It does so by allowing the client to advertise its desire to use
3341   another protocol, such as a later version of HTTP with a higher major
3342   version number, even though the current request has been made using
3343   HTTP/1.1.  This eases the difficult transition between incompatible
3344   protocols by allowing the client to initiate a request in the more
3345   commonly supported protocol while indicating to the server that it
3346   would like to use a "better" protocol if available (where "better" is
3347   determined by the server, possibly according to the nature of the
3348   request method or target resource).
3349
3350   The Upgrade header field only applies to switching application-layer
3351   protocols upon the existing transport-layer connection.  Upgrade
3352   cannot be used to insist on a protocol change; its acceptance and use
3353   by the server is optional.  The capabilities and nature of the
3354   application-layer communication after the protocol change is entirely
3355   dependent upon the new protocol chosen, although the first action
3356
3357
3358
3359Fielding, et al.        Expires February 25, 2012              [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1                 August 2011
3362
3363
3364   after changing the protocol MUST be a response to the initial HTTP
3365   request containing the Upgrade header field.
3366
3367   The Upgrade header field only applies to the immediate connection.
3368   Therefore, the upgrade keyword MUST be supplied within a Connection
3369   header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1
3370   message.
3371
3372   The Upgrade header field cannot be used to indicate a switch to a
3373   protocol on a different connection.  For that purpose, it is more
3374   appropriate to use a 3xx redirection response (Section 8.3 of
3375   [Part2]).
3376
3377   Servers MUST include the "Upgrade" header field in 101 (Switching
3378   Protocols) responses to indicate which protocol(s) are being switched
3379   to, and MUST include it in 426 (Upgrade Required) responses to
3380   indicate acceptable protocols to upgrade to.  Servers MAY include it
3381   in any other response to indicate that they are willing to upgrade to
3382   one of the specified protocols.
3383
3384   This specification only defines the protocol name "HTTP" for use by
3385   the family of Hypertext Transfer Protocols, as defined by the HTTP
3386   version rules of Section 2.6 and future updates to this
3387   specification.  Additional tokens can be registered with IANA using
3388   the registration procedure defined below.
3389
33909.8.1.  Upgrade Token Registry
3391
3392   The HTTP Upgrade Token Registry defines the name space for product
3393   tokens used to identify protocols in the Upgrade header field.  Each
3394   registered token is associated with contact information and an
3395   optional set of specifications that details how the connection will
3396   be processed after it has been upgraded.
3397
3398   Registrations are allowed on a First Come First Served basis as
3399   described in Section 4.1 of [RFC5226].  The specifications need not
3400   be IETF documents or be subject to IESG review.  Registrations are
3401   subject to the following rules:
3402
3403   1.  A token, once registered, stays registered forever.
3404
3405   2.  The registration MUST name a responsible party for the
3406       registration.
3407
3408   3.  The registration MUST name a point of contact.
3409
3410   4.  The registration MAY name a set of specifications associated with
3411       that token.  Such specifications need not be publicly available.
3412
3413
3414
3415Fielding, et al.        Expires February 25, 2012              [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1                 August 2011
3418
3419
3420   5.  The responsible party MAY change the registration at any time.
3421       The IANA will keep a record of all such changes, and make them
3422       available upon request.
3423
3424   6.  The responsible party for the first registration of a "product"
3425       token MUST approve later registrations of a "version" token
3426       together with that "product" token before they can be registered.
3427
3428   7.  If absolutely required, the IESG MAY reassign the responsibility
3429       for a token.  This will normally only be used in the case when a
3430       responsible party cannot be contacted.
3431
34329.9.  Via
3433
3434   The "Via" header field MUST be sent by a proxy or gateway to indicate
3435   the intermediate protocols and recipients between the user agent and
3436   the server on requests, and between the origin server and the client
3437   on responses.  It is analogous to the "Received" field used by email
3438   systems (Section 3.6.7 of [RFC5322]) and is intended to be used for
3439   tracking message forwards, avoiding request loops, and identifying
3440   the protocol capabilities of all senders along the request/response
3441   chain.
3442
3443     Via               = 1#( received-protocol RWS received-by
3444                             [ RWS comment ] )
3445     received-protocol = [ protocol-name "/" ] protocol-version
3446     protocol-name     = token
3447     protocol-version  = token
3448     received-by       = ( uri-host [ ":" port ] ) / pseudonym
3449     pseudonym         = token
3450
3451   The received-protocol indicates the protocol version of the message
3452   received by the server or client along each segment of the request/
3453   response chain.  The received-protocol version is appended to the Via
3454   field value when the message is forwarded so that information about
3455   the protocol capabilities of upstream applications remains visible to
3456   all recipients.
3457
3458   The protocol-name is excluded if and only if it would be "HTTP".  The
3459   received-by field is normally the host and optional port number of a
3460   recipient server or client that subsequently forwarded the message.
3461   However, if the real host is considered to be sensitive information,
3462   it MAY be replaced by a pseudonym.  If the port is not given, it MAY
3463   be assumed to be the default port of the received-protocol.
3464
3465   Multiple Via field values represent each proxy or gateway that has
3466   forwarded the message.  Each recipient MUST append its information
3467   such that the end result is ordered according to the sequence of
3468
3469
3470
3471Fielding, et al.        Expires February 25, 2012              [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1                 August 2011
3474
3475
3476   forwarding applications.
3477
3478   Comments MAY be used in the Via header field to identify the software
3479   of each recipient, analogous to the User-Agent and Server header
3480   fields.  However, all comments in the Via field are optional and MAY
3481   be removed by any recipient prior to forwarding the message.
3482
3483   For example, a request message could be sent from an HTTP/1.0 user
3484   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
3485   forward the request to a public proxy at p.example.net, which
3486   completes the request by forwarding it to the origin server at
3487   www.example.com.  The request received by www.example.com would then
3488   have the following Via header field:
3489
3490     Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
3491
3492   A proxy or gateway used as a portal through a network firewall SHOULD
3493   NOT forward the names and ports of hosts within the firewall region
3494   unless it is explicitly enabled to do so.  If not enabled, the
3495   received-by host of any host behind the firewall SHOULD be replaced
3496   by an appropriate pseudonym for that host.
3497
3498   For organizations that have strong privacy requirements for hiding
3499   internal structures, a proxy or gateway MAY combine an ordered
3500   subsequence of Via header field entries with identical received-
3501   protocol values into a single such entry.  For example,
3502
3503     Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
3504
3505   could be collapsed to
3506
3507     Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
3508
3509   Senders SHOULD NOT combine multiple entries unless they are all under
3510   the same organizational control and the hosts have already been
3511   replaced by pseudonyms.  Senders MUST NOT combine entries which have
3512   different received-protocol values.
3513
351410.  IANA Considerations
3515
351610.1.  Header Field Registration
3517
3518   The Message Header Field Registry located at <http://www.iana.org/
3519   assignments/message-headers/message-header-index.html> shall be
3520   updated with the permanent registrations below (see [RFC3864]):
3521
3522
3523
3524
3525
3526
3527Fielding, et al.        Expires February 25, 2012              [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1                 August 2011
3530
3531
3532   +-------------------+----------+----------+-------------+
3533   | Header Field Name | Protocol | Status   | Reference   |
3534   +-------------------+----------+----------+-------------+
3535   | Connection        | http     | standard | Section 9.1 |
3536   | Content-Length    | http     | standard | Section 9.2 |
3537   | Date              | http     | standard | Section 9.3 |
3538   | Host              | http     | standard | Section 9.4 |
3539   | TE                | http     | standard | Section 9.5 |
3540   | Trailer           | http     | standard | Section 9.6 |
3541   | Transfer-Encoding | http     | standard | Section 9.7 |
3542   | Upgrade           | http     | standard | Section 9.8 |
3543   | Via               | http     | standard | Section 9.9 |
3544   +-------------------+----------+----------+-------------+
3545
3546   Furthermore, the header field name "Close" shall be registered as
3547   "reserved", as its use as HTTP header field would be in conflict with
3548   the use of the "close" connection option for the "Connection" header
3549   field (Section 9.1).
3550
3551   +-------------------+----------+----------+--------------+
3552   | Header Field Name | Protocol | Status   | Reference    |
3553   +-------------------+----------+----------+--------------+
3554   | Close             | http     | reserved | Section 10.1 |
3555   +-------------------+----------+----------+--------------+
3556
3557   The change controller is: "IETF (iesg@ietf.org) - Internet
3558   Engineering Task Force".
3559
356010.2.  URI Scheme Registration
3561
3562   The entries for the "http" and "https" URI Schemes in the registry
3563   located at <http://www.iana.org/assignments/uri-schemes.html> shall
3564   be updated to point to Sections 2.7.1 and 2.7.2 of this document (see
3565   [RFC4395]).
3566
356710.3.  Internet Media Type Registrations
3568
3569   This document serves as the specification for the Internet media
3570   types "message/http" and "application/http".  The following is to be
3571   registered with IANA (see [RFC4288]).
3572
357310.3.1.  Internet Media Type message/http
3574
3575   The message/http type can be used to enclose a single HTTP request or
3576   response message, provided that it obeys the MIME restrictions for
3577   all "message" types regarding line length and encodings.
3578
3579
3580
3581
3582
3583Fielding, et al.        Expires February 25, 2012              [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1                 August 2011
3586
3587
3588   Type name:  message
3589
3590   Subtype name:  http
3591
3592   Required parameters:  none
3593
3594   Optional parameters:  version, msgtype
3595
3596      version:  The HTTP-Version number of the enclosed message (e.g.,
3597         "1.1").  If not present, the version can be determined from the
3598         first line of the body.
3599
3600      msgtype:  The message type -- "request" or "response".  If not
3601         present, the type can be determined from the first line of the
3602         body.
3603
3604   Encoding considerations:  only "7bit", "8bit", or "binary" are
3605      permitted
3606
3607   Security considerations:  none
3608
3609   Interoperability considerations:  none
3610
3611   Published specification:  This specification (see Section 10.3.1).
3612
3613   Applications that use this media type:
3614
3615   Additional information:
3616
3617      Magic number(s):  none
3618
3619      File extension(s):  none
3620
3621      Macintosh file type code(s):  none
3622
3623   Person and email address to contact for further information:  See
3624      Authors Section.
3625
3626   Intended usage:  COMMON
3627
3628   Restrictions on usage:  none
3629
3630   Author/Change controller:  IESG
3631
3632
3633
3634
3635
3636
3637
3638
3639Fielding, et al.        Expires February 25, 2012              [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1                 August 2011
3642
3643
364410.3.2.  Internet Media Type application/http
3645
3646   The application/http type can be used to enclose a pipeline of one or
3647   more HTTP request or response messages (not intermixed).
3648
3649   Type name:  application
3650
3651   Subtype name:  http
3652
3653   Required parameters:  none
3654
3655   Optional parameters:  version, msgtype
3656
3657      version:  The HTTP-Version number of the enclosed messages (e.g.,
3658         "1.1").  If not present, the version can be determined from the
3659         first line of the body.
3660
3661      msgtype:  The message type -- "request" or "response".  If not
3662         present, the type can be determined from the first line of the
3663         body.
3664
3665   Encoding considerations:  HTTP messages enclosed by this type are in
3666      "binary" format; use of an appropriate Content-Transfer-Encoding
3667      is required when transmitted via E-mail.
3668
3669   Security considerations:  none
3670
3671   Interoperability considerations:  none
3672
3673   Published specification:  This specification (see Section 10.3.2).
3674
3675   Applications that use this media type:
3676
3677   Additional information:
3678
3679      Magic number(s):  none
3680
3681      File extension(s):  none
3682
3683      Macintosh file type code(s):  none
3684
3685   Person and email address to contact for further information:  See
3686      Authors Section.
3687
3688   Intended usage:  COMMON
3689
3690
3691
3692
3693
3694
3695Fielding, et al.        Expires February 25, 2012              [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1                 August 2011
3698
3699
3700   Restrictions on usage:  none
3701
3702   Author/Change controller:  IESG
3703
370410.4.  Transfer Coding Registry
3705
3706   The registration procedure for HTTP Transfer Codings is now defined
3707   by Section 6.2.3 of this document.
3708
3709   The HTTP Transfer Codings Registry located at
3710   <http://www.iana.org/assignments/http-parameters> shall be updated
3711   with the registrations below:
3712
3713   +----------+--------------------------------------+-----------------+
3714   | Name     | Description                          | Reference       |
3715   +----------+--------------------------------------+-----------------+
3716   | chunked  | Transfer in a series of chunks       | Section 6.2.1   |
3717   | compress | UNIX "compress" program method       | Section 6.2.2.1 |
3718   | deflate  | "deflate" compression mechanism      | Section 6.2.2.2 |
3719   |          | ([RFC1951]) used inside the "zlib"   |                 |
3720   |          | data format ([RFC1950])              |                 |
3721   | gzip     | Same as GNU zip [RFC1952]            | Section 6.2.2.3 |
3722   +----------+--------------------------------------+-----------------+
3723
372410.5.  Upgrade Token Registration
3725
3726   The registration procedure for HTTP Upgrade Tokens -- previously
3727   defined in Section 7.2 of [RFC2817] -- is now defined by
3728   Section 9.8.1 of this document.
3729
3730   The HTTP Status Code Registry located at
3731   <http://www.iana.org/assignments/http-upgrade-tokens/> shall be
3732   updated with the registration below:
3733
3734   +-------+---------------------------+-------------------------------+
3735   | Value | Description               | Reference                     |
3736   +-------+---------------------------+-------------------------------+
3737   | HTTP  | Hypertext Transfer        | Section 2.6 of this           |
3738   |       | Protocol                  | specification                 |
3739   +-------+---------------------------+-------------------------------+
3740
374111.  Security Considerations
3742
3743   This section is meant to inform application developers, information
3744   providers, and users of the security limitations in HTTP/1.1 as
3745   described by this document.  The discussion does not include
3746   definitive solutions to the problems revealed, though it does make
3747   some suggestions for reducing security risks.
3748
3749
3750
3751Fielding, et al.        Expires February 25, 2012              [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1                 August 2011
3754
3755
375611.1.  Personal Information
3757
3758   HTTP clients are often privy to large amounts of personal information
3759   (e.g., the user's name, location, mail address, passwords, encryption
3760   keys, etc.), and SHOULD be very careful to prevent unintentional
3761   leakage of this information.  We very strongly recommend that a
3762   convenient interface be provided for the user to control
3763   dissemination of such information, and that designers and
3764   implementors be particularly careful in this area.  History shows
3765   that errors in this area often create serious security and/or privacy
3766   problems and generate highly adverse publicity for the implementor's
3767   company.
3768
376911.2.  Abuse of Server Log Information
3770
3771   A server is in the position to save personal data about a user's
3772   requests which might identify their reading patterns or subjects of
3773   interest.  This information is clearly confidential in nature and its
3774   handling can be constrained by law in certain countries.  People
3775   using HTTP to provide data are responsible for ensuring that such
3776   material is not distributed without the permission of any individuals
3777   that are identifiable by the published results.
3778
377911.3.  Attacks Based On File and Path Names
3780
3781   Implementations of HTTP origin servers SHOULD be careful to restrict
3782   the documents returned by HTTP requests to be only those that were
3783   intended by the server administrators.  If an HTTP server translates
3784   HTTP URIs directly into file system calls, the server MUST take
3785   special care not to serve files that were not intended to be
3786   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
3787   other operating systems use ".." as a path component to indicate a
3788   directory level above the current one.  On such a system, an HTTP
3789   server MUST disallow any such construct in the request-target if it
3790   would otherwise allow access to a resource outside those intended to
3791   be accessible via the HTTP server.  Similarly, files intended for
3792   reference only internally to the server (such as access control
3793   files, configuration files, and script code) MUST be protected from
3794   inappropriate retrieval, since they might contain sensitive
3795   information.  Experience has shown that minor bugs in such HTTP
3796   server implementations have turned into security risks.
3797
379811.4.  DNS-related Attacks
3799
3800   HTTP clients rely heavily on the Domain Name Service (DNS), and are
3801   thus generally prone to security attacks based on the deliberate
3802   misassociation of IP addresses and DNS names not protected by DNSSec.
3803   Clients need to be cautious in assuming the validity of an IP number/
3804
3805
3806
3807Fielding, et al.        Expires February 25, 2012              [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 1                 August 2011
3810
3811
3812   DNS name association unless the response is protected by DNSSec
3813   ([RFC4033]).
3814
381511.5.  Proxies and Caching
3816
3817   By their very nature, HTTP proxies are men-in-the-middle, and
3818   represent an opportunity for man-in-the-middle attacks.  Compromise
3819   of the systems on which the proxies run can result in serious
3820   security and privacy problems.  Proxies have access to security-
3821   related information, personal information about individual users and
3822   organizations, and proprietary information belonging to users and
3823   content providers.  A compromised proxy, or a proxy implemented or
3824   configured without regard to security and privacy considerations,
3825   might be used in the commission of a wide range of potential attacks.
3826
3827   Proxy operators need to protect the systems on which proxies run as
3828   they would protect any system that contains or transports sensitive
3829   information.  In particular, log information gathered at proxies
3830   often contains highly sensitive personal information, and/or
3831   information about organizations.  Log information needs to be
3832   carefully guarded, and appropriate guidelines for use need to be
3833   developed and followed.  (Section 11.2).
3834
3835   Proxy implementors need to consider the privacy and security
3836   implications of their design and coding decisions, and of the
3837   configuration options they provide to proxy operators (especially the
3838   default configuration).
3839
3840   Users of a proxy need to be aware that proxies are no trustworthier
3841   than the people who run them; HTTP itself cannot solve this problem.
3842
3843   The judicious use of cryptography, when appropriate, might suffice to
3844   protect against a broad range of security and privacy attacks.  Such
3845   cryptography is beyond the scope of the HTTP/1.1 specification.
3846
384711.6.  Protocol Element Size Overflows
3848
3849   Because HTTP uses mostly textual, character-delimited fields,
3850   attackers can overflow buffers in implementations, and/or perform a
3851   Denial of Service against implementations that accept fields with
3852   unlimited lengths.
3853
3854   To promote interoperability, this specification makes specific
3855   recommendations for size limits on request-targets (Section 4.1.2)
3856   and blocks of header fields (Section 3.2).  These are minimum
3857   recommendations, chosen to be supportable even by implementations
3858   with limited resources; it is expected that most implementations will
3859   choose substantially higher limits.
3860
3861
3862
3863Fielding, et al.        Expires February 25, 2012              [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 1                 August 2011
3866
3867
3868   This specification also provides a way for servers to reject messages
3869   that have request-targets that are too long (Section 8.4.15 of
3870   [Part2]) or request entities that are too large (Section 8.4 of
3871   [Part2]).
3872
3873   Other fields (including but not limited to request methods, response
3874   status phrases, header field-names, and body chunks) SHOULD be
3875   limited by implementations carefully, so as to not impede
3876   interoperability.
3877
387811.7.  Denial of Service Attacks on Proxies
3879
3880   They exist.  They are hard to defend against.  Research continues.
3881   Beware.
3882
388312.  Acknowledgments
3884
3885   This document revision builds on the work that went into RFC 2616 and
3886   its predecessors.  See Section 16 of [RFC2616] for detailed
3887   acknowledgements.
3888
3889   [[todoacks: Insert HTTPbis-specific acknowledgements here.]]
3890
389113.  References
3892
389313.1.  Normative References
3894
3895   [ISO-8859-1]  International Organization for Standardization,
3896                 "Information technology -- 8-bit single-byte coded
3897                 graphic character sets -- Part 1: Latin alphabet No.
3898                 1", ISO/IEC 8859-1:1998, 1998.
3899
3900   [Part2]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3901                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3902                 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
3903                 Semantics", draft-ietf-httpbis-p2-semantics-16 (work in
3904                 progress), August 2011.
3905
3906   [Part3]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3907                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3908                 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
3909                 Payload and Content Negotiation",
3910                 draft-ietf-httpbis-p3-payload-16 (work in progress),
3911                 August 2011.
3912
3913   [Part6]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3914                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3915                 Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
3916
3917
3918
3919Fielding, et al.        Expires February 25, 2012              [Page 70]
3920
3921Internet-Draft              HTTP/1.1, Part 1                 August 2011
3922
3923
3924                 "HTTP/1.1, part 6: Caching",
3925                 draft-ietf-httpbis-p6-cache-16 (work in progress),
3926                 August 2011.
3927
3928   [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
3929                 Format Specification version 3.3", RFC 1950, May 1996.
3930
3931                 RFC 1950 is an Informational RFC, thus it might be less
3932                 stable than this specification.  On the other hand,
3933                 this downward reference was present since the
3934                 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3935                 it is unlikely to cause problems in practice.  See also
3936                 [BCP97].
3937
3938   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
3939                 Specification version 1.3", RFC 1951, May 1996.
3940
3941                 RFC 1951 is an Informational RFC, thus it might be less
3942                 stable than this specification.  On the other hand,
3943                 this downward reference was present since the
3944                 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3945                 it is unlikely to cause problems in practice.  See also
3946                 [BCP97].
3947
3948   [RFC1952]     Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
3949                 G. Randers-Pehrson, "GZIP file format specification
3950                 version 4.3", RFC 1952, May 1996.
3951
3952                 RFC 1952 is an Informational RFC, thus it might be less
3953                 stable than this specification.  On the other hand,
3954                 this downward reference was present since the
3955                 publication of RFC 2068 in 1997 ([RFC2068]), therefore
3956                 it is unlikely to cause problems in practice.  See also
3957                 [BCP97].
3958
3959   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
3960                 Requirement Levels", BCP 14, RFC 2119, March 1997.
3961
3962   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
3963                 "Uniform Resource Identifier (URI): Generic Syntax",
3964                 STD 66, RFC 3986, January 2005.
3965
3966   [RFC5234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
3967                 Syntax Specifications: ABNF", STD 68, RFC 5234,
3968                 January 2008.
3969
3970   [USASCII]     American National Standards Institute, "Coded Character
3971                 Set -- 7-bit American Standard Code for Information
3972
3973
3974
3975Fielding, et al.        Expires February 25, 2012              [Page 71]
3976
3977Internet-Draft              HTTP/1.1, Part 1                 August 2011
3978
3979
3980                 Interchange", ANSI X3.4, 1986.
3981
398213.2.  Informative References
3983
3984   [BCP97]       Klensin, J. and S. Hartman, "Handling Normative
3985                 References to Standards-Track Documents", BCP 97,
3986                 RFC 4897, June 2007.
3987
3988   [Kri2001]     Kristol, D., "HTTP Cookies: Standards, Privacy, and
3989                 Politics", ACM Transactions on Internet Technology Vol.
3990                 1, #2, November 2001,
3991                 <http://arxiv.org/abs/cs.SE/0105018>.
3992
3993   [Nie1997]     Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
3994                 and C. Lilley, "Network Performance Effects of
3995                 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
3996                 SIGCOMM '97 conference on Applications, technologies,
3997                 architectures, and protocols for computer communication
3998                 SIGCOMM '97, September 1997,
3999                 <http://doi.acm.org/10.1145/263105.263157>.
4000
4001   [Pad1995]     Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
4002                 Computer Networks and ISDN Systems v. 28, pp. 25-35,
4003                 December 1995,
4004                 <http://portal.acm.org/citation.cfm?id=219094>.
4005
4006   [RFC1123]     Braden, R., "Requirements for Internet Hosts -
4007                 Application and Support", STD 3, RFC 1123,
4008                 October 1989.
4009
4010   [RFC1919]     Chatel, M., "Classical versus Transparent IP Proxies",
4011                 RFC 1919, March 1996.
4012
4013   [RFC1945]     Berners-Lee, T., Fielding, R., and H. Nielsen,
4014                 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
4015                 May 1996.
4016
4017   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
4018                 Mail Extensions (MIME) Part One: Format of Internet
4019                 Message Bodies", RFC 2045, November 1996.
4020
4021   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
4022                 Extensions) Part Three: Message Header Extensions for
4023                 Non-ASCII Text", RFC 2047, November 1996.
4024
4025   [RFC2068]     Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
4026                 T. Berners-Lee, "Hypertext Transfer Protocol --
4027                 HTTP/1.1", RFC 2068, January 1997.
4028
4029
4030
4031Fielding, et al.        Expires February 25, 2012              [Page 72]
4032
4033Internet-Draft              HTTP/1.1, Part 1                 August 2011
4034
4035
4036   [RFC2145]     Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
4037                 "Use and Interpretation of HTTP Version Numbers",
4038                 RFC 2145, May 1997.
4039
4040   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
4041                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
4042                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
4043
4044   [RFC2817]     Khare, R. and S. Lawrence, "Upgrading to TLS Within
4045                 HTTP/1.1", RFC 2817, May 2000.
4046
4047   [RFC2818]     Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
4048
4049   [RFC2965]     Kristol, D. and L. Montulli, "HTTP State Management
4050                 Mechanism", RFC 2965, October 2000.
4051
4052   [RFC3040]     Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
4053                 Replication and Caching Taxonomy", RFC 3040,
4054                 January 2001.
4055
4056   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
4057                 Procedures for Message Header Fields", BCP 90,
4058                 RFC 3864, September 2004.
4059
4060   [RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
4061                 Rose, "DNS Security Introduction and Requirements",
4062                 RFC 4033, March 2005.
4063
4064   [RFC4288]     Freed, N. and J. Klensin, "Media Type Specifications
4065                 and Registration Procedures", BCP 13, RFC 4288,
4066                 December 2005.
4067
4068   [RFC4395]     Hansen, T., Hardie, T., and L. Masinter, "Guidelines
4069                 and Registration Procedures for New URI Schemes",
4070                 BCP 115, RFC 4395, February 2006.
4071
4072   [RFC4559]     Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
4073                 Kerberos and NTLM HTTP Authentication in Microsoft
4074                 Windows", RFC 4559, June 2006.
4075
4076   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
4077                 an IANA Considerations Section in RFCs", BCP 26,
4078                 RFC 5226, May 2008.
4079
4080   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
4081                 October 2008.
4082
4083   [RFC6265]     Barth, A., "HTTP State Management Mechanism", RFC 6265,
4084
4085
4086
4087Fielding, et al.        Expires February 25, 2012              [Page 73]
4088
4089Internet-Draft              HTTP/1.1, Part 1                 August 2011
4090
4091
4092                 April 2011.
4093
4094   [Spe]         Spero, S., "Analysis of HTTP Performance Problems",
4095                 <http://sunsite.unc.edu/mdma-release/http-prob.html>.
4096
4097   [Tou1998]     Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
4098                 HTTP Performance", ISI Research Report ISI/RR-98-463,
4099                 Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
4100
4101                 (original report dated Aug. 1996)
4102
4103Appendix A.  HTTP Version History
4104
4105   HTTP has been in use by the World-Wide Web global information
4106   initiative since 1990.  The first version of HTTP, later referred to
4107   as HTTP/0.9, was a simple protocol for hypertext data transfer across
4108   the Internet with only a single request method (GET) and no metadata.
4109   HTTP/1.0, as defined by [RFC1945], added a range of request methods
4110   and MIME-like messaging that could include metadata about the data
4111   transferred and modifiers on the request/response semantics.
4112   However, HTTP/1.0 did not sufficiently take into consideration the
4113   effects of hierarchical proxies, caching, the need for persistent
4114   connections, or name-based virtual hosts.  The proliferation of
4115   incompletely-implemented applications calling themselves "HTTP/1.0"
4116   further necessitated a protocol version change in order for two
4117   communicating applications to determine each other's true
4118   capabilities.
4119
4120   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
4121   requirements that enable reliable implementations, adding only those
4122   new features that will either be safely ignored by an HTTP/1.0
4123   recipient or only sent when communicating with a party advertising
4124   compliance with HTTP/1.1.
4125
4126   It is beyond the scope of a protocol specification to mandate
4127   compliance with previous versions.  HTTP/1.1 was deliberately
4128   designed, however, to make supporting previous versions easy.  We
4129   would expect a general-purpose HTTP/1.1 server to understand any
4130   valid request in the format of HTTP/1.0 and respond appropriately
4131   with an HTTP/1.1 message that only uses features understood (or
4132   safely ignored) by HTTP/1.0 clients.  Likewise, would expect an
4133   HTTP/1.1 client to understand any valid HTTP/1.0 response.
4134
4135   Since HTTP/0.9 did not support header fields in a request, there is
4136   no mechanism for it to support name-based virtual hosts (selection of
4137   resource by inspection of the Host header field).  Any server that
4138   implements name-based virtual hosts ought to disable support for
4139   HTTP/0.9.  Most requests that appear to be HTTP/0.9 are, in fact,
4140
4141
4142
4143Fielding, et al.        Expires February 25, 2012              [Page 74]
4144
4145Internet-Draft              HTTP/1.1, Part 1                 August 2011
4146
4147
4148   badly constructed HTTP/1.x requests wherein a buggy client failed to
4149   properly encode linear whitespace found in a URI reference and placed
4150   in the request-target.
4151
4152A.1.  Changes from HTTP/1.0
4153
4154   This section summarizes major differences between versions HTTP/1.0
4155   and HTTP/1.1.
4156
4157A.1.1.  Multi-homed Web Servers
4158
4159   The requirements that clients and servers support the Host header
4160   field (Section 9.4), report an error if it is missing from an
4161   HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among
4162   the most important changes defined by HTTP/1.1.
4163
4164   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
4165   addresses and servers; there was no other established mechanism for
4166   distinguishing the intended server of a request than the IP address
4167   to which that request was directed.  The Host header field was
4168   introduced during the development of HTTP/1.1 and, though it was
4169   quickly implemented by most HTTP/1.0 browsers, additional
4170   requirements were placed on all HTTP/1.1 requests in order to ensure
4171   complete adoption.  At the time of this writing, most HTTP-based
4172   services are dependent upon the Host header field for targeting
4173   requests.
4174
4175A.1.2.  Keep-Alive Connections
4176
4177   For most implementations of HTTP/1.0, each connection is established
4178   by the client prior to the request and closed by the server after
4179   sending the response.  However, some implementations implement the
4180   Keep-Alive version of persistent connections described in Section
4181   19.7.1 of [RFC2068].
4182
4183   Some clients and servers might wish to be compatible with some
4184   previous implementations of persistent connections in HTTP/1.0
4185   clients and servers.  Persistent connections in HTTP/1.0 are
4186   explicitly negotiated as they are not the default behavior.  HTTP/1.0
4187   experimental implementations of persistent connections are faulty,
4188   and the new facilities in HTTP/1.1 are designed to rectify these
4189   problems.  The problem was that some existing HTTP/1.0 clients might
4190   send Keep-Alive to a proxy server that doesn't understand Connection,
4191   which would then erroneously forward it to the next inbound server,
4192   which would establish the Keep-Alive connection and result in a hung
4193   HTTP/1.0 proxy waiting for the close on the response.  The result is
4194   that HTTP/1.0 clients must be prevented from using Keep-Alive when
4195   talking to proxies.
4196
4197
4198
4199Fielding, et al.        Expires February 25, 2012              [Page 75]
4200
4201Internet-Draft              HTTP/1.1, Part 1                 August 2011
4202
4203
4204   However, talking to proxies is the most important use of persistent
4205   connections, so that prohibition is clearly unacceptable.  Therefore,
4206   we need some other mechanism for indicating a persistent connection
4207   is desired, which is safe to use even when talking to an old proxy
4208   that ignores Connection.  Persistent connections are the default for
4209   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
4210   declaring non-persistence.  See Section 9.1.
4211
4212A.2.  Changes from RFC 2616
4213
4214   Empty list elements in list productions have been deprecated.
4215   (Section 1.2.1)
4216
4217   Rules about implicit linear whitespace between certain grammar
4218   productions have been removed; now it's only allowed when
4219   specifically pointed out in the ABNF.  (Section 1.2.2)
4220
4221   Clarify that the string "HTTP" in the HTTP-Version ABFN production is
4222   case sensitive.  Restrict the version numbers to be single digits due
4223   to the fact that implementations are known to handle multi-digit
4224   version numbers incorrectly.  (Section 2.6)
4225
4226   Require that invalid whitespace around field-names be rejected.
4227   (Section 3.2)
4228
4229   The NUL octet is no longer allowed in comment and quoted-string text.
4230   The quoted-pair rule no longer allows escaping control characters
4231   other than HTAB.  Non-ASCII content in header fields and reason
4232   phrase has been obsoleted and made opaque (the TEXT rule was
4233   removed).  (Section 3.2.3)
4234
4235   Require recipients to handle bogus Content-Length header fields as
4236   errors.  (Section 3.3)
4237
4238   Remove reference to non-existent identity transfer-coding value
4239   tokens.  (Sections 3.3 and 6.2)
4240
4241   Update use of abs_path production from RFC 1808 to the path-absolute
4242   + query components of RFC 3986.  State that the asterisk form is
4243   allowed for the OPTIONS request method only.  (Section 4.1.2)
4244
4245   Clarification that the chunk length does not include the count of the
4246   octets in the chunk header and trailer.  Furthermore disallowed line
4247   folding in chunk extensions.  (Section 6.2.1)
4248
4249   Remove hard limit of two connections per server.  (Section 7.1.4)
4250
4251   Change ABNF productions for header fields to only define the field
4252
4253
4254
4255Fielding, et al.        Expires February 25, 2012              [Page 76]
4256
4257Internet-Draft              HTTP/1.1, Part 1                 August 2011
4258
4259
4260   value.  (Section 9)
4261
4262   Clarify exactly when close connection options must be sent.
4263   (Section 9.1)
4264
4265   Define the semantics of the "Upgrade" header field in responses other
4266   than 101 (this was incorporated from [RFC2817]).  (Section 9.8)
4267
4268Appendix B.  Collected ABNF
4269
4270   BWS = OWS
4271
4272   Chunked-Body = *chunk last-chunk trailer-part CRLF
4273   Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
4274    connection-token ] )
4275   Content-Length = 1*DIGIT
4276
4277   Date = HTTP-date
4278
4279   GMT = %x47.4D.54 ; GMT
4280
4281   HTTP-Prot-Name = %x48.54.54.50 ; HTTP
4282   HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
4283   HTTP-date = rfc1123-date / obs-date
4284   HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4285    ]
4286   Host = uri-host [ ":" port ]
4287
4288   Method = token
4289
4290   OWS = *( [ obs-fold ] WSP )
4291
4292   RWS = 1*( [ obs-fold ] WSP )
4293   Reason-Phrase = *( WSP / VCHAR / obs-text )
4294   Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
4295   Request-Line = Method SP request-target SP HTTP-Version CRLF
4296   Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
4297
4298   Status-Code = 3DIGIT
4299   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
4300
4301   TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4302   Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4303   Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4304    transfer-coding ] )
4305
4306   URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
4307   Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
4308
4309
4310
4311Fielding, et al.        Expires February 25, 2012              [Page 77]
4312
4313Internet-Draft              HTTP/1.1, Part 1                 August 2011
4314
4315
4316   Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
4317    *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
4318    )
4319
4320   absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
4321   asctime-date = day-name SP date3 SP time-of-day SP year
4322   attribute = token
4323   authority = <authority, defined in [RFC3986], Section 3.2>
4324
4325   chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
4326   chunk-data = 1*OCTET
4327   chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
4328   chunk-ext-name = token
4329   chunk-ext-val = token / quoted-str-nf
4330   chunk-size = 1*HEXDIG
4331   comment = "(" *( ctext / quoted-cpair / comment ) ")"
4332   connection-token = token
4333   ctext = OWS / %x21-27 ; '!'-'''
4334    / %x2A-5B ; '*'-'['
4335    / %x5D-7E ; ']'-'~'
4336    / obs-text
4337
4338   date1 = day SP month SP year
4339   date2 = day "-" month "-" 2DIGIT
4340   date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
4341   day = 2DIGIT
4342   day-name = %x4D.6F.6E ; Mon
4343    / %x54.75.65 ; Tue
4344    / %x57.65.64 ; Wed
4345    / %x54.68.75 ; Thu
4346    / %x46.72.69 ; Fri
4347    / %x53.61.74 ; Sat
4348    / %x53.75.6E ; Sun
4349   day-name-l = %x4D.6F.6E.64.61.79 ; Monday
4350    / %x54.75.65.73.64.61.79 ; Tuesday
4351    / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
4352    / %x54.68.75.72.73.64.61.79 ; Thursday
4353    / %x46.72.69.64.61.79 ; Friday
4354    / %x53.61.74.75.72.64.61.79 ; Saturday
4355    / %x53.75.6E.64.61.79 ; Sunday
4356
4357   field-content = *( WSP / VCHAR / obs-text )
4358   field-name = token
4359   field-value = *( field-content / OWS )
4360
4361   header-field = field-name ":" OWS [ field-value ] OWS
4362   hour = 2DIGIT
4363   http-URI = "http://" authority path-abempty [ "?" query ]
4364
4365
4366
4367Fielding, et al.        Expires February 25, 2012              [Page 78]
4368
4369Internet-Draft              HTTP/1.1, Part 1                 August 2011
4370
4371
4372   https-URI = "https://" authority path-abempty [ "?" query ]
4373
4374   last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
4375
4376   message-body = *OCTET
4377   minute = 2DIGIT
4378   month = %x4A.61.6E ; Jan
4379    / %x46.65.62 ; Feb
4380    / %x4D.61.72 ; Mar
4381    / %x41.70.72 ; Apr
4382    / %x4D.61.79 ; May
4383    / %x4A.75.6E ; Jun
4384    / %x4A.75.6C ; Jul
4385    / %x41.75.67 ; Aug
4386    / %x53.65.70 ; Sep
4387    / %x4F.63.74 ; Oct
4388    / %x4E.6F.76 ; Nov
4389    / %x44.65.63 ; Dec
4390
4391   obs-date = rfc850-date / asctime-date
4392   obs-fold = CRLF
4393   obs-text = %x80-FF
4394
4395   partial-URI = relative-part [ "?" query ]
4396   path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
4397   path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
4398   port = <port, defined in [RFC3986], Section 3.2.3>
4399   product = token [ "/" product-version ]
4400   product-version = token
4401   protocol-name = token
4402   protocol-version = token
4403   pseudonym = token
4404
4405   qdtext = OWS / "!" / %x23-5B ; '#'-'['
4406    / %x5D-7E ; ']'-'~'
4407    / obs-text
4408   qdtext-nf = WSP / "!" / %x23-5B ; '#'-'['
4409    / %x5D-7E ; ']'-'~'
4410    / obs-text
4411   query = <query, defined in [RFC3986], Section 3.4>
4412   quoted-cpair = "\" ( WSP / VCHAR / obs-text )
4413   quoted-pair = "\" ( WSP / VCHAR / obs-text )
4414   quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
4415   quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4416   qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4417
4418   received-by = ( uri-host [ ":" port ] ) / pseudonym
4419   received-protocol = [ protocol-name "/" ] protocol-version
4420
4421
4422
4423Fielding, et al.        Expires February 25, 2012              [Page 79]
4424
4425Internet-Draft              HTTP/1.1, Part 1                 August 2011
4426
4427
4428   relative-part = <relative-part, defined in [RFC3986], Section 4.2>
4429   request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
4430    / authority
4431   rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
4432   rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
4433
4434   second = 2DIGIT
4435   special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
4436    DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
4437   start-line = Request-Line / Status-Line
4438
4439   t-codings = "trailers" / ( transfer-extension [ te-params ] )
4440   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4441    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4442   te-ext = OWS ";" OWS token [ "=" word ]
4443   te-params = OWS ";" OWS "q=" qvalue *te-ext
4444   time-of-day = hour ":" minute ":" second
4445   token = 1*tchar
4446   trailer-part = *( header-field CRLF )
4447   transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4448    transfer-extension
4449   transfer-extension = token *( OWS ";" OWS transfer-parameter )
4450   transfer-parameter = attribute BWS "=" BWS value
4451
4452   uri-host = <host, defined in [RFC3986], Section 3.2.2>
4453
4454   value = word
4455
4456   word = token / quoted-string
4457
4458   year = 4DIGIT
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479Fielding, et al.        Expires February 25, 2012              [Page 80]
4480
4481Internet-Draft              HTTP/1.1, Part 1                 August 2011
4482
4483
4484   ABNF diagnostics:
4485
4486   ; Chunked-Body defined but not used
4487   ; Connection defined but not used
4488   ; Content-Length defined but not used
4489   ; Date defined but not used
4490   ; HTTP-message defined but not used
4491   ; Host defined but not used
4492   ; Request defined but not used
4493   ; Response defined but not used
4494   ; TE defined but not used
4495   ; Trailer defined but not used
4496   ; Transfer-Encoding defined but not used
4497   ; URI-reference defined but not used
4498   ; Upgrade defined but not used
4499   ; Via defined but not used
4500   ; http-URI defined but not used
4501   ; https-URI defined but not used
4502   ; partial-URI defined but not used
4503   ; special defined but not used
4504
4505Appendix C.  Change Log (to be removed by RFC Editor before publication)
4506
4507C.1.  Since RFC 2616
4508
4509   Extracted relevant partitions from [RFC2616].
4510
4511C.2.  Since draft-ietf-httpbis-p1-messaging-00
4512
4513   Closed issues:
4514
4515   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
4516      should be case sensitive"
4517      (<http://purl.org/NET/http-errata#verscase>)
4518
4519   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
4520      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
4521
4522   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
4523      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
4524
4525   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
4526      (<http://purl.org/NET/http-errata#msg-len-chars>)
4527
4528   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
4529      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
4530
4531
4532
4533
4534
4535Fielding, et al.        Expires February 25, 2012              [Page 81]
4536
4537Internet-Draft              HTTP/1.1, Part 1                 August 2011
4538
4539
4540   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
4541      query" (<http://purl.org/NET/http-errata#uriquery>)
4542
4543   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
4544      1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
4545
4546   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
4547      'identity' token references"
4548      (<http://purl.org/NET/http-errata#identity>)
4549
4550   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
4551      BNF"
4552
4553   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
4554
4555   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
4556      Informative references"
4557
4558   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
4559      Compliance"
4560
4561   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
4562      reference"
4563
4564   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
4565      references"
4566
4567   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
4568      in date format explanation"
4569
4570   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
4571      typo"
4572
4573   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
4574      references"
4575
4576   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
4577      Reference"
4578
4579   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
4580      to-date references"
4581
4582   Other changes:
4583
4584   o  Update media type registrations to use RFC4288 template.
4585
4586   o  Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
4587      for chunk-data (work in progress on
4588
4589
4590
4591Fielding, et al.        Expires February 25, 2012              [Page 82]
4592
4593Internet-Draft              HTTP/1.1, Part 1                 August 2011
4594
4595
4596      <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
4597
4598C.3.  Since draft-ietf-httpbis-p1-messaging-01
4599
4600   Closed issues:
4601
4602   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
4603      (and other) requests"
4604
4605   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
4606      RFC4288"
4607
4608   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
4609      and Reason Phrase"
4610
4611   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
4612      used"
4613
4614   Ongoing work on ABNF conversion
4615   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4616
4617   o  Get rid of duplicate BNF rule names ("host" -> "uri-host",
4618      "trailer" -> "trailer-part").
4619
4620   o  Avoid underscore character in rule names ("http_URL" -> "http-
4621      URL", "abs_path" -> "path-absolute").
4622
4623   o  Add rules for terms imported from URI spec ("absoluteURI",
4624      "authority", "path-absolute", "port", "query", "relativeURI",
4625      "host) -- these will have to be updated when switching over to
4626      RFC3986.
4627
4628   o  Synchronize core rules with RFC5234.
4629
4630   o  Get rid of prose rules that span multiple lines.
4631
4632   o  Get rid of unused rules LOALPHA and UPALPHA.
4633
4634   o  Move "Product Tokens" section (back) into Part 1, as "token" is
4635      used in the definition of the Upgrade header field.
4636
4637   o  Add explicit references to BNF syntax and rules imported from
4638      other parts of the specification.
4639
4640   o  Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
4641      "TEXT".
4642
4643
4644
4645
4646
4647Fielding, et al.        Expires February 25, 2012              [Page 83]
4648
4649Internet-Draft              HTTP/1.1, Part 1                 August 2011
4650
4651
4652C.4.  Since draft-ietf-httpbis-p1-messaging-02
4653
4654   Closed issues:
4655
4656   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
4657      rfc1123-date"
4658
4659   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
4660      pair"
4661
4662   Ongoing work on IANA Message Header Field Registration
4663   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
4664
4665   o  Reference RFC 3984, and update header field registrations for
4666      headers defined in this document.
4667
4668   Ongoing work on ABNF conversion
4669   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4670
4671   o  Replace string literals when the string really is case-sensitive
4672      (HTTP-Version).
4673
4674C.5.  Since draft-ietf-httpbis-p1-messaging-03
4675
4676   Closed issues:
4677
4678   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4679      closing"
4680
4681   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
4682      registrations and registry information to IANA Considerations"
4683
4684   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
4685      for PAD1995 reference"
4686
4687   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
4688      Considerations: update HTTP URI scheme registration"
4689
4690   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
4691      URI scheme definition"
4692
4693   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
4694      headers vs Set-Cookie"
4695
4696   Ongoing work on ABNF conversion
4697   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4698
4699
4700
4701
4702
4703Fielding, et al.        Expires February 25, 2012              [Page 84]
4704
4705Internet-Draft              HTTP/1.1, Part 1                 August 2011
4706
4707
4708   o  Replace string literals when the string really is case-sensitive
4709      (HTTP-Date).
4710
4711   o  Replace HEX by HEXDIG for future consistence with RFC 5234's core
4712      rules.
4713
4714C.6.  Since draft-ietf-httpbis-p1-messaging-04
4715
4716   Closed issues:
4717
4718   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
4719      reference for URIs"
4720
4721   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
4722      updated by RFC 5322"
4723
4724   Ongoing work on ABNF conversion
4725   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4726
4727   o  Use "/" instead of "|" for alternatives.
4728
4729   o  Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4730
4731   o  Only reference RFC 5234's core rules.
4732
4733   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4734      whitespace ("OWS") and required whitespace ("RWS").
4735
4736   o  Rewrite ABNFs to spell out whitespace rules, factor out header
4737      field value format definitions.
4738
4739C.7.  Since draft-ietf-httpbis-p1-messaging-05
4740
4741   Closed issues:
4742
4743   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
4744
4745   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
4746      Terminology"
4747
4748   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
4749      encoded words"
4750
4751   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
4752      Encodings in TEXT"
4753
4754   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
4755
4756
4757
4758
4759Fielding, et al.        Expires February 25, 2012              [Page 85]
4760
4761Internet-Draft              HTTP/1.1, Part 1                 August 2011
4762
4763
4764   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4765      proxies"
4766
4767   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
4768      BNF"
4769
4770   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
4771
4772   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
4773      "Differences Between HTTP Entities and RFC 2045 Entities"?"
4774
4775   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
4776      reference left in discussion of date formats"
4777
4778   Final work on ABNF conversion
4779   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4780
4781   o  Rewrite definition of list rules, deprecate empty list elements.
4782
4783   o  Add appendix containing collected and expanded ABNF.
4784
4785   Other changes:
4786
4787   o  Rewrite introduction; add mostly new Architecture Section.
4788
4789   o  Move definition of quality values from Part 3 into Part 1; make TE
4790      request header field grammar independent of accept-params (defined
4791      in Part 3).
4792
4793C.8.  Since draft-ietf-httpbis-p1-messaging-06
4794
4795   Closed issues:
4796
4797   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
4798      numeric protocol elements"
4799
4800   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
4801
4802   Partly resolved issues:
4803
4804   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
4805      (took out language that implied that there might be methods for
4806      which a request body MUST NOT be included)
4807
4808   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
4809      improvements around HTTP-date"
4810
4811
4812
4813
4814
4815Fielding, et al.        Expires February 25, 2012              [Page 86]
4816
4817Internet-Draft              HTTP/1.1, Part 1                 August 2011
4818
4819
4820C.9.  Since draft-ietf-httpbis-p1-messaging-07
4821
4822   Closed issues:
4823
4824   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
4825      single-value headers"
4826
4827   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
4828      connection limit"
4829
4830   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
4831      in URLs"
4832
4833   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over
4834      HTTP Upgrade Token Registry"
4835
4836   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in
4837      chunk extension values"
4838
4839   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9
4840      support"
4841
4842   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
4843      policy (RFC5226) for Transfer Coding / Content Coding"
4844
4845   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
4846      definitions of gzip/deflate/compress to part 1"
4847
4848   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
4849      control characters in quoted-pair"
4850
4851   Partly resolved issues:
4852
4853   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
4854      requirements wrt Transfer-Coding values" (add the IANA
4855      Considerations subsection)
4856
4857C.10.  Since draft-ietf-httpbis-p1-messaging-08
4858
4859   Closed issues:
4860
4861   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
4862      parsing, treatment of leading and trailing OWS"
4863
4864   Partly resolved issues:
4865
4866   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
4867      13.5.1 and 13.5.2"
4868
4869
4870
4871Fielding, et al.        Expires February 25, 2012              [Page 87]
4872
4873Internet-Draft              HTTP/1.1, Part 1                 August 2011
4874
4875
4876   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4877      "word" when talking about header structure"
4878
4879C.11.  Since draft-ietf-httpbis-p1-messaging-09
4880
4881   Closed issues:
4882
4883   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
4884      of the term 'deflate'"
4885
4886   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4887      proxies"
4888
4889   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
4890      not listed in P1, general header fields"
4891
4892   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
4893      for content/transfer encodings"
4894
4895   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
4896      sensitivity of HTTP-date"
4897
4898   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4899      "word" when talking about header structure"
4900
4901   Partly resolved issues:
4902
4903   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
4904      requested resource's URI"
4905
4906C.12.  Since draft-ietf-httpbis-p1-messaging-10
4907
4908   Closed issues:
4909
4910   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4911      Closing"
4912
4913   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
4914      messages with multipart/byteranges"
4915
4916   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4917      multiple Content-Length headers"
4918
4919   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
4920      entity / representation / variant terminology"
4921
4922   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
4923      removing the 'changes from 2068' sections"
4924
4925
4926
4927Fielding, et al.        Expires February 25, 2012              [Page 88]
4928
4929Internet-Draft              HTTP/1.1, Part 1                 August 2011
4930
4931
4932   Partly resolved issues:
4933
4934   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4935      scheme definitions"
4936
4937C.13.  Since draft-ietf-httpbis-p1-messaging-11
4938
4939   Closed issues:
4940
4941   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer
4942      requirements"
4943
4944   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
4945      clock requirement for caches belongs in p6"
4946
4947   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective
4948      request URI: handling of missing host in HTTP/1.0"
4949
4950   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing
4951      Date requirements for clients"
4952
4953   Partly resolved issues:
4954
4955   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4956      multiple Content-Length headers"
4957
4958C.14.  Since draft-ietf-httpbis-p1-messaging-12
4959
4960   Closed issues:
4961
4962   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145
4963      Normative"
4964
4965   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4966      scheme definitions" (tune the requirements on userinfo)
4967
4968   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define
4969      'transparent' proxy"
4970
4971   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
4972      Classification"
4973
4974   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable
4975      as a request-uri for new methods?"
4976
4977   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
4978      Upgrade details from RFC2817"
4979
4980
4981
4982
4983Fielding, et al.        Expires February 25, 2012              [Page 89]
4984
4985Internet-Draft              HTTP/1.1, Part 1                 August 2011
4986
4987
4988   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
4989      ABNFs for header fields"
4990
4991   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
4992      2109 reference"
4993
4994C.15.  Since draft-ietf-httpbis-p1-messaging-13
4995
4996   Closed issues:
4997
4998   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
4999      in 13.5.2"
5000
5001   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
5002      multiple Content-Length headers"
5003
5004   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
5005      ABNFs for header fields"
5006
5007   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
5008      Length ABNF broken"
5009
5010C.16.  Since draft-ietf-httpbis-p1-messaging-14
5011
5012   Closed issues:
5013
5014   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version
5015      should be redefined as fixed length pair of DIGIT .  DIGIT"
5016
5017   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
5018      minimum sizes for protocol elements"
5019
5020   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set
5021      expectations around buffering"
5022
5023   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering
5024      messages in isolation"
5025
5026C.17.  Since draft-ietf-httpbis-p1-messaging-15
5027
5028   Closed issues:
5029
5030   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing
5031      / DNS Binding advice"
5032
5033   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs
5034      2145, 2616, 2817 to Historic status"
5035
5036
5037
5038
5039Fielding, et al.        Expires February 25, 2012              [Page 90]
5040
5041Internet-Draft              HTTP/1.1, Part 1                 August 2011
5042
5043
5044   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in
5045      quoted strings"
5046
5047   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close'
5048      should be reserved in the HTTP header field registry"
5049
5050Index
5051
5052   A
5053      absolute-URI form (of request-target)  30
5054      accelerator  13
5055      application/http Media Type  66
5056      asterisk form (of request-target)  30
5057      authority form (of request-target)  31
5058
5059   B
5060      browser  9
5061
5062   C
5063      cache  14
5064      cacheable  14
5065      captive portal  14
5066      chunked (Coding Format)  39
5067      client  9
5068      Coding Format
5069         chunked  39
5070         compress  42
5071         deflate  42
5072         gzip  42
5073      compress (Coding Format)  42
5074      connection  9
5075      Connection header field  53
5076      Content-Length header field  55
5077
5078   D
5079      Date header field  55
5080      deflate (Coding Format)  42
5081      downstream  12
5082
5083   E
5084      effective request URI  33
5085
5086   G
5087      gateway  13
5088      Grammar
5089         absolute-URI  17
5090         ALPHA  7
5091         asctime-date  38
5092
5093
5094
5095Fielding, et al.        Expires February 25, 2012              [Page 91]
5096
5097Internet-Draft              HTTP/1.1, Part 1                 August 2011
5098
5099
5100         attribute  38
5101         authority  17
5102         BWS  9
5103         chunk  39
5104         chunk-data  39
5105         chunk-ext  39
5106         chunk-ext-name  39
5107         chunk-ext-val  39
5108         chunk-size  39
5109         Chunked-Body  39
5110         comment  25
5111         Connection  54
5112         connection-token  54
5113         Content-Length  55
5114         CR  7
5115         CRLF  7
5116         ctext  25
5117         CTL  7
5118         Date  55
5119         date1  37
5120         date2  38
5121         date3  38
5122         day  37
5123         day-name  37
5124         day-name-l  37
5125         DIGIT  7
5126         DQUOTE  7
5127         field-content  22
5128         field-name  22
5129         field-value  22
5130         GMT  37
5131         header-field  22
5132         HEXDIG  7
5133         Host  57
5134         hour  37
5135         HTTP-date  36
5136         HTTP-message  21
5137         HTTP-Prot-Name  15
5138         http-URI  18
5139         HTTP-Version  15
5140         https-URI  19
5141         last-chunk  39
5142         LF  7
5143         message-body  25
5144         Method  30
5145         minute  37
5146         month  37
5147         obs-date  37
5148
5149
5150
5151Fielding, et al.        Expires February 25, 2012              [Page 92]
5152
5153Internet-Draft              HTTP/1.1, Part 1                 August 2011
5154
5155
5156         obs-text  24
5157         OCTET  7
5158         OWS  9
5159         path-absolute  17
5160         port  17
5161         product  43
5162         product-version  43
5163         protocol-name  62
5164         protocol-version  62
5165         pseudonym  62
5166         qdtext  24
5167         qdtext-nf  39
5168         query  17
5169         quoted-cpair  25
5170         quoted-pair  25
5171         quoted-str-nf  39
5172         quoted-string  24
5173         qvalue  43
5174         Reason-Phrase  35
5175         received-by  62
5176         received-protocol  62
5177         Request  29
5178         Request-Line  30
5179         request-target  30
5180         Response  34
5181         rfc850-date  38
5182         rfc1123-date  37
5183         RWS  9
5184         second  37
5185         SP  7
5186         special  24
5187         Status-Code  35
5188         Status-Line  35
5189         t-codings  58
5190         tchar  24
5191         TE  58
5192         te-ext  58
5193         te-params  58
5194         time-of-day  37
5195         token  24
5196         Trailer  59
5197         trailer-part  39
5198         transfer-coding  38
5199         Transfer-Encoding  60
5200         transfer-extension  38
5201         transfer-parameter  38
5202         Upgrade  60
5203         uri-host  17
5204
5205
5206
5207Fielding, et al.        Expires February 25, 2012              [Page 93]
5208
5209Internet-Draft              HTTP/1.1, Part 1                 August 2011
5210
5211
5212         URI-reference  17
5213         value  38
5214         VCHAR  7
5215         Via  62
5216         word  24
5217         WSP  7
5218         year  37
5219      gzip (Coding Format)  42
5220
5221   H
5222      header field  20
5223      Header Fields
5224         Connection  53
5225         Content-Length  55
5226         Date  55
5227         Host  57
5228         TE  58
5229         Trailer  59
5230         Transfer-Encoding  59
5231         Upgrade  60
5232         Via  62
5233      header section  20
5234      headers  20
5235      Host header field  57
5236      http URI scheme  18
5237      https URI scheme  19
5238
5239   I
5240      inbound  12
5241      interception proxy  14
5242      intermediary  12
5243
5244   M
5245      Media Type
5246         application/http  66
5247         message/http  64
5248      message  10
5249      message/http Media Type  64
5250
5251   N
5252      non-transforming proxy  13
5253
5254   O
5255      origin form (of request-target)  31
5256      origin server  9
5257      outbound  12
5258
5259   P
5260
5261
5262
5263Fielding, et al.        Expires February 25, 2012              [Page 94]
5264
5265Internet-Draft              HTTP/1.1, Part 1                 August 2011
5266
5267
5268      proxy  12
5269
5270   R
5271      recipient  9
5272      request  10
5273      resource  17
5274      response  10
5275      reverse proxy  13
5276
5277   S
5278      sender  9
5279      server  9
5280      spider  9
5281
5282   T
5283      target resource  33
5284      TE header field  58
5285      Trailer header field  59
5286      Transfer-Encoding header field  59
5287      transforming proxy  13
5288      transparent proxy  14
5289      tunnel  13
5290
5291   U
5292      Upgrade header field  60
5293      upstream  12
5294      URI scheme
5295         http  18
5296         https  19
5297      user agent  9
5298
5299   V
5300      Via header field  62
5301
5302Authors' Addresses
5303
5304   Roy T. Fielding (editor)
5305   Adobe Systems Incorporated
5306   345 Park Ave
5307   San Jose, CA  95110
5308   USA
5309
5310   EMail: fielding@gbiv.com
5311   URI:   http://roy.gbiv.com/
5312
5313
5314
5315
5316
5317
5318
5319Fielding, et al.        Expires February 25, 2012              [Page 95]
5320
5321Internet-Draft              HTTP/1.1, Part 1                 August 2011
5322
5323
5324   Jim Gettys
5325   Alcatel-Lucent Bell Labs
5326   21 Oak Knoll Road
5327   Carlisle, MA  01741
5328   USA
5329
5330   EMail: jg@freedesktop.org
5331   URI:   http://gettys.wordpress.com/
5332
5333
5334   Jeffrey C. Mogul
5335   Hewlett-Packard Company
5336   HP Labs, Large Scale Systems Group
5337   1501 Page Mill Road, MS 1177
5338   Palo Alto, CA  94304
5339   USA
5340
5341   EMail: JeffMogul@acm.org
5342
5343
5344   Henrik Frystyk Nielsen
5345   Microsoft Corporation
5346   1 Microsoft Way
5347   Redmond, WA  98052
5348   USA
5349
5350   EMail: henrikn@microsoft.com
5351
5352
5353   Larry Masinter
5354   Adobe Systems Incorporated
5355   345 Park Ave
5356   San Jose, CA  95110
5357   USA
5358
5359   EMail: LMM@acm.org
5360   URI:   http://larry.masinter.net/
5361
5362
5363   Paul J. Leach
5364   Microsoft Corporation
5365   1 Microsoft Way
5366   Redmond, WA  98052
5367
5368   EMail: paulle@microsoft.com
5369
5370
5371
5372
5373
5374
5375Fielding, et al.        Expires February 25, 2012              [Page 96]
5376
5377Internet-Draft              HTTP/1.1, Part 1                 August 2011
5378
5379
5380   Tim Berners-Lee
5381   World Wide Web Consortium
5382   MIT Computer Science and Artificial Intelligence Laboratory
5383   The Stata Center, Building 32
5384   32 Vassar Street
5385   Cambridge, MA  02139
5386   USA
5387
5388   EMail: timbl@w3.org
5389   URI:   http://www.w3.org/People/Berners-Lee/
5390
5391
5392   Yves Lafon (editor)
5393   World Wide Web Consortium
5394   W3C / ERCIM
5395   2004, rte des Lucioles
5396   Sophia-Antipolis, AM  06902
5397   France
5398
5399   EMail: ylafon@w3.org
5400   URI:   http://www.raubacapeu.net/people/yves/
5401
5402
5403   Julian F. Reschke (editor)
5404   greenbytes GmbH
5405   Hafenweg 16
5406   Muenster, NW  48155
5407   Germany
5408
5409   Phone: +49 251 2807760
5410   Fax:   +49 251 2807761
5411   EMail: julian.reschke@greenbytes.de
5412   URI:   http://greenbytes.de/tech/webdav/
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431Fielding, et al.        Expires February 25, 2012              [Page 97]
5432
Note: See TracBrowser for help on using the repository browser.