source: draft-ietf-httpbis/13/draft-ietf-httpbis-p1-messaging-13.txt @ 1450

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

prepare publication of -13

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