source: draft-ietf-httpbis/06/draft-ietf-httpbis-p1-messaging-06.txt @ 877

Last change on this file since 877 was 558, checked in by fielding@…, 11 years ago

Draft 06 (as recorded by www.ietf.org)

  • Property svn:eol-style set to native
File size: 165.5 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                    One Laptop per Child
8Expires: September 10, 2009                                     J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 9, 2009
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-06
27
28Status of this Memo
29
30   This Internet-Draft is submitted to IETF in full conformance with the
31   provisions of BCP 78 and BCP 79.  This document may contain material
32   from IETF Documents or IETF Contributions published or made publicly
33   available before November 10, 2008.  The person(s) controlling the
34   copyright in some of this material may not have granted the IETF
35   Trust the right to allow modifications of such material outside the
36   IETF Standards Process.  Without obtaining an adequate license from
37   the person(s) controlling the copyright in such materials, this
38   document may not be modified outside the IETF Standards Process, and
39   derivative works of it may not be created outside the IETF Standards
40   Process, except to format it for publication as an RFC or to
41   translate it into languages other than English.
42
43   Internet-Drafts are working documents of the Internet Engineering
44   Task Force (IETF), its areas, and its working groups.  Note that
45   other groups may also distribute working documents as Internet-
46   Drafts.
47
48   Internet-Drafts are draft documents valid for a maximum of six months
49   and may be updated, replaced, or obsoleted by other documents at any
50   time.  It is inappropriate to use Internet-Drafts as reference
51   material or to cite them other than as "work in progress."
52
53
54
55Fielding, et al.       Expires September 10, 2009               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1                  March 2009
58
59
60   The list of current Internet-Drafts can be accessed at
61   http://www.ietf.org/ietf/1id-abstracts.txt.
62
63   The list of Internet-Draft Shadow Directories can be accessed at
64   http://www.ietf.org/shadow.html.
65
66   This Internet-Draft will expire on September 10, 2009.
67
68Copyright Notice
69
70   Copyright (c) 2009 IETF Trust and the persons identified as the
71   document authors.  All rights reserved.
72
73   This document is subject to BCP 78 and the IETF Trust's Legal
74   Provisions Relating to IETF Documents in effect on the date of
75   publication of this document (http://trustee.ietf.org/license-info).
76   Please review these documents carefully, as they describe your rights
77   and restrictions with respect to this document.
78
79Abstract
80
81   The Hypertext Transfer Protocol (HTTP) is an application-level
82   protocol for distributed, collaborative, hypertext information
83   systems.  HTTP has been in use by the World Wide Web global
84   information initiative since 1990.  This document is Part 1 of the
85   seven-part specification that defines the protocol referred to as
86   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 1 provides
87   an overview of HTTP and its associated terminology, defines the
88   "http" and "https" Uniform Resource Identifier (URI) schemes, defines
89   the generic message syntax and parsing requirements for HTTP message
90   frames, and describes general security concerns for implementations.
91
92Editorial Note (To be removed by RFC Editor)
93
94   Discussion of this draft should take place on the HTTPBIS working
95   group mailing list (ietf-http-wg@w3.org).  The current issues list is
96   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
97   documents (including fancy diffs) can be found at
98   <http://tools.ietf.org/wg/httpbis/>.
99
100   The changes in this draft are summarized in Appendix E.7.
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 10, 2009               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1                  March 2009
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  7
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  7
121       1.2.1.  ABNF Extension: #rule  . . . . . . . . . . . . . . . .  7
122       1.2.2.  Basic Rules  . . . . . . . . . . . . . . . . . . . . .  8
123       1.2.3.  ABNF Rules defined in other Parts of the
124               Specification  . . . . . . . . . . . . . . . . . . . .  9
125   2.  HTTP architecture  . . . . . . . . . . . . . . . . . . . . . . 10
126     2.1.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 10
127       2.1.1.  http URI scheme  . . . . . . . . . . . . . . . . . . . 11
128       2.1.2.  https URI scheme . . . . . . . . . . . . . . . . . . . 11
129       2.1.3.  URI Comparison . . . . . . . . . . . . . . . . . . . . 11
130       2.1.4.  Scheme aliases considered harmful  . . . . . . . . . . 12
131     2.2.  Overall Operation  . . . . . . . . . . . . . . . . . . . . 12
132     2.3.  Use of HTTP for proxy communication  . . . . . . . . . . . 14
133     2.4.  Interception of HTTP for access control  . . . . . . . . . 14
134     2.5.  Use of HTTP by other protocols . . . . . . . . . . . . . . 14
135     2.6.  Use of HTTP by media type specification  . . . . . . . . . 14
136   3.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 14
137     3.1.  HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
138     3.2.  Date/Time Formats  . . . . . . . . . . . . . . . . . . . . 15
139       3.2.1.  Full Date  . . . . . . . . . . . . . . . . . . . . . . 15
140     3.3.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . 17
141       3.3.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . 18
142     3.4.  Product Tokens . . . . . . . . . . . . . . . . . . . . . . 20
143     3.5.  Quality Values . . . . . . . . . . . . . . . . . . . . . . 21
144   4.  HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21
145     4.1.  Message Types  . . . . . . . . . . . . . . . . . . . . . . 21
146     4.2.  Message Headers  . . . . . . . . . . . . . . . . . . . . . 22
147     4.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 23
148     4.4.  Message Length . . . . . . . . . . . . . . . . . . . . . . 24
149     4.5.  General Header Fields  . . . . . . . . . . . . . . . . . . 26
150   5.  Request  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
151     5.1.  Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27
152       5.1.1.  Method . . . . . . . . . . . . . . . . . . . . . . . . 27
153       5.1.2.  request-target . . . . . . . . . . . . . . . . . . . . 27
154     5.2.  The Resource Identified by a Request . . . . . . . . . . . 29
155   6.  Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
156     6.1.  Status-Line  . . . . . . . . . . . . . . . . . . . . . . . 30
157       6.1.1.  Status Code and Reason Phrase  . . . . . . . . . . . . 30
158   7.  Connections  . . . . . . . . . . . . . . . . . . . . . . . . . 31
159     7.1.  Persistent Connections . . . . . . . . . . . . . . . . . . 31
160       7.1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . 31
161       7.1.2.  Overall Operation  . . . . . . . . . . . . . . . . . . 32
162       7.1.3.  Proxy Servers  . . . . . . . . . . . . . . . . . . . . 33
163       7.1.4.  Practical Considerations . . . . . . . . . . . . . . . 33
164
165
166
167Fielding, et al.       Expires September 10, 2009               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1                  March 2009
170
171
172     7.2.  Message Transmission Requirements  . . . . . . . . . . . . 34
173       7.2.1.  Persistent Connections and Flow Control  . . . . . . . 34
174       7.2.2.  Monitoring Connections for Error Status Messages . . . 35
175       7.2.3.  Use of the 100 (Continue) Status . . . . . . . . . . . 35
176       7.2.4.  Client Behavior if Server Prematurely Closes
177               Connection . . . . . . . . . . . . . . . . . . . . . . 37
178   8.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 38
179     8.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 38
180     8.2.  Content-Length . . . . . . . . . . . . . . . . . . . . . . 39
181     8.3.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
182       8.3.1.  Clockless Origin Server Operation  . . . . . . . . . . 41
183     8.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
184     8.5.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
185     8.6.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 43
186     8.7.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . . . 43
187     8.8.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 44
188     8.9.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
189   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47
190     9.1.  Message Header Registration  . . . . . . . . . . . . . . . 47
191     9.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 47
192     9.3.  Internet Media Type Registrations  . . . . . . . . . . . . 47
193       9.3.1.  Internet Media Type message/http . . . . . . . . . . . 47
194       9.3.2.  Internet Media Type application/http . . . . . . . . . 48
195   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 50
196     10.1. Personal Information . . . . . . . . . . . . . . . . . . . 50
197     10.2. Abuse of Server Log Information  . . . . . . . . . . . . . 50
198     10.3. Attacks Based On File and Path Names . . . . . . . . . . . 50
199     10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 51
200     10.5. Proxies and Caching  . . . . . . . . . . . . . . . . . . . 51
201     10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 52
202   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 52
203   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
204     12.1. Normative References . . . . . . . . . . . . . . . . . . . 53
205     12.2. Informative References . . . . . . . . . . . . . . . . . . 54
206   Appendix A.  Tolerant Applications . . . . . . . . . . . . . . . . 56
207   Appendix B.  Compatibility with Previous Versions  . . . . . . . . 57
208     B.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 58
209       B.1.1.  Changes to Simplify Multi-homed Web Servers and
210               Conserve IP Addresses  . . . . . . . . . . . . . . . . 58
211     B.2.  Compatibility with HTTP/1.0 Persistent Connections . . . . 59
212     B.3.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 59
213     B.4.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 60
214   Appendix C.  Terminology . . . . . . . . . . . . . . . . . . . . . 60
215   Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 64
216   Appendix E.  Change Log (to be removed by RFC Editor before
217                publication)  . . . . . . . . . . . . . . . . . . . . 68
218     E.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 68
219     E.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 68
220
221
222
223Fielding, et al.       Expires September 10, 2009               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1                  March 2009
226
227
228     E.3.  Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 70
229     E.4.  Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 71
230     E.5.  Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 71
231     E.6.  Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 72
232     E.7.  Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 72
233   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
234   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279Fielding, et al.       Expires September 10, 2009               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1                  March 2009
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 request targets and
291   relationships between resources.  Messages are passed in a format
292   similar to that used by Internet mail [RFC5322] and the Multipurpose
293   Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3]
294   for the differences between HTTP and MIME messages).
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 a generic protocol for translating
307   communication to and from other Internet information systems.  HTTP
308   proxies and gateways provide access to alternative information
309   services by translating their diverse protocols into a hypertext
310   format that can be viewed and manipulated by clients in the same way
311   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   should be reflected in corresponding changes to the observable
319   interface provided by servers.  However, since multiple clients may
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" and obsoleting
325   [RFC2616].  Part 1 describes the architectural elements that are used
326   or referred to in HTTP and defines the URI schemes specific to HTTP-
327   based resources, overall network operation, connection management,
328   and HTTP message framing and forwarding requirements.  Our goal is to
329   define all of the mechanisms necessary for HTTP message handling that
330   are independent of message semantics, thereby defining the complete
331   set of requirements for message parsers and message-forwarding
332
333
334
335Fielding, et al.       Expires September 10, 2009               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1                  March 2009
338
339
340   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
3691.2.1.  ABNF Extension: #rule
370
371   One extension to the ABNF rules of [RFC5234] is used to improve
372   readability.
373
374   A construct "#" is defined, similar to "*", for defining lists of
375   elements.  The full form is "<n>#<m>element" indicating at least <n>
376   and at most <m> elements, each separated by a single comma (",") and
377   optional whitespace (OWS).
378
379   Thus,
380
381     1#element => element *( OWS "," OWS element )
382
383   and:
384
385     #element => [ 1#element ]
386
387
388
389
390
391Fielding, et al.       Expires September 10, 2009               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1                  March 2009
394
395
396   and for n >= 1 and m > 1:
397
398     <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
399
400   For compatibility with legacy list rules, recipients SHOULD accept
401   empty list elements.  In other words, consumers would follow the list
402   productions:
403
404     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
405
406     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
407
408   Appendix D shows the collected ABNF, with the list rules expanded as
409   explained above.
410
4111.2.2.  Basic Rules
412
413   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
414   protocol elements except the entity-body (see Appendix A for tolerant
415   applications).  The end-of-line marker within an entity-body is
416   defined by its associated media type, as described in Section 2.3 of
417   [Part3].
418
419   This specification uses three rules to denote the use of linear
420   whitespace: OWS (optional whitespace), RWS (required whitespace), and
421   BWS ("bad" whitespace).
422
423   The OWS rule is used where zero or more linear whitespace characters
424   may appear.  OWS SHOULD either not be produced or be produced as a
425   single SP character.  Multiple OWS characters that occur within
426   field-content SHOULD be replaced with a single SP before interpreting
427   the field value or forwarding the message downstream.
428
429   RWS is used when at least one linear whitespace character is required
430   to separate field tokens.  RWS SHOULD be produced as a single SP
431   character.  Multiple RWS characters that occur within field-content
432   SHOULD be replaced with a single SP before interpreting the field
433   value or forwarding the message downstream.
434
435   BWS is used where the grammar allows optional whitespace for
436   historical reasons but senders SHOULD NOT produce it in messages.
437   HTTP/1.1 recipients MUST accept such bad optional whitespace and
438   remove it before interpreting the field value or forwarding the
439   message downstream.
440
441
442
443
444
445
446
447Fielding, et al.       Expires September 10, 2009               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1                  March 2009
450
451
452     OWS            = *( [ obs-fold ] WSP )
453                    ; "optional" whitespace
454     RWS            = 1*( [ obs-fold ] WSP )
455                    ; "required" whitespace
456     BWS            = OWS
457                    ; "bad" whitespace
458     obs-fold       = CRLF
459                    ; see Section 4.2
460
461   Many HTTP/1.1 header field values consist of words separated by
462   whitespace or special characters.  These special characters MUST be
463   in a quoted string to be used within a parameter value (as defined in
464   Section 3.3).
465
466     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
467                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
468                    / DIGIT / ALPHA
469
470     token          = 1*tchar
471
472   A string of text is parsed as a single word if it is quoted using
473   double-quote marks.
474
475     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
476     qdtext         = *( OWS / %x21 / %x23-5B / %x5D-7E / obs-text )
477     obs-text       = %x80-FF
478
479   The backslash character ("\") MAY be used as a single-character
480   quoting mechanism only within quoted-string and comment constructs.
481
482     quoted-text    = %x01-09 /
483                      %x0B-0C /
484                      %x0E-FF ; Characters excluding NUL, CR and LF
485     quoted-pair    = "\" quoted-text
486
4871.2.3.  ABNF Rules defined in other Parts of the Specification
488
489   The ABNF rules below are defined in other parts:
490
491     request-header  = <request-header, defined in [Part2], Section 3>
492     response-header = <response-header, defined in [Part2], Section 5>
493
494
495     entity-body     = <entity-body, defined in [Part3], Section 3.2>
496     entity-header   = <entity-header, defined in [Part3], Section 3.1>
497
498
499
500
501
502
503Fielding, et al.       Expires September 10, 2009               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1                  March 2009
506
507
508     Cache-Control   = <Cache-Control, defined in [Part6], Section 3.4>
509     Pragma          = <Pragma, defined in [Part6], Section 3.4>
510     Warning         = <Warning, defined in [Part6], Section 3.6>
511
512
5132.  HTTP architecture
514
515   HTTP was created with a specific architecture in mind, the World Wide
516   Web, and has evolved over time to support the scalability needs of a
517   worldwide hypertext system.  Much of that architecture is reflected
518   in the terminology and syntax productions used to define HTTP.
519
5202.1.  Uniform Resource Identifiers
521
522   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
523   HTTP as the means for identifying resources.  URI references are used
524   to target requests, redirect responses, and define relationships.
525   HTTP does not limit what a resource may be; it merely defines an
526   interface that can be used to interact with a resource via HTTP.
527   More information on the scope of URIs and resources can be found in
528   [RFC3986].
529
530   This specification adopts the definitions of "URI-reference",
531   "absolute-URI", "relative-part", "fragment", "port", "host", "path-
532   abempty", "path-absolute", "query", and "authority" from [RFC3986].
533   In addition, we define a partial-URI rule for protocol elements that
534   allow a relative URI without a fragment.
535
536     URI           = <URI, defined in [RFC3986], Section 3>
537     URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
538     absolute-URI  = <absolute-URI, defined in [RFC3986], Section 4.3>
539     relative-part = <relative-part, defined in [RFC3986], Section 4.2>
540     authority     = <authority, defined in [RFC3986], Section 3.2>
541     fragment      = <fragment, defined in [RFC3986], Section 3.5>
542     path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
543     path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
544     port          = <port, defined in [RFC3986], Section 3.2.3>
545     query         = <query, defined in [RFC3986], Section 3.4>
546     uri-host      = <host, defined in [RFC3986], Section 3.2.2>
547
548     partial-URI   = relative-part [ "?" query ]
549
550   Each protocol element in HTTP that allows a URI reference will
551   indicate in its ABNF production whether the element allows only a URI
552   in absolute form (absolute-URI), any relative reference (relative-
553   ref), or some other subset of the URI-reference grammar.  Unless
554   otherwise indicated, URI references are parsed relative to the
555   request target (the default base URI for both the request and its
556
557
558
559Fielding, et al.       Expires September 10, 2009              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1                  March 2009
562
563
564   corresponding response).
565
5662.1.1.  http URI scheme
567
568   The "http" scheme is used to locate network resources via the HTTP
569   protocol.
570
571     http-URI = "http:" "//" authority path-abempty [ "?" query ]
572
573   If the port is empty or not given, port 80 is assumed.  The semantics
574   are that the identified resource is located at the server listening
575   for TCP connections on that port of that host, and the request-target
576   for the resource is path-absolute (Section 5.1.2).  The use of IP
577   addresses in URLs SHOULD be avoided whenever possible (see
578   [RFC1900]).  If the path-absolute is not present in the URL, it MUST
579   be given as "/" when used as a request-target for a resource
580   (Section 5.1.2).  If a proxy receives a host name which is not a
581   fully qualified domain name, it MAY add its domain to the host name
582   it received.  If a proxy receives a fully qualified domain name, the
583   proxy MUST NOT change the host name.
584
5852.1.2.  https URI scheme
586
587   [[anchor1: TBD: Define and explain purpose of https scheme.]]
588
589      Note: the "https" scheme is defined in [RFC2818].
590
5912.1.3.  URI Comparison
592
593   When comparing two URIs to decide if they match or not, a client
594   SHOULD use a case-sensitive octet-by-octet comparison of the entire
595   URIs, with these exceptions:
596
597   o  A port that is empty or not given is equivalent to the default
598      port for that URI-reference;
599
600   o  Comparisons of host names MUST be case-insensitive;
601
602   o  Comparisons of scheme names MUST be case-insensitive;
603
604   o  An empty path-absolute is equivalent to a path-absolute of "/".
605
606   o  Characters other than those in the "reserved" set are equivalent
607      to their percent-encoded octets (see [RFC3986], Section 2.1).
608
609   For example, the following three URIs are equivalent:
610
611
612
613
614
615Fielding, et al.       Expires September 10, 2009              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1                  March 2009
618
619
620      http://example.com:80/~smith/home.html
621      http://EXAMPLE.com/%7Esmith/home.html
622      http://EXAMPLE.com:/%7esmith/home.html
623
6242.1.4.  Scheme aliases considered harmful
625
6262.2.  Overall Operation
627
628   HTTP is a request/response protocol.  A client sends a request to the
629   server in the form of a request method, URI, and protocol version,
630   followed by a MIME-like message containing request modifiers, client
631   information, and possible body content over a connection with a
632   server.  The server responds with a status line, including the
633   message's protocol version and a success or error code, followed by a
634   MIME-like message containing server information, entity
635   metainformation, and possible entity-body content.
636
637   Most HTTP communication is initiated by a user agent and consists of
638   a request to be applied to a resource on some origin server.  In the
639   simplest case, this may be accomplished via a single connection (v)
640   between the user agent (UA) and the origin server (O).
641
642          request chain ------------------------>
643       UA -------------------v------------------- O
644          <----------------------- response chain
645
646   A more complicated situation occurs when one or more intermediaries
647   are present in the request/response chain.  There are three common
648   forms of intermediary: proxy, gateway, and tunnel.  A proxy is a
649   forwarding agent, receiving requests for a URI in its absolute form,
650   rewriting all or part of the message, and forwarding the reformatted
651   request toward the server identified by the URI.  A gateway is a
652   receiving agent, acting as a layer above some other server(s) and, if
653   necessary, translating the requests to the underlying server's
654   protocol.  A tunnel acts as a relay point between two connections
655   without changing the messages; tunnels are used when the
656   communication needs to pass through an intermediary (such as a
657   firewall) even when the intermediary cannot understand the contents
658   of the messages.
659
660          request chain -------------------------------------->
661       UA -----v----- A -----v----- B -----v----- C -----v----- O
662          <------------------------------------- response chain
663
664   The figure above shows three intermediaries (A, B, and C) between the
665   user agent and origin server.  A request or response message that
666   travels the whole chain will pass through four separate connections.
667   This distinction is important because some HTTP communication options
668
669
670
671Fielding, et al.       Expires September 10, 2009              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1                  March 2009
674
675
676   may apply only to the connection with the nearest, non-tunnel
677   neighbor, only to the end-points of the chain, or to all connections
678   along the chain.  Although the diagram is linear, each participant
679   may be engaged in multiple, simultaneous communications.  For
680   example, B may be receiving requests from many clients other than A,
681   and/or forwarding requests to servers other than C, at the same time
682   that it is handling A's request.
683
684   Any party to the communication which is not acting as a tunnel may
685   employ an internal cache for handling requests.  The effect of a
686   cache is that the request/response chain is shortened if one of the
687   participants along the chain has a cached response applicable to that
688   request.  The following illustrates the resulting chain if B has a
689   cached copy of an earlier response from O (via C) for a request which
690   has not been cached by UA or A.
691
692             request chain ---------->
693          UA -----v----- A -----v----- B - - - - - - C - - - - - - O
694             <--------- response chain
695
696   Not all responses are usefully cacheable, and some requests may
697   contain modifiers which place special requirements on cache behavior.
698   HTTP requirements for cache behavior and cacheable responses are
699   defined in Section 1 of [Part6].
700
701   In fact, there are a wide variety of architectures and configurations
702   of caches and proxies currently being experimented with or deployed
703   across the World Wide Web. These systems include national hierarchies
704   of proxy caches to save transoceanic bandwidth, systems that
705   broadcast or multicast cache entries, organizations that distribute
706   subsets of cached data via CD-ROM, and so on.  HTTP systems are used
707   in corporate intranets over high-bandwidth links, and for access via
708   PDAs with low-power radio links and intermittent connectivity.  The
709   goal of HTTP/1.1 is to support the wide diversity of configurations
710   already deployed while introducing protocol constructs that meet the
711   needs of those who build web applications that require high
712   reliability and, failing that, at least reliable indications of
713   failure.
714
715   HTTP communication usually takes place over TCP/IP connections.  The
716   default port is TCP 80
717   (<http://www.iana.org/assignments/port-numbers>), but other ports can
718   be used.  This does not preclude HTTP from being implemented on top
719   of any other protocol on the Internet, or on other networks.  HTTP
720   only presumes a reliable transport; any protocol that provides such
721   guarantees can be used; the mapping of the HTTP/1.1 request and
722   response structures onto the transport data units of the protocol in
723   question is outside the scope of this specification.
724
725
726
727Fielding, et al.       Expires September 10, 2009              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1                  March 2009
730
731
732   In HTTP/1.0, most implementations used a new connection for each
733   request/response exchange.  In HTTP/1.1, a connection may be used for
734   one or more request/response exchanges, although connections may be
735   closed for a variety of reasons (see Section 7.1).
736
7372.3.  Use of HTTP for proxy communication
738
739   [[anchor2: TBD: Configured to use HTTP to proxy HTTP or other
740   protocols.]]
741
7422.4.  Interception of HTTP for access control
743
744   [[anchor3: TBD: Interception of HTTP traffic for initiating access
745   control.]]
746
7472.5.  Use of HTTP by other protocols
748
749   [[anchor4: TBD: Profiles of HTTP defined by other protocol.
750   Extensions of HTTP like WebDAV.]]
751
7522.6.  Use of HTTP by media type specification
753
754   [[anchor5: TBD: Instructions on composing HTTP requests via hypertext
755   formats.]]
756
757
7583.  Protocol Parameters
759
7603.1.  HTTP Version
761
762   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
763   of the protocol.  The protocol versioning policy is intended to allow
764   the sender to indicate the format of a message and its capacity for
765   understanding further HTTP communication, rather than the features
766   obtained via that communication.  No change is made to the version
767   number for the addition of message components which do not affect
768   communication behavior or which only add to extensible field values.
769   The <minor> number is incremented when the changes made to the
770   protocol add features which do not change the general message parsing
771   algorithm, but which may add to the message semantics and imply
772   additional capabilities of the sender.  The <major> number is
773   incremented when the format of a message within the protocol is
774   changed.  See [RFC2145] for a fuller explanation.
775
776   The version of an HTTP message is indicated by an HTTP-Version field
777   in the first line of the message.  HTTP-Version is case-sensitive.
778
779     HTTP-Version   = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
780
781
782
783Fielding, et al.       Expires September 10, 2009              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1                  March 2009
786
787
788     HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
789
790   Note that the major and minor numbers MUST be treated as separate
791   integers and that each MAY be incremented higher than a single digit.
792   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
793   lower than HTTP/12.3.  Leading zeros MUST be ignored by recipients
794   and MUST NOT be sent.
795
796   An application that sends a request or response message that includes
797   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
798   with this specification.  Applications that are at least
799   conditionally compliant with this specification SHOULD use an HTTP-
800   Version of "HTTP/1.1" in their messages, and MUST do so for any
801   message that is not compatible with HTTP/1.0.  For more details on
802   when to send specific HTTP-Version values, see [RFC2145].
803
804   The HTTP version of an application is the highest HTTP version for
805   which the application is at least conditionally compliant.
806
807   Proxy and gateway applications need to be careful when forwarding
808   messages in protocol versions different from that of the application.
809   Since the protocol version indicates the protocol capability of the
810   sender, a proxy/gateway MUST NOT send a message with a version
811   indicator which is greater than its actual version.  If a higher
812   version request is received, the proxy/gateway MUST either downgrade
813   the request version, or respond with an error, or switch to tunnel
814   behavior.
815
816   Due to interoperability problems with HTTP/1.0 proxies discovered
817   since the publication of [RFC2068], caching proxies MUST, gateways
818   MAY, and tunnels MUST NOT upgrade the request to the highest version
819   they support.  The proxy/gateway's response to that request MUST be
820   in the same major version as the request.
821
822      Note: Converting between versions of HTTP may involve modification
823      of header fields required or forbidden by the versions involved.
824
8253.2.  Date/Time Formats
826
8273.2.1.  Full Date
828
829   HTTP applications have historically allowed three different formats
830   for the representation of date/time stamps:
831
832     Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
833     Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
834     Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
835
836
837
838
839Fielding, et al.       Expires September 10, 2009              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1                  March 2009
842
843
844   The first format is preferred as an Internet standard and represents
845   a fixed-length subset of that defined by [RFC1123].  The other
846   formats are described here only for compatibility with obsolete
847   implementations.  HTTP/1.1 clients and servers that parse the date
848   value MUST accept all three formats (for compatibility with
849   HTTP/1.0), though they MUST only generate the RFC 1123 format for
850   representing HTTP-date values in header fields.  See Appendix A for
851   further information.
852
853      Note: Recipients of date values are encouraged to be robust in
854      accepting date values that may have been sent by non-HTTP
855      applications, as is sometimes the case when retrieving or posting
856      messages via proxies/gateways to SMTP or NNTP.
857
858   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
859   (GMT), without exception.  For the purposes of HTTP, GMT is exactly
860   equal to UTC (Coordinated Universal Time).  This is indicated in the
861   first two formats by the inclusion of "GMT" as the three-letter
862   abbreviation for time zone, and MUST be assumed when reading the
863   asctime format.  HTTP-date is case sensitive and MUST NOT include
864   additional whitespace beyond that specifically included as SP in the
865   grammar.
866
867     HTTP-date    = rfc1123-date / obsolete-date
868     obsolete-date = rfc850-date / asctime-date
869     rfc1123-date = wkday "," SP date1 SP time SP GMT
870     rfc850-date  = weekday "," SP date2 SP time SP GMT
871     asctime-date = wkday SP date3 SP time SP 4DIGIT
872     date1        = 2DIGIT SP month SP 4DIGIT
873                    ; day month year (e.g., 02 Jun 1982)
874     date2        = 2DIGIT "-" month "-" 2DIGIT
875                    ; day-month-year (e.g., 02-Jun-82)
876     date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
877                    ; month day (e.g., Jun  2)
878     time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
879                    ; 00:00:00 - 23:59:59
880     wkday        = s-Mon / s-Tue / s-Wed
881                  / s-Thu / s-Fri / s-Sat / s-Sun
882     weekday      = l-Mon / l-Tue / l-Wed
883                  / l-Thu / l-Fri / l-Sat / l-Sun
884     month        = s-Jan / s-Feb / s-Mar / s-Apr
885                  / s-May / s-Jun / s-Jul / s-Aug
886                  / s-Sep / s-Oct / s-Nov / s-Dec
887
888     GMT   = %x47.4D.54 ; "GMT", case-sensitive
889
890     s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
891     s-Tue = %x54.75.65 ; "Tue", case-sensitive
892
893
894
895Fielding, et al.       Expires September 10, 2009              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1                  March 2009
898
899
900     s-Wed = %x57.65.64 ; "Wed", case-sensitive
901     s-Thu = %x54.68.75 ; "Thu", case-sensitive
902     s-Fri = %x46.72.69 ; "Fri", case-sensitive
903     s-Sat = %x53.61.74 ; "Sat", case-sensitive
904     s-Sun = %x53.75.6E ; "Sun", case-sensitive
905
906     l-Mon = %x4D.6F.6E.64.61.79          ; "Monday", case-sensitive
907     l-Tue = %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
908     l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
909     l-Thu = %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
910     l-Fri = %x46.72.69.64.61.79          ; "Friday", case-sensitive
911     l-Sat = %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
912     l-Sun = %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
913
914     s-Jan = %x4A.61.6E ; "Jan", case-sensitive
915     s-Feb = %x46.65.62 ; "Feb", case-sensitive
916     s-Mar = %x4D.61.72 ; "Mar", case-sensitive
917     s-Apr = %x41.70.72 ; "Apr", case-sensitive
918     s-May = %x4D.61.79 ; "May", case-sensitive
919     s-Jun = %x4A.75.6E ; "Jun", case-sensitive
920     s-Jul = %x4A.75.6C ; "Jul", case-sensitive
921     s-Aug = %x41.75.67 ; "Aug", case-sensitive
922     s-Sep = %x53.65.70 ; "Sep", case-sensitive
923     s-Oct = %x4F.63.74 ; "Oct", case-sensitive
924     s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
925     s-Dec = %x44.65.63 ; "Dec", case-sensitive
926
927   Note: HTTP requirements for the date/time stamp format apply only to
928   their usage within the protocol stream.  Clients and servers are not
929   required to use these formats for user presentation, request logging,
930   etc.
931
9323.3.  Transfer Codings
933
934   Transfer-coding values are used to indicate an encoding
935   transformation that has been, can be, or may need to be applied to an
936   entity-body in order to ensure "safe transport" through the network.
937   This differs from a content coding in that the transfer-coding is a
938   property of the message, not of the original entity.
939
940     transfer-coding         = "chunked" / transfer-extension
941     transfer-extension      = token *( OWS ";" OWS parameter )
942
943   Parameters are in the form of attribute/value pairs.
944
945     parameter               = attribute BWS "=" BWS value
946     attribute               = token
947     value                   = token / quoted-string
948
949
950
951Fielding, et al.       Expires September 10, 2009              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1                  March 2009
954
955
956   All transfer-coding values are case-insensitive.  HTTP/1.1 uses
957   transfer-coding values in the TE header field (Section 8.5) and in
958   the Transfer-Encoding header field (Section 8.7).
959
960   Whenever a transfer-coding is applied to a message-body, the set of
961   transfer-codings MUST include "chunked", unless the message indicates
962   it is terminated by closing the connection.  When the "chunked"
963   transfer-coding is used, it MUST be the last transfer-coding applied
964   to the message-body.  The "chunked" transfer-coding MUST NOT be
965   applied more than once to a message-body.  These rules allow the
966   recipient to determine the transfer-length of the message
967   (Section 4.4).
968
969   Transfer-codings are analogous to the Content-Transfer-Encoding
970   values of MIME [RFC2045], which were designed to enable safe
971   transport of binary data over a 7-bit transport service.  However,
972   safe transport has a different focus for an 8bit-clean transfer
973   protocol.  In HTTP, the only unsafe characteristic of message-bodies
974   is the difficulty in determining the exact body length (Section 4.4),
975   or the desire to encrypt data over a shared transport.
976
977   The Internet Assigned Numbers Authority (IANA) acts as a registry for
978   transfer-coding value tokens.  Initially, the registry contains the
979   following tokens: "chunked" (Section 3.3.1), "gzip", "compress", and
980   "deflate" (Section 2.2 of [Part3]).
981
982   New transfer-coding value tokens SHOULD be registered in the same way
983   as new content-coding value tokens (Section 2.2 of [Part3]).
984
985   A server which receives an entity-body with a transfer-coding it does
986   not understand SHOULD return 501 (Not Implemented), and close the
987   connection.  A server MUST NOT send transfer-codings to an HTTP/1.0
988   client.
989
9903.3.1.  Chunked Transfer Coding
991
992   The chunked encoding modifies the body of a message in order to
993   transfer it as a series of chunks, each with its own size indicator,
994   followed by an OPTIONAL trailer containing entity-header fields.
995   This allows dynamically produced content to be transferred along with
996   the information necessary for the recipient to verify that it has
997   received the full message.
998
999
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.       Expires September 10, 2009              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1                  March 2009
1010
1011
1012     Chunked-Body   = *chunk
1013                      last-chunk
1014                      trailer-part
1015                      CRLF
1016
1017     chunk          = chunk-size *WSP [ chunk-ext ] CRLF
1018                      chunk-data CRLF
1019     chunk-size     = 1*HEXDIG
1020     last-chunk     = 1*("0") *WSP [ chunk-ext ] CRLF
1021
1022     chunk-ext      = *( ";" *WSP chunk-ext-name
1023                         [ "=" chunk-ext-val ] *WSP )
1024     chunk-ext-name = token
1025     chunk-ext-val  = token / quoted-string
1026     chunk-data     = 1*OCTET ; a sequence of chunk-size octets
1027     trailer-part   = *( entity-header CRLF )
1028
1029   The chunk-size field is a string of hex digits indicating the size of
1030   the chunk-data in octets.  The chunked encoding is ended by any chunk
1031   whose size is zero, followed by the trailer, which is terminated by
1032   an empty line.
1033
1034   The trailer allows the sender to include additional HTTP header
1035   fields at the end of the message.  The Trailer header field can be
1036   used to indicate which header fields are included in a trailer (see
1037   Section 8.6).
1038
1039   A server using chunked transfer-coding in a response MUST NOT use the
1040   trailer for any header fields unless at least one of the following is
1041   true:
1042
1043   1.  the request included a TE header field that indicates "trailers"
1044       is acceptable in the transfer-coding of the response, as
1045       described in Section 8.5; or,
1046
1047   2.  the server is the origin server for the response, the trailer
1048       fields consist entirely of optional metadata, and the recipient
1049       could use the message (in a manner acceptable to the origin
1050       server) without receiving this metadata.  In other words, the
1051       origin server is willing to accept the possibility that the
1052       trailer fields might be silently discarded along the path to the
1053       client.
1054
1055   This requirement prevents an interoperability failure when the
1056   message is being received by an HTTP/1.1 (or later) proxy and
1057   forwarded to an HTTP/1.0 recipient.  It avoids a situation where
1058   compliance with the protocol would have necessitated a possibly
1059   infinite buffer on the proxy.
1060
1061
1062
1063Fielding, et al.       Expires September 10, 2009              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1                  March 2009
1066
1067
1068   A process for decoding the "chunked" transfer-coding can be
1069   represented in pseudo-code as:
1070
1071     length := 0
1072     read chunk-size, chunk-ext (if any) and CRLF
1073     while (chunk-size > 0) {
1074        read chunk-data and CRLF
1075        append chunk-data to entity-body
1076        length := length + chunk-size
1077        read chunk-size and CRLF
1078     }
1079     read entity-header
1080     while (entity-header not empty) {
1081        append entity-header to existing header fields
1082        read entity-header
1083     }
1084     Content-Length := length
1085     Remove "chunked" from Transfer-Encoding
1086
1087   All HTTP/1.1 applications MUST be able to receive and decode the
1088   "chunked" transfer-coding, and MUST ignore chunk-ext extensions they
1089   do not understand.
1090
10913.4.  Product Tokens
1092
1093   Product tokens are used to allow communicating applications to
1094   identify themselves by software name and version.  Most fields using
1095   product tokens also allow sub-products which form a significant part
1096   of the application to be listed, separated by whitespace.  By
1097   convention, the products are listed in order of their significance
1098   for identifying the application.
1099
1100     product         = token ["/" product-version]
1101     product-version = token
1102
1103   Examples:
1104
1105     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1106     Server: Apache/0.8.4
1107
1108   Product tokens SHOULD be short and to the point.  They MUST NOT be
1109   used for advertising or other non-essential information.  Although
1110   any token character MAY appear in a product-version, this token
1111   SHOULD only be used for a version identifier (i.e., successive
1112   versions of the same product SHOULD only differ in the product-
1113   version portion of the product value).
1114
1115
1116
1117
1118
1119Fielding, et al.       Expires September 10, 2009              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1                  March 2009
1122
1123
11243.5.  Quality Values
1125
1126   Both transfer codings (TE request header, Section 8.5) and content
1127   negotiation (Section 4 of [Part3]) use short "floating point" numbers
1128   to indicate the relative importance ("weight") of various negotiable
1129   parameters.  A weight is normalized to a real number in the range 0
1130   through 1, where 0 is the minimum and 1 the maximum value.  If a
1131   parameter has a quality value of 0, then content with this parameter
1132   is `not acceptable' for the client.  HTTP/1.1 applications MUST NOT
1133   generate more than three digits after the decimal point.  User
1134   configuration of these values SHOULD also be limited in this fashion.
1135
1136     qvalue         = ( "0" [ "." 0*3DIGIT ] )
1137                    / ( "1" [ "." 0*3("0") ] )
1138
1139      Note: "Quality values" is a misnomer, since these values merely
1140      represent relative degradation in desired quality.
1141
1142
11434.  HTTP Message
1144
11454.1.  Message Types
1146
1147   HTTP messages consist of requests from client to server and responses
1148   from server to client.
1149
1150     HTTP-message   = Request / Response     ; HTTP/1.1 messages
1151
1152   Request (Section 5) and Response (Section 6) messages use the generic
1153   message format of [RFC5322] for transferring entities (the payload of
1154   the message).  Both types of message consist of a start-line, zero or
1155   more header fields (also known as "headers"), an empty line (i.e., a
1156   line with nothing preceding the CRLF) indicating the end of the
1157   header fields, and possibly a message-body.
1158
1159     generic-message = start-line
1160                       *( message-header CRLF )
1161                       CRLF
1162                       [ message-body ]
1163     start-line      = Request-Line / Status-Line
1164
1165   In the interest of robustness, servers SHOULD ignore any empty
1166   line(s) received where a Request-Line is expected.  In other words,
1167   if the server is reading the protocol stream at the beginning of a
1168   message and receives a CRLF first, it should ignore the CRLF.
1169
1170   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1171   after a POST request.  To restate what is explicitly forbidden by the
1172
1173
1174
1175Fielding, et al.       Expires September 10, 2009              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1                  March 2009
1178
1179
1180   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1181   extra CRLF.
1182
1183   Whitespace (WSP) MUST NOT be sent between the start-line and the
1184   first header field.  The presence of whitespace might be an attempt
1185   to trick a noncompliant implementation of HTTP into ignoring that
1186   field or processing the next line as a new request, either of which
1187   may result in security issues when implementations within the request
1188   chain interpret the same message differently.  HTTP/1.1 servers MUST
1189   reject such a message with a 400 (Bad Request) response.
1190
11914.2.  Message Headers
1192
1193   HTTP header fields follow the same general format as Internet
1194   messages in Section 2.1 of [RFC5322].  Each header field consists of
1195   a name followed by a colon (":"), optional whitespace, and the field
1196   value.  Field names are case-insensitive.
1197
1198     message-header = field-name ":" OWS [ field-value ] OWS
1199     field-name     = token
1200     field-value    = *( field-content / OWS )
1201     field-content  = *( WSP / VCHAR / obs-text )
1202
1203   Historically, HTTP has allowed field-content with text in the ISO-
1204   8859-1 [ISO-8859-1] character encoding (allowing other character sets
1205   through use of [RFC2047] encoding).  In practice, most HTTP header
1206   field-values use only a subset of the US-ASCII charset [USASCII].
1207   Newly defined header fields SHOULD constrain their field-values to
1208   US-ASCII characters.  Recipients SHOULD treat other (obs-text) octets
1209   in field-content as opaque data.
1210
1211   No whitespace is allowed between the header field-name and colon.
1212   For security reasons, any request message received containing such
1213   whitespace MUST be rejected with a response code of 400 (Bad Request)
1214   and any such whitespace in a response message MUST be removed.
1215
1216   The field value MAY be preceded by optional whitespace; a single SP
1217   is preferred.  The field-value does not include any leading or
1218   trailing white space: OWS occurring before the first non-whitespace
1219   character of the field-value or after the last non-whitespace
1220   character of the field-value is ignored and MAY be removed without
1221   changing the meaning of the header field.
1222
1223   Historically, HTTP header field values could be extended over
1224   multiple lines by preceding each extra line with at least one space
1225   or horizontal tab character (line folding).  This specification
1226   deprecates such line folding except within the message/http media
1227   type (Section 9.3.1).  HTTP/1.1 senders MUST NOT produce messages
1228
1229
1230
1231Fielding, et al.       Expires September 10, 2009              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1                  March 2009
1234
1235
1236   that include line folding (i.e., that contain any field-content that
1237   matches the obs-fold rule) unless the message is intended for
1238   packaging within the message/http media type.  HTTP/1.1 recipients
1239   SHOULD accept line folding and replace any embedded obs-fold
1240   whitespace with a single SP prior to interpreting the field value or
1241   forwarding the message downstream.
1242
1243   Comments can be included in some HTTP header fields by surrounding
1244   the comment text with parentheses.  Comments are only allowed in
1245   fields containing "comment" as part of their field value definition.
1246   In all other fields, parentheses are considered part of the field
1247   value.
1248
1249     comment        = "(" *( ctext / quoted-pair / comment ) ")"
1250     ctext          = *( OWS / %x21-27 / %x2A-7E / obs-text )
1251
1252   The order in which header fields with differing field names are
1253   received is not significant.  However, it is "good practice" to send
1254   general-header fields first, followed by request-header or response-
1255   header fields, and ending with the entity-header fields.
1256
1257   Multiple message-header fields with the same field-name MAY be
1258   present in a message if and only if the entire field-value for that
1259   header field is defined as a comma-separated list [i.e., #(values)].
1260   It MUST be possible to combine the multiple header fields into one
1261   "field-name: field-value" pair, without changing the semantics of the
1262   message, by appending each subsequent field-value to the first, each
1263   separated by a comma.  The order in which header fields with the same
1264   field-name are received is therefore significant to the
1265   interpretation of the combined field value, and thus a proxy MUST NOT
1266   change the order of these field values when a message is forwarded.
1267
1268      Note: the "Set-Cookie" header as implemented in practice (as
1269      opposed to how it is specified in [RFC2109]) can occur multiple
1270      times, but does not use the list syntax, and thus cannot be
1271      combined into a single line.  (See Appendix A.2.3 of [Kri2001] for
1272      details.)  Also note that the Set-Cookie2 header specified in
1273      [RFC2965] does not share this problem.
1274
12754.3.  Message Body
1276
1277   The message-body (if any) of an HTTP message is used to carry the
1278   entity-body associated with the request or response.  The message-
1279   body differs from the entity-body only when a transfer-coding has
1280   been applied, as indicated by the Transfer-Encoding header field
1281   (Section 8.7).
1282
1283     message-body = entity-body
1284
1285
1286
1287Fielding, et al.       Expires September 10, 2009              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1                  March 2009
1290
1291
1292                  / <entity-body encoded as per Transfer-Encoding>
1293
1294   Transfer-Encoding MUST be used to indicate any transfer-codings
1295   applied by an application to ensure safe and proper transfer of the
1296   message.  Transfer-Encoding is a property of the message, not of the
1297   entity, and thus MAY be added or removed by any application along the
1298   request/response chain.  (However, Section 3.3 places restrictions on
1299   when certain transfer-codings may be used.)
1300
1301   The rules for when a message-body is allowed in a message differ for
1302   requests and responses.
1303
1304   The presence of a message-body in a request is signaled by the
1305   inclusion of a Content-Length or Transfer-Encoding header field in
1306   the request's message-headers.  A message-body MUST NOT be included
1307   in a request if the specification of the request method (Section 2 of
1308   [Part2]) explicitly disallows an entity-body in requests.  When a
1309   request message contains both a message-body of non-zero length and a
1310   method that does not define any semantics for that request message-
1311   body, then an origin server SHOULD either ignore the message-body or
1312   respond with an appropriate error message (e.g., 413).  A proxy or
1313   gateway, when presented the same request, SHOULD either forward the
1314   request inbound with the message-body or ignore the message-body when
1315   determining a response.
1316
1317   For response messages, whether or not a message-body is included with
1318   a message is dependent on both the request method and the response
1319   status code (Section 6.1.1).  All responses to the HEAD request
1320   method MUST NOT include a message-body, even though the presence of
1321   entity-header fields might lead one to believe they do.  All 1xx
1322   (informational), 204 (No Content), and 304 (Not Modified) responses
1323   MUST NOT include a message-body.  All other responses do include a
1324   message-body, although it MAY be of zero length.
1325
13264.4.  Message Length
1327
1328   The transfer-length of a message is the length of the message-body as
1329   it appears in the message; that is, after any transfer-codings have
1330   been applied.  When a message-body is included with a message, the
1331   transfer-length of that body is determined by one of the following
1332   (in order of precedence):
1333
1334   1.  Any response message which "MUST NOT" include a message-body
1335       (such as the 1xx, 204, and 304 responses and any response to a
1336       HEAD request) is always terminated by the first empty line after
1337       the header fields, regardless of the entity-header fields present
1338       in the message.
1339
1340
1341
1342
1343Fielding, et al.       Expires September 10, 2009              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1                  March 2009
1346
1347
1348   2.  If a Transfer-Encoding header field (Section 8.7) is present and
1349       the "chunked" transfer-coding (Section 3.3) is used, the
1350       transfer-length is defined by the use of this transfer-coding.
1351       If a Transfer-Encoding header field is present and the "chunked"
1352       transfer-coding is not present, the transfer-length is defined by
1353       the sender closing the connection.
1354
1355   3.  If a Content-Length header field (Section 8.2) is present, its
1356       decimal value in OCTETs represents both the entity-length and the
1357       transfer-length.  The Content-Length header field MUST NOT be
1358       sent if these two lengths are different (i.e., if a Transfer-
1359       Encoding header field is present).  If a message is received with
1360       both a Transfer-Encoding header field and a Content-Length header
1361       field, the latter MUST be ignored.
1362
1363   4.  If the message uses the media type "multipart/byteranges", and
1364       the transfer-length is not otherwise specified, then this self-
1365       delimiting media type defines the transfer-length.  This media
1366       type MUST NOT be used unless the sender knows that the recipient
1367       can parse it; the presence in a request of a Range header with
1368       multiple byte-range specifiers from a 1.1 client implies that the
1369       client can parse multipart/byteranges responses.
1370
1371          A range header might be forwarded by a 1.0 proxy that does not
1372          understand multipart/byteranges; in this case the server MUST
1373          delimit the message using methods defined in items 1, 3 or 5
1374          of this section.
1375
1376   5.  By the server closing the connection.  (Closing the connection
1377       cannot be used to indicate the end of a request body, since that
1378       would leave no possibility for the server to send back a
1379       response.)
1380
1381   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1382   containing a message-body MUST include a valid Content-Length header
1383   field unless the server is known to be HTTP/1.1 compliant.  If a
1384   request contains a message-body and a Content-Length is not given,
1385   the server SHOULD respond with 400 (Bad Request) if it cannot
1386   determine the length of the message, or with 411 (Length Required) if
1387   it wishes to insist on receiving a valid Content-Length.
1388
1389   All HTTP/1.1 applications that receive entities MUST accept the
1390   "chunked" transfer-coding (Section 3.3), thus allowing this mechanism
1391   to be used for messages when the message length cannot be determined
1392   in advance.
1393
1394   Messages MUST NOT include both a Content-Length header field and a
1395   transfer-coding.  If the message does include a transfer-coding, the
1396
1397
1398
1399Fielding, et al.       Expires September 10, 2009              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1                  March 2009
1402
1403
1404   Content-Length MUST be ignored.
1405
1406   When a Content-Length is given in a message where a message-body is
1407   allowed, its field value MUST exactly match the number of OCTETs in
1408   the message-body.  HTTP/1.1 user agents MUST notify the user when an
1409   invalid length is received and detected.
1410
14114.5.  General Header Fields
1412
1413   There are a few header fields which have general applicability for
1414   both request and response messages, but which do not apply to the
1415   entity being transferred.  These header fields apply only to the
1416   message being transmitted.
1417
1418     general-header = Cache-Control            ; [Part6], Section 3.2
1419                    / Connection               ; Section 8.1
1420                    / Date                     ; Section 8.3
1421                    / Pragma                   ; [Part6], Section 3.4
1422                    / Trailer                  ; Section 8.6
1423                    / Transfer-Encoding        ; Section 8.7
1424                    / Upgrade                  ; Section 8.8
1425                    / Via                      ; Section 8.9
1426                    / Warning                  ; [Part6], Section 3.6
1427
1428   General-header field names can be extended reliably only in
1429   combination with a change in the protocol version.  However, new or
1430   experimental header fields may be given the semantics of general
1431   header fields if all parties in the communication recognize them to
1432   be general-header fields.  Unrecognized header fields are treated as
1433   entity-header fields.
1434
1435
14365.  Request
1437
1438   A request message from a client to a server includes, within the
1439   first line of that message, the method to be applied to the resource,
1440   the identifier of the resource, and the protocol version in use.
1441
1442     Request       = Request-Line              ; Section 5.1
1443                     *(( general-header        ; Section 4.5
1444                      / request-header         ; [Part2], Section 3
1445                      / entity-header ) CRLF )  ; [Part3], Section 3.1
1446                     CRLF
1447                     [ message-body ]          ; Section 4.3
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.       Expires September 10, 2009              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1                  March 2009
1458
1459
14605.1.  Request-Line
1461
1462   The Request-Line begins with a method token, followed by the request-
1463   target and the protocol version, and ending with CRLF.  The elements
1464   are separated by SP characters.  No CR or LF is allowed except in the
1465   final CRLF sequence.
1466
1467     Request-Line   = Method SP request-target SP HTTP-Version CRLF
1468
14695.1.1.  Method
1470
1471   The Method token indicates the method to be performed on the resource
1472   identified by the request-target.  The method is case-sensitive.
1473
1474     Method         = token
1475
14765.1.2.  request-target
1477
1478   The request-target identifies the resource upon which to apply the
1479   request.
1480
1481     request-target = "*"
1482                    / absolute-URI
1483                    / ( path-absolute [ "?" query ] )
1484                    / authority
1485
1486   The four options for request-target are dependent on the nature of
1487   the request.  The asterisk "*" means that the request does not apply
1488   to a particular resource, but to the server itself, and is only
1489   allowed when the method used does not necessarily apply to a
1490   resource.  One example would be
1491
1492     OPTIONS * HTTP/1.1
1493
1494   The absolute-URI form is REQUIRED when the request is being made to a
1495   proxy.  The proxy is requested to forward the request or service it
1496   from a valid cache, and return the response.  Note that the proxy MAY
1497   forward the request on to another proxy or directly to the server
1498   specified by the absolute-URI.  In order to avoid request loops, a
1499   proxy MUST be able to recognize all of its server names, including
1500   any aliases, local variations, and the numeric IP address.  An
1501   example Request-Line would be:
1502
1503     GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1504
1505   To allow for transition to absolute-URIs in all requests in future
1506   versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1507   form in requests, even though HTTP/1.1 clients will only generate
1508
1509
1510
1511Fielding, et al.       Expires September 10, 2009              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1                  March 2009
1514
1515
1516   them in requests to proxies.
1517
1518   The authority form is only used by the CONNECT method (Section 7.9 of
1519   [Part2]).
1520
1521   The most common form of request-target is that used to identify a
1522   resource on an origin server or gateway.  In this case the absolute
1523   path of the URI MUST be transmitted (see Section 2.1.1, path-
1524   absolute) as the request-target, and the network location of the URI
1525   (authority) MUST be transmitted in a Host header field.  For example,
1526   a client wishing to retrieve the resource above directly from the
1527   origin server would create a TCP connection to port 80 of the host
1528   "www.example.org" and send the lines:
1529
1530     GET /pub/WWW/TheProject.html HTTP/1.1
1531     Host: www.example.org
1532
1533   followed by the remainder of the Request.  Note that the absolute
1534   path cannot be empty; if none is present in the original URI, it MUST
1535   be given as "/" (the server root).
1536
1537   If a proxy receives a request without any path in the request-target
1538   and the method specified is capable of supporting the asterisk form
1539   of request-target, then the last proxy on the request chain MUST
1540   forward the request with "*" as the final request-target.
1541
1542   For example, the request
1543
1544     OPTIONS http://www.example.org:8001 HTTP/1.1
1545
1546   would be forwarded by the proxy as
1547
1548     OPTIONS * HTTP/1.1
1549     Host: www.example.org:8001
1550
1551   after connecting to port 8001 of host "www.example.org".
1552
1553   The request-target is transmitted in the format specified in
1554   Section 2.1.1.  If the request-target is percent-encoded ([RFC3986],
1555   Section 2.1), the origin server MUST decode the request-target in
1556   order to properly interpret the request.  Servers SHOULD respond to
1557   invalid request-targets with an appropriate status code.
1558
1559   A transparent proxy MUST NOT rewrite the "path-absolute" part of the
1560   received request-target when forwarding it to the next inbound
1561   server, except as noted above to replace a null path-absolute with
1562   "/".
1563
1564
1565
1566
1567Fielding, et al.       Expires September 10, 2009              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1                  March 2009
1570
1571
1572      Note: The "no rewrite" rule prevents the proxy from changing the
1573      meaning of the request when the origin server is improperly using
1574      a non-reserved URI character for a reserved purpose.  Implementors
1575      should be aware that some pre-HTTP/1.1 proxies have been known to
1576      rewrite the request-target.
1577
1578   HTTP does not place a pre-defined limit on the length of a request-
1579   target.  A server MUST be prepared to receive URIs of unbounded
1580   length and respond with the 414 (URI Too Long) status if the received
1581   request-target would be longer than the server wishes to handle (see
1582   Section 8.4.15 of [Part2]).
1583
1584   Various ad-hoc limitations on request-target length are found in
1585   practice.  It is RECOMMENDED that all HTTP senders and recipients
1586   support request-target lengths of 8000 or more OCTETs.
1587
15885.2.  The Resource Identified by a Request
1589
1590   The exact resource identified by an Internet request is determined by
1591   examining both the request-target and the Host header field.
1592
1593   An origin server that does not allow resources to differ by the
1594   requested host MAY ignore the Host header field value when
1595   determining the resource identified by an HTTP/1.1 request.  (But see
1596   Appendix B.1.1 for other requirements on Host support in HTTP/1.1.)
1597
1598   An origin server that does differentiate resources based on the host
1599   requested (sometimes referred to as virtual hosts or vanity host
1600   names) MUST use the following rules for determining the requested
1601   resource on an HTTP/1.1 request:
1602
1603   1.  If request-target is an absolute-URI, the host is part of the
1604       request-target.  Any Host header field value in the request MUST
1605       be ignored.
1606
1607   2.  If the request-target is not an absolute-URI, and the request
1608       includes a Host header field, the host is determined by the Host
1609       header field value.
1610
1611   3.  If the host as determined by rule 1 or 2 is not a valid host on
1612       the server, the response MUST be a 400 (Bad Request) error
1613       message.
1614
1615   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1616   attempt to use heuristics (e.g., examination of the URI path for
1617   something unique to a particular host) in order to determine what
1618   exact resource is being requested.
1619
1620
1621
1622
1623Fielding, et al.       Expires September 10, 2009              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1                  March 2009
1626
1627
16286.  Response
1629
1630   After receiving and interpreting a request message, a server responds
1631   with an HTTP response message.
1632
1633     Response      = Status-Line               ; Section 6.1
1634                     *(( general-header        ; Section 4.5
1635                      / response-header        ; [Part2], Section 5
1636                      / entity-header ) CRLF )  ; [Part3], Section 3.1
1637                     CRLF
1638                     [ message-body ]          ; Section 4.3
1639
16406.1.  Status-Line
1641
1642   The first line of a Response message is the Status-Line, consisting
1643   of the protocol version followed by a numeric status code and its
1644   associated textual phrase, with each element separated by SP
1645   characters.  No CR or LF is allowed except in the final CRLF
1646   sequence.
1647
1648     Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1649
16506.1.1.  Status Code and Reason Phrase
1651
1652   The Status-Code element is a 3-digit integer result code of the
1653   attempt to understand and satisfy the request.  These codes are fully
1654   defined in Section 8 of [Part2].  The Reason Phrase exists for the
1655   sole purpose of providing a textual description associated with the
1656   numeric status code, out of deference to earlier Internet application
1657   protocols that were more frequently used with interactive text
1658   clients.  A client SHOULD ignore the content of the Reason Phrase.
1659
1660   The first digit of the Status-Code defines the class of response.
1661   The last two digits do not have any categorization role.  There are 5
1662   values for the first digit:
1663
1664   o  1xx: Informational - Request received, continuing process
1665
1666   o  2xx: Success - The action was successfully received, understood,
1667      and accepted
1668
1669   o  3xx: Redirection - Further action must be taken in order to
1670      complete the request
1671
1672   o  4xx: Client Error - The request contains bad syntax or cannot be
1673      fulfilled
1674
1675
1676
1677
1678
1679Fielding, et al.       Expires September 10, 2009              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1                  March 2009
1682
1683
1684   o  5xx: Server Error - The server failed to fulfill an apparently
1685      valid request
1686
1687
1688     Status-Code    = 3DIGIT
1689     Reason-Phrase  = *( WSP / VCHAR / obs-text )
1690
1691
16927.  Connections
1693
16947.1.  Persistent Connections
1695
16967.1.1.  Purpose
1697
1698   Prior to persistent connections, a separate TCP connection was
1699   established to fetch each URL, increasing the load on HTTP servers
1700   and causing congestion on the Internet.  The use of inline images and
1701   other associated data often require a client to make multiple
1702   requests of the same server in a short amount of time.  Analysis of
1703   these performance problems and results from a prototype
1704   implementation are available [Pad1995] [Spe].  Implementation
1705   experience and measurements of actual HTTP/1.1 (RFC 2068)
1706   implementations show good results [Nie1997].  Alternatives have also
1707   been explored, for example, T/TCP [Tou1998].
1708
1709   Persistent HTTP connections have a number of advantages:
1710
1711   o  By opening and closing fewer TCP connections, CPU time is saved in
1712      routers and hosts (clients, servers, proxies, gateways, tunnels,
1713      or caches), and memory used for TCP protocol control blocks can be
1714      saved in hosts.
1715
1716   o  HTTP requests and responses can be pipelined on a connection.
1717      Pipelining allows a client to make multiple requests without
1718      waiting for each response, allowing a single TCP connection to be
1719      used much more efficiently, with much lower elapsed time.
1720
1721   o  Network congestion is reduced by reducing the number of packets
1722      caused by TCP opens, and by allowing TCP sufficient time to
1723      determine the congestion state of the network.
1724
1725   o  Latency on subsequent requests is reduced since there is no time
1726      spent in TCP's connection opening handshake.
1727
1728   o  HTTP can evolve more gracefully, since errors can be reported
1729      without the penalty of closing the TCP connection.  Clients using
1730      future versions of HTTP might optimistically try a new feature,
1731      but if communicating with an older server, retry with old
1732
1733
1734
1735Fielding, et al.       Expires September 10, 2009              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1                  March 2009
1738
1739
1740      semantics after an error is reported.
1741
1742   HTTP implementations SHOULD implement persistent connections.
1743
17447.1.2.  Overall Operation
1745
1746   A significant difference between HTTP/1.1 and earlier versions of
1747   HTTP is that persistent connections are the default behavior of any
1748   HTTP connection.  That is, unless otherwise indicated, the client
1749   SHOULD assume that the server will maintain a persistent connection,
1750   even after error responses from the server.
1751
1752   Persistent connections provide a mechanism by which a client and a
1753   server can signal the close of a TCP connection.  This signaling
1754   takes place using the Connection header field (Section 8.1).  Once a
1755   close has been signaled, the client MUST NOT send any more requests
1756   on that connection.
1757
17587.1.2.1.  Negotiation
1759
1760   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
1761   maintain a persistent connection unless a Connection header including
1762   the connection-token "close" was sent in the request.  If the server
1763   chooses to close the connection immediately after sending the
1764   response, it SHOULD send a Connection header including the
1765   connection-token close.
1766
1767   An HTTP/1.1 client MAY expect a connection to remain open, but would
1768   decide to keep it open based on whether the response from a server
1769   contains a Connection header with the connection-token close.  In
1770   case the client does not want to maintain a connection for more than
1771   that request, it SHOULD send a Connection header including the
1772   connection-token close.
1773
1774   If either the client or the server sends the close token in the
1775   Connection header, that request becomes the last one for the
1776   connection.
1777
1778   Clients and servers SHOULD NOT assume that a persistent connection is
1779   maintained for HTTP versions less than 1.1 unless it is explicitly
1780   signaled.  See Appendix B.2 for more information on backward
1781   compatibility with HTTP/1.0 clients.
1782
1783   In order to remain persistent, all messages on the connection MUST
1784   have a self-defined message length (i.e., one not defined by closure
1785   of the connection), as described in Section 4.4.
1786
1787
1788
1789
1790
1791Fielding, et al.       Expires September 10, 2009              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1                  March 2009
1794
1795
17967.1.2.2.  Pipelining
1797
1798   A client that supports persistent connections MAY "pipeline" its
1799   requests (i.e., send multiple requests without waiting for each
1800   response).  A server MUST send its responses to those requests in the
1801   same order that the requests were received.
1802
1803   Clients which assume persistent connections and pipeline immediately
1804   after connection establishment SHOULD be prepared to retry their
1805   connection if the first pipelined attempt fails.  If a client does
1806   such a retry, it MUST NOT pipeline before it knows the connection is
1807   persistent.  Clients MUST also be prepared to resend their requests
1808   if the server closes the connection before sending all of the
1809   corresponding responses.
1810
1811   Clients SHOULD NOT pipeline requests using non-idempotent methods or
1812   non-idempotent sequences of methods (see Section 7.1.2 of [Part2]).
1813   Otherwise, a premature termination of the transport connection could
1814   lead to indeterminate results.  A client wishing to send a non-
1815   idempotent request SHOULD wait to send that request until it has
1816   received the response status for the previous request.
1817
18187.1.3.  Proxy Servers
1819
1820   It is especially important that proxies correctly implement the
1821   properties of the Connection header field as specified in
1822   Section 8.1.
1823
1824   The proxy server MUST signal persistent connections separately with
1825   its clients and the origin servers (or other proxy servers) that it
1826   connects to.  Each persistent connection applies to only one
1827   transport link.
1828
1829   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
1830   with an HTTP/1.0 client (but see [RFC2068] for information and
1831   discussion of the problems with the Keep-Alive header implemented by
1832   many HTTP/1.0 clients).
1833
18347.1.4.  Practical Considerations
1835
1836   Servers will usually have some time-out value beyond which they will
1837   no longer maintain an inactive connection.  Proxy servers might make
1838   this a higher value since it is likely that the client will be making
1839   more connections through the same server.  The use of persistent
1840   connections places no requirements on the length (or existence) of
1841   this time-out for either the client or the server.
1842
1843   When a client or server wishes to time-out it SHOULD issue a graceful
1844
1845
1846
1847Fielding, et al.       Expires September 10, 2009              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1                  March 2009
1850
1851
1852   close on the transport connection.  Clients and servers SHOULD both
1853   constantly watch for the other side of the transport close, and
1854   respond to it as appropriate.  If a client or server does not detect
1855   the other side's close promptly it could cause unnecessary resource
1856   drain on the network.
1857
1858   A client, server, or proxy MAY close the transport connection at any
1859   time.  For example, a client might have started to send a new request
1860   at the same time that the server has decided to close the "idle"
1861   connection.  From the server's point of view, the connection is being
1862   closed while it was idle, but from the client's point of view, a
1863   request is in progress.
1864
1865   This means that clients, servers, and proxies MUST be able to recover
1866   from asynchronous close events.  Client software SHOULD reopen the
1867   transport connection and retransmit the aborted sequence of requests
1868   without user interaction so long as the request sequence is
1869   idempotent (see Section 7.1.2 of [Part2]).  Non-idempotent methods or
1870   sequences MUST NOT be automatically retried, although user agents MAY
1871   offer a human operator the choice of retrying the request(s).
1872   Confirmation by user-agent software with semantic understanding of
1873   the application MAY substitute for user confirmation.  The automatic
1874   retry SHOULD NOT be repeated if the second sequence of requests
1875   fails.
1876
1877   Servers SHOULD always respond to at least one request per connection,
1878   if at all possible.  Servers SHOULD NOT close a connection in the
1879   middle of transmitting a response, unless a network or client failure
1880   is suspected.
1881
1882   Clients that use persistent connections SHOULD limit the number of
1883   simultaneous connections that they maintain to a given server.  A
1884   single-user client SHOULD NOT maintain more than 2 connections with
1885   any server or proxy.  A proxy SHOULD use up to 2*N connections to
1886   another server or proxy, where N is the number of simultaneously
1887   active users.  These guidelines are intended to improve HTTP response
1888   times and avoid congestion.
1889
18907.2.  Message Transmission Requirements
1891
18927.2.1.  Persistent Connections and Flow Control
1893
1894   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
1895   flow control mechanisms to resolve temporary overloads, rather than
1896   terminating connections with the expectation that clients will retry.
1897   The latter technique can exacerbate network congestion.
1898
1899
1900
1901
1902
1903Fielding, et al.       Expires September 10, 2009              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1                  March 2009
1906
1907
19087.2.2.  Monitoring Connections for Error Status Messages
1909
1910   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
1911   the network connection for an error status while it is transmitting
1912   the request.  If the client sees an error status, it SHOULD
1913   immediately cease transmitting the body.  If the body is being sent
1914   using a "chunked" encoding (Section 3.3), a zero length chunk and
1915   empty trailer MAY be used to prematurely mark the end of the message.
1916   If the body was preceded by a Content-Length header, the client MUST
1917   close the connection.
1918
19197.2.3.  Use of the 100 (Continue) Status
1920
1921   The purpose of the 100 (Continue) status (see Section 8.1.1 of
1922   [Part2]) is to allow a client that is sending a request message with
1923   a request body to determine if the origin server is willing to accept
1924   the request (based on the request headers) before the client sends
1925   the request body.  In some cases, it might either be inappropriate or
1926   highly inefficient for the client to send the body if the server will
1927   reject the message without looking at the body.
1928
1929   Requirements for HTTP/1.1 clients:
1930
1931   o  If a client will wait for a 100 (Continue) response before sending
1932      the request body, it MUST send an Expect request-header field
1933      (Section 9.2 of [Part2]) with the "100-continue" expectation.
1934
1935   o  A client MUST NOT send an Expect request-header field (Section 9.2
1936      of [Part2]) with the "100-continue" expectation if it does not
1937      intend to send a request body.
1938
1939   Because of the presence of older implementations, the protocol allows
1940   ambiguous situations in which a client may send "Expect: 100-
1941   continue" without receiving either a 417 (Expectation Failed) status
1942   or a 100 (Continue) status.  Therefore, when a client sends this
1943   header field to an origin server (possibly via a proxy) from which it
1944   has never seen a 100 (Continue) status, the client SHOULD NOT wait
1945   for an indefinite period before sending the request body.
1946
1947   Requirements for HTTP/1.1 origin servers:
1948
1949   o  Upon receiving a request which includes an Expect request-header
1950      field with the "100-continue" expectation, an origin server MUST
1951      either respond with 100 (Continue) status and continue to read
1952      from the input stream, or respond with a final status code.  The
1953      origin server MUST NOT wait for the request body before sending
1954      the 100 (Continue) response.  If it responds with a final status
1955      code, it MAY close the transport connection or it MAY continue to
1956
1957
1958
1959Fielding, et al.       Expires September 10, 2009              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1                  March 2009
1962
1963
1964      read and discard the rest of the request.  It MUST NOT perform the
1965      requested method if it returns a final status code.
1966
1967   o  An origin server SHOULD NOT send a 100 (Continue) response if the
1968      request message does not include an Expect request-header field
1969      with the "100-continue" expectation, and MUST NOT send a 100
1970      (Continue) response if such a request comes from an HTTP/1.0 (or
1971      earlier) client.  There is an exception to this rule: for
1972      compatibility with [RFC2068], a server MAY send a 100 (Continue)
1973      status in response to an HTTP/1.1 PUT or POST request that does
1974      not include an Expect request-header field with the "100-continue"
1975      expectation.  This exception, the purpose of which is to minimize
1976      any client processing delays associated with an undeclared wait
1977      for 100 (Continue) status, applies only to HTTP/1.1 requests, and
1978      not to requests with any other HTTP-version value.
1979
1980   o  An origin server MAY omit a 100 (Continue) response if it has
1981      already received some or all of the request body for the
1982      corresponding request.
1983
1984   o  An origin server that sends a 100 (Continue) response MUST
1985      ultimately send a final status code, once the request body is
1986      received and processed, unless it terminates the transport
1987      connection prematurely.
1988
1989   o  If an origin server receives a request that does not include an
1990      Expect request-header field with the "100-continue" expectation,
1991      the request includes a request body, and the server responds with
1992      a final status code before reading the entire request body from
1993      the transport connection, then the server SHOULD NOT close the
1994      transport connection until it has read the entire request, or
1995      until the client closes the connection.  Otherwise, the client
1996      might not reliably receive the response message.  However, this
1997      requirement is not be construed as preventing a server from
1998      defending itself against denial-of-service attacks, or from badly
1999      broken client implementations.
2000
2001   Requirements for HTTP/1.1 proxies:
2002
2003   o  If a proxy receives a request that includes an Expect request-
2004      header field with the "100-continue" expectation, and the proxy
2005      either knows that the next-hop server complies with HTTP/1.1 or
2006      higher, or does not know the HTTP version of the next-hop server,
2007      it MUST forward the request, including the Expect header field.
2008
2009   o  If the proxy knows that the version of the next-hop server is
2010      HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2011      respond with a 417 (Expectation Failed) status.
2012
2013
2014
2015Fielding, et al.       Expires September 10, 2009              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1                  March 2009
2018
2019
2020   o  Proxies SHOULD maintain a cache recording the HTTP version numbers
2021      received from recently-referenced next-hop servers.
2022
2023   o  A proxy MUST NOT forward a 100 (Continue) response if the request
2024      message was received from an HTTP/1.0 (or earlier) client and did
2025      not include an Expect request-header field with the "100-continue"
2026      expectation.  This requirement overrides the general rule for
2027      forwarding of 1xx responses (see Section 8.1 of [Part2]).
2028
20297.2.4.  Client Behavior if Server Prematurely Closes Connection
2030
2031   If an HTTP/1.1 client sends a request which includes a request body,
2032   but which does not include an Expect request-header field with the
2033   "100-continue" expectation, and if the client is not directly
2034   connected to an HTTP/1.1 origin server, and if the client sees the
2035   connection close before receiving any status from the server, the
2036   client SHOULD retry the request.  If the client does retry this
2037   request, it MAY use the following "binary exponential backoff"
2038   algorithm to be assured of obtaining a reliable response:
2039
2040   1.  Initiate a new connection to the server
2041
2042   2.  Transmit the request-headers
2043
2044   3.  Initialize a variable R to the estimated round-trip time to the
2045       server (e.g., based on the time it took to establish the
2046       connection), or to a constant value of 5 seconds if the round-
2047       trip time is not available.
2048
2049   4.  Compute T = R * (2**N), where N is the number of previous retries
2050       of this request.
2051
2052   5.  Wait either for an error response from the server, or for T
2053       seconds (whichever comes first)
2054
2055   6.  If no error response is received, after T seconds transmit the
2056       body of the request.
2057
2058   7.  If client sees that the connection is closed prematurely, repeat
2059       from step 1 until the request is accepted, an error response is
2060       received, or the user becomes impatient and terminates the retry
2061       process.
2062
2063   If at any point an error status is received, the client
2064
2065   o  SHOULD NOT continue and
2066
2067
2068
2069
2070
2071Fielding, et al.       Expires September 10, 2009              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1                  March 2009
2074
2075
2076   o  SHOULD close the connection if it has not completed sending the
2077      request message.
2078
2079
20808.  Header Field Definitions
2081
2082   This section defines the syntax and semantics of HTTP/1.1 header
2083   fields related to message framing and transport protocols.
2084
2085   For entity-header fields, both sender and recipient refer to either
2086   the client or the server, depending on who sends and who receives the
2087   entity.
2088
20898.1.  Connection
2090
2091   The general-header field "Connection" allows the sender to specify
2092   options that are desired for that particular connection and MUST NOT
2093   be communicated by proxies over further connections.
2094
2095   The Connection header's value has the following grammar:
2096
2097     Connection       = "Connection" ":" OWS Connection-v
2098     Connection-v     = 1#connection-token
2099     connection-token = token
2100
2101   HTTP/1.1 proxies MUST parse the Connection header field before a
2102   message is forwarded and, for each connection-token in this field,
2103   remove any header field(s) from the message with the same name as the
2104   connection-token.  Connection options are signaled by the presence of
2105   a connection-token in the Connection header field, not by any
2106   corresponding additional header field(s), since the additional header
2107   field may not be sent if there are no parameters associated with that
2108   connection option.
2109
2110   Message headers listed in the Connection header MUST NOT include end-
2111   to-end headers, such as Cache-Control.
2112
2113   HTTP/1.1 defines the "close" connection option for the sender to
2114   signal that the connection will be closed after completion of the
2115   response.  For example,
2116
2117     Connection: close
2118
2119   in either the request or the response header fields indicates that
2120   the connection SHOULD NOT be considered `persistent' (Section 7.1)
2121   after the current request/response is complete.
2122
2123   An HTTP/1.1 client that does not support persistent connections MUST
2124
2125
2126
2127Fielding, et al.       Expires September 10, 2009              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1                  March 2009
2130
2131
2132   include the "close" connection option in every request message.
2133
2134   An HTTP/1.1 server that does not support persistent connections MUST
2135   include the "close" connection option in every response message that
2136   does not have a 1xx (informational) status code.
2137
2138   A system receiving an HTTP/1.0 (or lower-version) message that
2139   includes a Connection header MUST, for each connection-token in this
2140   field, remove and ignore any header field(s) from the message with
2141   the same name as the connection-token.  This protects against
2142   mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
2143   See Appendix B.2.
2144
21458.2.  Content-Length
2146
2147   The entity-header field "Content-Length" indicates the size of the
2148   entity-body, in decimal number of OCTETs, sent to the recipient or,
2149   in the case of the HEAD method, the size of the entity-body that
2150   would have been sent had the request been a GET.
2151
2152     Content-Length   = "Content-Length" ":" OWS 1*Content-Length-v
2153     Content-Length-v = 1*DIGIT
2154
2155   An example is
2156
2157     Content-Length: 3495
2158
2159   Applications SHOULD use this field to indicate the transfer-length of
2160   the message-body, unless this is prohibited by the rules in
2161   Section 4.4.
2162
2163   Any Content-Length greater than or equal to zero is a valid value.
2164   Section 4.4 describes how to determine the length of a message-body
2165   if a Content-Length is not given.
2166
2167   Note that the meaning of this field is significantly different from
2168   the corresponding definition in MIME, where it is an optional field
2169   used within the "message/external-body" content-type.  In HTTP, it
2170   SHOULD be sent whenever the message's length can be determined prior
2171   to being transferred, unless this is prohibited by the rules in
2172   Section 4.4.
2173
21748.3.  Date
2175
2176   The general-header field "Date" represents the date and time at which
2177   the message was originated, having the same semantics as orig-date in
2178   Section 3.6.1 of [RFC5322].  The field value is an HTTP-date, as
2179   described in Section 3.2.1; it MUST be sent in rfc1123-date format.
2180
2181
2182
2183Fielding, et al.       Expires September 10, 2009              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1                  March 2009
2186
2187
2188     Date   = "Date" ":" OWS Date-v
2189     Date-v = HTTP-date
2190
2191   An example is
2192
2193     Date: Tue, 15 Nov 1994 08:12:31 GMT
2194
2195   Origin servers MUST include a Date header field in all responses,
2196   except in these cases:
2197
2198   1.  If the response status code is 100 (Continue) or 101 (Switching
2199       Protocols), the response MAY include a Date header field, at the
2200       server's option.
2201
2202   2.  If the response status code conveys a server error, e.g. 500
2203       (Internal Server Error) or 503 (Service Unavailable), and it is
2204       inconvenient or impossible to generate a valid Date.
2205
2206   3.  If the server does not have a clock that can provide a reasonable
2207       approximation of the current time, its responses MUST NOT include
2208       a Date header field.  In this case, the rules in Section 8.3.1
2209       MUST be followed.
2210
2211   A received message that does not have a Date header field MUST be
2212   assigned one by the recipient if the message will be cached by that
2213   recipient or gatewayed via a protocol which requires a Date.  An HTTP
2214   implementation without a clock MUST NOT cache responses without
2215   revalidating them on every use.  An HTTP cache, especially a shared
2216   cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
2217   its clock with a reliable external standard.
2218
2219   Clients SHOULD only send a Date header field in messages that include
2220   an entity-body, as in the case of the PUT and POST requests, and even
2221   then it is optional.  A client without a clock MUST NOT send a Date
2222   header field in a request.
2223
2224   The HTTP-date sent in a Date header SHOULD NOT represent a date and
2225   time subsequent to the generation of the message.  It SHOULD
2226   represent the best available approximation of the date and time of
2227   message generation, unless the implementation has no means of
2228   generating a reasonably accurate date and time.  In theory, the date
2229   ought to represent the moment just before the entity is generated.
2230   In practice, the date can be generated at any time during the message
2231   origination without affecting its semantic value.
2232
2233
2234
2235
2236
2237
2238
2239Fielding, et al.       Expires September 10, 2009              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1                  March 2009
2242
2243
22448.3.1.  Clockless Origin Server Operation
2245
2246   Some origin server implementations might not have a clock available.
2247   An origin server without a clock MUST NOT assign Expires or Last-
2248   Modified values to a response, unless these values were associated
2249   with the resource by a system or user with a reliable clock.  It MAY
2250   assign an Expires value that is known, at or before server
2251   configuration time, to be in the past (this allows "pre-expiration"
2252   of responses without storing separate Expires values for each
2253   resource).
2254
22558.4.  Host
2256
2257   The request-header field "Host" specifies the Internet host and port
2258   number of the resource being requested, as obtained from the original
2259   URI given by the user or referring resource (generally an http URI,
2260   as described in Section 2.1.1).  The Host field value MUST represent
2261   the naming authority of the origin server or gateway given by the
2262   original URL.  This allows the origin server or gateway to
2263   differentiate between internally-ambiguous URLs, such as the root "/"
2264   URL of a server for multiple host names on a single IP address.
2265
2266     Host   = "Host" ":" OWS Host-v
2267     Host-v = uri-host [ ":" port ] ; Section 2.1.1
2268
2269   A "host" without any trailing port information implies the default
2270   port for the service requested (e.g., "80" for an HTTP URL).  For
2271   example, a request on the origin server for
2272   <http://www.example.org/pub/WWW/> would properly include:
2273
2274     GET /pub/WWW/ HTTP/1.1
2275     Host: www.example.org
2276
2277   A client MUST include a Host header field in all HTTP/1.1 request
2278   messages.  If the requested URI does not include an Internet host
2279   name for the service being requested, then the Host header field MUST
2280   be given with an empty value.  An HTTP/1.1 proxy MUST ensure that any
2281   request message it forwards does contain an appropriate Host header
2282   field that identifies the service being requested by the proxy.  All
2283   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
2284   status code to any HTTP/1.1 request message which lacks a Host header
2285   field.
2286
2287   See Sections 5.2 and B.1.1 for other requirements relating to Host.
2288
2289
2290
2291
2292
2293
2294
2295Fielding, et al.       Expires September 10, 2009              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1                  March 2009
2298
2299
23008.5.  TE
2301
2302   The request-header field "TE" indicates what extension transfer-
2303   codings it is willing to accept in the response and whether or not it
2304   is willing to accept trailer fields in a chunked transfer-coding.
2305   Its value may consist of the keyword "trailers" and/or a comma-
2306   separated list of extension transfer-coding names with optional
2307   accept parameters (as described in Section 3.3).
2308
2309     TE        = "TE" ":" OWS TE-v
2310     TE-v      = #t-codings
2311     t-codings = "trailers" / ( transfer-extension [ te-params ] )
2312     te-params = OWS ";" OWS "q=" qvalue *( te-ext )
2313     te-ext    = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
2314
2315   The presence of the keyword "trailers" indicates that the client is
2316   willing to accept trailer fields in a chunked transfer-coding, as
2317   defined in Section 3.3.1.  This keyword is reserved for use with
2318   transfer-coding values even though it does not itself represent a
2319   transfer-coding.
2320
2321   Examples of its use are:
2322
2323     TE: deflate
2324     TE:
2325     TE: trailers, deflate;q=0.5
2326
2327   The TE header field only applies to the immediate connection.
2328   Therefore, the keyword MUST be supplied within a Connection header
2329   field (Section 8.1) whenever TE is present in an HTTP/1.1 message.
2330
2331   A server tests whether a transfer-coding is acceptable, according to
2332   a TE field, using these rules:
2333
2334   1.  The "chunked" transfer-coding is always acceptable.  If the
2335       keyword "trailers" is listed, the client indicates that it is
2336       willing to accept trailer fields in the chunked response on
2337       behalf of itself and any downstream clients.  The implication is
2338       that, if given, the client is stating that either all downstream
2339       clients are willing to accept trailer fields in the forwarded
2340       response, or that it will attempt to buffer the response on
2341       behalf of downstream recipients.
2342
2343       Note: HTTP/1.1 does not define any means to limit the size of a
2344       chunked response such that a client can be assured of buffering
2345       the entire response.
2346
2347
2348
2349
2350
2351Fielding, et al.       Expires September 10, 2009              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1                  March 2009
2354
2355
2356   2.  If the transfer-coding being tested is one of the transfer-
2357       codings listed in the TE field, then it is acceptable unless it
2358       is accompanied by a qvalue of 0.  (As defined in Section 3.5, a
2359       qvalue of 0 means "not acceptable.")
2360
2361   3.  If multiple transfer-codings are acceptable, then the acceptable
2362       transfer-coding with the highest non-zero qvalue is preferred.
2363       The "chunked" transfer-coding always has a qvalue of 1.
2364
2365   If the TE field-value is empty or if no TE field is present, the only
2366   transfer-coding is "chunked".  A message with no transfer-coding is
2367   always acceptable.
2368
23698.6.  Trailer
2370
2371   The general field "Trailer" indicates that the given set of header
2372   fields is present in the trailer of a message encoded with chunked
2373   transfer-coding.
2374
2375     Trailer   = "Trailer" ":" OWS Trailer-v
2376     Trailer-v = 1#field-name
2377
2378   An HTTP/1.1 message SHOULD include a Trailer header field in a
2379   message using chunked transfer-coding with a non-empty trailer.
2380   Doing so allows the recipient to know which header fields to expect
2381   in the trailer.
2382
2383   If no Trailer header field is present, the trailer SHOULD NOT include
2384   any header fields.  See Section 3.3.1 for restrictions on the use of
2385   trailer fields in a "chunked" transfer-coding.
2386
2387   Message header fields listed in the Trailer header field MUST NOT
2388   include the following header fields:
2389
2390   o  Transfer-Encoding
2391
2392   o  Content-Length
2393
2394   o  Trailer
2395
23968.7.  Transfer-Encoding
2397
2398   The general-header "Transfer-Encoding" field indicates what (if any)
2399   type of transformation has been applied to the message body in order
2400   to safely transfer it between the sender and the recipient.  This
2401   differs from the content-coding in that the transfer-coding is a
2402   property of the message, not of the entity.
2403
2404
2405
2406
2407Fielding, et al.       Expires September 10, 2009              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1                  March 2009
2410
2411
2412     Transfer-Encoding   = "Transfer-Encoding" ":" OWS
2413                           Transfer-Encoding-v
2414     Transfer-Encoding-v = 1#transfer-coding
2415
2416   Transfer-codings are defined in Section 3.3.  An example is:
2417
2418     Transfer-Encoding: chunked
2419
2420   If multiple encodings have been applied to an entity, the transfer-
2421   codings MUST be listed in the order in which they were applied.
2422   Additional information about the encoding parameters MAY be provided
2423   by other entity-header fields not defined by this specification.
2424
2425   Many older HTTP/1.0 applications do not understand the Transfer-
2426   Encoding header.
2427
24288.8.  Upgrade
2429
2430   The general-header "Upgrade" allows the client to specify what
2431   additional communication protocols it supports and would like to use
2432   if the server finds it appropriate to switch protocols.  The server
2433   MUST use the Upgrade header field within a 101 (Switching Protocols)
2434   response to indicate which protocol(s) are being switched.
2435
2436     Upgrade   = "Upgrade" ":" OWS Upgrade-v
2437     Upgrade-v = 1#product
2438
2439   For example,
2440
2441     Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
2442
2443   The Upgrade header field is intended to provide a simple mechanism
2444   for transition from HTTP/1.1 to some other, incompatible protocol.
2445   It does so by allowing the client to advertise its desire to use
2446   another protocol, such as a later version of HTTP with a higher major
2447   version number, even though the current request has been made using
2448   HTTP/1.1.  This eases the difficult transition between incompatible
2449   protocols by allowing the client to initiate a request in the more
2450   commonly supported protocol while indicating to the server that it
2451   would like to use a "better" protocol if available (where "better" is
2452   determined by the server, possibly according to the nature of the
2453   method and/or resource being requested).
2454
2455   The Upgrade header field only applies to switching application-layer
2456   protocols upon the existing transport-layer connection.  Upgrade
2457   cannot be used to insist on a protocol change; its acceptance and use
2458   by the server is optional.  The capabilities and nature of the
2459   application-layer communication after the protocol change is entirely
2460
2461
2462
2463Fielding, et al.       Expires September 10, 2009              [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1                  March 2009
2466
2467
2468   dependent upon the new protocol chosen, although the first action
2469   after changing the protocol MUST be a response to the initial HTTP
2470   request containing the Upgrade header field.
2471
2472   The Upgrade header field only applies to the immediate connection.
2473   Therefore, the upgrade keyword MUST be supplied within a Connection
2474   header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1
2475   message.
2476
2477   The Upgrade header field cannot be used to indicate a switch to a
2478   protocol on a different connection.  For that purpose, it is more
2479   appropriate to use a 301, 302, 303, or 305 redirection response.
2480
2481   This specification only defines the protocol name "HTTP" for use by
2482   the family of Hypertext Transfer Protocols, as defined by the HTTP
2483   version rules of Section 3.1 and future updates to this
2484   specification.  Any token can be used as a protocol name; however, it
2485   will only be useful if both the client and server associate the name
2486   with the same protocol.
2487
24888.9.  Via
2489
2490   The general-header field "Via" MUST be used by gateways and proxies
2491   to indicate the intermediate protocols and recipients between the
2492   user agent and the server on requests, and between the origin server
2493   and the client on responses.  It is analogous to the "Received" field
2494   defined in Section 3.6.7 of [RFC5322] and is intended to be used for
2495   tracking message forwards, avoiding request loops, and identifying
2496   the protocol capabilities of all senders along the request/response
2497   chain.
2498
2499     Via               = "Via" ":" OWS Via-v
2500     Via-v             = 1#( received-protocol RWS received-by
2501                             [ RWS comment ] )
2502     received-protocol = [ protocol-name "/" ] protocol-version
2503     protocol-name     = token
2504     protocol-version  = token
2505     received-by       = ( uri-host [ ":" port ] ) / pseudonym
2506     pseudonym         = token
2507
2508   The received-protocol indicates the protocol version of the message
2509   received by the server or client along each segment of the request/
2510   response chain.  The received-protocol version is appended to the Via
2511   field value when the message is forwarded so that information about
2512   the protocol capabilities of upstream applications remains visible to
2513   all recipients.
2514
2515   The protocol-name is optional if and only if it would be "HTTP".  The
2516
2517
2518
2519Fielding, et al.       Expires September 10, 2009              [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1                  March 2009
2522
2523
2524   received-by field is normally the host and optional port number of a
2525   recipient server or client that subsequently forwarded the message.
2526   However, if the real host is considered to be sensitive information,
2527   it MAY be replaced by a pseudonym.  If the port is not given, it MAY
2528   be assumed to be the default port of the received-protocol.
2529
2530   Multiple Via field values represents each proxy or gateway that has
2531   forwarded the message.  Each recipient MUST append its information
2532   such that the end result is ordered according to the sequence of
2533   forwarding applications.
2534
2535   Comments MAY be used in the Via header field to identify the software
2536   of the recipient proxy or gateway, analogous to the User-Agent and
2537   Server header fields.  However, all comments in the Via field are
2538   optional and MAY be removed by any recipient prior to forwarding the
2539   message.
2540
2541   For example, a request message could be sent from an HTTP/1.0 user
2542   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2543   forward the request to a public proxy at p.example.net, which
2544   completes the request by forwarding it to the origin server at
2545   www.example.com.  The request received by www.example.com would then
2546   have the following Via header field:
2547
2548     Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
2549
2550   Proxies and gateways used as a portal through a network firewall
2551   SHOULD NOT, by default, forward the names and ports of hosts within
2552   the firewall region.  This information SHOULD only be propagated if
2553   explicitly enabled.  If not enabled, the received-by host of any host
2554   behind the firewall SHOULD be replaced by an appropriate pseudonym
2555   for that host.
2556
2557   For organizations that have strong privacy requirements for hiding
2558   internal structures, a proxy MAY combine an ordered subsequence of
2559   Via header field entries with identical received-protocol values into
2560   a single such entry.  For example,
2561
2562     Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2563
2564   could be collapsed to
2565
2566     Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2567
2568   Applications SHOULD NOT combine multiple entries unless they are all
2569   under the same organizational control and the hosts have already been
2570   replaced by pseudonyms.  Applications MUST NOT combine entries which
2571   have different received-protocol values.
2572
2573
2574
2575Fielding, et al.       Expires September 10, 2009              [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1                  March 2009
2578
2579
25809.  IANA Considerations
2581
25829.1.  Message Header Registration
2583
2584   The Message Header Registry located at <http://www.iana.org/
2585   assignments/message-headers/message-header-index.html> should be
2586   updated with the permanent registrations below (see [RFC3864]):
2587
2588   +-------------------+----------+----------+-------------+
2589   | Header Field Name | Protocol | Status   | Reference   |
2590   +-------------------+----------+----------+-------------+
2591   | Connection        | http     | standard | Section 8.1 |
2592   | Content-Length    | http     | standard | Section 8.2 |
2593   | Date              | http     | standard | Section 8.3 |
2594   | Host              | http     | standard | Section 8.4 |
2595   | TE                | http     | standard | Section 8.5 |
2596   | Trailer           | http     | standard | Section 8.6 |
2597   | Transfer-Encoding | http     | standard | Section 8.7 |
2598   | Upgrade           | http     | standard | Section 8.8 |
2599   | Via               | http     | standard | Section 8.9 |
2600   +-------------------+----------+----------+-------------+
2601
2602   The change controller is: "IETF (iesg@ietf.org) - Internet
2603   Engineering Task Force".
2604
26059.2.  URI Scheme Registration
2606
2607   The entry for the "http" URI Scheme in the registry located at
2608   <http://www.iana.org/assignments/uri-schemes.html> should be updated
2609   to point to Section 2.1.1 of this document (see [RFC4395]).
2610
26119.3.  Internet Media Type Registrations
2612
2613   This document serves as the specification for the Internet media
2614   types "message/http" and "application/http".  The following is to be
2615   registered with IANA (see [RFC4288]).
2616
26179.3.1.  Internet Media Type message/http
2618
2619   The message/http type can be used to enclose a single HTTP request or
2620   response message, provided that it obeys the MIME restrictions for
2621   all "message" types regarding line length and encodings.
2622
2623   Type name:  message
2624
2625
2626
2627
2628
2629
2630
2631Fielding, et al.       Expires September 10, 2009              [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1                  March 2009
2634
2635
2636   Subtype name:  http
2637
2638   Required parameters:  none
2639
2640   Optional parameters:  version, msgtype
2641
2642      version:  The HTTP-Version number of the enclosed message (e.g.,
2643         "1.1").  If not present, the version can be determined from the
2644         first line of the body.
2645
2646      msgtype:  The message type -- "request" or "response".  If not
2647         present, the type can be determined from the first line of the
2648         body.
2649
2650   Encoding considerations:  only "7bit", "8bit", or "binary" are
2651      permitted
2652
2653   Security considerations:  none
2654
2655   Interoperability considerations:  none
2656
2657   Published specification:  This specification (see Section 9.3.1).
2658
2659   Applications that use this media type:
2660
2661   Additional information:
2662
2663      Magic number(s):  none
2664
2665      File extension(s):  none
2666
2667      Macintosh file type code(s):  none
2668
2669   Person and email address to contact for further information:  See
2670      Authors Section.
2671
2672   Intended usage:  COMMON
2673
2674   Restrictions on usage:  none
2675
2676   Author/Change controller:  IESG
2677
26789.3.2.  Internet Media Type application/http
2679
2680   The application/http type can be used to enclose a pipeline of one or
2681   more HTTP request or response messages (not intermixed).
2682
2683
2684
2685
2686
2687Fielding, et al.       Expires September 10, 2009              [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1                  March 2009
2690
2691
2692   Type name:  application
2693
2694   Subtype name:  http
2695
2696   Required parameters:  none
2697
2698   Optional parameters:  version, msgtype
2699
2700      version:  The HTTP-Version number of the enclosed messages (e.g.,
2701         "1.1").  If not present, the version can be determined from the
2702         first line of the body.
2703
2704      msgtype:  The message type -- "request" or "response".  If not
2705         present, the type can be determined from the first line of the
2706         body.
2707
2708   Encoding considerations:  HTTP messages enclosed by this type are in
2709      "binary" format; use of an appropriate Content-Transfer-Encoding
2710      is required when transmitted via E-mail.
2711
2712   Security considerations:  none
2713
2714   Interoperability considerations:  none
2715
2716   Published specification:  This specification (see Section 9.3.2).
2717
2718   Applications that use this media type:
2719
2720   Additional information:
2721
2722      Magic number(s):  none
2723
2724      File extension(s):  none
2725
2726      Macintosh file type code(s):  none
2727
2728   Person and email address to contact for further information:  See
2729      Authors Section.
2730
2731   Intended usage:  COMMON
2732
2733   Restrictions on usage:  none
2734
2735   Author/Change controller:  IESG
2736
2737
2738
2739
2740
2741
2742
2743Fielding, et al.       Expires September 10, 2009              [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1                  March 2009
2746
2747
274810.  Security Considerations
2749
2750   This section is meant to inform application developers, information
2751   providers, and users of the security limitations in HTTP/1.1 as
2752   described by this document.  The discussion does not include
2753   definitive solutions to the problems revealed, though it does make
2754   some suggestions for reducing security risks.
2755
275610.1.  Personal Information
2757
2758   HTTP clients are often privy to large amounts of personal information
2759   (e.g. the user's name, location, mail address, passwords, encryption
2760   keys, etc.), and SHOULD be very careful to prevent unintentional
2761   leakage of this information.  We very strongly recommend that a
2762   convenient interface be provided for the user to control
2763   dissemination of such information, and that designers and
2764   implementors be particularly careful in this area.  History shows
2765   that errors in this area often create serious security and/or privacy
2766   problems and generate highly adverse publicity for the implementor's
2767   company.
2768
276910.2.  Abuse of Server Log Information
2770
2771   A server is in the position to save personal data about a user's
2772   requests which might identify their reading patterns or subjects of
2773   interest.  This information is clearly confidential in nature and its
2774   handling can be constrained by law in certain countries.  People
2775   using HTTP to provide data are responsible for ensuring that such
2776   material is not distributed without the permission of any individuals
2777   that are identifiable by the published results.
2778
277910.3.  Attacks Based On File and Path Names
2780
2781   Implementations of HTTP origin servers SHOULD be careful to restrict
2782   the documents returned by HTTP requests to be only those that were
2783   intended by the server administrators.  If an HTTP server translates
2784   HTTP URIs directly into file system calls, the server MUST take
2785   special care not to serve files that were not intended to be
2786   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
2787   other operating systems use ".." as a path component to indicate a
2788   directory level above the current one.  On such a system, an HTTP
2789   server MUST disallow any such construct in the request-target if it
2790   would otherwise allow access to a resource outside those intended to
2791   be accessible via the HTTP server.  Similarly, files intended for
2792   reference only internally to the server (such as access control
2793   files, configuration files, and script code) MUST be protected from
2794   inappropriate retrieval, since they might contain sensitive
2795   information.  Experience has shown that minor bugs in such HTTP
2796
2797
2798
2799Fielding, et al.       Expires September 10, 2009              [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1                  March 2009
2802
2803
2804   server implementations have turned into security risks.
2805
280610.4.  DNS Spoofing
2807
2808   Clients using HTTP rely heavily on the Domain Name Service, and are
2809   thus generally prone to security attacks based on the deliberate mis-
2810   association of IP addresses and DNS names.  Clients need to be
2811   cautious in assuming the continuing validity of an IP number/DNS name
2812   association.
2813
2814   In particular, HTTP clients SHOULD rely on their name resolver for
2815   confirmation of an IP number/DNS name association, rather than
2816   caching the result of previous host name lookups.  Many platforms
2817   already can cache host name lookups locally when appropriate, and
2818   they SHOULD be configured to do so.  It is proper for these lookups
2819   to be cached, however, only when the TTL (Time To Live) information
2820   reported by the name server makes it likely that the cached
2821   information will remain useful.
2822
2823   If HTTP clients cache the results of host name lookups in order to
2824   achieve a performance improvement, they MUST observe the TTL
2825   information reported by DNS.
2826
2827   If HTTP clients do not observe this rule, they could be spoofed when
2828   a previously-accessed server's IP address changes.  As network
2829   renumbering is expected to become increasingly common [RFC1900], the
2830   possibility of this form of attack will grow.  Observing this
2831   requirement thus reduces this potential security vulnerability.
2832
2833   This requirement also improves the load-balancing behavior of clients
2834   for replicated servers using the same DNS name and reduces the
2835   likelihood of a user's experiencing failure in accessing sites which
2836   use that strategy.
2837
283810.5.  Proxies and Caching
2839
2840   By their very nature, HTTP proxies are men-in-the-middle, and
2841   represent an opportunity for man-in-the-middle attacks.  Compromise
2842   of the systems on which the proxies run can result in serious
2843   security and privacy problems.  Proxies have access to security-
2844   related information, personal information about individual users and
2845   organizations, and proprietary information belonging to users and
2846   content providers.  A compromised proxy, or a proxy implemented or
2847   configured without regard to security and privacy considerations,
2848   might be used in the commission of a wide range of potential attacks.
2849
2850   Proxy operators should protect the systems on which proxies run as
2851   they would protect any system that contains or transports sensitive
2852
2853
2854
2855Fielding, et al.       Expires September 10, 2009              [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1                  March 2009
2858
2859
2860   information.  In particular, log information gathered at proxies
2861   often contains highly sensitive personal information, and/or
2862   information about organizations.  Log information should be carefully
2863   guarded, and appropriate guidelines for use developed and followed.
2864   (Section 10.2).
2865
2866   Proxy implementors should consider the privacy and security
2867   implications of their design and coding decisions, and of the
2868   configuration options they provide to proxy operators (especially the
2869   default configuration).
2870
2871   Users of a proxy need to be aware that they are no trustworthier than
2872   the people who run the proxy; HTTP itself cannot solve this problem.
2873
2874   The judicious use of cryptography, when appropriate, may suffice to
2875   protect against a broad range of security and privacy attacks.  Such
2876   cryptography is beyond the scope of the HTTP/1.1 specification.
2877
287810.6.  Denial of Service Attacks on Proxies
2879
2880   They exist.  They are hard to defend against.  Research continues.
2881   Beware.
2882
2883
288411.  Acknowledgments
2885
2886   HTTP has evolved considerably over the years.  It has benefited from
2887   a large and active developer community--the many people who have
2888   participated on the www-talk mailing list--and it is that community
2889   which has been most responsible for the success of HTTP and of the
2890   World-Wide Web in general.  Marc Andreessen, Robert Cailliau, Daniel
2891   W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
2892   Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
2893   Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
2894   recognition for their efforts in defining early aspects of the
2895   protocol.
2896
2897   This document has benefited greatly from the comments of all those
2898   participating in the HTTP-WG.  In addition to those already
2899   mentioned, the following individuals have contributed to this
2900   specification:
2901
2902   Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
2903   Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
2904   Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
2905   Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
2906   Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut,
2907   David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert
2908
2909
2910
2911Fielding, et al.       Expires September 10, 2009              [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1                  March 2009
2914
2915
2916   Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David
2917   Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott
2918   Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich
2919   Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
2920   Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
2921   Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
2922
2923   Thanks to the "cave men" of Palo Alto.  You know who you are.
2924
2925   Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
2926   Fielding, the editor of [RFC2068], along with John Klensin, Jeff
2927   Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
2928   Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
2929   help.  And thanks go particularly to Jeff Mogul and Scott Lawrence
2930   for performing the "MUST/MAY/SHOULD" audit.
2931
2932   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
2933   Frystyk implemented RFC 2068 early, and we wish to thank them for the
2934   discovery of many of the problems that this document attempts to
2935   rectify.
2936
2937   This specification makes heavy use of the augmented BNF and generic
2938   constructs defined by David H. Crocker for [RFC5234].  Similarly, it
2939   reuses many of the definitions provided by Nathaniel Borenstein and
2940   Ned Freed for MIME [RFC2045].  We hope that their inclusion in this
2941   specification will help reduce past confusion over the relationship
2942   between HTTP and Internet mail message formats.
2943
2944
294512.  References
2946
294712.1.  Normative References
2948
2949   [ISO-8859-1]
2950              International Organization for Standardization,
2951              "Information technology -- 8-bit single-byte coded graphic
2952              character sets -- Part 1: Latin alphabet No. 1", ISO/
2953              IEC 8859-1:1998, 1998.
2954
2955   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2956              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2957              and J. Reschke, Ed., "HTTP/1.1, part 2: Message
2958              Semantics", draft-ietf-httpbis-p2-semantics-06 (work in
2959              progress), March 2009.
2960
2961   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2962              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2963              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2964
2965
2966
2967Fielding, et al.       Expires September 10, 2009              [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1                  March 2009
2970
2971
2972              and Content Negotiation", draft-ietf-httpbis-p3-payload-06
2973              (work in progress), March 2009.
2974
2975   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2976              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2977              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2978              Partial Responses", draft-ietf-httpbis-p5-range-06 (work
2979              in progress), March 2009.
2980
2981   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2982              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2983              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2984              draft-ietf-httpbis-p6-cache-06 (work in progress),
2985              March 2009.
2986
2987   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2988              Requirement Levels", BCP 14, RFC 2119, March 1997.
2989
2990   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2991              Resource Identifier (URI): Generic Syntax", RFC 3986,
2992              STD 66, January 2005.
2993
2994   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2995              Specifications: ABNF", STD 68, RFC 5234, January 2008.
2996
2997   [USASCII]  American National Standards Institute, "Coded Character
2998              Set -- 7-bit American Standard Code for Information
2999              Interchange", ANSI X3.4, 1986.
3000
300112.2.  Informative References
3002
3003   [Kri2001]  Kristol, D., "HTTP Cookies: Standards, Privacy, and
3004              Politics", ACM Transactions on Internet Technology Vol. 1,
3005              #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
3006
3007   [Nie1997]  Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
3008              C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
3009              and PNG", ACM Proceedings of the ACM SIGCOMM '97
3010              conference on Applications, technologies, architectures,
3011              and protocols for computer communication SIGCOMM '97,
3012              September 1997,
3013              <http://doi.acm.org/10.1145/263105.263157>.
3014
3015   [Pad1995]  Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
3016              Computer Networks and ISDN Systems v. 28, pp. 25-35,
3017              December 1995,
3018              <http://portal.acm.org/citation.cfm?id=219094>.
3019
3020
3021
3022
3023Fielding, et al.       Expires September 10, 2009              [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1                  March 2009
3026
3027
3028   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
3029              and Support", STD 3, RFC 1123, October 1989.
3030
3031   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
3032              Specification, Implementation", RFC 1305, March 1992.
3033
3034   [RFC1900]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
3035              RFC 1900, February 1996.
3036
3037   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
3038              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
3039
3040   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
3041              Extensions (MIME) Part One: Format of Internet Message
3042              Bodies", RFC 2045, November 1996.
3043
3044   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
3045              Part Three: Message Header Extensions for Non-ASCII Text",
3046              RFC 2047, November 1996.
3047
3048   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
3049              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
3050              RFC 2068, January 1997.
3051
3052   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
3053              Mechanism", RFC 2109, February 1997.
3054
3055   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
3056              and Interpretation of HTTP Version Numbers", RFC 2145,
3057              May 1997.
3058
3059   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3060              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3061              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3062
3063   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3064
3065   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
3066              Mechanism", RFC 2965, October 2000.
3067
3068   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
3069              Procedures for Message Header Fields", BCP 90, RFC 3864,
3070              September 2004.
3071
3072   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
3073              Registration Procedures", BCP 13, RFC 4288, December 2005.
3074
3075   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
3076
3077
3078
3079Fielding, et al.       Expires September 10, 2009              [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1                  March 2009
3082
3083
3084              Registration Procedures for New URI Schemes", BCP 115,
3085              RFC 4395, February 2006.
3086
3087   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
3088              October 2008.
3089
3090   [Spe]      Spero, S., "Analysis of HTTP Performance Problems",
3091              <http://sunsite.unc.edu/mdma-release/http-prob.html>.
3092
3093   [Tou1998]  Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
3094              HTTP Performance", ISI Research Report ISI/RR-98-463,
3095              Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
3096
3097              (original report dated Aug. 1996)
3098
3099
3100Appendix A.  Tolerant Applications
3101
3102   Although this document specifies the requirements for the generation
3103   of HTTP/1.1 messages, not all applications will be correct in their
3104   implementation.  We therefore recommend that operational applications
3105   be tolerant of deviations whenever those deviations can be
3106   interpreted unambiguously.
3107
3108   Clients SHOULD be tolerant in parsing the Status-Line and servers
3109   tolerant when parsing the Request-Line.  In particular, they SHOULD
3110   accept any amount of WSP characters between fields, even though only
3111   a single SP is required.
3112
3113   The line terminator for message-header fields is the sequence CRLF.
3114   However, we recommend that applications, when parsing such headers,
3115   recognize a single LF as a line terminator and ignore the leading CR.
3116
3117   The character set of an entity-body SHOULD be labeled as the lowest
3118   common denominator of the character codes used within that body, with
3119   the exception that not labeling the entity is preferred over labeling
3120   the entity with the labels US-ASCII or ISO-8859-1.  See [Part3].
3121
3122   Additional rules for requirements on parsing and encoding of dates
3123   and other potential problems with date encodings include:
3124
3125   o  HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
3126      which appears to be more than 50 years in the future is in fact in
3127      the past (this helps solve the "year 2000" problem).
3128
3129   o  An HTTP/1.1 implementation MAY internally represent a parsed
3130      Expires date as earlier than the proper value, but MUST NOT
3131      internally represent a parsed Expires date as later than the
3132
3133
3134
3135Fielding, et al.       Expires September 10, 2009              [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1                  March 2009
3138
3139
3140      proper value.
3141
3142   o  All expiration-related calculations MUST be done in GMT.  The
3143      local time zone MUST NOT influence the calculation or comparison
3144      of an age or expiration time.
3145
3146   o  If an HTTP header incorrectly carries a date value with a time
3147      zone other than GMT, it MUST be converted into GMT using the most
3148      conservative possible conversion.
3149
3150
3151Appendix B.  Compatibility with Previous Versions
3152
3153   HTTP has been in use by the World-Wide Web global information
3154   initiative since 1990.  The first version of HTTP, later referred to
3155   as HTTP/0.9, was a simple protocol for hypertext data transfer across
3156   the Internet with only a single method and no metadata.  HTTP/1.0, as
3157   defined by [RFC1945], added a range of request methods and MIME-like
3158   messaging that could include metadata about the data transferred and
3159   modifiers on the request/response semantics.  However, HTTP/1.0 did
3160   not sufficiently take into consideration the effects of hierarchical
3161   proxies, caching, the need for persistent connections, or name-based
3162   virtual hosts.  The proliferation of incompletely-implemented
3163   applications calling themselves "HTTP/1.0" further necessitated a
3164   protocol version change in order for two communicating applications
3165   to determine each other's true capabilities.
3166
3167   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
3168   requirements that enable reliable implementations, adding only those
3169   new features that will either be safely ignored by an HTTP/1.0
3170   recipient or only sent when communicating with a party advertising
3171   compliance with HTTP/1.1.
3172
3173   It is beyond the scope of a protocol specification to mandate
3174   compliance with previous versions.  HTTP/1.1 was deliberately
3175   designed, however, to make supporting previous versions easy.  It is
3176   worth noting that, at the time of composing this specification
3177   (1996), we would expect commercial HTTP/1.1 servers to:
3178
3179   o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and
3180      1.1 requests;
3181
3182   o  understand any valid request in the format of HTTP/0.9, 1.0, or
3183      1.1;
3184
3185   o  respond appropriately with a message in the same major version
3186      used by the client.
3187
3188
3189
3190
3191Fielding, et al.       Expires September 10, 2009              [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1                  March 2009
3194
3195
3196   And we would expect HTTP/1.1 clients to:
3197
3198   o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
3199      responses;
3200
3201   o  understand any valid response in the format of HTTP/0.9, 1.0, or
3202      1.1.
3203
3204   For most implementations of HTTP/1.0, each connection is established
3205   by the client prior to the request and closed by the server after
3206   sending the response.  Some implementations implement the Keep-Alive
3207   version of persistent connections described in Section 19.7.1 of
3208   [RFC2068].
3209
3210B.1.  Changes from HTTP/1.0
3211
3212   This section summarizes major differences between versions HTTP/1.0
3213   and HTTP/1.1.
3214
3215B.1.1.  Changes to Simplify Multi-homed Web Servers and Conserve IP
3216        Addresses
3217
3218   The requirements that clients and servers support the Host request-
3219   header, report an error if the Host request-header (Section 8.4) is
3220   missing from an HTTP/1.1 request, and accept absolute URIs
3221   (Section 5.1.2) are among the most important changes defined by this
3222   specification.
3223
3224   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3225   addresses and servers; there was no other established mechanism for
3226   distinguishing the intended server of a request than the IP address
3227   to which that request was directed.  The changes outlined above will
3228   allow the Internet, once older HTTP clients are no longer common, to
3229   support multiple Web sites from a single IP address, greatly
3230   simplifying large operational Web servers, where allocation of many
3231   IP addresses to a single host has created serious problems.  The
3232   Internet will also be able to recover the IP addresses that have been
3233   allocated for the sole purpose of allowing special-purpose domain
3234   names to be used in root-level HTTP URLs.  Given the rate of growth
3235   of the Web, and the number of servers already deployed, it is
3236   extremely important that all implementations of HTTP (including
3237   updates to existing HTTP/1.0 applications) correctly implement these
3238   requirements:
3239
3240   o  Both clients and servers MUST support the Host request-header.
3241
3242   o  A client that sends an HTTP/1.1 request MUST send a Host header.
3243
3244
3245
3246
3247Fielding, et al.       Expires September 10, 2009              [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1                  March 2009
3250
3251
3252   o  Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
3253      request does not include a Host request-header.
3254
3255   o  Servers MUST accept absolute URIs.
3256
3257B.2.  Compatibility with HTTP/1.0 Persistent Connections
3258
3259   Some clients and servers might wish to be compatible with some
3260   previous implementations of persistent connections in HTTP/1.0
3261   clients and servers.  Persistent connections in HTTP/1.0 are
3262   explicitly negotiated as they are not the default behavior.  HTTP/1.0
3263   experimental implementations of persistent connections are faulty,
3264   and the new facilities in HTTP/1.1 are designed to rectify these
3265   problems.  The problem was that some existing 1.0 clients may be
3266   sending Keep-Alive to a proxy server that doesn't understand
3267   Connection, which would then erroneously forward it to the next
3268   inbound server, which would establish the Keep-Alive connection and
3269   result in a hung HTTP/1.0 proxy waiting for the close on the
3270   response.  The result is that HTTP/1.0 clients must be prevented from
3271   using Keep-Alive when talking to proxies.
3272
3273   However, talking to proxies is the most important use of persistent
3274   connections, so that prohibition is clearly unacceptable.  Therefore,
3275   we need some other mechanism for indicating a persistent connection
3276   is desired, which is safe to use even when talking to an old proxy
3277   that ignores Connection.  Persistent connections are the default for
3278   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
3279   declaring non-persistence.  See Section 8.1.
3280
3281   The original HTTP/1.0 form of persistent connections (the Connection:
3282   Keep-Alive and Keep-Alive header) is documented in [RFC2068].
3283
3284B.3.  Changes from RFC 2068
3285
3286   This specification has been carefully audited to correct and
3287   disambiguate key word usage; RFC 2068 had many problems in respect to
3288   the conventions laid out in [RFC2119].
3289
3290   Transfer-coding and message lengths all interact in ways that
3291   required fixing exactly when chunked encoding is used (to allow for
3292   transfer encoding that may not be self delimiting); it was important
3293   to straighten out exactly how message lengths are computed.
3294   (Sections 3.3, 4.4, 8.2, see also [Part3], [Part5] and [Part6])
3295
3296   The use and interpretation of HTTP version numbers has been clarified
3297   by [RFC2145].  Require proxies to upgrade requests to highest
3298   protocol version they support to deal with problems discovered in
3299   HTTP/1.0 implementations (Section 3.1)
3300
3301
3302
3303Fielding, et al.       Expires September 10, 2009              [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1                  March 2009
3306
3307
3308   Quality Values of zero should indicate that "I don't want something"
3309   to allow clients to refuse a representation.  (Section 3.5)
3310
3311   Transfer-coding had significant problems, particularly with
3312   interactions with chunked encoding.  The solution is that transfer-
3313   codings become as full fledged as content-codings.  This involves
3314   adding an IANA registry for transfer-codings (separate from content
3315   codings), a new header field (TE) and enabling trailer headers in the
3316   future.  Transfer encoding is a major performance benefit, so it was
3317   worth fixing [Nie1997].  TE also solves another, obscure, downward
3318   interoperability problem that could have occurred due to interactions
3319   between authentication trailers, chunked encoding and HTTP/1.0
3320   clients.(Section 3.3, 3.3.1, and 8.5)
3321
3322B.4.  Changes from RFC 2616
3323
3324   Empty list elements in list productions have been deprecated.
3325   (Section 1.2.1)
3326
3327   Rules about implicit linear whitespace between certain grammar
3328   productions have been removed; now it's only allowed when
3329   specifically pointed out in the ABNF.  The NUL character is no longer
3330   allowed in comment and quoted-string text.  The quoted-pair rule no
3331   longer allows escaping NUL, CR or LF.  Non-ASCII content in header
3332   fields and reason phrase has been obsoleted and made opaque (the TEXT
3333   rule was removed) (Section 1.2.2)
3334
3335   Clarify that HTTP-Version is case sensitive.  (Section 3.1)
3336
3337   Remove reference to non-existant identity transfer-coding value
3338   tokens.  (Sections 3.3 and 4.4)
3339
3340   Clarification that the chunk length does not include the count of the
3341   octets in the chunk header and trailer.  (Section 3.3.1)
3342
3343   Require that invalid whitespace around field-names be rejected.
3344   (Section 4.2)
3345
3346   Update use of abs_path production from RFC1808 to the path-absolute +
3347   query components of RFC3986.  (Section 5.1.2)
3348
3349   Clarify exactly when close connection options must be sent.
3350   (Section 8.1)
3351
3352
3353Appendix C.  Terminology
3354
3355   This specification uses a number of terms to refer to the roles
3356
3357
3358
3359Fielding, et al.       Expires September 10, 2009              [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1                  March 2009
3362
3363
3364   played by participants in, and objects of, the HTTP communication.
3365
3366   cache
3367
3368      A program's local store of response messages and the subsystem
3369      that controls its message storage, retrieval, and deletion.  A
3370      cache stores cacheable responses in order to reduce the response
3371      time and network bandwidth consumption on future, equivalent
3372      requests.  Any client or server may include a cache, though a
3373      cache cannot be used by a server that is acting as a tunnel.
3374
3375   cacheable
3376
3377      A response is cacheable if a cache is allowed to store a copy of
3378      the response message for use in answering subsequent requests.
3379      The rules for determining the cacheability of HTTP responses are
3380      defined in Section 1 of [Part6].  Even if a resource is cacheable,
3381      there may be additional constraints on whether a cache can use the
3382      cached copy for a particular request.
3383
3384   client
3385
3386      A program that establishes connections for the purpose of sending
3387      requests.
3388
3389   connection
3390
3391      A transport layer virtual circuit established between two programs
3392      for the purpose of communication.
3393
3394   content negotiation
3395
3396      The mechanism for selecting the appropriate representation when
3397      servicing a request, as described in Section 4 of [Part3].  The
3398      representation of entities in any response can be negotiated
3399      (including error responses).
3400
3401   entity
3402
3403      The information transferred as the payload of a request or
3404      response.  An entity consists of metainformation in the form of
3405      entity-header fields and content in the form of an entity-body, as
3406      described in Section 3 of [Part3].
3407
3408   gateway
3409
3410      A server which acts as an intermediary for some other server.
3411      Unlike a proxy, a gateway receives requests as if it were the
3412
3413
3414
3415Fielding, et al.       Expires September 10, 2009              [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1                  March 2009
3418
3419
3420      origin server for the requested resource; the requesting client
3421      may not be aware that it is communicating with a gateway.
3422
3423   inbound/outbound
3424
3425      Inbound and outbound refer to the request and response paths for
3426      messages: "inbound" means "traveling toward the origin server",
3427      and "outbound" means "traveling toward the user agent"
3428
3429   message
3430
3431      The basic unit of HTTP communication, consisting of a structured
3432      sequence of octets matching the syntax defined in Section 4 and
3433      transmitted via the connection.
3434
3435   origin server
3436
3437      The server on which a given resource resides or is to be created.
3438
3439   proxy
3440
3441      An intermediary program which acts as both a server and a client
3442      for the purpose of making requests on behalf of other clients.
3443      Requests are serviced internally or by passing them on, with
3444      possible translation, to other servers.  A proxy MUST implement
3445      both the client and server requirements of this specification.  A
3446      "transparent proxy" is a proxy that does not modify the request or
3447      response beyond what is required for proxy authentication and
3448      identification.  A "non-transparent proxy" is a proxy that
3449      modifies the request or response in order to provide some added
3450      service to the user agent, such as group annotation services,
3451      media type transformation, protocol reduction, or anonymity
3452      filtering.  Except where either transparent or non-transparent
3453      behavior is explicitly stated, the HTTP proxy requirements apply
3454      to both types of proxies.
3455
3456   request
3457
3458      An HTTP request message, as defined in Section 5.
3459
3460   resource
3461
3462      A network data object or service that can be identified by a URI,
3463      as defined in Section 2.1.  Resources may be available in multiple
3464      representations (e.g. multiple languages, data formats, size, and
3465      resolutions) or vary in other ways.
3466
3467
3468
3469
3470
3471Fielding, et al.       Expires September 10, 2009              [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1                  March 2009
3474
3475
3476   response
3477
3478      An HTTP response message, as defined in Section 6.
3479
3480   representation
3481
3482      An entity included with a response that is subject to content
3483      negotiation, as described in Section 4 of [Part3].  There may
3484      exist multiple representations associated with a particular
3485      response status.
3486
3487   server
3488
3489      An application program that accepts connections in order to
3490      service requests by sending back responses.  Any given program may
3491      be capable of being both a client and a server; our use of these
3492      terms refers only to the role being performed by the program for a
3493      particular connection, rather than to the program's capabilities
3494      in general.  Likewise, any server may act as an origin server,
3495      proxy, gateway, or tunnel, switching behavior based on the nature
3496      of each request.
3497
3498   tunnel
3499
3500      An intermediary program which is acting as a blind relay between
3501      two connections.  Once active, a tunnel is not considered a party
3502      to the HTTP communication, though the tunnel may have been
3503      initiated by an HTTP request.  The tunnel ceases to exist when
3504      both ends of the relayed connections are closed.
3505
3506   upstream/downstream
3507
3508      Upstream and downstream describe the flow of a message: all
3509      messages flow from upstream to downstream.
3510
3511   user agent
3512
3513      The client which initiates a request.  These are often browsers,
3514      editors, spiders (web-traversing robots), or other end user tools.
3515
3516   variant
3517
3518      A resource may have one, or more than one, representation(s)
3519      associated with it at any given instant.  Each of these
3520      representations is termed a `variant'.  Use of the term `variant'
3521      does not necessarily imply that the resource is subject to content
3522      negotiation.
3523
3524
3525
3526
3527Fielding, et al.       Expires September 10, 2009              [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1                  March 2009
3530
3531
3532Appendix D.  Collected ABNF
3533
3534   BWS = OWS
3535
3536   Cache-Control = <Cache-Control, defined in [Part6], Section 3.4>
3537   Chunked-Body = *chunk last-chunk trailer-part CRLF
3538   Connection = "Connection:" OWS Connection-v
3539   Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
3540    connection-token ] )
3541   Content-Length = "Content-Length:" OWS 1*Content-Length-v
3542   Content-Length-v = 1*DIGIT
3543
3544   Date = "Date:" OWS Date-v
3545   Date-v = HTTP-date
3546
3547   GMT = %x47.4D.54
3548
3549   HTTP-Prot-Name = %x48.54.54.50
3550   HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
3551   HTTP-date = rfc1123-date / obsolete-date
3552   HTTP-message = Request / Response
3553   Host = "Host:" OWS Host-v
3554   Host-v = uri-host [ ":" port ]
3555
3556   Method = token
3557
3558   OWS = *( [ obs-fold ] WSP )
3559
3560   Pragma = <Pragma, defined in [Part6], Section 3.4>
3561
3562   RWS = 1*( [ obs-fold ] WSP )
3563   Reason-Phrase = *( WSP / VCHAR / obs-text )
3564   Request = Request-Line *( ( general-header / request-header /
3565    entity-header ) CRLF ) CRLF [ message-body ]
3566   Request-Line = Method SP request-target SP HTTP-Version CRLF
3567   Response = Status-Line *( ( general-header / response-header /
3568    entity-header ) CRLF ) CRLF [ message-body ]
3569
3570   Status-Code = 3DIGIT
3571   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
3572
3573   TE = "TE:" OWS TE-v
3574   TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
3575   Trailer = "Trailer:" OWS Trailer-v
3576   Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
3577   Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
3578   Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
3579    transfer-coding ] )
3580
3581
3582
3583Fielding, et al.       Expires September 10, 2009              [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1                  March 2009
3586
3587
3588   URI = <URI, defined in [RFC3986], Section 3>
3589   URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
3590   Upgrade = "Upgrade:" OWS Upgrade-v
3591   Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
3592
3593   Via = "Via:" OWS Via-v
3594   Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
3595    ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
3596    ] )
3597
3598   Warning = <Warning, defined in [Part6], Section 3.6>
3599
3600   absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
3601   asctime-date = wkday SP date3 SP time SP 4DIGIT
3602   attribute = token
3603   authority = <authority, defined in [RFC3986], Section 3.2>
3604
3605   chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
3606   chunk-data = 1*OCTET
3607   chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
3608   chunk-ext-name = token
3609   chunk-ext-val = token / quoted-string
3610   chunk-size = 1*HEXDIG
3611   comment = "(" *( ctext / quoted-pair / comment ) ")"
3612   connection-token = token
3613   ctext = *( OWS / %x21-27 / %x2A-7E / obs-text )
3614
3615   date1 = 2DIGIT SP month SP 4DIGIT
3616   date2 = 2DIGIT "-" month "-" 2DIGIT
3617   date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
3618
3619   entity-body = <entity-body, defined in [Part3], Section 3.2>
3620   entity-header = <entity-header, defined in [Part3], Section 3.1>
3621
3622   field-content = *( WSP / VCHAR / obs-text )
3623   field-name = token
3624   field-value = *( field-content / OWS )
3625   fragment = <fragment, defined in [RFC3986], Section 3.5>
3626
3627   general-header = Cache-Control / Connection / Date / Pragma / Trailer
3628    / Transfer-Encoding / Upgrade / Via / Warning
3629   generic-message = start-line *( message-header CRLF ) CRLF [
3630    message-body ]
3631
3632   http-URI = "http://" authority path-abempty [ "?" query ]
3633
3634   l-Fri = %x46.72.69.64.61.79
3635   l-Mon = %x4D.6F.6E.64.61.79
3636
3637
3638
3639Fielding, et al.       Expires September 10, 2009              [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1                  March 2009
3642
3643
3644   l-Sat = %x53.61.74.75.72.64.61.79
3645   l-Sun = %x53.75.6E.64.61.79
3646   l-Thu = %x54.68.75.72.73.64.61.79
3647   l-Tue = %x54.75.65.73.64.61.79
3648   l-Wed = %x57.65.64.6E.65.73.64.61.79
3649   last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
3650
3651   message-body = entity-body /
3652    <entity-body encoded as per Transfer-Encoding>
3653   message-header = field-name ":" OWS [ field-value ] OWS
3654   month = s-Jan / s-Feb / s-Mar / s-Apr / s-May / s-Jun / s-Jul / s-Aug
3655    / s-Sep / s-Oct / s-Nov / s-Dec
3656
3657   obs-fold = CRLF
3658   obs-text = %x80-FF
3659   obsolete-date = rfc850-date / asctime-date
3660
3661   parameter = attribute BWS "=" BWS value
3662   partial-URI = relative-part [ "?" query ]
3663   path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
3664   path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
3665   port = <port, defined in [RFC3986], Section 3.2.3>
3666   product = token [ "/" product-version ]
3667   product-version = token
3668   protocol-name = token
3669   protocol-version = token
3670   pseudonym = token
3671
3672   qdtext = *( OWS / "!" / %x23-5B / %x5D-7E / obs-text )
3673   query = <query, defined in [RFC3986], Section 3.4>
3674   quoted-pair = "\" quoted-text
3675   quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
3676   quoted-text = %x01-09 / %x0B-0C / %x0E-FF
3677   qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
3678
3679   received-by = ( uri-host [ ":" port ] ) / pseudonym
3680   received-protocol = [ protocol-name "/" ] protocol-version
3681   relative-part = <relative-part, defined in [RFC3986], Section 4.2>
3682   request-header = <request-header, defined in [Part2], Section 3>
3683   request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
3684    / authority
3685   response-header = <response-header, defined in [Part2], Section 5>
3686   rfc1123-date = wkday "," SP date1 SP time SP GMT
3687   rfc850-date = weekday "," SP date2 SP time SP GMT
3688
3689   s-Apr = %x41.70.72
3690   s-Aug = %x41.75.67
3691   s-Dec = %x44.65.63
3692
3693
3694
3695Fielding, et al.       Expires September 10, 2009              [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1                  March 2009
3698
3699
3700   s-Feb = %x46.65.62
3701   s-Fri = %x46.72.69
3702   s-Jan = %x4A.61.6E
3703   s-Jul = %x4A.75.6C
3704   s-Jun = %x4A.75.6E
3705   s-Mar = %x4D.61.72
3706   s-May = %x4D.61.79
3707   s-Mon = %x4D.6F.6E
3708   s-Nov = %x4E.6F.76
3709   s-Oct = %x4F.63.74
3710   s-Sat = %x53.61.74
3711   s-Sep = %x53.65.70
3712   s-Sun = %x53.75.6E
3713   s-Thu = %x54.68.75
3714   s-Tue = %x54.75.65
3715   s-Wed = %x57.65.64
3716   start-line = Request-Line / Status-Line
3717
3718   t-codings = "trailers" / ( transfer-extension [ te-params ] )
3719   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
3720    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
3721   te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
3722   te-params = OWS ";" OWS "q=" qvalue *te-ext
3723   time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
3724   token = 1*tchar
3725   trailer-part = *( entity-header CRLF )
3726   transfer-coding = "chunked" / transfer-extension
3727   transfer-extension = token *( OWS ";" OWS parameter )
3728
3729   uri-host = <host, defined in [RFC3986], Section 3.2.2>
3730
3731   value = token / quoted-string
3732
3733   weekday = l-Mon / l-Tue / l-Wed / l-Thu / l-Fri / l-Sat / l-Sun
3734   wkday = s-Mon / s-Tue / s-Wed / s-Thu / s-Fri / s-Sat / s-Sun
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751Fielding, et al.       Expires September 10, 2009              [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1                  March 2009
3754
3755
3756   ABNF diagnostics:
3757
3758   ; Chunked-Body defined but not used
3759   ; Content-Length defined but not used
3760   ; HTTP-message defined but not used
3761   ; Host defined but not used
3762   ; TE defined but not used
3763   ; URI defined but not used
3764   ; URI-reference defined but not used
3765   ; fragment defined but not used
3766   ; generic-message defined but not used
3767   ; http-URI defined but not used
3768   ; partial-URI defined but not used
3769
3770
3771Appendix E.  Change Log (to be removed by RFC Editor before publication)
3772
3773E.1.  Since RFC2616
3774
3775   Extracted relevant partitions from [RFC2616].
3776
3777E.2.  Since draft-ietf-httpbis-p1-messaging-00
3778
3779   Closed issues:
3780
3781   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
3782      should be case sensitive"
3783      (<http://purl.org/NET/http-errata#verscase>)
3784
3785   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
3786      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
3787
3788   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
3789      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
3790
3791   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
3792      (<http://purl.org/NET/http-errata#msg-len-chars>)
3793
3794   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
3795      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
3796
3797   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
3798      query" (<http://purl.org/NET/http-errata#uriquery>)
3799
3800   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
3801      1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
3802
3803
3804
3805
3806
3807Fielding, et al.       Expires September 10, 2009              [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 1                  March 2009
3810
3811
3812   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
3813      'identity' token references"
3814      (<http://purl.org/NET/http-errata#identity>)
3815
3816   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
3817      BNF"
3818
3819   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
3820
3821   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
3822      Informative references"
3823
3824   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
3825      Compliance"
3826
3827   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
3828      reference"
3829
3830   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
3831      references"
3832
3833   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
3834      in date format explanation"
3835
3836   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
3837      typo"
3838
3839   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
3840      references"
3841
3842   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
3843      Reference"
3844
3845   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
3846      to-date references"
3847
3848   Other changes:
3849
3850   o  Update media type registrations to use RFC4288 template.
3851
3852   o  Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
3853      for chunk-data (work in progress on
3854      <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
3855
3856
3857
3858
3859
3860
3861
3862
3863Fielding, et al.       Expires September 10, 2009              [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 1                  March 2009
3866
3867
3868E.3.  Since draft-ietf-httpbis-p1-messaging-01
3869
3870   Closed issues:
3871
3872   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
3873      (and other) requests"
3874
3875   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
3876      RFC4288"
3877
3878   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
3879      and Reason Phrase"
3880
3881   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
3882      used"
3883
3884   Ongoing work on ABNF conversion
3885   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3886
3887   o  Get rid of duplicate BNF rule names ("host" -> "uri-host",
3888      "trailer" -> "trailer-part").
3889
3890   o  Avoid underscore character in rule names ("http_URL" -> "http-
3891      URL", "abs_path" -> "path-absolute").
3892
3893   o  Add rules for terms imported from URI spec ("absoluteURI",
3894      "authority", "path-absolute", "port", "query", "relativeURI",
3895      "host) -- these will have to be updated when switching over to
3896      RFC3986.
3897
3898   o  Synchronize core rules with RFC5234.
3899
3900   o  Get rid of prose rules that span multiple lines.
3901
3902   o  Get rid of unused rules LOALPHA and UPALPHA.
3903
3904   o  Move "Product Tokens" section (back) into Part 1, as "token" is
3905      used in the definition of the Upgrade header.
3906
3907   o  Add explicit references to BNF syntax and rules imported from
3908      other parts of the specification.
3909
3910   o  Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
3911      "TEXT".
3912
3913
3914
3915
3916
3917
3918
3919Fielding, et al.       Expires September 10, 2009              [Page 70]
3920
3921Internet-Draft              HTTP/1.1, Part 1                  March 2009
3922
3923
3924E.4.  Since draft-ietf-httpbis-p1-messaging-02
3925
3926   Closed issues:
3927
3928   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
3929      rfc1123-date"
3930
3931   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
3932      pair"
3933
3934   Ongoing work on IANA Message Header Registration
3935   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
3936
3937   o  Reference RFC 3984, and update header registrations for headers
3938      defined in this document.
3939
3940   Ongoing work on ABNF conversion
3941   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3942
3943   o  Replace string literals when the string really is case-sensitive
3944      (HTTP-Version).
3945
3946E.5.  Since draft-ietf-httpbis-p1-messaging-03
3947
3948   Closed issues:
3949
3950   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
3951      closing"
3952
3953   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
3954      registrations and registry information to IANA Considerations"
3955
3956   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
3957      for PAD1995 reference"
3958
3959   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
3960      Considerations: update HTTP URI scheme registration"
3961
3962   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
3963      URI scheme definition"
3964
3965   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
3966      headers vs Set-Cookie"
3967
3968   Ongoing work on ABNF conversion
3969   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3970
3971
3972
3973
3974
3975Fielding, et al.       Expires September 10, 2009              [Page 71]
3976
3977Internet-Draft              HTTP/1.1, Part 1                  March 2009
3978
3979
3980   o  Replace string literals when the string really is case-sensitive
3981      (HTTP-Date).
3982
3983   o  Replace HEX by HEXDIG for future consistence with RFC 5234's core
3984      rules.
3985
3986E.6.  Since draft-ietf-httpbis-p1-messaging-04
3987
3988   Closed issues:
3989
3990   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
3991      reference for URIs"
3992
3993   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
3994      updated by RFC 5322"
3995
3996   Ongoing work on ABNF conversion
3997   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3998
3999   o  Use "/" instead of "|" for alternatives.
4000
4001   o  Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4002
4003   o  Only reference RFC 5234's core rules.
4004
4005   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4006      whitespace ("OWS") and required whitespace ("RWS").
4007
4008   o  Rewrite ABNFs to spell out whitespace rules, factor out header
4009      value format definitions.
4010
4011E.7.  Since draft-ietf-httpbis-p1-messaging-05
4012
4013   Closed issues:
4014
4015   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
4016
4017   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
4018      Terminology"
4019
4020   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
4021      encoded words"
4022
4023   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
4024      Encodings in TEXT"
4025
4026   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
4027
4028
4029
4030
4031Fielding, et al.       Expires September 10, 2009              [Page 72]
4032
4033Internet-Draft              HTTP/1.1, Part 1                  March 2009
4034
4035
4036   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4037      proxies"
4038
4039   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
4040      BNF"
4041
4042   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
4043
4044   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
4045      "Differences Between HTTP Entities and RFC 2045 Entities"?"
4046
4047   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
4048      reference left in discussion of date formats"
4049
4050   Final work on ABNF conversion
4051   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4052
4053   o  Rewrite definition of list rules, deprecate empty list elements.
4054
4055   o  Add appendix containing collected and expanded ABNF.
4056
4057   Other changes:
4058
4059   o  Rewrite introduction; add mostly new Architecture Section.
4060
4061   o  Move definition of quality values from Part 3 into Part 1; make TE
4062      request header grammar independent of accept-params (defined in
4063      Part 3).
4064
4065
4066Index
4067
4068   A
4069      application/http Media Type  48
4070
4071   C
4072      cache  61
4073      cacheable  61
4074      client  61
4075      connection  61
4076      Connection header  38
4077      content negotiation  61
4078      Content-Length header  39
4079
4080   D
4081      Date header  39
4082      downstream  63
4083
4084
4085
4086
4087Fielding, et al.       Expires September 10, 2009              [Page 73]
4088
4089Internet-Draft              HTTP/1.1, Part 1                  March 2009
4090
4091
4092   E
4093      entity  61
4094
4095   G
4096      gateway  61
4097      Grammar
4098         absolute-URI  10
4099         ALPHA  7
4100         asctime-date  16
4101         attribute  17
4102         authority  10
4103         BWS  9
4104         chunk  19
4105         chunk-data  19
4106         chunk-ext  19
4107         chunk-ext-name  19
4108         chunk-ext-val  19
4109         chunk-size  19
4110         Chunked-Body  19
4111         comment  23
4112         Connection  38
4113         connection-token  38
4114         Connection-v  38
4115         Content-Length  39
4116         Content-Length-v  39
4117         CR  7
4118         CRLF  7
4119         ctext  23
4120         CTL  7
4121         Date  40
4122         Date-v  40
4123         date1  16
4124         date2  16
4125         date3  16
4126         DIGIT  7
4127         DQUOTE  7
4128         extension-code  31
4129         extension-method  27
4130         field-content  22
4131         field-name  22
4132         field-value  22
4133         general-header  26
4134         generic-message  21
4135         HEXDIG  7
4136         Host  41
4137         Host-v  41
4138         HTTP-date  16
4139         HTTP-message  21
4140
4141
4142
4143Fielding, et al.       Expires September 10, 2009              [Page 74]
4144
4145Internet-Draft              HTTP/1.1, Part 1                  March 2009
4146
4147
4148         HTTP-Prot-Name  14
4149         http-URI  11
4150         HTTP-Version  14
4151         last-chunk  19
4152         LF  7
4153         message-body  23
4154         message-header  22
4155         Method  27
4156         month  16
4157         obs-text  9
4158         obsolete-date  16
4159         OCTET  7
4160         OWS  9
4161         parameter  17
4162         path-absolute  10
4163         port  10
4164         product  20
4165         product-version  20
4166         protocol-name  45
4167         protocol-version  45
4168         pseudonym  45
4169         qdtext  9
4170         query  10
4171         quoted-pair  9
4172         quoted-string  9
4173         quoted-text  9
4174         qvalue  21
4175         Reason-Phrase  31
4176         received-by  45
4177         received-protocol  45
4178         Request  26
4179         Request-Line  27
4180         request-target  27
4181         Response  30
4182         rfc850-date  16
4183         rfc1123-date  16
4184         RWS  9
4185         SP  7
4186         start-line  21
4187         Status-Code  31
4188         Status-Line  30
4189         t-codings  42
4190         tchar  9
4191         TE  42
4192         te-ext  42
4193         te-params  42
4194         TE-v  42
4195         time  16
4196
4197
4198
4199Fielding, et al.       Expires September 10, 2009              [Page 75]
4200
4201Internet-Draft              HTTP/1.1, Part 1                  March 2009
4202
4203
4204         token  9
4205         Trailer  43
4206         trailer-part  19
4207         Trailer-v  43
4208         transfer-coding  17
4209         Transfer-Encoding  44
4210         Transfer-Encoding-v  44
4211         transfer-extension  17
4212         Upgrade  44
4213         Upgrade-v  44
4214         uri-host  10
4215         URI-reference  10
4216         value  17
4217         VCHAR  7
4218         Via  45
4219         Via-v  45
4220         weekday  16
4221         wkday  16
4222         WSP  7
4223
4224   H
4225      Headers
4226         Connection  38
4227         Content-Length  39
4228         Date  39
4229         Host  41
4230         TE  42
4231         Trailer  43
4232         Transfer-Encoding  43
4233         Upgrade  44
4234         Via  45
4235      Host header  41
4236      http URI scheme  11
4237      https URI scheme  11
4238
4239   I
4240      inbound  62
4241
4242   M
4243      Media Type
4244         application/http  48
4245         message/http  47
4246      message  62
4247      message/http Media Type  47
4248
4249   O
4250      origin server  62
4251      outbound  62
4252
4253
4254
4255Fielding, et al.       Expires September 10, 2009              [Page 76]
4256
4257Internet-Draft              HTTP/1.1, Part 1                  March 2009
4258
4259
4260   P
4261      proxy  62
4262
4263   R
4264      representation  63
4265      request  62
4266      resource  62
4267      response  62
4268
4269   S
4270      server  63
4271
4272   T
4273      TE header  42
4274      Trailer header  43
4275      Transfer-Encoding header  43
4276      tunnel  63
4277
4278   U
4279      Upgrade header  44
4280      upstream  63
4281      URI scheme
4282         http  11
4283         https  11
4284      user agent  63
4285
4286   V
4287      variant  63
4288      Via header  45
4289
4290
4291Authors' Addresses
4292
4293   Roy T. Fielding (editor)
4294   Day Software
4295   23 Corporate Plaza DR, Suite 280
4296   Newport Beach, CA  92660
4297   USA
4298
4299   Phone: +1-949-706-5300
4300   Fax:   +1-949-706-5305
4301   Email: fielding@gbiv.com
4302   URI:   http://roy.gbiv.com/
4303
4304
4305
4306
4307
4308
4309
4310
4311Fielding, et al.       Expires September 10, 2009              [Page 77]
4312
4313Internet-Draft              HTTP/1.1, Part 1                  March 2009
4314
4315
4316   Jim Gettys
4317   One Laptop per Child
4318   21 Oak Knoll Road
4319   Carlisle, MA  01741
4320   USA
4321
4322   Email: jg@laptop.org
4323   URI:   http://www.laptop.org/
4324
4325
4326   Jeffrey C. Mogul
4327   Hewlett-Packard Company
4328   HP Labs, Large Scale Systems Group
4329   1501 Page Mill Road, MS 1177
4330   Palo Alto, CA  94304
4331   USA
4332
4333   Email: JeffMogul@acm.org
4334
4335
4336   Henrik Frystyk Nielsen
4337   Microsoft Corporation
4338   1 Microsoft Way
4339   Redmond, WA  98052
4340   USA
4341
4342   Email: henrikn@microsoft.com
4343
4344
4345   Larry Masinter
4346   Adobe Systems, Incorporated
4347   345 Park Ave
4348   San Jose, CA  95110
4349   USA
4350
4351   Email: LMM@acm.org
4352   URI:   http://larry.masinter.net/
4353
4354
4355   Paul J. Leach
4356   Microsoft Corporation
4357   1 Microsoft Way
4358   Redmond, WA  98052
4359
4360   Email: paulle@microsoft.com
4361
4362
4363
4364
4365
4366
4367Fielding, et al.       Expires September 10, 2009              [Page 78]
4368
4369Internet-Draft              HTTP/1.1, Part 1                  March 2009
4370
4371
4372   Tim Berners-Lee
4373   World Wide Web Consortium
4374   MIT Computer Science and Artificial Intelligence Laboratory
4375   The Stata Center, Building 32
4376   32 Vassar Street
4377   Cambridge, MA  02139
4378   USA
4379
4380   Email: timbl@w3.org
4381   URI:   http://www.w3.org/People/Berners-Lee/
4382
4383
4384   Yves Lafon (editor)
4385   World Wide Web Consortium
4386   W3C / ERCIM
4387   2004, rte des Lucioles
4388   Sophia-Antipolis, AM  06902
4389   France
4390
4391   Email: ylafon@w3.org
4392   URI:   http://www.raubacapeu.net/people/yves/
4393
4394
4395   Julian F. Reschke (editor)
4396   greenbytes GmbH
4397   Hafenweg 16
4398   Muenster, NW  48155
4399   Germany
4400
4401   Phone: +49 251 2807760
4402   Fax:   +49 251 2807761
4403   Email: julian.reschke@greenbytes.de
4404   URI:   http://greenbytes.de/tech/webdav/
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423Fielding, et al.       Expires September 10, 2009              [Page 79]
4424
Note: See TracBrowser for help on using the repository browser.