source: draft-ietf-httpbis/12/draft-ietf-httpbis-p1-messaging-12.txt @ 1515

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

Back-port clarification of trailer requirements to -12 (see #193 and [1053])

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