source: draft-ietf-httpbis/15/draft-ietf-httpbis-p1-messaging-15.txt @ 2082

Last change on this file since 2082 was 1326, checked in by julian.reschke@…, 8 years ago

Prepare publication of -15 on 2011-07-11

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