source: draft-ietf-httpbis/10/draft-ietf-httpbis-p1-messaging-10.txt @ 956

Last change on this file since 956 was 956, checked in by fielding@…, 9 years ago

forgot to set eol-style

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