source: draft-ietf-httpbis/17/draft-ietf-httpbis-p1-messaging-17.txt @ 1529

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

Prepare publication of -17.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 198.1 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2145,2616 (if approved)                             J. Gettys
7Updates: 2817 (if approved)                               Alcatel-Lucent
8Intended status: Standards Track                                J. Mogul
9Expires: May 3, 2012                                                  HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                        October 31, 2011
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-17
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 and moves it to
36   historic status, along with its predecessor RFC 2068.
37
38   Part 1 provides an overview of HTTP and its associated terminology,
39   defines the "http" and "https" Uniform Resource Identifier (URI)
40   schemes, defines the generic message syntax and parsing requirements
41   for HTTP message frames, and describes general security concerns for
42   implementations.
43
44   This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817
45   (on using CONNECT for TLS upgrades) and moves them to historic
46   status.
47
48Editorial Note (To be removed by RFC Editor)
49
50   Discussion of this draft should take place on the HTTPBIS working
51   group mailing list (ietf-http-wg@w3.org), which is archived at
52
53
54
55Fielding, et al.           Expires May 3, 2012                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1                October 2011
58
59
60   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
61
62   The current issues list is at
63   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
64   documents (including fancy diffs) can be found at
65   <http://tools.ietf.org/wg/httpbis/>.
66
67   The changes in this draft are summarized in Appendix C.18.
68
69Status of This Memo
70
71   This Internet-Draft is submitted in full conformance with the
72   provisions of BCP 78 and BCP 79.
73
74   Internet-Drafts are working documents of the Internet Engineering
75   Task Force (IETF).  Note that other groups may also distribute
76   working documents as Internet-Drafts.  The list of current Internet-
77   Drafts is at http://datatracker.ietf.org/drafts/current/.
78
79   Internet-Drafts are draft documents valid for a maximum of six months
80   and may be updated, replaced, or obsoleted by other documents at any
81   time.  It is inappropriate to use Internet-Drafts as reference
82   material or to cite them other than as "work in progress."
83
84   This Internet-Draft will expire on May 3, 2012.
85
86Copyright Notice
87
88   Copyright (c) 2011 IETF Trust and the persons identified as the
89   document authors.  All rights reserved.
90
91   This document is subject to BCP 78 and the IETF Trust's Legal
92   Provisions Relating to IETF Documents
93   (http://trustee.ietf.org/license-info) in effect on the date of
94   publication of this document.  Please review these documents
95   carefully, as they describe your rights and restrictions with respect
96   to this document.  Code Components extracted from this document must
97   include Simplified BSD License text as described in Section 4.e of
98   the Trust Legal Provisions and are provided without warranty as
99   described in the Simplified BSD License.
100
101   This document may contain material from IETF Documents or IETF
102   Contributions published or made publicly available before November
103   10, 2008.  The person(s) controlling the copyright in some of this
104   material may not have granted the IETF Trust the right to allow
105   modifications of such material outside the IETF Standards Process.
106   Without obtaining an adequate license from the person(s) controlling
107   the copyright in such materials, this document may not be modified
108
109
110
111Fielding, et al.           Expires May 3, 2012                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1                October 2011
114
115
116   outside the IETF Standards Process, and derivative works of it may
117   not be created outside the IETF Standards Process, except to format
118   it for publication as an RFC or to translate it into languages other
119   than English.
120
121Table of Contents
122
123   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
124     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  7
125     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  7
126       1.2.1.  ABNF Extension: #rule  . . . . . . . . . . . . . . . .  8
127       1.2.2.  Basic Rules  . . . . . . . . . . . . . . . . . . . . .  9
128   2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  9
129     2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . . 10
130     2.2.  Message Orientation and Buffering  . . . . . . . . . . . . 11
131     2.3.  Connections and Transport Independence . . . . . . . . . . 12
132     2.4.  Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
133     2.5.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14
134     2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 15
135     2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
136       2.7.1.  http URI scheme  . . . . . . . . . . . . . . . . . . . 18
137       2.7.2.  https URI scheme . . . . . . . . . . . . . . . . . . . 19
138       2.7.3.  http and https URI Normalization and Comparison  . . . 20
139   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20
140     3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21
141       3.1.1.  Request-Line . . . . . . . . . . . . . . . . . . . . . 22
142       3.1.2.  Response Status-Line . . . . . . . . . . . . . . . . . 23
143     3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 23
144       3.2.1.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 24
145       3.2.2.  Field Length . . . . . . . . . . . . . . . . . . . . . 25
146       3.2.3.  Common Field ABNF Rules  . . . . . . . . . . . . . . . 25
147     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
148     3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 30
149     3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 30
150   4.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 31
151     4.1.  Types of Request Target  . . . . . . . . . . . . . . . . . 31
152     4.2.  The Resource Identified by a Request . . . . . . . . . . . 33
153     4.3.  Effective Request URI  . . . . . . . . . . . . . . . . . . 34
154   5.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 35
155     5.1.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35
156       5.1.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . 36
157       5.1.2.  Compression Codings  . . . . . . . . . . . . . . . . . 38
158       5.1.3.  Transfer Coding Registry . . . . . . . . . . . . . . . 39
159     5.2.  Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
160     5.3.  Quality Values . . . . . . . . . . . . . . . . . . . . . . 40
161   6.  Connections  . . . . . . . . . . . . . . . . . . . . . . . . . 40
162     6.1.  Persistent Connections . . . . . . . . . . . . . . . . . . 40
163       6.1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . 40
164
165
166
167Fielding, et al.           Expires May 3, 2012                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1                October 2011
170
171
172       6.1.2.  Overall Operation  . . . . . . . . . . . . . . . . . . 41
173       6.1.3.  Proxy Servers  . . . . . . . . . . . . . . . . . . . . 42
174       6.1.4.  Practical Considerations . . . . . . . . . . . . . . . 45
175       6.1.5.  Retrying Requests  . . . . . . . . . . . . . . . . . . 46
176     6.2.  Message Transmission Requirements  . . . . . . . . . . . . 46
177       6.2.1.  Persistent Connections and Flow Control  . . . . . . . 46
178       6.2.2.  Monitoring Connections for Error Status Messages . . . 46
179       6.2.3.  Use of the 100 (Continue) Status . . . . . . . . . . . 46
180   7.  Miscellaneous notes that might disappear . . . . . . . . . . . 48
181     7.1.  Scheme aliases considered harmful  . . . . . . . . . . . . 48
182     7.2.  Use of HTTP for proxy communication  . . . . . . . . . . . 49
183     7.3.  Interception of HTTP for access control  . . . . . . . . . 49
184     7.4.  Use of HTTP by other protocols . . . . . . . . . . . . . . 49
185     7.5.  Use of HTTP by media type specification  . . . . . . . . . 49
186   8.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
187     8.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
188     8.2.  Content-Length . . . . . . . . . . . . . . . . . . . . . . 51
189     8.3.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
190     8.4.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
191     8.5.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 54
192     8.6.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . . . 54
193     8.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 55
194       8.7.1.  Upgrade Token Registry . . . . . . . . . . . . . . . . 56
195     8.8.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
196   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 58
197     9.1.  Header Field Registration  . . . . . . . . . . . . . . . . 58
198     9.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 59
199     9.3.  Internet Media Type Registrations  . . . . . . . . . . . . 59
200       9.3.1.  Internet Media Type message/http . . . . . . . . . . . 59
201       9.3.2.  Internet Media Type application/http . . . . . . . . . 61
202     9.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
203     9.5.  Upgrade Token Registration . . . . . . . . . . . . . . . . 62
204   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 62
205     10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
206     10.2. Abuse of Server Log Information  . . . . . . . . . . . . . 63
207     10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
208     10.4. DNS-related Attacks  . . . . . . . . . . . . . . . . . . . 63
209     10.5. Proxies and Caching  . . . . . . . . . . . . . . . . . . . 64
210     10.6. Protocol Element Size Overflows  . . . . . . . . . . . . . 64
211     10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
212   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 65
213   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
214     12.1. Normative References . . . . . . . . . . . . . . . . . . . 66
215     12.2. Informative References . . . . . . . . . . . . . . . . . . 68
216   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 70
217     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 71
218       A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 71
219       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 71
220
221
222
223Fielding, et al.           Expires May 3, 2012                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1                October 2011
226
227
228     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 72
229   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 73
230   Appendix C.  Change Log (to be removed by RFC Editor before
231                publication)  . . . . . . . . . . . . . . . . . . . . 76
232     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76
233     C.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76
234     C.3.  Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78
235     C.4.  Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79
236     C.5.  Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79
237     C.6.  Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80
238     C.7.  Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80
239     C.8.  Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81
240     C.9.  Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82
241     C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
242     C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83
243     C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83
244     C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84
245     C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84
246     C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85
247     C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85
248     C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
249     C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86
250   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
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 May 3, 2012                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1                October 2011
282
283
2841.  Introduction
285
286   The Hypertext Transfer Protocol (HTTP) is an application-level
287   request/response protocol that uses extensible semantics and MIME-
288   like message payloads for flexible interaction with network-based
289   hypertext information systems.  HTTP relies upon the Uniform Resource
290   Identifier (URI) standard [RFC3986] to indicate the target resource
291   and relationships between resources.  Messages are passed in a format
292   similar to that used by Internet mail [RFC5322] and the Multipurpose
293   Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3]
294   for the differences between HTTP and MIME messages).
295
296   HTTP is a generic interface protocol for information systems.  It is
297   designed to hide the details of how a service is implemented by
298   presenting a uniform interface to clients that is independent of the
299   types of resources provided.  Likewise, servers do not need to be
300   aware of each client's purpose: an HTTP request can be considered in
301   isolation rather than being associated with a specific type of client
302   or a predetermined sequence of application steps.  The result is a
303   protocol that can be used effectively in many different contexts and
304   for which implementations can evolve independently over time.
305
306   HTTP is also designed for use as an intermediation protocol for
307   translating communication to and from non-HTTP information systems.
308   HTTP proxies and gateways can provide access to alternative
309   information services by translating their diverse protocols into a
310   hypertext format that can be viewed and manipulated by clients in the
311   same way as HTTP services.
312
313   One consequence of HTTP flexibility is that the protocol cannot be
314   defined in terms of what occurs behind the interface.  Instead, we
315   are limited to defining the syntax of communication, the intent of
316   received communication, and the expected behavior of recipients.  If
317   the communication is considered in isolation, then successful actions
318   ought to be reflected in corresponding changes to the observable
319   interface provided by servers.  However, since multiple clients might
320   act in parallel and perhaps at cross-purposes, we cannot require that
321   such changes be observable beyond the scope of a single response.
322
323   This document is Part 1 of the seven-part specification of HTTP,
324   defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]
325   and [RFC2145].  Part 1 describes the architectural elements that are
326   used or referred to in HTTP, defines the "http" and "https" URI
327   schemes, describes overall network operation and connection
328   management, and defines HTTP message framing and forwarding
329   requirements.  Our goal is to define all of the mechanisms necessary
330   for HTTP message handling that are independent of message semantics,
331   thereby defining the complete set of requirements for message parsers
332
333
334
335Fielding, et al.           Expires May 3, 2012                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1                October 2011
338
339
340   and message-forwarding intermediaries.
341
3421.1.  Conformance and Error Handling
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   This document defines conformance criteria for several roles in HTTP
349   communication, including Senders, Recipients, Clients, Servers, User-
350   Agents, Origin Servers, Intermediaries, Proxies and Gateways.  See
351   Section 2 for definitions of these terms.
352
353   An implementation is considered conformant if it complies with all of
354   the requirements associated with its role(s).  Note that SHOULD-level
355   requirements are relevant here, unless one of the documented
356   exceptions is applicable.
357
358   This document also uses ABNF to define valid protocol elements
359   (Section 1.2).  In addition to the prose requirements placed upon
360   them, Senders MUST NOT generate protocol elements that are invalid.
361
362   Unless noted otherwise, Recipients MAY take steps to recover a usable
363   protocol element from an invalid construct.  However, HTTP does not
364   define specific error handling mechanisms, except in cases where it
365   has direct impact on security.  This is because different uses of the
366   protocol require different error handling strategies; for example, a
367   Web browser may wish to transparently recover from a response where
368   the Location header field doesn't parse according to the ABNF,
369   whereby in a systems control protocol using HTTP, this type of error
370   recovery could lead to dangerous consequences.
371
3721.2.  Syntax Notation
373
374   This specification uses the Augmented Backus-Naur Form (ABNF)
375   notation of [RFC5234].
376
377   The following core rules are included by reference, as defined in
378   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
379   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
380   HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
381   feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
382   visible [USASCII] character).
383
384   As a syntactic convention, ABNF rule names prefixed with "obs-"
385   denote "obsolete" grammar rules that appear for historical reasons.
386
387
388
389
390
391Fielding, et al.           Expires May 3, 2012                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1                October 2011
394
395
3961.2.1.  ABNF Extension: #rule
397
398   The #rule extension to the ABNF rules of [RFC5234] is used to improve
399   readability.
400
401   A construct "#" is defined, similar to "*", for defining comma-
402   delimited lists of elements.  The full form is "<n>#<m>element"
403   indicating at least <n> and at most <m> elements, each separated by a
404   single comma (",") and optional whitespace (OWS, Section 1.2.2).
405
406   Thus,
407
408     1#element => element *( OWS "," OWS element )
409
410   and:
411
412     #element => [ 1#element ]
413
414   and for n >= 1 and m > 1:
415
416     <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
417
418   For compatibility with legacy list rules, recipients SHOULD accept
419   empty list elements.  In other words, consumers would follow the list
420   productions:
421
422     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
423
424     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
425
426   Note that empty elements do not contribute to the count of elements
427   present, though.
428
429   For example, given these ABNF productions:
430
431     example-list      = 1#example-list-elmt
432     example-list-elmt = token ; see Section 3.2.3
433
434   Then these are valid values for example-list (not including the
435   double quotes, which are present for delimitation only):
436
437     "foo,bar"
438     "foo ,bar,"
439     "foo , ,bar,charlie   "
440
441   But these values would be invalid, as at least one non-empty element
442   is required:
443
444
445
446
447Fielding, et al.           Expires May 3, 2012                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1                October 2011
450
451
452     ""
453     ","
454     ",   ,"
455
456   Appendix B shows the collected ABNF, with the list rules expanded as
457   explained above.
458
4591.2.2.  Basic Rules
460
461   This specification uses three rules to denote the use of linear
462   whitespace: OWS (optional whitespace), RWS (required whitespace), and
463   BWS ("bad" whitespace).
464
465   The OWS rule is used where zero or more linear whitespace octets
466   might appear.  OWS SHOULD either not be produced or be produced as a
467   single SP.  Multiple OWS octets that occur within field-content
468   SHOULD either be replaced with a single SP or transformed to all SP
469   octets (each octet other than SP replaced with SP) before
470   interpreting the field value or forwarding the message downstream.
471
472   RWS is used when at least one linear whitespace octet is required to
473   separate field tokens.  RWS SHOULD be produced as a single SP.
474   Multiple RWS octets that occur within field-content SHOULD either be
475   replaced with a single SP or transformed to all SP octets before
476   interpreting the field value or forwarding the message downstream.
477
478   BWS is used where the grammar allows optional whitespace for
479   historical reasons but senders SHOULD NOT produce it in messages.
480   HTTP/1.1 recipients MUST accept such bad optional whitespace and
481   remove it before interpreting the field value or forwarding the
482   message downstream.
483
484
485     OWS            = *( SP / HTAB / obs-fold )
486                    ; "optional" whitespace
487     RWS            = 1*( SP / HTAB / obs-fold )
488                    ; "required" whitespace
489     BWS            = OWS
490                    ; "bad" whitespace
491     obs-fold       = CRLF ( SP / HTAB )
492                    ; obsolete line folding
493                    ; see Section 3.2.1
494
4952.  Architecture
496
497   HTTP was created for the World Wide Web architecture and has evolved
498   over time to support the scalability needs of a worldwide hypertext
499   system.  Much of that architecture is reflected in the terminology
500
501
502
503Fielding, et al.           Expires May 3, 2012                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1                October 2011
506
507
508   and syntax productions used to define HTTP.
509
5102.1.  Client/Server Messaging
511
512   HTTP is a stateless request/response protocol that operates by
513   exchanging messages (Section 3) across a reliable transport or
514   session-layer "connection".  An HTTP "client" is a program that
515   establishes a connection to a server for the purpose of sending one
516   or more HTTP requests.  An HTTP "server" is a program that accepts
517   connections in order to service HTTP requests by sending HTTP
518   responses.
519
520   Note that the terms client and server refer only to the roles that
521   these programs perform for a particular connection.  The same program
522   might act as a client on some connections and a server on others.  We
523   use the term "user agent" to refer to the program that initiates a
524   request, such as a WWW browser, editor, or spider (web-traversing
525   robot), and the term "origin server" to refer to the program that can
526   originate authoritative responses to a request.  For general
527   requirements, we use the term "sender" to refer to whichever
528   component sent a given message and the term "recipient" to refer to
529   any component that receives the message.
530
531   Most HTTP communication consists of a retrieval request (GET) for a
532   representation of some resource identified by a URI.  In the simplest
533   case, this might be accomplished via a single bidirectional
534   connection (===) between the user agent (UA) and the origin server
535   (O).
536
537            request   >
538       UA ======================================= O
539                                   <   response
540
541   A client sends an HTTP request to the server in the form of a request
542   message, beginning with a request-line that includes a method, URI,
543   and protocol version (Section 3.1.1), followed by MIME-like header
544   fields containing request modifiers, client information, and payload
545   metadata (Section 3.2), an empty line to indicate the end of the
546   header section, and finally a message body containing the payload
547   body (if any, Section 3.3).
548
549   A server responds to the client's request by sending an HTTP response
550   message, beginning with a status line that includes the protocol
551   version, a success or error code, and textual reason phrase
552   (Section 3.1.2), followed by MIME-like header fields containing
553   server information, resource metadata, and payload metadata
554   (Section 3.2), an empty line to indicate the end of the header
555   section, and finally a message body containing the payload body (if
556
557
558
559Fielding, et al.           Expires May 3, 2012                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1                October 2011
562
563
564   any, Section 3.3).
565
566   The following example illustrates a typical message exchange for a
567   GET request on the URI "http://www.example.com/hello.txt":
568
569   client request:
570
571     GET /hello.txt HTTP/1.1
572     User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
573     Host: www.example.com
574     Accept: */*
575
576
577   server response:
578
579     HTTP/1.1 200 OK
580     Date: Mon, 27 Jul 2009 12:28:53 GMT
581     Server: Apache
582     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
583     ETag: "34aa387-d-1568eb00"
584     Accept-Ranges: bytes
585     Content-Length: 14
586     Vary: Accept-Encoding
587     Content-Type: text/plain
588
589     Hello World!
590
5912.2.  Message Orientation and Buffering
592
593   Fundamentally, HTTP is a message-based protocol.  Although message
594   bodies can be chunked (Section 5.1.1) and implementations often make
595   parts of a message available progressively, this is not required, and
596   some widely-used implementations only make a message available when
597   it is complete.  Furthermore, while most proxies will progressively
598   stream messages, some amount of buffering will take place, and some
599   proxies might buffer messages to perform transformations, check
600   content or provide other services.
601
602   Therefore, extensions to and uses of HTTP cannot rely on the
603   availability of a partial message, or assume that messages will not
604   be buffered.  There are strategies that can be used to test for
605   buffering in a given connection, but it should be understood that
606   behaviors can differ across connections, and between requests and
607   responses.
608
609   Recipients MUST consider every message in a connection in isolation;
610   because HTTP is a stateless protocol, it cannot be assumed that two
611   requests on the same connection are from the same client or share any
612
613
614
615Fielding, et al.           Expires May 3, 2012                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1                October 2011
618
619
620   other common attributes.  In particular, intermediaries might mix
621   requests from different clients into a single server connection.
622   Note that some existing HTTP extensions (e.g., [RFC4559]) violate
623   this requirement, thereby potentially causing interoperability and
624   security problems.
625
6262.3.  Connections and Transport Independence
627
628   HTTP messaging is independent of the underlying transport or session-
629   layer connection protocol(s).  HTTP only presumes a reliable
630   transport with in-order delivery of requests and the corresponding
631   in-order delivery of responses.  The mapping of HTTP request and
632   response structures onto the data units of the underlying transport
633   protocol is outside the scope of this specification.
634
635   The specific connection protocols to be used for an interaction are
636   determined by client configuration and the target resource's URI.
637   For example, the "http" URI scheme (Section 2.7.1) indicates a
638   default connection of TCP over IP, with a default TCP port of 80, but
639   the client might be configured to use a proxy via some other
640   connection port or protocol instead of using the defaults.
641
642   A connection might be used for multiple HTTP request/response
643   exchanges, as defined in Section 6.1.
644
6452.4.  Intermediaries
646
647   HTTP enables the use of intermediaries to satisfy requests through a
648   chain of connections.  There are three common forms of HTTP
649   intermediary: proxy, gateway, and tunnel.  In some cases, a single
650   intermediary might act as an origin server, proxy, gateway, or
651   tunnel, switching behavior based on the nature of each request.
652
653            >             >             >             >
654       UA =========== A =========== B =========== C =========== O
655                  <             <             <             <
656
657   The figure above shows three intermediaries (A, B, and C) between the
658   user agent and origin server.  A request or response message that
659   travels the whole chain will pass through four separate connections.
660   Some HTTP communication options might apply only to the connection
661   with the nearest, non-tunnel neighbor, only to the end-points of the
662   chain, or to all connections along the chain.  Although the diagram
663   is linear, each participant might be engaged in multiple,
664   simultaneous communications.  For example, B might be receiving
665   requests from many clients other than A, and/or forwarding requests
666   to servers other than C, at the same time that it is handling A's
667   request.
668
669
670
671Fielding, et al.           Expires May 3, 2012                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1                October 2011
674
675
676   We use the terms "upstream" and "downstream" to describe various
677   requirements in relation to the directional flow of a message: all
678   messages flow from upstream to downstream.  Likewise, we use the
679   terms inbound and outbound to refer to directions in relation to the
680   request path: "inbound" means toward the origin server and "outbound"
681   means toward the user agent.
682
683   A "proxy" is a message forwarding agent that is selected by the
684   client, usually via local configuration rules, to receive requests
685   for some type(s) of absolute URI and attempt to satisfy those
686   requests via translation through the HTTP interface.  Some
687   translations are minimal, such as for proxy requests for "http" URIs,
688   whereas other requests might require translation to and from entirely
689   different application-layer protocols.  Proxies are often used to
690   group an organization's HTTP requests through a common intermediary
691   for the sake of security, annotation services, or shared caching.
692
693   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
694   designed or configured to modify request or response messages in a
695   semantically meaningful way (i.e., modifications, beyond those
696   required by normal HTTP processing, that change the message in a way
697   that would be significant to the original sender or potentially
698   significant to downstream recipients).  For example, a transforming
699   proxy might be acting as a shared annotation server (modifying
700   responses to include references to a local annotation database), a
701   malware filter, a format transcoder, or an intranet-to-Internet
702   privacy filter.  Such transformations are presumed to be desired by
703   the client (or client organization) that selected the proxy and are
704   beyond the scope of this specification.  However, when a proxy is not
705   intended to transform a given message, we use the term "non-
706   transforming proxy" to target requirements that preserve HTTP message
707   semantics.  See Section 7.2.4 of [Part2] and Section 3.6 of [Part6]
708   for status and warning codes related to transformations.
709
710   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
711   as a layer above some other server(s) and translates the received
712   requests to the underlying server's protocol.  Gateways are often
713   used to encapsulate legacy or untrusted information services, to
714   improve server performance through "accelerator" caching, and to
715   enable partitioning or load-balancing of HTTP services across
716   multiple machines.
717
718   A gateway behaves as an origin server on its outbound connection and
719   as a user agent on its inbound connection.  All HTTP requirements
720   applicable to an origin server also apply to the outbound
721   communication of a gateway.  A gateway communicates with inbound
722   servers using any protocol that it desires, including private
723   extensions to HTTP that are outside the scope of this specification.
724
725
726
727Fielding, et al.           Expires May 3, 2012                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1                October 2011
730
731
732   However, an HTTP-to-HTTP gateway that wishes to interoperate with
733   third-party HTTP servers MUST comply with HTTP user agent
734   requirements on the gateway's inbound connection and MUST implement
735   the Connection (Section 8.1) and Via (Section 8.8) header fields for
736   both connections.
737
738   A "tunnel" acts as a blind relay between two connections without
739   changing the messages.  Once active, a tunnel is not considered a
740   party to the HTTP communication, though the tunnel might have been
741   initiated by an HTTP request.  A tunnel ceases to exist when both
742   ends of the relayed connection are closed.  Tunnels are used to
743   extend a virtual connection through an intermediary, such as when
744   transport-layer security is used to establish private communication
745   through a shared firewall proxy.
746
747   In addition, there may exist network intermediaries that are not
748   considered part of the HTTP communication but nevertheless act as
749   filters or redirecting agents (usually violating HTTP semantics,
750   causing security problems, and otherwise making a mess of things).
751   Such a network intermediary, often referred to as an "interception
752   proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal",
753   differs from an HTTP proxy because it has not been selected by the
754   client.  Instead, the network intermediary redirects outgoing TCP
755   port 80 packets (and occasionally other common port traffic) to an
756   internal HTTP server.  Interception proxies are commonly found on
757   public network access points, as a means of enforcing account
758   subscription prior to allowing use of non-local Internet services,
759   and within corporate firewalls to enforce network usage policies.
760   They are indistinguishable from a man-in-the-middle attack.
761
7622.5.  Caches
763
764   A "cache" is a local store of previous response messages and the
765   subsystem that controls its message storage, retrieval, and deletion.
766   A cache stores cacheable responses in order to reduce the response
767   time and network bandwidth consumption on future, equivalent
768   requests.  Any client or server MAY employ a cache, though a cache
769   cannot be used by a server while it is acting as a tunnel.
770
771   The effect of a cache is that the request/response chain is shortened
772   if one of the participants along the chain has a cached response
773   applicable to that request.  The following illustrates the resulting
774   chain if B has a cached copy of an earlier response from O (via C)
775   for a request which has not been cached by UA or A.
776
777               >             >
778          UA =========== A =========== B - - - - - - C - - - - - - O
779                     <             <
780
781
782
783Fielding, et al.           Expires May 3, 2012                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1                October 2011
786
787
788   A response is "cacheable" if a cache is allowed to store a copy of
789   the response message for use in answering subsequent requests.  Even
790   when a response is cacheable, there might be additional constraints
791   placed by the client or by the origin server on when that cached
792   response can be used for a particular request.  HTTP requirements for
793   cache behavior and cacheable responses are defined in Section 2 of
794   [Part6].
795
796   There are a wide variety of architectures and configurations of
797   caches and proxies deployed across the World Wide Web and inside
798   large organizations.  These systems include national hierarchies of
799   proxy caches to save transoceanic bandwidth, systems that broadcast
800   or multicast cache entries, organizations that distribute subsets of
801   cached data via optical media, and so on.
802
8032.6.  Protocol Versioning
804
805   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
806   of the protocol.  This specification defines version "1.1".  The
807   protocol version as a whole indicates the sender's compliance with
808   the set of requirements laid out in that version's corresponding
809   specification of HTTP.
810
811   The version of an HTTP message is indicated by an HTTP-Version field
812   in the first line of the message.  HTTP-Version is case-sensitive.
813
814     HTTP-Version   = HTTP-Prot-Name "/" DIGIT "." DIGIT
815     HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
816
817   The HTTP version number consists of two decimal digits separated by a
818   "." (period or decimal point).  The first digit ("major version")
819   indicates the HTTP messaging syntax, whereas the second digit ("minor
820   version") indicates the highest minor version to which the sender is
821   at least conditionally compliant and able to understand for future
822   communication.  The minor version advertises the sender's
823   communication capabilities even when the sender is only using a
824   backwards-compatible subset of the protocol, thereby letting the
825   recipient know that more advanced features can be used in response
826   (by servers) or in future requests (by clients).
827
828   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
829   or a recipient whose version is unknown, the HTTP/1.1 message is
830   constructed such that it can be interpreted as a valid HTTP/1.0
831   message if all of the newer features are ignored.  This specification
832   places recipient-version requirements on some new features so that a
833   compliant sender will only use compatible features until it has
834   determined, through configuration or the receipt of a message, that
835   the recipient supports HTTP/1.1.
836
837
838
839Fielding, et al.           Expires May 3, 2012                 [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1                October 2011
842
843
844   The interpretation of an HTTP header field does not change between
845   minor versions of the same major version, though the default behavior
846   of a recipient in the absence of such a field can change.  Unless
847   specified otherwise, header fields defined in HTTP/1.1 are defined
848   for all versions of HTTP/1.x.  In particular, the Host and Connection
849   header fields ought to be implemented by all HTTP/1.x implementations
850   whether or not they advertise compliance with HTTP/1.1.
851
852   New header fields can be defined such that, when they are understood
853   by a recipient, they might override or enhance the interpretation of
854   previously defined header fields.  When an implementation receives an
855   unrecognized header field, the recipient MUST ignore that header
856   field for local processing regardless of the message's HTTP version.
857   An unrecognized header field received by a proxy MUST be forwarded
858   downstream unless the header field's field-name is listed in the
859   message's Connection header-field (see Section 8.1).  These
860   requirements allow HTTP's functionality to be enhanced without
861   requiring prior update of all compliant intermediaries.
862
863   Intermediaries that process HTTP messages (i.e., all intermediaries
864   other than those acting as a tunnel) MUST send their own HTTP-Version
865   in forwarded messages.  In other words, they MUST NOT blindly forward
866   the first line of an HTTP message without ensuring that the protocol
867   version matches what the intermediary understands, and is at least
868   conditionally compliant to, for both the receiving and sending of
869   messages.  Forwarding an HTTP message without rewriting the HTTP-
870   Version might result in communication errors when downstream
871   recipients use the message sender's version to determine what
872   features are safe to use for later communication with that sender.
873
874   An HTTP client SHOULD send a request version equal to the highest
875   version for which the client is at least conditionally compliant and
876   whose major version is no higher than the highest version supported
877   by the server, if this is known.  An HTTP client MUST NOT send a
878   version for which it is not at least conditionally compliant.
879
880   An HTTP client MAY send a lower request version if it is known that
881   the server incorrectly implements the HTTP specification, but only
882   after the client has attempted at least one normal request and
883   determined from the response status or header fields (e.g., Server)
884   that the server improperly handles higher request versions.
885
886   An HTTP server SHOULD send a response version equal to the highest
887   version for which the server is at least conditionally compliant and
888   whose major version is less than or equal to the one received in the
889   request.  An HTTP server MUST NOT send a version for which it is not
890   at least conditionally compliant.  A server MAY send a 505 (HTTP
891   Version Not Supported) response if it cannot send a response using
892
893
894
895Fielding, et al.           Expires May 3, 2012                 [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1                October 2011
898
899
900   the major version used in the client's request.
901
902   An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
903   if it is known or suspected that the client incorrectly implements
904   the HTTP specification and is incapable of correctly processing later
905   version responses, such as when a client fails to parse the version
906   number correctly or when an intermediary is known to blindly forward
907   the HTTP-Version even when it doesn't comply with the given minor
908   version of the protocol.  Such protocol downgrades SHOULD NOT be
909   performed unless triggered by specific client attributes, such as
910   when one or more of the request header fields (e.g., User-Agent)
911   uniquely match the values sent by a client known to be in error.
912
913   The intention of HTTP's versioning design is that the major number
914   will only be incremented if an incompatible message syntax is
915   introduced, and that the minor number will only be incremented when
916   changes made to the protocol have the effect of adding to the message
917   semantics or implying additional capabilities of the sender.
918   However, the minor version was not incremented for the changes
919   introduced between [RFC2068] and [RFC2616], and this revision is
920   specifically avoiding any such changes to the protocol.
921
9222.7.  Uniform Resource Identifiers
923
924   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
925   HTTP as the means for identifying resources.  URI references are used
926   to target requests, indicate redirects, and define relationships.
927   HTTP does not limit what a resource might be; it merely defines an
928   interface that can be used to interact with a resource via HTTP.
929   More information on the scope of URIs and resources can be found in
930   [RFC3986].
931
932   This specification adopts the definitions of "URI-reference",
933   "absolute-URI", "relative-part", "port", "host", "path-abempty",
934   "path-absolute", "query", and "authority" from the URI generic syntax
935   [RFC3986].  In addition, we define a partial-URI rule for protocol
936   elements that allow a relative URI but not a fragment.
937
938     URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
939     absolute-URI  = <absolute-URI, defined in [RFC3986], Section 4.3>
940     relative-part = <relative-part, defined in [RFC3986], Section 4.2>
941     authority     = <authority, defined in [RFC3986], Section 3.2>
942     path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
943     path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
944     port          = <port, defined in [RFC3986], Section 3.2.3>
945     query         = <query, defined in [RFC3986], Section 3.4>
946     uri-host      = <host, defined in [RFC3986], Section 3.2.2>
947
948
949
950
951Fielding, et al.           Expires May 3, 2012                 [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1                October 2011
954
955
956     partial-URI   = relative-part [ "?" query ]
957
958   Each protocol element in HTTP that allows a URI reference will
959   indicate in its ABNF production whether the element allows any form
960   of reference (URI-reference), only a URI in absolute form (absolute-
961   URI), only the path and optional query components, or some
962   combination of the above.  Unless otherwise indicated, URI references
963   are parsed relative to the effective request URI, which defines the
964   default base URI for references in both the request and its
965   corresponding response.
966
9672.7.1.  http URI scheme
968
969   The "http" URI scheme is hereby defined for the purpose of minting
970   identifiers according to their association with the hierarchical
971   namespace governed by a potential HTTP origin server listening for
972   TCP connections on a given port.
973
974     http-URI = "http:" "//" authority path-abempty [ "?" query ]
975
976   The HTTP origin server is identified by the generic syntax's
977   authority component, which includes a host identifier and optional
978   TCP port ([RFC3986], Section 3.2.2).  The remainder of the URI,
979   consisting of both the hierarchical path component and optional query
980   component, serves as an identifier for a potential resource within
981   that origin server's name space.
982
983   If the host identifier is provided as an IP literal or IPv4 address,
984   then the origin server is any listener on the indicated TCP port at
985   that IP address.  If host is a registered name, then that name is
986   considered an indirect identifier and the recipient might use a name
987   resolution service, such as DNS, to find the address of a listener
988   for that host.  The host MUST NOT be empty; if an "http" URI is
989   received with an empty host, then it MUST be rejected as invalid.  If
990   the port subcomponent is empty or not given, then TCP port 80 is
991   assumed (the default reserved port for WWW services).
992
993   Regardless of the form of host identifier, access to that host is not
994   implied by the mere presence of its name or address.  The host might
995   or might not exist and, even when it does exist, might or might not
996   be running an HTTP server or listening to the indicated port.  The
997   "http" URI scheme makes use of the delegated nature of Internet names
998   and addresses to establish a naming authority (whatever entity has
999   the ability to place an HTTP server at that Internet name or address)
1000   and allows that authority to determine which names are valid and how
1001   they might be used.
1002
1003   When an "http" URI is used within a context that calls for access to
1004
1005
1006
1007Fielding, et al.           Expires May 3, 2012                 [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1                October 2011
1010
1011
1012   the indicated resource, a client MAY attempt access by resolving the
1013   host to an IP address, establishing a TCP connection to that address
1014   on the indicated port, and sending an HTTP request message
1015   (Section 3) containing the URI's identifying data (Section 4) to the
1016   server.  If the server responds to that request with a non-interim
1017   HTTP response message, as described in Section 4 of [Part2], then
1018   that response is considered an authoritative answer to the client's
1019   request.
1020
1021   Although HTTP is independent of the transport protocol, the "http"
1022   scheme is specific to TCP-based services because the name delegation
1023   process depends on TCP for establishing authority.  An HTTP service
1024   based on some other underlying connection protocol would presumably
1025   be identified using a different URI scheme, just as the "https"
1026   scheme (below) is used for servers that require an SSL/TLS transport
1027   layer on a connection.  Other protocols might also be used to provide
1028   access to "http" identified resources -- it is only the authoritative
1029   interface used for mapping the namespace that is specific to TCP.
1030
1031   The URI generic syntax for authority also includes a deprecated
1032   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
1033   authentication information in the URI.  Some implementations make use
1034   of the userinfo component for internal configuration of
1035   authentication information, such as within command invocation
1036   options, configuration files, or bookmark lists, even though such
1037   usage might expose a user identifier or password.  Senders MUST NOT
1038   include a userinfo subcomponent (and its "@" delimiter) when
1039   transmitting an "http" URI in a message.  Recipients of HTTP messages
1040   that contain a URI reference SHOULD parse for the existence of
1041   userinfo and treat its presence as an error, likely indicating that
1042   the deprecated subcomponent is being used to obscure the authority
1043   for the sake of phishing attacks.
1044
10452.7.2.  https URI scheme
1046
1047   The "https" URI scheme is hereby defined for the purpose of minting
1048   identifiers according to their association with the hierarchical
1049   namespace governed by a potential HTTP origin server listening for
1050   SSL/TLS-secured connections on a given TCP port.
1051
1052   All of the requirements listed above for the "http" scheme are also
1053   requirements for the "https" scheme, except that a default TCP port
1054   of 443 is assumed if the port subcomponent is empty or not given, and
1055   the TCP connection MUST be secured for privacy through the use of
1056   strong encryption prior to sending the first HTTP request.
1057
1058     https-URI = "https:" "//" authority path-abempty [ "?" query ]
1059
1060
1061
1062
1063Fielding, et al.           Expires May 3, 2012                 [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1                October 2011
1066
1067
1068   Unlike the "http" scheme, responses to "https" identified requests
1069   are never "public" and thus MUST NOT be reused for shared caching.
1070   They can, however, be reused in a private cache if the message is
1071   cacheable by default in HTTP or specifically indicated as such by the
1072   Cache-Control header field (Section 3.2 of [Part6]).
1073
1074   Resources made available via the "https" scheme have no shared
1075   identity with the "http" scheme even if their resource identifiers
1076   indicate the same authority (the same host listening to the same TCP
1077   port).  They are distinct name spaces and are considered to be
1078   distinct origin servers.  However, an extension to HTTP that is
1079   defined to apply to entire host domains, such as the Cookie protocol
1080   [RFC6265], can allow information set by one service to impact
1081   communication with other services within a matching group of host
1082   domains.
1083
1084   The process for authoritative access to an "https" identified
1085   resource is defined in [RFC2818].
1086
10872.7.3.  http and https URI Normalization and Comparison
1088
1089   Since the "http" and "https" schemes conform to the URI generic
1090   syntax, such URIs are normalized and compared according to the
1091   algorithm defined in [RFC3986], Section 6, using the defaults
1092   described above for each scheme.
1093
1094   If the port is equal to the default port for a scheme, the normal
1095   form is to elide the port subcomponent.  Likewise, an empty path
1096   component is equivalent to an absolute path of "/", so the normal
1097   form is to provide a path of "/" instead.  The scheme and host are
1098   case-insensitive and normally provided in lowercase; all other
1099   components are compared in a case-sensitive manner.  Characters other
1100   than those in the "reserved" set are equivalent to their percent-
1101   encoded octets (see [RFC3986], Section 2.1): the normal form is to
1102   not encode them.
1103
1104   For example, the following three URIs are equivalent:
1105
1106      http://example.com:80/~smith/home.html
1107      http://EXAMPLE.com/%7Esmith/home.html
1108      http://EXAMPLE.com:/%7esmith/home.html
1109
11103.  Message Format
1111
1112   All HTTP/1.1 messages consist of a start-line followed by a sequence
1113   of octets in a format similar to the Internet Message Format
1114   [RFC5322]: zero or more header fields (collectively referred to as
1115   the "headers" or the "header section"), an empty line indicating the
1116
1117
1118
1119Fielding, et al.           Expires May 3, 2012                 [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1                October 2011
1122
1123
1124   end of the header section, and an optional message-body.
1125
1126     HTTP-message    = start-line
1127                       *( header-field CRLF )
1128                       CRLF
1129                       [ message-body ]
1130
1131   The normal procedure for parsing an HTTP message is to read the
1132   start-line into a structure, read each header field into a hash table
1133   by field name until the empty line, and then use the parsed data to
1134   determine if a message-body is expected.  If a message-body has been
1135   indicated, then it is read as a stream until an amount of octets
1136   equal to the message-body length is read or the connection is closed.
1137
1138   Recipients MUST parse an HTTP message as a sequence of octets in an
1139   encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
1140   message as a stream of Unicode characters, without regard for the
1141   specific encoding, creates security vulnerabilities due to the
1142   varying ways that string processing libraries handle invalid
1143   multibyte character sequences that contain the octet LF (%x0A).
1144   String-based parsers can only be safely used within protocol elements
1145   after the element has been extracted from the message, such as within
1146   a header field-value after message parsing has delineated the
1147   individual fields.
1148
11493.1.  Start Line
1150
1151   An HTTP message can either be a request from client to server or a
1152   response from server to client.  Syntactically, the two types of
1153   message differ only in the start-line, which is either a Request-Line
1154   (for requests) or a Status-Line (for responses), and in the algorithm
1155   for determining the length of the message-body (Section 3.3).  In
1156   theory, a client could receive requests and a server could receive
1157   responses, distinguishing them by their different start-line formats,
1158   but in practice servers are implemented to only expect a request (a
1159   response is interpreted as an unknown or invalid request method) and
1160   clients are implemented to only expect a response.
1161
1162     start-line      = Request-Line / Status-Line
1163
1164   Implementations MUST NOT send whitespace between the start-line and
1165   the first header field.  The presence of such whitespace in a request
1166   might be an attempt to trick a server into ignoring that field or
1167   processing the line after it as a new request, either of which might
1168   result in a security vulnerability if other implementations within
1169   the request chain interpret the same message differently.  Likewise,
1170   the presence of such whitespace in a response might be ignored by
1171   some clients or cause others to cease parsing.
1172
1173
1174
1175Fielding, et al.           Expires May 3, 2012                 [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1                October 2011
1178
1179
11803.1.1.  Request-Line
1181
1182   The Request-Line begins with a method token, followed by a single
1183   space (SP), the request-target, another single space (SP), the
1184   protocol version, and ending with CRLF.
1185
1186     Request-Line   = Method SP request-target SP HTTP-Version CRLF
1187
11883.1.1.1.  Method
1189
1190   The Method token indicates the request method to be performed on the
1191   target resource.  The request method is case-sensitive.
1192
1193     Method         = token
1194
1195   See Section 2 of [Part2] for further information, such as the list of
1196   methods defined by this specification, the IANA registry, and
1197   considerations for new methods.
1198
11993.1.1.2.  request-target
1200
1201   The request-target identifies the target resource upon which to apply
1202   the request.  The four options for request-target are described in
1203   Section 4.1.
1204
1205     request-target = "*"
1206                    / absolute-URI
1207                    / ( path-absolute [ "?" query ] )
1208                    / authority
1209
1210   HTTP does not place a pre-defined limit on the length of a request-
1211   target.  A server MUST be prepared to receive URIs of unbounded
1212   length and respond with the 414 (URI Too Long) status code if the
1213   received request-target would be longer than the server wishes to
1214   handle (see Section 7.4.15 of [Part2]).
1215
1216   Various ad-hoc limitations on request-target length are found in
1217   practice.  It is RECOMMENDED that all HTTP senders and recipients
1218   support request-target lengths of 8000 or more octets.
1219
1220      Note: Fragments ([RFC3986], Section 3.5) are not part of the
1221      request-target and thus will not be transmitted in an HTTP
1222      request.
1223
1224
1225
1226
1227
1228
1229
1230
1231Fielding, et al.           Expires May 3, 2012                 [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1                October 2011
1234
1235
12363.1.2.  Response Status-Line
1237
1238   The first line of a Response message is the Status-Line, consisting
1239   of the protocol version, a space (SP), the status code, another
1240   space, a possibly-empty textual phrase describing the status code,
1241   and ending with CRLF.
1242
1243     Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1244
12453.1.2.1.  Status Code
1246
1247   The Status-Code element is a 3-digit integer result code of the
1248   attempt to understand and satisfy the request.  See Section 4 of
1249   [Part2] for further information, such as the list of status codes
1250   defined by this specification, the IANA registry, and considerations
1251   for new status codes.
1252
1253     Status-Code    = 3DIGIT
1254
12553.1.2.2.  Reason Phrase
1256
1257   The Reason Phrase exists for the sole purpose of providing a textual
1258   description associated with the numeric status code, out of deference
1259   to earlier Internet application protocols that were more frequently
1260   used with interactive text clients.  A client SHOULD ignore the
1261   content of the Reason Phrase.
1262
1263     Reason-Phrase  = *( HTAB / SP / VCHAR / obs-text )
1264
12653.2.  Header Fields
1266
1267   Each HTTP header field consists of a case-insensitive field name
1268   followed by a colon (":"), optional whitespace, and the field value.
1269
1270     header-field   = field-name ":" OWS field-value BWS
1271     field-name     = token
1272     field-value    = *( field-content / obs-fold )
1273     field-content  = *( HTAB / SP / VCHAR / obs-text )
1274
1275   The field-name token labels the corresponding field-value as having
1276   the semantics defined by that header field.  For example, the Date
1277   header field is defined in Section 9.2 of [Part2] as containing the
1278   origination timestamp for the message in which it appears.
1279
1280   HTTP header fields are fully extensible: there is no limit on the
1281   introduction of new field names, each presumably defining new
1282   semantics, or on the number of header fields used in a given message.
1283   Existing fields are defined in each part of this specification and in
1284
1285
1286
1287Fielding, et al.           Expires May 3, 2012                 [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1                October 2011
1290
1291
1292   many other specifications outside the standards process.  New header
1293   fields can be introduced without changing the protocol version if
1294   their defined semantics allow them to be safely ignored by recipients
1295   that do not recognize them.
1296
1297   New HTTP header fields SHOULD be registered with IANA according to
1298   the procedures in Section 3.1 of [Part2].  Unrecognized header fields
1299   MUST be forwarded by a proxy unless the field-name is listed in the
1300   Connection header field (Section 8.1) or the proxy is specifically
1301   configured to block or otherwise transform such fields.  Unrecognized
1302   header fields SHOULD be ignored by other recipients.
1303
1304   The order in which header fields with differing field names are
1305   received is not significant.  However, it is "good practice" to send
1306   header fields that contain control data first, such as Host on
1307   requests and Date on responses, so that implementations can decide
1308   when not to handle a message as early as possible.  A server MUST
1309   wait until the entire header section is received before interpreting
1310   a request message, since later header fields might include
1311   conditionals, authentication credentials, or deliberately misleading
1312   duplicate header fields that would impact request processing.
1313
1314   Multiple header fields with the same field name MUST NOT be sent in a
1315   message unless the entire field value for that header field is
1316   defined as a comma-separated list [i.e., #(values)].  Multiple header
1317   fields with the same field name can be combined into one "field-name:
1318   field-value" pair, without changing the semantics of the message, by
1319   appending each subsequent field value to the combined field value in
1320   order, separated by a comma.  The order in which header fields with
1321   the same field name are received is therefore significant to the
1322   interpretation of the combined field value; a proxy MUST NOT change
1323   the order of these field values when forwarding a message.
1324
1325      Note: The "Set-Cookie" header field as implemented in practice can
1326      occur multiple times, but does not use the list syntax, and thus
1327      cannot be combined into a single line ([RFC6265]).  (See Appendix
1328      A.2.3 of [Kri2001] for details.)  Also note that the Set-Cookie2
1329      header field specified in [RFC2965] does not share this problem.
1330
13313.2.1.  Field Parsing
1332
1333   No whitespace is allowed between the header field-name and colon.  In
1334   the past, differences in the handling of such whitespace have led to
1335   security vulnerabilities in request routing and response handling.
1336   Any received request message that contains whitespace between a
1337   header field-name and colon MUST be rejected with a response code of
1338   400 (Bad Request).  A proxy MUST remove any such whitespace from a
1339   response message before forwarding the message downstream.
1340
1341
1342
1343Fielding, et al.           Expires May 3, 2012                 [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1                October 2011
1346
1347
1348   A field value MAY be preceded by optional whitespace (OWS); a single
1349   SP is preferred.  The field value does not include any leading or
1350   trailing white space: OWS occurring before the first non-whitespace
1351   octet of the field value or after the last non-whitespace octet of
1352   the field value is ignored and SHOULD be removed before further
1353   processing (as this does not change the meaning of the header field).
1354
1355   Historically, HTTP header field values could be extended over
1356   multiple lines by preceding each extra line with at least one space
1357   or horizontal tab (obs-fold).  This specification deprecates such
1358   line folding except within the message/http media type
1359   (Section 9.3.1).  HTTP senders MUST NOT produce messages that include
1360   line folding (i.e., that contain any field-content that matches the
1361   obs-fold rule) unless the message is intended for packaging within
1362   the message/http media type.  HTTP recipients SHOULD accept line
1363   folding and replace any embedded obs-fold whitespace with either a
1364   single SP or a matching number of SP octets (to avoid buffer copying)
1365   prior to interpreting the field value or forwarding the message
1366   downstream.
1367
1368   Historically, HTTP has allowed field content with text in the ISO-
1369   8859-1 [ISO-8859-1] character encoding and supported other character
1370   sets only through use of [RFC2047] encoding.  In practice, most HTTP
1371   header field values use only a subset of the US-ASCII character
1372   encoding [USASCII].  Newly defined header fields SHOULD limit their
1373   field values to US-ASCII octets.  Recipients SHOULD treat other (obs-
1374   text) octets in field content as opaque data.
1375
13763.2.2.  Field Length
1377
1378   HTTP does not place a pre-defined limit on the length of header
1379   fields, either in isolation or as a set.  A server MUST be prepared
1380   to receive request header fields of unbounded length and respond with
1381   a 4xx status code if the received header field(s) would be longer
1382   than the server wishes to handle.
1383
1384   A client that receives response headers that are longer than it
1385   wishes to handle can only treat it as a server error.
1386
1387   Various ad-hoc limitations on header length are found in practice.
1388   It is RECOMMENDED that all HTTP senders and recipients support
1389   messages whose combined header fields have 4000 or more octets.
1390
13913.2.3.  Common Field ABNF Rules
1392
1393   Many HTTP/1.1 header field values consist of words (token or quoted-
1394   string) separated by whitespace or special characters.  These special
1395   characters MUST be in a quoted string to be used within a parameter
1396
1397
1398
1399Fielding, et al.           Expires May 3, 2012                 [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1                October 2011
1402
1403
1404   value (as defined in Section 5.1).
1405
1406     word           = token / quoted-string
1407
1408     token          = 1*tchar
1409
1410     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1411                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1412                    / DIGIT / ALPHA
1413                    ; any VCHAR, except special
1414
1415     special        = "(" / ")" / "<" / ">" / "@" / ","
1416                    / ";" / ":" / "\" / DQUOTE / "/" / "["
1417                    / "]" / "?" / "=" / "{" / "}"
1418
1419   A string of text is parsed as a single word if it is quoted using
1420   double-quote marks.
1421
1422     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1423     qdtext         = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
1424     obs-text       = %x80-FF
1425
1426   The backslash octet ("\") can be used as a single-octet quoting
1427   mechanism within quoted-string constructs:
1428
1429     quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
1430
1431   Recipients that process the value of the quoted-string MUST handle a
1432   quoted-pair as if it were replaced by the octet following the
1433   backslash.
1434
1435   Senders SHOULD NOT escape octets in quoted-strings that do not
1436   require escaping (i.e., other than DQUOTE and the backslash octet).
1437
1438   Comments can be included in some HTTP header fields by surrounding
1439   the comment text with parentheses.  Comments are only allowed in
1440   fields containing "comment" as part of their field value definition.
1441
1442     comment        = "(" *( ctext / quoted-cpair / comment ) ")"
1443     ctext          = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1444
1445   The backslash octet ("\") can be used as a single-octet quoting
1446   mechanism within comment constructs:
1447
1448     quoted-cpair    = "\" ( HTAB / SP / VCHAR / obs-text )
1449
1450   Senders SHOULD NOT escape octets in comments that do not require
1451   escaping (i.e., other than the backslash octet "\" and the
1452
1453
1454
1455Fielding, et al.           Expires May 3, 2012                 [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1                October 2011
1458
1459
1460   parentheses "(" and ")").
1461
14623.3.  Message Body
1463
1464   The message-body (if any) of an HTTP message is used to carry the
1465   payload body associated with the request or response.
1466
1467     message-body = *OCTET
1468
1469   The message-body differs from the payload body only when a transfer-
1470   coding has been applied, as indicated by the Transfer-Encoding header
1471   field (Section 8.6).  If more than one Transfer-Encoding header field
1472   is present in a message, the multiple field-values MUST be combined
1473   into one field-value, according to the algorithm defined in
1474   Section 3.2, before determining the message-body length.
1475
1476   When one or more transfer-codings are applied to a payload in order
1477   to form the message-body, the Transfer-Encoding header field MUST
1478   contain the list of transfer-codings applied.  Transfer-Encoding is a
1479   property of the message, not of the payload, and thus MAY be added or
1480   removed by any implementation along the request/response chain under
1481   the constraints found in Section 5.1.
1482
1483   If a message is received that has multiple Content-Length header
1484   fields (Section 8.2) with field-values consisting of the same decimal
1485   value, or a single Content-Length header field with a field value
1486   containing a list of identical decimal values (e.g., "Content-Length:
1487   42, 42"), indicating that duplicate Content-Length header fields have
1488   been generated or combined by an upstream message processor, then the
1489   recipient MUST either reject the message as invalid or replace the
1490   duplicated field-values with a single valid Content-Length field
1491   containing that decimal value prior to determining the message-body
1492   length.
1493
1494   The rules for when a message-body is allowed in a message differ for
1495   requests and responses.
1496
1497   The presence of a message-body in a request is signaled by the
1498   inclusion of a Content-Length or Transfer-Encoding header field in
1499   the request's header fields, even if the request method does not
1500   define any use for a message-body.  This allows the request message
1501   framing algorithm to be independent of method semantics.
1502
1503   For response messages, whether or not a message-body is included with
1504   a message is dependent on both the request method and the response
1505   status code (Section 3.1.2.1).  Responses to the HEAD request method
1506   never include a message-body because the associated response header
1507   fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
1508
1509
1510
1511Fielding, et al.           Expires May 3, 2012                 [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1                October 2011
1514
1515
1516   what their values would have been if the request method had been GET.
1517   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1518   responses MUST NOT include a message-body.  All other responses do
1519   include a message-body, although the body MAY be of zero length.
1520
1521   The length of the message-body is determined by one of the following
1522   (in order of precedence):
1523
1524   1.  Any response to a HEAD request and any response with a status
1525       code of 100-199, 204, or 304 is always terminated by the first
1526       empty line after the header fields, regardless of the header
1527       fields present in the message, and thus cannot contain a message-
1528       body.
1529
1530   2.  If a Transfer-Encoding header field is present and the "chunked"
1531       transfer-coding (Section 5.1) is the final encoding, the message-
1532       body length is determined by reading and decoding the chunked
1533       data until the transfer-coding indicates the data is complete.
1534
1535       If a Transfer-Encoding header field is present in a response and
1536       the "chunked" transfer-coding is not the final encoding, the
1537       message-body length is determined by reading the connection until
1538       it is closed by the server.  If a Transfer-Encoding header field
1539       is present in a request and the "chunked" transfer-coding is not
1540       the final encoding, the message-body length cannot be determined
1541       reliably; the server MUST respond with the 400 (Bad Request)
1542       status code and then close the connection.
1543
1544       If a message is received with both a Transfer-Encoding header
1545       field and a Content-Length header field, the Transfer-Encoding
1546       overrides the Content-Length.  Such a message might indicate an
1547       attempt to perform request or response smuggling (bypass of
1548       security-related checks on message routing or content) and thus
1549       ought to be handled as an error.  The provided Content-Length
1550       MUST be removed, prior to forwarding the message downstream, or
1551       replaced with the real message-body length after the transfer-
1552       coding is decoded.
1553
1554   3.  If a message is received without Transfer-Encoding and with
1555       either multiple Content-Length header fields having differing
1556       field-values or a single Content-Length header field having an
1557       invalid value, then the message framing is invalid and MUST be
1558       treated as an error to prevent request or response smuggling.  If
1559       this is a request message, the server MUST respond with a 400
1560       (Bad Request) status code and then close the connection.  If this
1561       is a response message received by a proxy, the proxy MUST discard
1562       the received response, send a 502 (Bad Gateway) status code as
1563       its downstream response, and then close the connection.  If this
1564
1565
1566
1567Fielding, et al.           Expires May 3, 2012                 [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1                October 2011
1570
1571
1572       is a response message received by a user-agent, it MUST be
1573       treated as an error by discarding the message and closing the
1574       connection.
1575
1576   4.  If a valid Content-Length header field is present without
1577       Transfer-Encoding, its decimal value defines the message-body
1578       length in octets.  If the actual number of octets sent in the
1579       message is less than the indicated Content-Length, the recipient
1580       MUST consider the message to be incomplete and treat the
1581       connection as no longer usable.  If the actual number of octets
1582       sent in the message is more than the indicated Content-Length,
1583       the recipient MUST only process the message-body up to the field
1584       value's number of octets; the remainder of the message MUST
1585       either be discarded or treated as the next message in a pipeline.
1586       For the sake of robustness, a user-agent MAY attempt to detect
1587       and correct such an error in message framing if it is parsing the
1588       response to the last request on a connection and the connection
1589       has been closed by the server.
1590
1591   5.  If this is a request message and none of the above are true, then
1592       the message-body length is zero (no message-body is present).
1593
1594   6.  Otherwise, this is a response message without a declared message-
1595       body length, so the message-body length is determined by the
1596       number of octets received prior to the server closing the
1597       connection.
1598
1599   Since there is no way to distinguish a successfully completed, close-
1600   delimited message from a partially-received message interrupted by
1601   network failure, implementations SHOULD use encoding or length-
1602   delimited messages whenever possible.  The close-delimiting feature
1603   exists primarily for backwards compatibility with HTTP/1.0.
1604
1605   A server MAY reject a request that contains a message-body but not a
1606   Content-Length by responding with 411 (Length Required).
1607
1608   Unless a transfer-coding other than "chunked" has been applied, a
1609   client that sends a request containing a message-body SHOULD use a
1610   valid Content-Length header field if the message-body length is known
1611   in advance, rather than the "chunked" encoding, since some existing
1612   services respond to "chunked" with a 411 (Length Required) status
1613   code even though they understand the chunked encoding.  This is
1614   typically because such services are implemented via a gateway that
1615   requires a content-length in advance of being called and the server
1616   is unable or unwilling to buffer the entire request before
1617   processing.
1618
1619   A client that sends a request containing a message-body MUST include
1620
1621
1622
1623Fielding, et al.           Expires May 3, 2012                 [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1                October 2011
1626
1627
1628   a valid Content-Length header field if it does not know the server
1629   will handle HTTP/1.1 (or later) requests; such knowledge can be in
1630   the form of specific user configuration or by remembering the version
1631   of a prior received response.
1632
16333.4.  Handling Incomplete Messages
1634
1635   Request messages that are prematurely terminated, possibly due to a
1636   cancelled connection or a server-imposed time-out exception, MUST
1637   result in closure of the connection; sending an HTTP/1.1 error
1638   response prior to closing the connection is OPTIONAL.
1639
1640   Response messages that are prematurely terminated, usually by closure
1641   of the connection prior to receiving the expected number of octets or
1642   by failure to decode a transfer-encoded message-body, MUST be
1643   recorded as incomplete.  A response that terminates in the middle of
1644   the header block (before the empty line is received) cannot be
1645   assumed to convey the full semantics of the response and MUST be
1646   treated as an error.
1647
1648   A message-body that uses the chunked transfer encoding is incomplete
1649   if the zero-sized chunk that terminates the encoding has not been
1650   received.  A message that uses a valid Content-Length is incomplete
1651   if the size of the message-body received (in octets) is less than the
1652   value given by Content-Length.  A response that has neither chunked
1653   transfer encoding nor Content-Length is terminated by closure of the
1654   connection, and thus is considered complete regardless of the number
1655   of message-body octets received, provided that the header block was
1656   received intact.
1657
1658   A user agent MUST NOT render an incomplete response message-body as
1659   if it were complete (i.e., some indication must be given to the user
1660   that an error occurred).  Cache requirements for incomplete responses
1661   are defined in Section 2.1 of [Part6].
1662
1663   A server MUST read the entire request message-body or close the
1664   connection after sending its response, since otherwise the remaining
1665   data on a persistent connection would be misinterpreted as the next
1666   request.  Likewise, a client MUST read the entire response message-
1667   body if it intends to reuse the same connection for a subsequent
1668   request.  Pipelining multiple requests on a connection is described
1669   in Section 6.1.2.2.
1670
16713.5.  Message Parsing Robustness
1672
1673   Older HTTP/1.0 client implementations might send an extra CRLF after
1674   a POST request as a lame workaround for some early server
1675   applications that failed to read message-body content that was not
1676
1677
1678
1679Fielding, et al.           Expires May 3, 2012                 [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1                October 2011
1682
1683
1684   terminated by a line-ending.  An HTTP/1.1 client MUST NOT preface or
1685   follow a request with an extra CRLF.  If terminating the request
1686   message-body with a line-ending is desired, then the client MUST
1687   include the terminating CRLF octets as part of the message-body
1688   length.
1689
1690   In the interest of robustness, servers SHOULD ignore at least one
1691   empty line received where a Request-Line is expected.  In other
1692   words, if the server is reading the protocol stream at the beginning
1693   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
1694   Likewise, although the line terminator for the start-line and header
1695   fields is the sequence CRLF, we recommend that recipients recognize a
1696   single LF as a line terminator and ignore any CR.
1697
1698   When a server listening only for HTTP request messages, or processing
1699   what appears from the start-line to be an HTTP request message,
1700   receives a sequence of octets that does not match the HTTP-message
1701   grammar aside from the robustness exceptions listed above, the server
1702   MUST respond with an HTTP/1.1 400 (Bad Request) response.
1703
17044.  Message Routing
1705
1706   In most cases, the user agent is provided a URI reference from which
1707   it determines an absolute URI for identifying the target resource.
1708   When a request to the resource is initiated, all or part of that URI
1709   is used to construct the HTTP request-target.
1710
17114.1.  Types of Request Target
1712
1713   The four options for request-target are dependent on the nature of
1714   the request.
1715
1716   The asterisk "*" form of request-target, which MUST NOT be used with
1717   any request method other than OPTIONS, means that the request applies
1718   to the server as a whole (the listening process) rather than to a
1719   specific named resource at that server.  For example,
1720
1721     OPTIONS * HTTP/1.1
1722
1723   The "absolute-URI" form is REQUIRED when the request is being made to
1724   a proxy.  The proxy is requested to either forward the request or
1725   service it from a valid cache, and then return the response.  Note
1726   that the proxy MAY forward the request on to another proxy or
1727   directly to the server specified by the absolute-URI.  In order to
1728   avoid request loops, a proxy that forwards requests to other proxies
1729   MUST be able to recognize and exclude all of its own server names,
1730   including any aliases, local variations, and the numeric IP address.
1731   An example Request-Line would be:
1732
1733
1734
1735Fielding, et al.           Expires May 3, 2012                 [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1                October 2011
1738
1739
1740     GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1741
1742   To allow for transition to absolute-URIs in all requests in future
1743   versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1744   form in requests, even though HTTP/1.1 clients will only generate
1745   them in requests to proxies.
1746
1747   If a proxy receives a host name that is not a fully qualified domain
1748   name, it MAY add its domain to the host name it received.  If a proxy
1749   receives a fully qualified domain name, the proxy MUST NOT change the
1750   host name.
1751
1752   The "authority form" is only used by the CONNECT request method
1753   (Section 6.9 of [Part2]).
1754
1755   The most common form of request-target is that used when making a
1756   request to an origin server ("origin form").  In this case, the
1757   absolute path and query components of the URI MUST be transmitted as
1758   the request-target, and the authority component MUST be transmitted
1759   in a Host header field.  For example, a client wishing to retrieve a
1760   representation of the resource, as identified above, directly from
1761   the origin server would open (or reuse) a TCP connection to port 80
1762   of the host "www.example.org" and send the lines:
1763
1764     GET /pub/WWW/TheProject.html HTTP/1.1
1765     Host: www.example.org
1766
1767   followed by the remainder of the Request.  Note that the origin form
1768   of request-target always starts with an absolute path; if the target
1769   resource's URI path is empty, then an absolute path of "/" MUST be
1770   provided in the request-target.
1771
1772   If a proxy receives an OPTIONS request with an absolute-URI form of
1773   request-target in which the URI has an empty path and no query
1774   component, then the last proxy on the request chain MUST use a
1775   request-target of "*" when it forwards the request to the indicated
1776   origin server.
1777
1778   For example, the request
1779
1780     OPTIONS http://www.example.org:8001 HTTP/1.1
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791Fielding, et al.           Expires May 3, 2012                 [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1                October 2011
1794
1795
1796   would be forwarded by the final proxy as
1797
1798     OPTIONS * HTTP/1.1
1799     Host: www.example.org:8001
1800
1801   after connecting to port 8001 of host "www.example.org".
1802
1803   The request-target is transmitted in the format specified in
1804   Section 2.7.1.  If the request-target is percent-encoded ([RFC3986],
1805   Section 2.1), the origin server MUST decode the request-target in
1806   order to properly interpret the request.  Servers SHOULD respond to
1807   invalid request-targets with an appropriate status code.
1808
1809   A non-transforming proxy MUST NOT rewrite the "path-absolute" part of
1810   the received request-target when forwarding it to the next inbound
1811   server, except as noted above to replace a null path-absolute with
1812   "/" or "*".
1813
1814      Note: The "no rewrite" rule prevents the proxy from changing the
1815      meaning of the request when the origin server is improperly using
1816      a non-reserved URI character for a reserved purpose.  Implementors
1817      need to be aware that some pre-HTTP/1.1 proxies have been known to
1818      rewrite the request-target.
1819
18204.2.  The Resource Identified by a Request
1821
1822   The exact resource identified by an Internet request is determined by
1823   examining both the request-target and the Host header field.
1824
1825   An origin server that does not allow resources to differ by the
1826   requested host MAY ignore the Host header field value when
1827   determining the resource identified by an HTTP/1.1 request.  (But see
1828   Appendix A.1.1 for other requirements on Host support in HTTP/1.1.)
1829
1830   An origin server that does differentiate resources based on the host
1831   requested (sometimes referred to as virtual hosts or vanity host
1832   names) MUST use the following rules for determining the requested
1833   resource on an HTTP/1.1 request:
1834
1835   1.  If request-target is an absolute-URI, the host is part of the
1836       request-target.  Any Host header field value in the request MUST
1837       be ignored.
1838
1839   2.  If the request-target is not an absolute-URI, and the request
1840       includes a Host header field, the host is determined by the Host
1841       header field value.
1842
1843
1844
1845
1846
1847Fielding, et al.           Expires May 3, 2012                 [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1                October 2011
1850
1851
1852   3.  If the host as determined by rule 1 or 2 is not a valid host on
1853       the server, the response MUST be a 400 (Bad Request) error
1854       message.
1855
1856   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1857   attempt to use heuristics (e.g., examination of the URI path for
1858   something unique to a particular host) in order to determine what
1859   exact resource is being requested.
1860
18614.3.  Effective Request URI
1862
1863   HTTP requests often do not carry the absolute URI ([RFC3986], Section
1864   4.3) for the target resource; instead, the URI needs to be inferred
1865   from the request-target, Host header field, and connection context.
1866   The result of this process is called the "effective request URI".
1867   The "target resource" is the resource identified by the effective
1868   request URI.
1869
1870   If the request-target is an absolute-URI, then the effective request
1871   URI is the request-target.
1872
1873   If the request-target uses the path-absolute form or the asterisk
1874   form, and the Host header field is present, then the effective
1875   request URI is constructed by concatenating
1876
1877   o  the scheme name: "http" if the request was received over an
1878      insecure TCP connection, or "https" when received over a SSL/
1879      TLS-secured TCP connection,
1880
1881   o  the octet sequence "://",
1882
1883   o  the authority component, as specified in the Host header field
1884      (Section 8.3), and
1885
1886   o  the request-target obtained from the Request-Line, unless the
1887      request-target is just the asterisk "*".
1888
1889   If the request-target uses the path-absolute form or the asterisk
1890   form, and the Host header field is not present, then the effective
1891   request URI is undefined.
1892
1893   Otherwise, when request-target uses the authority form, the effective
1894   request URI is undefined.
1895
1896
1897
1898
1899
1900
1901
1902
1903Fielding, et al.           Expires May 3, 2012                 [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1                October 2011
1906
1907
1908   Example 1: the effective request URI for the message
1909
1910     GET /pub/WWW/TheProject.html HTTP/1.1
1911     Host: www.example.org:8080
1912
1913   (received over an insecure TCP connection) is "http", plus "://",
1914   plus the authority component "www.example.org:8080", plus the
1915   request-target "/pub/WWW/TheProject.html", thus
1916   "http://www.example.org:8080/pub/WWW/TheProject.html".
1917
1918   Example 2: the effective request URI for the message
1919
1920     OPTIONS * HTTP/1.1
1921     Host: www.example.org
1922
1923   (received over an SSL/TLS secured TCP connection) is "https", plus
1924   "://", plus the authority component "www.example.org", thus
1925   "https://www.example.org".
1926
1927   Effective request URIs are compared using the rules described in
1928   Section 2.7.3, except that empty path components MUST NOT be treated
1929   as equivalent to an absolute path of "/".
1930
19315.  Protocol Parameters
1932
19335.1.  Transfer Codings
1934
1935   Transfer-coding values are used to indicate an encoding
1936   transformation that has been, can be, or might need to be applied to
1937   a payload body in order to ensure "safe transport" through the
1938   network.  This differs from a content coding in that the transfer-
1939   coding is a property of the message rather than a property of the
1940   representation that is being transferred.
1941
1942     transfer-coding         = "chunked" ; Section 5.1.1
1943                             / "compress" ; Section 5.1.2.1
1944                             / "deflate" ; Section 5.1.2.2
1945                             / "gzip" ; Section 5.1.2.3
1946                             / transfer-extension
1947     transfer-extension      = token *( OWS ";" OWS transfer-parameter )
1948
1949   Parameters are in the form of attribute/value pairs.
1950
1951     transfer-parameter      = attribute BWS "=" BWS value
1952     attribute               = token
1953     value                   = word
1954
1955   All transfer-coding values are case-insensitive.  HTTP/1.1 uses
1956
1957
1958
1959Fielding, et al.           Expires May 3, 2012                 [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1                October 2011
1962
1963
1964   transfer-coding values in the TE header field (Section 8.4) and in
1965   the Transfer-Encoding header field (Section 8.6).
1966
1967   Transfer-codings are analogous to the Content-Transfer-Encoding
1968   values of MIME, which were designed to enable safe transport of
1969   binary data over a 7-bit transport service ([RFC2045], Section 6).
1970   However, safe transport has a different focus for an 8bit-clean
1971   transfer protocol.  In HTTP, the only unsafe characteristic of
1972   message-bodies is the difficulty in determining the exact message
1973   body length (Section 3.3), or the desire to encrypt data over a
1974   shared transport.
1975
1976   A server that receives a request message with a transfer-coding it
1977   does not understand SHOULD respond with 501 (Not Implemented) and
1978   then close the connection.  A server MUST NOT send transfer-codings
1979   to an HTTP/1.0 client.
1980
19815.1.1.  Chunked Transfer Coding
1982
1983   The chunked encoding modifies the body of a message in order to
1984   transfer it as a series of chunks, each with its own size indicator,
1985   followed by an OPTIONAL trailer containing header fields.  This
1986   allows dynamically produced content to be transferred along with the
1987   information necessary for the recipient to verify that it has
1988   received the full message.
1989
1990     Chunked-Body   = *chunk
1991                      last-chunk
1992                      trailer-part
1993                      CRLF
1994
1995     chunk          = chunk-size [ chunk-ext ] CRLF
1996                      chunk-data CRLF
1997     chunk-size     = 1*HEXDIG
1998     last-chunk     = 1*("0") [ chunk-ext ] CRLF
1999
2000     chunk-ext      = *( ";" chunk-ext-name
2001                         [ "=" chunk-ext-val ] )
2002     chunk-ext-name = token
2003     chunk-ext-val  = token / quoted-str-nf
2004     chunk-data     = 1*OCTET ; a sequence of chunk-size octets
2005     trailer-part   = *( header-field CRLF )
2006
2007     quoted-str-nf  = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
2008                    ; like quoted-string, but disallowing line folding
2009     qdtext-nf      = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
2010
2011   The chunk-size field is a string of hex digits indicating the size of
2012
2013
2014
2015Fielding, et al.           Expires May 3, 2012                 [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1                October 2011
2018
2019
2020   the chunk-data in octets.  The chunked encoding is ended by any chunk
2021   whose size is zero, followed by the trailer, which is terminated by
2022   an empty line.
2023
2024   The trailer allows the sender to include additional HTTP header
2025   fields at the end of the message.  The Trailer header field can be
2026   used to indicate which header fields are included in a trailer (see
2027   Section 8.5).
2028
2029   A server using chunked transfer-coding in a response MUST NOT use the
2030   trailer for any header fields unless at least one of the following is
2031   true:
2032
2033   1.  the request included a TE header field that indicates "trailers"
2034       is acceptable in the transfer-coding of the response, as
2035       described in Section 8.4; or,
2036
2037   2.  the trailer fields consist entirely of optional metadata, and the
2038       recipient could use the message (in a manner acceptable to the
2039       server where the field originated) without receiving it.  In
2040       other words, the server that generated the header (often but not
2041       always the origin server) is willing to accept the possibility
2042       that the trailer fields might be silently discarded along the
2043       path to the client.
2044
2045   This requirement prevents an interoperability failure when the
2046   message is being received by an HTTP/1.1 (or later) proxy and
2047   forwarded to an HTTP/1.0 recipient.  It avoids a situation where
2048   compliance with the protocol would have necessitated a possibly
2049   infinite buffer on the proxy.
2050
2051   A process for decoding the "chunked" transfer-coding can be
2052   represented in pseudo-code as:
2053
2054     length := 0
2055     read chunk-size, chunk-ext (if any) and CRLF
2056     while (chunk-size > 0) {
2057        read chunk-data and CRLF
2058        append chunk-data to decoded-body
2059        length := length + chunk-size
2060        read chunk-size and CRLF
2061     }
2062     read header-field
2063     while (header-field not empty) {
2064        append header-field to existing header fields
2065        read header-field
2066     }
2067     Content-Length := length
2068
2069
2070
2071Fielding, et al.           Expires May 3, 2012                 [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1                October 2011
2074
2075
2076     Remove "chunked" from Transfer-Encoding
2077
2078   All HTTP/1.1 applications MUST be able to receive and decode the
2079   "chunked" transfer-coding and MUST ignore chunk-ext extensions they
2080   do not understand.
2081
2082   Since "chunked" is the only transfer-coding required to be understood
2083   by HTTP/1.1 recipients, it plays a crucial role in delimiting
2084   messages on a persistent connection.  Whenever a transfer-coding is
2085   applied to a payload body in a request, the final transfer-coding
2086   applied MUST be "chunked".  If a transfer-coding is applied to a
2087   response payload body, then either the final transfer-coding applied
2088   MUST be "chunked" or the message MUST be terminated by closing the
2089   connection.  When the "chunked" transfer-coding is used, it MUST be
2090   the last transfer-coding applied to form the message-body.  The
2091   "chunked" transfer-coding MUST NOT be applied more than once in a
2092   message-body.
2093
20945.1.2.  Compression Codings
2095
2096   The codings defined below can be used to compress the payload of a
2097   message.
2098
2099      Note: Use of program names for the identification of encoding
2100      formats is not desirable and is discouraged for future encodings.
2101      Their use here is representative of historical practice, not good
2102      design.
2103
2104      Note: For compatibility with previous implementations of HTTP,
2105      applications SHOULD consider "x-gzip" and "x-compress" to be
2106      equivalent to "gzip" and "compress" respectively.
2107
21085.1.2.1.  Compress Coding
2109
2110   The "compress" format is produced by the common UNIX file compression
2111   program "compress".  This format is an adaptive Lempel-Ziv-Welch
2112   coding (LZW).
2113
21145.1.2.2.  Deflate Coding
2115
2116   The "deflate" format is defined as the "deflate" compression
2117   mechanism (described in [RFC1951]) used inside the "zlib" data format
2118   ([RFC1950]).
2119
2120      Note: Some incorrect implementations send the "deflate" compressed
2121      data without the zlib wrapper.
2122
2123
2124
2125
2126
2127Fielding, et al.           Expires May 3, 2012                 [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1                October 2011
2130
2131
21325.1.2.3.  Gzip Coding
2133
2134   The "gzip" format is produced by the file compression program "gzip"
2135   (GNU zip), as described in [RFC1952].  This format is a Lempel-Ziv
2136   coding (LZ77) with a 32 bit CRC.
2137
21385.1.3.  Transfer Coding Registry
2139
2140   The HTTP Transfer Coding Registry defines the name space for the
2141   transfer coding names.
2142
2143   Registrations MUST include the following fields:
2144
2145   o  Name
2146
2147   o  Description
2148
2149   o  Pointer to specification text
2150
2151   Names of transfer codings MUST NOT overlap with names of content
2152   codings (Section 2.2 of [Part3]), unless the encoding transformation
2153   is identical (as it is the case for the compression codings defined
2154   in Section 5.1.2).
2155
2156   Values to be added to this name space require a specification (see
2157   "Specification Required" in Section 4.1 of [RFC5226]), and MUST
2158   conform to the purpose of transfer coding defined in this section.
2159
2160   The registry itself is maintained at
2161   <http://www.iana.org/assignments/http-parameters>.
2162
21635.2.  Product Tokens
2164
2165   Product tokens are used to allow communicating applications to
2166   identify themselves by software name and version.  Most fields using
2167   product tokens also allow sub-products which form a significant part
2168   of the application to be listed, separated by whitespace.  By
2169   convention, the products are listed in order of their significance
2170   for identifying the application.
2171
2172     product         = token ["/" product-version]
2173     product-version = token
2174
2175   Examples:
2176
2177     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2178     Server: Apache/0.8.4
2179
2180
2181
2182
2183Fielding, et al.           Expires May 3, 2012                 [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1                October 2011
2186
2187
2188   Product tokens SHOULD be short and to the point.  They MUST NOT be
2189   used for advertising or other non-essential information.  Although
2190   any token octet MAY appear in a product-version, this token SHOULD
2191   only be used for a version identifier (i.e., successive versions of
2192   the same product SHOULD only differ in the product-version portion of
2193   the product value).
2194
21955.3.  Quality Values
2196
2197   Both transfer codings (TE request header field, Section 8.4) and
2198   content negotiation (Section 5 of [Part3]) use short "floating point"
2199   numbers to indicate the relative importance ("weight") of various
2200   negotiable parameters.  A weight is normalized to a real number in
2201   the range 0 through 1, where 0 is the minimum and 1 the maximum
2202   value.  If a parameter has a quality value of 0, then content with
2203   this parameter is "not acceptable" for the client.  HTTP/1.1
2204   applications MUST NOT generate more than three digits after the
2205   decimal point.  User configuration of these values SHOULD also be
2206   limited in this fashion.
2207
2208     qvalue         = ( "0" [ "." 0*3DIGIT ] )
2209                    / ( "1" [ "." 0*3("0") ] )
2210
2211      Note: "Quality values" is a misnomer, since these values merely
2212      represent relative degradation in desired quality.
2213
22146.  Connections
2215
22166.1.  Persistent Connections
2217
22186.1.1.  Purpose
2219
2220   Prior to persistent connections, a separate TCP connection was
2221   established for each request, increasing the load on HTTP servers and
2222   causing congestion on the Internet.  The use of inline images and
2223   other associated data often requires a client to make multiple
2224   requests of the same server in a short amount of time.  Analysis of
2225   these performance problems and results from a prototype
2226   implementation are available [Pad1995] [Spe].  Implementation
2227   experience and measurements of actual HTTP/1.1 implementations show
2228   good results [Nie1997].  Alternatives have also been explored, for
2229   example, T/TCP [Tou1998].
2230
2231   Persistent HTTP connections have a number of advantages:
2232
2233   o  By opening and closing fewer TCP connections, CPU time is saved in
2234      routers and hosts (clients, servers, proxies, gateways, tunnels,
2235      or caches), and memory used for TCP protocol control blocks can be
2236
2237
2238
2239Fielding, et al.           Expires May 3, 2012                 [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1                October 2011
2242
2243
2244      saved in hosts.
2245
2246   o  HTTP requests and responses can be pipelined on a connection.
2247      Pipelining allows a client to make multiple requests without
2248      waiting for each response, allowing a single TCP connection to be
2249      used much more efficiently, with much lower elapsed time.
2250
2251   o  Network congestion is reduced by reducing the number of packets
2252      caused by TCP opens, and by allowing TCP sufficient time to
2253      determine the congestion state of the network.
2254
2255   o  Latency on subsequent requests is reduced since there is no time
2256      spent in TCP's connection opening handshake.
2257
2258   o  HTTP can evolve more gracefully, since errors can be reported
2259      without the penalty of closing the TCP connection.  Clients using
2260      future versions of HTTP might optimistically try a new feature,
2261      but if communicating with an older server, retry with old
2262      semantics after an error is reported.
2263
2264   HTTP implementations SHOULD implement persistent connections.
2265
22666.1.2.  Overall Operation
2267
2268   A significant difference between HTTP/1.1 and earlier versions of
2269   HTTP is that persistent connections are the default behavior of any
2270   HTTP connection.  That is, unless otherwise indicated, the client
2271   SHOULD assume that the server will maintain a persistent connection,
2272   even after error responses from the server.
2273
2274   Persistent connections provide a mechanism by which a client and a
2275   server can signal the close of a TCP connection.  This signaling
2276   takes place using the Connection header field (Section 8.1).  Once a
2277   close has been signaled, the client MUST NOT send any more requests
2278   on that connection.
2279
22806.1.2.1.  Negotiation
2281
2282   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2283   maintain a persistent connection unless a Connection header field
2284   including the connection-token "close" was sent in the request.  If
2285   the server chooses to close the connection immediately after sending
2286   the response, it SHOULD send a Connection header field including the
2287   connection-token "close".
2288
2289   An HTTP/1.1 client MAY expect a connection to remain open, but would
2290   decide to keep it open based on whether the response from a server
2291   contains a Connection header field with the connection-token close.
2292
2293
2294
2295Fielding, et al.           Expires May 3, 2012                 [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1                October 2011
2298
2299
2300   In case the client does not want to maintain a connection for more
2301   than that request, it SHOULD send a Connection header field including
2302   the connection-token close.
2303
2304   If either the client or the server sends the close token in the
2305   Connection header field, that request becomes the last one for the
2306   connection.
2307
2308   Clients and servers SHOULD NOT assume that a persistent connection is
2309   maintained for HTTP versions less than 1.1 unless it is explicitly
2310   signaled.  See Appendix A.1.2 for more information on backward
2311   compatibility with HTTP/1.0 clients.
2312
2313   In order to remain persistent, all messages on the connection MUST
2314   have a self-defined message length (i.e., one not defined by closure
2315   of the connection), as described in Section 3.3.
2316
23176.1.2.2.  Pipelining
2318
2319   A client that supports persistent connections MAY "pipeline" its
2320   requests (i.e., send multiple requests without waiting for each
2321   response).  A server MUST send its responses to those requests in the
2322   same order that the requests were received.
2323
2324   Clients which assume persistent connections and pipeline immediately
2325   after connection establishment SHOULD be prepared to retry their
2326   connection if the first pipelined attempt fails.  If a client does
2327   such a retry, it MUST NOT pipeline before it knows the connection is
2328   persistent.  Clients MUST also be prepared to resend their requests
2329   if the server closes the connection before sending all of the
2330   corresponding responses.
2331
2332   Clients SHOULD NOT pipeline requests using non-idempotent request
2333   methods or non-idempotent sequences of request methods (see Section
2334   6.1.2 of [Part2]).  Otherwise, a premature termination of the
2335   transport connection could lead to indeterminate results.  A client
2336   wishing to send a non-idempotent request SHOULD wait to send that
2337   request until it has received the response status line for the
2338   previous request.
2339
23406.1.3.  Proxy Servers
2341
2342   It is especially important that proxies correctly implement the
2343   properties of the Connection header field as specified in
2344   Section 8.1.
2345
2346   The proxy server MUST signal persistent connections separately with
2347   its clients and the origin servers (or other proxy servers) that it
2348
2349
2350
2351Fielding, et al.           Expires May 3, 2012                 [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1                October 2011
2354
2355
2356   connects to.  Each persistent connection applies to only one
2357   transport link.
2358
2359   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2360   with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
2361   information and discussion of the problems with the Keep-Alive header
2362   field implemented by many HTTP/1.0 clients).
2363
23646.1.3.1.  End-to-end and Hop-by-hop Header Fields
2365
2366   For the purpose of defining the behavior of caches and non-caching
2367   proxies, we divide HTTP header fields into two categories:
2368
2369   o  End-to-end header fields, which are transmitted to the ultimate
2370      recipient of a request or response.  End-to-end header fields in
2371      responses MUST be stored as part of a cache entry and MUST be
2372      transmitted in any response formed from a cache entry.
2373
2374   o  Hop-by-hop header fields, which are meaningful only for a single
2375      transport-level connection, and are not stored by caches or
2376      forwarded by proxies.
2377
2378   The following HTTP/1.1 header fields are hop-by-hop header fields:
2379
2380   o  Connection
2381
2382   o  Keep-Alive
2383
2384   o  Proxy-Authenticate
2385
2386   o  Proxy-Authorization
2387
2388   o  TE
2389
2390   o  Trailer
2391
2392   o  Transfer-Encoding
2393
2394   o  Upgrade
2395
2396   All other header fields defined by HTTP/1.1 are end-to-end header
2397   fields.
2398
2399   Other hop-by-hop header fields MUST be listed in a Connection header
2400   field (Section 8.1).
2401
2402
2403
2404
2405
2406
2407Fielding, et al.           Expires May 3, 2012                 [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1                October 2011
2410
2411
24126.1.3.2.  Non-modifiable Header Fields
2413
2414   Some features of HTTP/1.1, such as Digest Authentication, depend on
2415   the value of certain end-to-end header fields.  A non-transforming
2416   proxy SHOULD NOT modify an end-to-end header field unless the
2417   definition of that header field requires or specifically allows that.
2418
2419   A non-transforming proxy MUST NOT modify any of the following fields
2420   in a request or response, and it MUST NOT add any of these fields if
2421   not already present:
2422
2423   o  Allow
2424
2425   o  Content-Location
2426
2427   o  Content-MD5
2428
2429   o  ETag
2430
2431   o  Last-Modified
2432
2433   o  Server
2434
2435   A non-transforming proxy MUST NOT modify any of the following fields
2436   in a response:
2437
2438   o  Expires
2439
2440   but it MAY add any of these fields if not already present.  If an
2441   Expires header field is added, it MUST be given a field-value
2442   identical to that of the Date header field in that response.
2443
2444   A proxy MUST NOT modify or add any of the following fields in a
2445   message that contains the no-transform cache-control directive, or in
2446   any request:
2447
2448   o  Content-Encoding
2449
2450   o  Content-Range
2451
2452   o  Content-Type
2453
2454   A transforming proxy MAY modify or add these fields to a message that
2455   does not include no-transform, but if it does so, it MUST add a
2456   Warning 214 (Transformation applied) if one does not already appear
2457   in the message (see Section 3.6 of [Part6]).
2458
2459
2460
2461
2462
2463Fielding, et al.           Expires May 3, 2012                 [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1                October 2011
2466
2467
2468      Warning: Unnecessary modification of end-to-end header fields
2469      might cause authentication failures if stronger authentication
2470      mechanisms are introduced in later versions of HTTP.  Such
2471      authentication mechanisms MAY rely on the values of header fields
2472      not listed here.
2473
2474   A non-transforming proxy MUST preserve the message payload ([Part3]),
2475   though it MAY change the message-body through application or removal
2476   of a transfer-coding (Section 5.1).
2477
24786.1.4.  Practical Considerations
2479
2480   Servers will usually have some time-out value beyond which they will
2481   no longer maintain an inactive connection.  Proxy servers might make
2482   this a higher value since it is likely that the client will be making
2483   more connections through the same server.  The use of persistent
2484   connections places no requirements on the length (or existence) of
2485   this time-out for either the client or the server.
2486
2487   When a client or server wishes to time-out it SHOULD issue a graceful
2488   close on the transport connection.  Clients and servers SHOULD both
2489   constantly watch for the other side of the transport close, and
2490   respond to it as appropriate.  If a client or server does not detect
2491   the other side's close promptly it could cause unnecessary resource
2492   drain on the network.
2493
2494   A client, server, or proxy MAY close the transport connection at any
2495   time.  For example, a client might have started to send a new request
2496   at the same time that the server has decided to close the "idle"
2497   connection.  From the server's point of view, the connection is being
2498   closed while it was idle, but from the client's point of view, a
2499   request is in progress.
2500
2501   Clients (including proxies) SHOULD limit the number of simultaneous
2502   connections that they maintain to a given server (including proxies).
2503
2504   Previous revisions of HTTP gave a specific number of connections as a
2505   ceiling, but this was found to be impractical for many applications.
2506   As a result, this specification does not mandate a particular maximum
2507   number of connections, but instead encourages clients to be
2508   conservative when opening multiple connections.
2509
2510   In particular, while using multiple connections avoids the "head-of-
2511   line blocking" problem (whereby a request that takes significant
2512   server-side processing and/or has a large payload can block
2513   subsequent requests on the same connection), each connection used
2514   consumes server resources (sometimes significantly), and furthermore
2515   using multiple connections can cause undesirable side effects in
2516
2517
2518
2519Fielding, et al.           Expires May 3, 2012                 [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1                October 2011
2522
2523
2524   congested networks.
2525
2526   Note that servers might reject traffic that they deem abusive,
2527   including an excessive number of connections from a client.
2528
25296.1.5.  Retrying Requests
2530
2531   Senders can close the transport connection at any time.  Therefore,
2532   clients, servers, and proxies MUST be able to recover from
2533   asynchronous close events.  Client software MAY reopen the transport
2534   connection and retransmit the aborted sequence of requests without
2535   user interaction so long as the request sequence is idempotent (see
2536   Section 6.1.2 of [Part2]).  Non-idempotent request methods or
2537   sequences MUST NOT be automatically retried, although user agents MAY
2538   offer a human operator the choice of retrying the request(s).
2539   Confirmation by user-agent software with semantic understanding of
2540   the application MAY substitute for user confirmation.  The automatic
2541   retry SHOULD NOT be repeated if the second sequence of requests
2542   fails.
2543
25446.2.  Message Transmission Requirements
2545
25466.2.1.  Persistent Connections and Flow Control
2547
2548   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2549   flow control mechanisms to resolve temporary overloads, rather than
2550   terminating connections with the expectation that clients will retry.
2551   The latter technique can exacerbate network congestion.
2552
25536.2.2.  Monitoring Connections for Error Status Messages
2554
2555   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2556   the network connection for an error status code while it is
2557   transmitting the request.  If the client sees an error status code,
2558   it SHOULD immediately cease transmitting the body.  If the body is
2559   being sent using a "chunked" encoding (Section 5.1), a zero length
2560   chunk and empty trailer MAY be used to prematurely mark the end of
2561   the message.  If the body was preceded by a Content-Length header
2562   field, the client MUST close the connection.
2563
25646.2.3.  Use of the 100 (Continue) Status
2565
2566   The purpose of the 100 (Continue) status code (see Section 7.1.1 of
2567   [Part2]) is to allow a client that is sending a request message with
2568   a request body to determine if the origin server is willing to accept
2569   the request (based on the request header fields) before the client
2570   sends the request body.  In some cases, it might either be
2571   inappropriate or highly inefficient for the client to send the body
2572
2573
2574
2575Fielding, et al.           Expires May 3, 2012                 [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1                October 2011
2578
2579
2580   if the server will reject the message without looking at the body.
2581
2582   Requirements for HTTP/1.1 clients:
2583
2584   o  If a client will wait for a 100 (Continue) response before sending
2585      the request body, it MUST send an Expect header field (Section 9.3
2586      of [Part2]) with the "100-continue" expectation.
2587
2588   o  A client MUST NOT send an Expect header field (Section 9.3 of
2589      [Part2]) with the "100-continue" expectation if it does not intend
2590      to send a request body.
2591
2592   Because of the presence of older implementations, the protocol allows
2593   ambiguous situations in which a client might send "Expect: 100-
2594   continue" without receiving either a 417 (Expectation Failed) or a
2595   100 (Continue) status code.  Therefore, when a client sends this
2596   header field to an origin server (possibly via a proxy) from which it
2597   has never seen a 100 (Continue) status code, the client SHOULD NOT
2598   wait for an indefinite period before sending the request body.
2599
2600   Requirements for HTTP/1.1 origin servers:
2601
2602   o  Upon receiving a request which includes an Expect header field
2603      with the "100-continue" expectation, an origin server MUST either
2604      respond with 100 (Continue) status code and continue to read from
2605      the input stream, or respond with a final status code.  The origin
2606      server MUST NOT wait for the request body before sending the 100
2607      (Continue) response.  If it responds with a final status code, it
2608      MAY close the transport connection or it MAY continue to read and
2609      discard the rest of the request.  It MUST NOT perform the request
2610      method if it returns a final status code.
2611
2612   o  An origin server SHOULD NOT send a 100 (Continue) response if the
2613      request message does not include an Expect header field with the
2614      "100-continue" expectation, and MUST NOT send a 100 (Continue)
2615      response if such a request comes from an HTTP/1.0 (or earlier)
2616      client.  There is an exception to this rule: for compatibility
2617      with [RFC2068], a server MAY send a 100 (Continue) status code in
2618      response to an HTTP/1.1 PUT or POST request that does not include
2619      an Expect header field with the "100-continue" expectation.  This
2620      exception, the purpose of which is to minimize any client
2621      processing delays associated with an undeclared wait for 100
2622      (Continue) status code, applies only to HTTP/1.1 requests, and not
2623      to requests with any other HTTP-version value.
2624
2625   o  An origin server MAY omit a 100 (Continue) response if it has
2626      already received some or all of the request body for the
2627      corresponding request.
2628
2629
2630
2631Fielding, et al.           Expires May 3, 2012                 [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1                October 2011
2634
2635
2636   o  An origin server that sends a 100 (Continue) response MUST
2637      ultimately send a final status code, once the request body is
2638      received and processed, unless it terminates the transport
2639      connection prematurely.
2640
2641   o  If an origin server receives a request that does not include an
2642      Expect header field with the "100-continue" expectation, the
2643      request includes a request body, and the server responds with a
2644      final status code before reading the entire request body from the
2645      transport connection, then the server SHOULD NOT close the
2646      transport connection until it has read the entire request, or
2647      until the client closes the connection.  Otherwise, the client
2648      might not reliably receive the response message.  However, this
2649      requirement is not be construed as preventing a server from
2650      defending itself against denial-of-service attacks, or from badly
2651      broken client implementations.
2652
2653   Requirements for HTTP/1.1 proxies:
2654
2655   o  If a proxy receives a request that includes an Expect header field
2656      with the "100-continue" expectation, and the proxy either knows
2657      that the next-hop server complies with HTTP/1.1 or higher, or does
2658      not know the HTTP version of the next-hop server, it MUST forward
2659      the request, including the Expect header field.
2660
2661   o  If the proxy knows that the version of the next-hop server is
2662      HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2663      respond with a 417 (Expectation Failed) status code.
2664
2665   o  Proxies SHOULD maintain a record of the HTTP version numbers
2666      received from recently-referenced next-hop servers.
2667
2668   o  A proxy MUST NOT forward a 100 (Continue) response if the request
2669      message was received from an HTTP/1.0 (or earlier) client and did
2670      not include an Expect header field with the "100-continue"
2671      expectation.  This requirement overrides the general rule for
2672      forwarding of 1xx responses (see Section 7.1 of [Part2]).
2673
26747.  Miscellaneous notes that might disappear
2675
26767.1.  Scheme aliases considered harmful
2677
2678   [[TBD-aliases-harmful: describe why aliases like webcal are
2679   harmful.]]
2680
2681
2682
2683
2684
2685
2686
2687Fielding, et al.           Expires May 3, 2012                 [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1                October 2011
2690
2691
26927.2.  Use of HTTP for proxy communication
2693
2694   [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
2695   protocols.]]
2696
26977.3.  Interception of HTTP for access control
2698
2699   [[TBD-intercept: Interception of HTTP traffic for initiating access
2700   control.]]
2701
27027.4.  Use of HTTP by other protocols
2703
2704   [[TBD-profiles: Profiles of HTTP defined by other protocol.
2705   Extensions of HTTP like WebDAV.]]
2706
27077.5.  Use of HTTP by media type specification
2708
2709   [[TBD-hypertext: Instructions on composing HTTP requests via
2710   hypertext formats.]]
2711
27128.  Header Field Definitions
2713
2714   This section defines the syntax and semantics of HTTP header fields
2715   related to message origination, framing, and routing.
2716
2717   +-------------------+---------------+
2718   | Header Field Name | Defined in... |
2719   +-------------------+---------------+
2720   | Connection        | Section 8.1   |
2721   | Content-Length    | Section 8.2   |
2722   | Host              | Section 8.3   |
2723   | TE                | Section 8.4   |
2724   | Trailer           | Section 8.5   |
2725   | Transfer-Encoding | Section 8.6   |
2726   | Upgrade           | Section 8.7   |
2727   | Via               | Section 8.8   |
2728   +-------------------+---------------+
2729
27308.1.  Connection
2731
2732   The "Connection" header field allows the sender to specify options
2733   that are desired only for that particular connection.  Such
2734   connection options MUST be removed or replaced before the message can
2735   be forwarded downstream by a proxy or gateway.  This mechanism also
2736   allows the sender to indicate which HTTP header fields used in the
2737   message are only intended for the immediate recipient ("hop-by-hop"),
2738   as opposed to all recipients on the chain ("end-to-end"), enabling
2739   the message to be self-descriptive and allowing future connection-
2740
2741
2742
2743Fielding, et al.           Expires May 3, 2012                 [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1                October 2011
2746
2747
2748   specific extensions to be deployed in HTTP without fear that they
2749   will be blindly forwarded by previously deployed intermediaries.
2750
2751   The Connection header field's value has the following grammar:
2752
2753     Connection       = 1#connection-token
2754     connection-token = token
2755
2756   A proxy or gateway MUST parse a received Connection header field
2757   before a message is forwarded and, for each connection-token in this
2758   field, remove any header field(s) from the message with the same name
2759   as the connection-token, and then remove the Connection header field
2760   itself or replace it with the sender's own connection options for the
2761   forwarded message.
2762
2763   A sender MUST NOT include field-names in the Connection header field-
2764   value for fields that are defined as expressing constraints for all
2765   recipients in the request or response chain, such as the Cache-
2766   Control header field (Section 3.2 of [Part6]).
2767
2768   The connection options do not have to correspond to a header field
2769   present in the message, since a connection-specific header field
2770   might not be needed if there are no parameters associated with that
2771   connection option.  Recipients that trigger certain connection
2772   behavior based on the presence of connection options MUST do so based
2773   on the presence of the connection-token rather than only the presence
2774   of the optional header field.  In other words, if the connection
2775   option is received as a header field but not indicated within the
2776   Connection field-value, then the recipient MUST ignore the
2777   connection-specific header field because it has likely been forwarded
2778   by an intermediary that is only partially compliant.
2779
2780   When defining new connection options, specifications ought to
2781   carefully consider existing deployed header fields and ensure that
2782   the new connection-token does not share the same name as an unrelated
2783   header field that might already be deployed.  Defining a new
2784   connection-token essentially reserves that potential field-name for
2785   carrying additional information related to the connection option,
2786   since it would be unwise for senders to use that field-name for
2787   anything else.
2788
2789   HTTP/1.1 defines the "close" connection option for the sender to
2790   signal that the connection will be closed after completion of the
2791   response.  For example,
2792
2793     Connection: close
2794
2795   in either the request or the response header fields indicates that
2796
2797
2798
2799Fielding, et al.           Expires May 3, 2012                 [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1                October 2011
2802
2803
2804   the connection SHOULD NOT be considered "persistent" (Section 6.1)
2805   after the current request/response is complete.
2806
2807   An HTTP/1.1 client that does not support persistent connections MUST
2808   include the "close" connection option in every request message.
2809
2810   An HTTP/1.1 server that does not support persistent connections MUST
2811   include the "close" connection option in every response message that
2812   does not have a 1xx (Informational) status code.
2813
28148.2.  Content-Length
2815
2816   The "Content-Length" header field indicates the size of the message-
2817   body, in decimal number of octets, for any message other than a
2818   response to a HEAD request or a response with a status code of 304.
2819   In the case of a response to a HEAD request, Content-Length indicates
2820   the size of the payload body (not including any potential transfer-
2821   coding) that would have been sent had the request been a GET.  In the
2822   case of a 304 (Not Modified) response to a GET request, Content-
2823   Length indicates the size of the payload body (not including any
2824   potential transfer-coding) that would have been sent in a 200 (OK)
2825   response.
2826
2827     Content-Length = 1*DIGIT
2828
2829   An example is
2830
2831     Content-Length: 3495
2832
2833   Implementations SHOULD use this field to indicate the message-body
2834   length when no transfer-coding is being applied and the payload's
2835   body length can be determined prior to being transferred.
2836   Section 3.3 describes how recipients determine the length of a
2837   message-body.
2838
2839   Any Content-Length greater than or equal to zero is a valid value.
2840
2841   Note that the use of this field in HTTP is significantly different
2842   from the corresponding definition in MIME, where it is an optional
2843   field used within the "message/external-body" content-type.
2844
28458.3.  Host
2846
2847   The "Host" header field in a request provides the host and port
2848   information from the target resource's URI, enabling the origin
2849   server to distinguish between resources while servicing requests for
2850   multiple host names on a single IP address.  Since the Host field-
2851   value is critical information for handling a request, it SHOULD be
2852
2853
2854
2855Fielding, et al.           Expires May 3, 2012                 [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1                October 2011
2858
2859
2860   sent as the first header field following the Request-Line.
2861
2862     Host = uri-host [ ":" port ] ; Section 2.7.1
2863
2864   A client MUST send a Host header field in all HTTP/1.1 request
2865   messages.  If the target resource's URI includes an authority
2866   component, then the Host field-value MUST be identical to that
2867   authority component after excluding any userinfo (Section 2.7.1).  If
2868   the authority component is missing or undefined for the target
2869   resource's URI, then the Host header field MUST be sent with an empty
2870   field-value.
2871
2872   For example, a GET request to the origin server for
2873   <http://www.example.org/pub/WWW/> would begin with:
2874
2875     GET /pub/WWW/ HTTP/1.1
2876     Host: www.example.org
2877
2878   The Host header field MUST be sent in an HTTP/1.1 request even if the
2879   request-target is in the form of an absolute-URI, since this allows
2880   the Host information to be forwarded through ancient HTTP/1.0 proxies
2881   that might not have implemented Host.
2882
2883   When an HTTP/1.1 proxy receives a request with a request-target in
2884   the form of an absolute-URI, the proxy MUST ignore the received Host
2885   header field (if any) and instead replace it with the host
2886   information of the request-target.  When a proxy forwards a request,
2887   it MUST generate the Host header field based on the received
2888   absolute-URI rather than the received Host.
2889
2890   Since the Host header field acts as an application-level routing
2891   mechanism, it is a frequent target for malware seeking to poison a
2892   shared cache or redirect a request to an unintended server.  An
2893   interception proxy is particularly vulnerable if it relies on the
2894   Host header field value for redirecting requests to internal servers,
2895   or for use as a cache key in a shared cache, without first verifying
2896   that the intercepted connection is targeting a valid IP address for
2897   that host.
2898
2899   A server MUST respond with a 400 (Bad Request) status code to any
2900   HTTP/1.1 request message that lacks a Host header field and to any
2901   request message that contains more than one Host header field or a
2902   Host header field with an invalid field-value.
2903
2904   See Sections 4.2 and A.1.1 for other requirements relating to Host.
2905
2906
2907
2908
2909
2910
2911Fielding, et al.           Expires May 3, 2012                 [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1                October 2011
2914
2915
29168.4.  TE
2917
2918   The "TE" header field indicates what extension transfer-codings it is
2919   willing to accept in the response, and whether or not it is willing
2920   to accept trailer fields in a chunked transfer-coding.
2921
2922   Its value consists of the keyword "trailers" and/or a comma-separated
2923   list of extension transfer-coding names with optional accept
2924   parameters (as described in Section 5.1).
2925
2926     TE        = #t-codings
2927     t-codings = "trailers" / ( transfer-extension [ te-params ] )
2928     te-params = OWS ";" OWS "q=" qvalue *( te-ext )
2929     te-ext    = OWS ";" OWS token [ "=" word ]
2930
2931   The presence of the keyword "trailers" indicates that the client is
2932   willing to accept trailer fields in a chunked transfer-coding, as
2933   defined in Section 5.1.1.  This keyword is reserved for use with
2934   transfer-coding values even though it does not itself represent a
2935   transfer-coding.
2936
2937   Examples of its use are:
2938
2939     TE: deflate
2940     TE:
2941     TE: trailers, deflate;q=0.5
2942
2943   The TE header field only applies to the immediate connection.
2944   Therefore, the keyword MUST be supplied within a Connection header
2945   field (Section 8.1) whenever TE is present in an HTTP/1.1 message.
2946
2947   A server tests whether a transfer-coding is acceptable, according to
2948   a TE field, using these rules:
2949
2950   1.  The "chunked" transfer-coding is always acceptable.  If the
2951       keyword "trailers" is listed, the client indicates that it is
2952       willing to accept trailer fields in the chunked response on
2953       behalf of itself and any downstream clients.  The implication is
2954       that, if given, the client is stating that either all downstream
2955       clients are willing to accept trailer fields in the forwarded
2956       response, or that it will attempt to buffer the response on
2957       behalf of downstream recipients.
2958
2959       Note: HTTP/1.1 does not define any means to limit the size of a
2960       chunked response such that a client can be assured of buffering
2961       the entire response.
2962
2963
2964
2965
2966
2967Fielding, et al.           Expires May 3, 2012                 [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1                October 2011
2970
2971
2972   2.  If the transfer-coding being tested is one of the transfer-
2973       codings listed in the TE field, then it is acceptable unless it
2974       is accompanied by a qvalue of 0.  (As defined in Section 5.3, a
2975       qvalue of 0 means "not acceptable".)
2976
2977   3.  If multiple transfer-codings are acceptable, then the acceptable
2978       transfer-coding with the highest non-zero qvalue is preferred.
2979       The "chunked" transfer-coding always has a qvalue of 1.
2980
2981   If the TE field-value is empty or if no TE field is present, the only
2982   transfer-coding is "chunked".  A message with no transfer-coding is
2983   always acceptable.
2984
29858.5.  Trailer
2986
2987   The "Trailer" header field indicates that the given set of header
2988   fields is present in the trailer of a message encoded with chunked
2989   transfer-coding.
2990
2991     Trailer = 1#field-name
2992
2993   An HTTP/1.1 message SHOULD include a Trailer header field in a
2994   message using chunked transfer-coding with a non-empty trailer.
2995   Doing so allows the recipient to know which header fields to expect
2996   in the trailer.
2997
2998   If no Trailer header field is present, the trailer SHOULD NOT include
2999   any header fields.  See Section 5.1.1 for restrictions on the use of
3000   trailer fields in a "chunked" transfer-coding.
3001
3002   Message header fields listed in the Trailer header field MUST NOT
3003   include the following header fields:
3004
3005   o  Transfer-Encoding
3006
3007   o  Content-Length
3008
3009   o  Trailer
3010
30118.6.  Transfer-Encoding
3012
3013   The "Transfer-Encoding" header field indicates what transfer-codings
3014   (if any) have been applied to the message body.  It differs from
3015   Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings
3016   are a property of the message (and therefore are removed by
3017   intermediaries), whereas content-codings are not.
3018
3019     Transfer-Encoding = 1#transfer-coding
3020
3021
3022
3023Fielding, et al.           Expires May 3, 2012                 [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1                October 2011
3026
3027
3028   Transfer-codings are defined in Section 5.1.  An example is:
3029
3030     Transfer-Encoding: chunked
3031
3032   If multiple encodings have been applied to a representation, the
3033   transfer-codings MUST be listed in the order in which they were
3034   applied.  Additional information about the encoding parameters MAY be
3035   provided by other header fields not defined by this specification.
3036
3037   Many older HTTP/1.0 applications do not understand the Transfer-
3038   Encoding header field.
3039
30408.7.  Upgrade
3041
3042   The "Upgrade" header field allows the client to specify what
3043   additional communication protocols it would like to use, if the
3044   server chooses to switch protocols.  Servers can use it to indicate
3045   what protocols they are willing to switch to.
3046
3047     Upgrade = 1#product
3048
3049   For example,
3050
3051     Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
3052
3053   The Upgrade header field is intended to provide a simple mechanism
3054   for transition from HTTP/1.1 to some other, incompatible protocol.
3055   It does so by allowing the client to advertise its desire to use
3056   another protocol, such as a later version of HTTP with a higher major
3057   version number, even though the current request has been made using
3058   HTTP/1.1.  This eases the difficult transition between incompatible
3059   protocols by allowing the client to initiate a request in the more
3060   commonly supported protocol while indicating to the server that it
3061   would like to use a "better" protocol if available (where "better" is
3062   determined by the server, possibly according to the nature of the
3063   request method or target resource).
3064
3065   The Upgrade header field only applies to switching application-layer
3066   protocols upon the existing transport-layer connection.  Upgrade
3067   cannot be used to insist on a protocol change; its acceptance and use
3068   by the server is optional.  The capabilities and nature of the
3069   application-layer communication after the protocol change is entirely
3070   dependent upon the new protocol chosen, although the first action
3071   after changing the protocol MUST be a response to the initial HTTP
3072   request containing the Upgrade header field.
3073
3074   The Upgrade header field only applies to the immediate connection.
3075   Therefore, the upgrade keyword MUST be supplied within a Connection
3076
3077
3078
3079Fielding, et al.           Expires May 3, 2012                 [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1                October 2011
3082
3083
3084   header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1
3085   message.
3086
3087   The Upgrade header field cannot be used to indicate a switch to a
3088   protocol on a different connection.  For that purpose, it is more
3089   appropriate to use a 3xx redirection response (Section 7.3 of
3090   [Part2]).
3091
3092   Servers MUST include the "Upgrade" header field in 101 (Switching
3093   Protocols) responses to indicate which protocol(s) are being switched
3094   to, and MUST include it in 426 (Upgrade Required) responses to
3095   indicate acceptable protocols to upgrade to.  Servers MAY include it
3096   in any other response to indicate that they are willing to upgrade to
3097   one of the specified protocols.
3098
3099   This specification only defines the protocol name "HTTP" for use by
3100   the family of Hypertext Transfer Protocols, as defined by the HTTP
3101   version rules of Section 2.6 and future updates to this
3102   specification.  Additional tokens can be registered with IANA using
3103   the registration procedure defined below.
3104
31058.7.1.  Upgrade Token Registry
3106
3107   The HTTP Upgrade Token Registry defines the name space for product
3108   tokens used to identify protocols in the Upgrade header field.  Each
3109   registered token is associated with contact information and an
3110   optional set of specifications that details how the connection will
3111   be processed after it has been upgraded.
3112
3113   Registrations are allowed on a First Come First Served basis as
3114   described in Section 4.1 of [RFC5226].  The specifications need not
3115   be IETF documents or be subject to IESG review.  Registrations are
3116   subject to the following rules:
3117
3118   1.  A token, once registered, stays registered forever.
3119
3120   2.  The registration MUST name a responsible party for the
3121       registration.
3122
3123   3.  The registration MUST name a point of contact.
3124
3125   4.  The registration MAY name a set of specifications associated with
3126       that token.  Such specifications need not be publicly available.
3127
3128   5.  The responsible party MAY change the registration at any time.
3129       The IANA will keep a record of all such changes, and make them
3130       available upon request.
3131
3132
3133
3134
3135Fielding, et al.           Expires May 3, 2012                 [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1                October 2011
3138
3139
3140   6.  The responsible party for the first registration of a "product"
3141       token MUST approve later registrations of a "version" token
3142       together with that "product" token before they can be registered.
3143
3144   7.  If absolutely required, the IESG MAY reassign the responsibility
3145       for a token.  This will normally only be used in the case when a
3146       responsible party cannot be contacted.
3147
31488.8.  Via
3149
3150   The "Via" header field MUST be sent by a proxy or gateway to indicate
3151   the intermediate protocols and recipients between the user agent and
3152   the server on requests, and between the origin server and the client
3153   on responses.  It is analogous to the "Received" field used by email
3154   systems (Section 3.6.7 of [RFC5322]) and is intended to be used for
3155   tracking message forwards, avoiding request loops, and identifying
3156   the protocol capabilities of all senders along the request/response
3157   chain.
3158
3159     Via               = 1#( received-protocol RWS received-by
3160                             [ RWS comment ] )
3161     received-protocol = [ protocol-name "/" ] protocol-version
3162     protocol-name     = token
3163     protocol-version  = token
3164     received-by       = ( uri-host [ ":" port ] ) / pseudonym
3165     pseudonym         = token
3166
3167   The received-protocol indicates the protocol version of the message
3168   received by the server or client along each segment of the request/
3169   response chain.  The received-protocol version is appended to the Via
3170   field value when the message is forwarded so that information about
3171   the protocol capabilities of upstream applications remains visible to
3172   all recipients.
3173
3174   The protocol-name is excluded if and only if it would be "HTTP".  The
3175   received-by field is normally the host and optional port number of a
3176   recipient server or client that subsequently forwarded the message.
3177   However, if the real host is considered to be sensitive information,
3178   it MAY be replaced by a pseudonym.  If the port is not given, it MAY
3179   be assumed to be the default port of the received-protocol.
3180
3181   Multiple Via field values represent each proxy or gateway that has
3182   forwarded the message.  Each recipient MUST append its information
3183   such that the end result is ordered according to the sequence of
3184   forwarding applications.
3185
3186   Comments MAY be used in the Via header field to identify the software
3187   of each recipient, analogous to the User-Agent and Server header
3188
3189
3190
3191Fielding, et al.           Expires May 3, 2012                 [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1                October 2011
3194
3195
3196   fields.  However, all comments in the Via field are optional and MAY
3197   be removed by any recipient prior to forwarding the message.
3198
3199   For example, a request message could be sent from an HTTP/1.0 user
3200   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
3201   forward the request to a public proxy at p.example.net, which
3202   completes the request by forwarding it to the origin server at
3203   www.example.com.  The request received by www.example.com would then
3204   have the following Via header field:
3205
3206     Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
3207
3208   A proxy or gateway used as a portal through a network firewall SHOULD
3209   NOT forward the names and ports of hosts within the firewall region
3210   unless it is explicitly enabled to do so.  If not enabled, the
3211   received-by host of any host behind the firewall SHOULD be replaced
3212   by an appropriate pseudonym for that host.
3213
3214   For organizations that have strong privacy requirements for hiding
3215   internal structures, a proxy or gateway MAY combine an ordered
3216   subsequence of Via header field entries with identical received-
3217   protocol values into a single such entry.  For example,
3218
3219     Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
3220
3221   could be collapsed to
3222
3223     Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
3224
3225   Senders SHOULD NOT combine multiple entries unless they are all under
3226   the same organizational control and the hosts have already been
3227   replaced by pseudonyms.  Senders MUST NOT combine entries which have
3228   different received-protocol values.
3229
32309.  IANA Considerations
3231
32329.1.  Header Field Registration
3233
3234   The Message Header Field Registry located at <http://www.iana.org/
3235   assignments/message-headers/message-header-index.html> shall be
3236   updated with the permanent registrations below (see [RFC3864]):
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247Fielding, et al.           Expires May 3, 2012                 [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1                October 2011
3250
3251
3252   +-------------------+----------+----------+-------------+
3253   | Header Field Name | Protocol | Status   | Reference   |
3254   +-------------------+----------+----------+-------------+
3255   | Connection        | http     | standard | Section 8.1 |
3256   | Content-Length    | http     | standard | Section 8.2 |
3257   | Host              | http     | standard | Section 8.3 |
3258   | TE                | http     | standard | Section 8.4 |
3259   | Trailer           | http     | standard | Section 8.5 |
3260   | Transfer-Encoding | http     | standard | Section 8.6 |
3261   | Upgrade           | http     | standard | Section 8.7 |
3262   | Via               | http     | standard | Section 8.8 |
3263   +-------------------+----------+----------+-------------+
3264
3265   Furthermore, the header field name "Close" shall be registered as
3266   "reserved", as its use as HTTP header field would be in conflict with
3267   the use of the "close" connection option for the "Connection" header
3268   field (Section 8.1).
3269
3270   +-------------------+----------+----------+-------------+
3271   | Header Field Name | Protocol | Status   | Reference   |
3272   +-------------------+----------+----------+-------------+
3273   | Close             | http     | reserved | Section 9.1 |
3274   +-------------------+----------+----------+-------------+
3275
3276   The change controller is: "IETF (iesg@ietf.org) - Internet
3277   Engineering Task Force".
3278
32799.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.7.1 and 2.7.2 of this document (see
3284   [RFC4395]).
3285
32869.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
32929.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 May 3, 2012                 [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1                October 2011
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 9.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 May 3, 2012                 [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1                October 2011
3362
3363
33649.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 9.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 May 3, 2012                 [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1                October 2011
3418
3419
3420   Restrictions on usage:  none
3421
3422   Author/Change controller:  IESG
3423
34249.4.  Transfer Coding Registry
3425
3426   The registration procedure for HTTP Transfer Codings is now defined
3427   by Section 5.1.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 5.1.1   |
3437   | compress | UNIX "compress" program method       | Section 5.1.2.1 |
3438   | deflate  | "deflate" compression mechanism      | Section 5.1.2.2 |
3439   |          | ([RFC1951]) used inside the "zlib"   |                 |
3440   |          | data format ([RFC1950])              |                 |
3441   | gzip     | Same as GNU zip [RFC1952]            | Section 5.1.2.3 |
3442   +----------+--------------------------------------+-----------------+
3443
34449.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 8.7.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.6 of this           |
3458   |       | Protocol                  | specification                 |
3459   +-------+---------------------------+-------------------------------+
3460
346110.  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 May 3, 2012                 [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1                October 2011
3474
3475
347610.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
348910.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
349910.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
351810.4.  DNS-related Attacks
3519
3520   HTTP clients rely heavily on the Domain Name Service (DNS), and are
3521   thus generally prone to security attacks based on the deliberate
3522   misassociation of IP addresses and DNS names not protected by DNSSec.
3523   Clients need to be cautious in assuming the validity of an IP number/
3524
3525
3526
3527Fielding, et al.           Expires May 3, 2012                 [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1                October 2011
3530
3531
3532   DNS name association unless the response is protected by DNSSec
3533   ([RFC4033]).
3534
353510.5.  Proxies and Caching
3536
3537   By their very nature, HTTP proxies are men-in-the-middle, and
3538   represent an opportunity for man-in-the-middle attacks.  Compromise
3539   of the systems on which the proxies run can result in serious
3540   security and privacy problems.  Proxies have access to security-
3541   related information, personal information about individual users and
3542   organizations, and proprietary information belonging to users and
3543   content providers.  A compromised proxy, or a proxy implemented or
3544   configured without regard to security and privacy considerations,
3545   might be used in the commission of a wide range of potential attacks.
3546
3547   Proxy operators need to protect the systems on which proxies run as
3548   they would protect any system that contains or transports sensitive
3549   information.  In particular, log information gathered at proxies
3550   often contains highly sensitive personal information, and/or
3551   information about organizations.  Log information needs to be
3552   carefully guarded, and appropriate guidelines for use need to be
3553   developed and followed.  (Section 10.2).
3554
3555   Proxy implementors need to consider the privacy and security
3556   implications of their design and coding decisions, and of the
3557   configuration options they provide to proxy operators (especially the
3558   default configuration).
3559
3560   Users of a proxy need to be aware that proxies are no trustworthier
3561   than the people who run them; HTTP itself cannot solve this problem.
3562
3563   The judicious use of cryptography, when appropriate, might suffice to
3564   protect against a broad range of security and privacy attacks.  Such
3565   cryptography is beyond the scope of the HTTP/1.1 specification.
3566
356710.6.  Protocol Element Size Overflows
3568
3569   Because HTTP uses mostly textual, character-delimited fields,
3570   attackers can overflow buffers in implementations, and/or perform a
3571   Denial of Service against implementations that accept fields with
3572   unlimited lengths.
3573
3574   To promote interoperability, this specification makes specific
3575   recommendations for size limits on request-targets (Section 3.1.1.2)
3576   and blocks of header fields (Section 3.2).  These are minimum
3577   recommendations, chosen to be supportable even by implementations
3578   with limited resources; it is expected that most implementations will
3579   choose substantially higher limits.
3580
3581
3582
3583Fielding, et al.           Expires May 3, 2012                 [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1                October 2011
3586
3587
3588   This specification also provides a way for servers to reject messages
3589   that have request-targets that are too long (Section 7.4.15 of
3590   [Part2]) or request entities that are too large (Section 7.4 of
3591   [Part2]).
3592
3593   Other fields (including but not limited to request methods, response
3594   status phrases, header field-names, and body chunks) SHOULD be
3595   limited by implementations carefully, so as to not impede
3596   interoperability.
3597
359810.7.  Denial of Service Attacks on Proxies
3599
3600   They exist.  They are hard to defend against.  Research continues.
3601   Beware.
3602
360311.  Acknowledgments
3604
3605   This document revision builds on the work that went into RFC 2616 and
3606   its predecessors.  See Section 16 of [RFC2616] for detailed
3607   acknowledgements.
3608
3609   Since 1999, many contributors have helped by reporting bugs, asking
3610   smart questions, drafting and reviewing text, and discussing open
3611   issues:
3612
3613   Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de
3614   Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey
3615   Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,
3616   Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,
3617   Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,
3618   Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob
3619   Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,
3620   Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry,
3621   Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel
3622   Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth,
3623   David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane
3624   Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams,
3625   Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank
3626   Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg
3627   Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
3628   Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas,
3629   Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James
3630   Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges
3631   (for coming up with the term 'effective Request-URI'), Jeff Walden,
3632   Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
3633   Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
3634   Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
3635   Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
3636
3637
3638
3639Fielding, et al.           Expires May 3, 2012                 [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1                October 2011
3642
3643
3644   Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
3645   Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
3646   Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
3647   Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
3648   (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,
3649   Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael
3650   Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,
3651   Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams,
3652   Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R.
3653   McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint-
3654   Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning
3655   Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak,
3656   Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson,
3657   Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy,
3658   Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam
3659   Ruby, Scott Lawrence (for maintaining the original issues list), Sean
3660   B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos
3661   Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju,
3662   Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin,
3663   Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close,
3664   Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo
3665   Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau,
3666   Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang,
3667   Yutaka Oiwa, and Zed A. Shaw.
3668
366912.  References
3670
367112.1.  Normative References
3672
3673   [ISO-8859-1]  International Organization for Standardization,
3674                 "Information technology -- 8-bit single-byte coded
3675                 graphic character sets -- Part 1: Latin alphabet No.
3676                 1", ISO/IEC 8859-1:1998, 1998.
3677
3678   [Part2]       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 2: Message
3681                 Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
3682                 progress), October 2011.
3683
3684   [Part3]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3685                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3686                 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
3687                 Payload and Content Negotiation",
3688                 draft-ietf-httpbis-p3-payload-17 (work in progress),
3689                 October 2011.
3690
3691   [Part6]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3692
3693
3694
3695Fielding, et al.           Expires May 3, 2012                 [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1                October 2011
3698
3699
3700                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3701                 Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
3702                 "HTTP/1.1, part 6: Caching",
3703                 draft-ietf-httpbis-p6-cache-17 (work in progress),
3704                 October 2011.
3705
3706   [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
3707                 Format Specification version 3.3", RFC 1950, May 1996.
3708
3709                 RFC 1950 is an Informational RFC, thus it might be less
3710                 stable than this specification.  On the other hand,
3711                 this downward reference was present since the
3712                 publication of RFC 2068 in 1997, therefore it is
3713                 unlikely to cause problems in practice.  See also
3714                 [BCP97].
3715
3716   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
3717                 Specification version 1.3", RFC 1951, May 1996.
3718
3719                 RFC 1951 is an Informational RFC, thus it might be less
3720                 stable than this specification.  On the other hand,
3721                 this downward reference was present since the
3722                 publication of RFC 2068 in 1997, therefore it is
3723                 unlikely to cause problems in practice.  See also
3724                 [BCP97].
3725
3726   [RFC1952]     Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
3727                 G. Randers-Pehrson, "GZIP file format specification
3728                 version 4.3", RFC 1952, May 1996.
3729
3730                 RFC 1952 is an Informational RFC, thus it might be less
3731                 stable than this specification.  On the other hand,
3732                 this downward reference was present since the
3733                 publication of RFC 2068 in 1997, therefore it is
3734                 unlikely to cause problems in practice.  See also
3735                 [BCP97].
3736
3737   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
3738                 Requirement Levels", BCP 14, RFC 2119, March 1997.
3739
3740   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
3741                 "Uniform Resource Identifier (URI): Generic Syntax",
3742                 STD 66, RFC 3986, January 2005.
3743
3744   [RFC5234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
3745                 Syntax Specifications: ABNF", STD 68, RFC 5234,
3746                 January 2008.
3747
3748
3749
3750
3751Fielding, et al.           Expires May 3, 2012                 [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1                October 2011
3754
3755
3756   [USASCII]     American National Standards Institute, "Coded Character
3757                 Set -- 7-bit American Standard Code for Information
3758                 Interchange", ANSI X3.4, 1986.
3759
376012.2.  Informative References
3761
3762   [BCP97]       Klensin, J. and S. Hartman, "Handling Normative
3763                 References to Standards-Track Documents", BCP 97,
3764                 RFC 4897, June 2007.
3765
3766   [Kri2001]     Kristol, D., "HTTP Cookies: Standards, Privacy, and
3767                 Politics", ACM Transactions on Internet Technology Vol.
3768                 1, #2, November 2001,
3769                 <http://arxiv.org/abs/cs.SE/0105018>.
3770
3771   [Nie1997]     Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
3772                 and C. Lilley, "Network Performance Effects of
3773                 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
3774                 SIGCOMM '97 conference on Applications, technologies,
3775                 architectures, and protocols for computer communication
3776                 SIGCOMM '97, September 1997,
3777                 <http://doi.acm.org/10.1145/263105.263157>.
3778
3779   [Pad1995]     Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
3780                 Computer Networks and ISDN Systems v. 28, pp. 25-35,
3781                 December 1995,
3782                 <http://portal.acm.org/citation.cfm?id=219094>.
3783
3784   [RFC1919]     Chatel, M., "Classical versus Transparent IP Proxies",
3785                 RFC 1919, March 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   [RFC2145]     Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
3804
3805
3806
3807Fielding, et al.           Expires May 3, 2012                 [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 1                October 2011
3810
3811
3812                 "Use and Interpretation of HTTP Version Numbers",
3813                 RFC 2145, May 1997.
3814
3815   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3816                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3817                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3818
3819   [RFC2817]     Khare, R. and S. Lawrence, "Upgrading to TLS Within
3820                 HTTP/1.1", RFC 2817, May 2000.
3821
3822   [RFC2818]     Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3823
3824   [RFC2965]     Kristol, D. and L. Montulli, "HTTP State Management
3825                 Mechanism", RFC 2965, October 2000.
3826
3827   [RFC3040]     Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
3828                 Replication and Caching Taxonomy", RFC 3040,
3829                 January 2001.
3830
3831   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
3832                 Procedures for Message Header Fields", BCP 90,
3833                 RFC 3864, September 2004.
3834
3835   [RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
3836                 Rose, "DNS Security Introduction and Requirements",
3837                 RFC 4033, March 2005.
3838
3839   [RFC4288]     Freed, N. and J. Klensin, "Media Type Specifications
3840                 and Registration Procedures", BCP 13, RFC 4288,
3841                 December 2005.
3842
3843   [RFC4395]     Hansen, T., Hardie, T., and L. Masinter, "Guidelines
3844                 and Registration Procedures for New URI Schemes",
3845                 BCP 115, RFC 4395, February 2006.
3846
3847   [RFC4559]     Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
3848                 Kerberos and NTLM HTTP Authentication in Microsoft
3849                 Windows", RFC 4559, June 2006.
3850
3851   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
3852                 an IANA Considerations Section in RFCs", BCP 26,
3853                 RFC 5226, May 2008.
3854
3855   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
3856                 October 2008.
3857
3858   [RFC6265]     Barth, A., "HTTP State Management Mechanism", RFC 6265,
3859                 April 2011.
3860
3861
3862
3863Fielding, et al.           Expires May 3, 2012                 [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 1                October 2011
3866
3867
3868   [Spe]         Spero, S., "Analysis of HTTP Performance Problems",
3869                 <http://sunsite.unc.edu/mdma-release/http-prob.html>.
3870
3871   [Tou1998]     Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
3872                 HTTP Performance", ISI Research Report ISI/RR-98-463,
3873                 Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
3874
3875                 (original report dated Aug. 1996)
3876
3877Appendix A.  HTTP Version History
3878
3879   HTTP has been in use by the World-Wide Web global information
3880   initiative since 1990.  The first version of HTTP, later referred to
3881   as HTTP/0.9, was a simple protocol for hypertext data transfer across
3882   the Internet with only a single request method (GET) and no metadata.
3883   HTTP/1.0, as defined by [RFC1945], added a range of request methods
3884   and MIME-like messaging that could include metadata about the data
3885   transferred and modifiers on the request/response semantics.
3886   However, HTTP/1.0 did not sufficiently take into consideration the
3887   effects of hierarchical proxies, caching, the need for persistent
3888   connections, or name-based virtual hosts.  The proliferation of
3889   incompletely-implemented applications calling themselves "HTTP/1.0"
3890   further necessitated a protocol version change in order for two
3891   communicating applications to determine each other's true
3892   capabilities.
3893
3894   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
3895   requirements that enable reliable implementations, adding only those
3896   new features that will either be safely ignored by an HTTP/1.0
3897   recipient or only sent when communicating with a party advertising
3898   compliance with HTTP/1.1.
3899
3900   It is beyond the scope of a protocol specification to mandate
3901   compliance with previous versions.  HTTP/1.1 was deliberately
3902   designed, however, to make supporting previous versions easy.  We
3903   would expect a general-purpose HTTP/1.1 server to understand any
3904   valid request in the format of HTTP/1.0 and respond appropriately
3905   with an HTTP/1.1 message that only uses features understood (or
3906   safely ignored) by HTTP/1.0 clients.  Likewise, would expect an
3907   HTTP/1.1 client to understand any valid HTTP/1.0 response.
3908
3909   Since HTTP/0.9 did not support header fields in a request, there is
3910   no mechanism for it to support name-based virtual hosts (selection of
3911   resource by inspection of the Host header field).  Any server that
3912   implements name-based virtual hosts ought to disable support for
3913   HTTP/0.9.  Most requests that appear to be HTTP/0.9 are, in fact,
3914   badly constructed HTTP/1.x requests wherein a buggy client failed to
3915   properly encode linear whitespace found in a URI reference and placed
3916
3917
3918
3919Fielding, et al.           Expires May 3, 2012                 [Page 70]
3920
3921Internet-Draft              HTTP/1.1, Part 1                October 2011
3922
3923
3924   in the request-target.
3925
3926A.1.  Changes from HTTP/1.0
3927
3928   This section summarizes major differences between versions HTTP/1.0
3929   and HTTP/1.1.
3930
3931A.1.1.  Multi-homed Web Servers
3932
3933   The requirements that clients and servers support the Host header
3934   field (Section 8.3), report an error if it is missing from an
3935   HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are
3936   among the most important changes defined by HTTP/1.1.
3937
3938   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3939   addresses and servers; there was no other established mechanism for
3940   distinguishing the intended server of a request than the IP address
3941   to which that request was directed.  The Host header field was
3942   introduced during the development of HTTP/1.1 and, though it was
3943   quickly implemented by most HTTP/1.0 browsers, additional
3944   requirements were placed on all HTTP/1.1 requests in order to ensure
3945   complete adoption.  At the time of this writing, most HTTP-based
3946   services are dependent upon the Host header field for targeting
3947   requests.
3948
3949A.1.2.  Keep-Alive Connections
3950
3951   For most implementations of HTTP/1.0, each connection is established
3952   by the client prior to the request and closed by the server after
3953   sending the response.  However, some implementations implement the
3954   Keep-Alive version of persistent connections described in Section
3955   19.7.1 of [RFC2068].
3956
3957   Some clients and servers might wish to be compatible with some
3958   previous implementations of persistent connections in HTTP/1.0
3959   clients and servers.  Persistent connections in HTTP/1.0 are
3960   explicitly negotiated as they are not the default behavior.  HTTP/1.0
3961   experimental implementations of persistent connections are faulty,
3962   and the new facilities in HTTP/1.1 are designed to rectify these
3963   problems.  The problem was that some existing HTTP/1.0 clients might
3964   send Keep-Alive to a proxy server that doesn't understand Connection,
3965   which would then erroneously forward it to the next inbound server,
3966   which would establish the Keep-Alive connection and result in a hung
3967   HTTP/1.0 proxy waiting for the close on the response.  The result is
3968   that HTTP/1.0 clients must be prevented from using Keep-Alive when
3969   talking to proxies.
3970
3971   However, talking to proxies is the most important use of persistent
3972
3973
3974
3975Fielding, et al.           Expires May 3, 2012                 [Page 71]
3976
3977Internet-Draft              HTTP/1.1, Part 1                October 2011
3978
3979
3980   connections, so that prohibition is clearly unacceptable.  Therefore,
3981   we need some other mechanism for indicating a persistent connection
3982   is desired, which is safe to use even when talking to an old proxy
3983   that ignores Connection.  Persistent connections are the default for
3984   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
3985   declaring non-persistence.  See Section 8.1.
3986
3987A.2.  Changes from RFC 2616
3988
3989   Empty list elements in list productions have been deprecated.
3990   (Section 1.2.1)
3991
3992   Rules about implicit linear whitespace between certain grammar
3993   productions have been removed; now it's only allowed when
3994   specifically pointed out in the ABNF.  (Section 1.2.2)
3995
3996   Clarify that the string "HTTP" in the HTTP-Version ABFN production is
3997   case sensitive.  Restrict the version numbers to be single digits due
3998   to the fact that implementations are known to handle multi-digit
3999   version numbers incorrectly.  (Section 2.6)
4000
4001   Require that invalid whitespace around field-names be rejected.
4002   (Section 3.2)
4003
4004   The NUL octet is no longer allowed in comment and quoted-string text.
4005   The quoted-pair rule no longer allows escaping control characters
4006   other than HTAB.  Non-ASCII content in header fields and reason
4007   phrase has been obsoleted and made opaque (the TEXT rule was
4008   removed).  (Section 3.2.3)
4009
4010   Require recipients to handle bogus Content-Length header fields as
4011   errors.  (Section 3.3)
4012
4013   Remove reference to non-existent identity transfer-coding value
4014   tokens.  (Sections 3.3 and 5.1)
4015
4016   Update use of abs_path production from RFC 1808 to the path-absolute
4017   + query components of RFC 3986.  State that the asterisk form is
4018   allowed for the OPTIONS request method only.  (Section 3.1.1.2)
4019
4020   Clarification that the chunk length does not include the count of the
4021   octets in the chunk header and trailer.  Furthermore disallowed line
4022   folding in chunk extensions.  (Section 5.1.1)
4023
4024   Remove hard limit of two connections per server.  Remove requirement
4025   to retry a sequence of requests as long it was idempotent.  Remove
4026   requirements about when servers are allowed to close connections
4027   prematurely.  (Section 6.1.4)
4028
4029
4030
4031Fielding, et al.           Expires May 3, 2012                 [Page 72]
4032
4033Internet-Draft              HTTP/1.1, Part 1                October 2011
4034
4035
4036   Remove requirement to retry requests under certain cirumstances when
4037   the server prematurely closes the connection.  (Section 6.2)
4038
4039   Change ABNF productions for header fields to only define the field
4040   value.  (Section 8)
4041
4042   Clarify exactly when close connection options must be sent.
4043   (Section 8.1)
4044
4045   Define the semantics of the "Upgrade" header field in responses other
4046   than 101 (this was incorporated from [RFC2817]).  (Section 8.7)
4047
4048Appendix B.  Collected ABNF
4049
4050   BWS = OWS
4051
4052   Chunked-Body = *chunk last-chunk trailer-part CRLF
4053   Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
4054    connection-token ] )
4055   Content-Length = 1*DIGIT
4056
4057   HTTP-Prot-Name = %x48.54.54.50 ; HTTP
4058   HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
4059   HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4060    ]
4061   Host = uri-host [ ":" port ]
4062
4063   Method = token
4064
4065   OWS = *( SP / HTAB / obs-fold )
4066
4067   RWS = 1*( SP / HTAB / obs-fold )
4068   Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
4069   Request-Line = Method SP request-target SP HTTP-Version CRLF
4070
4071   Status-Code = 3DIGIT
4072   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
4073
4074   TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4075   Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4076   Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4077    transfer-coding ] )
4078
4079   URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
4080   Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
4081
4082
4083
4084
4085
4086
4087Fielding, et al.           Expires May 3, 2012                 [Page 73]
4088
4089Internet-Draft              HTTP/1.1, Part 1                October 2011
4090
4091
4092   Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
4093    *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
4094    )
4095
4096   absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
4097   attribute = token
4098   authority = <authority, defined in [RFC3986], Section 3.2>
4099
4100   chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
4101   chunk-data = 1*OCTET
4102   chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
4103   chunk-ext-name = token
4104   chunk-ext-val = token / quoted-str-nf
4105   chunk-size = 1*HEXDIG
4106   comment = "(" *( ctext / quoted-cpair / comment ) ")"
4107   connection-token = token
4108   ctext = OWS / %x21-27 ; '!'-'''
4109    / %x2A-5B ; '*'-'['
4110    / %x5D-7E ; ']'-'~'
4111    / obs-text
4112
4113   field-content = *( HTAB / SP / VCHAR / obs-text )
4114   field-name = token
4115   field-value = *( field-content / obs-fold )
4116
4117   header-field = field-name ":" OWS field-value BWS
4118   http-URI = "http://" authority path-abempty [ "?" query ]
4119   https-URI = "https://" authority path-abempty [ "?" query ]
4120
4121   last-chunk = 1*"0" [ chunk-ext ] CRLF
4122
4123   message-body = *OCTET
4124
4125   obs-fold = CRLF ( SP / HTAB )
4126   obs-text = %x80-FF
4127
4128   partial-URI = relative-part [ "?" query ]
4129   path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
4130   path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
4131   port = <port, defined in [RFC3986], Section 3.2.3>
4132   product = token [ "/" product-version ]
4133   product-version = token
4134   protocol-name = token
4135   protocol-version = token
4136   pseudonym = token
4137
4138
4139
4140
4141
4142
4143Fielding, et al.           Expires May 3, 2012                 [Page 74]
4144
4145Internet-Draft              HTTP/1.1, Part 1                October 2011
4146
4147
4148   qdtext = OWS / "!" / %x23-5B ; '#'-'['
4149    / %x5D-7E ; ']'-'~'
4150    / obs-text
4151   qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'['
4152    / %x5D-7E ; ']'-'~'
4153    / obs-text
4154   query = <query, defined in [RFC3986], Section 3.4>
4155   quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text )
4156   quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
4157   quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
4158   quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4159   qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4160
4161   received-by = ( uri-host [ ":" port ] ) / pseudonym
4162   received-protocol = [ protocol-name "/" ] protocol-version
4163   relative-part = <relative-part, defined in [RFC3986], Section 4.2>
4164   request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
4165    / authority
4166
4167   special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
4168    DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
4169   start-line = Request-Line / Status-Line
4170
4171   t-codings = "trailers" / ( transfer-extension [ te-params ] )
4172   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4173    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4174   te-ext = OWS ";" OWS token [ "=" word ]
4175   te-params = OWS ";" OWS "q=" qvalue *te-ext
4176   token = 1*tchar
4177   trailer-part = *( header-field CRLF )
4178   transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4179    transfer-extension
4180   transfer-extension = token *( OWS ";" OWS transfer-parameter )
4181   transfer-parameter = attribute BWS "=" BWS value
4182
4183   uri-host = <host, defined in [RFC3986], Section 3.2.2>
4184
4185   value = word
4186
4187   word = token / quoted-string
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199Fielding, et al.           Expires May 3, 2012                 [Page 75]
4200
4201Internet-Draft              HTTP/1.1, Part 1                October 2011
4202
4203
4204   ABNF diagnostics:
4205
4206   ; Chunked-Body defined but not used
4207   ; Connection defined but not used
4208   ; Content-Length defined but not used
4209   ; HTTP-message defined but not used
4210   ; Host defined but not used
4211   ; TE defined but not used
4212   ; Trailer defined but not used
4213   ; Transfer-Encoding defined but not used
4214   ; URI-reference defined but not used
4215   ; Upgrade defined but not used
4216   ; Via defined but not used
4217   ; http-URI defined but not used
4218   ; https-URI defined but not used
4219   ; partial-URI defined but not used
4220   ; special defined but not used
4221
4222Appendix C.  Change Log (to be removed by RFC Editor before publication)
4223
4224C.1.  Since RFC 2616
4225
4226   Extracted relevant partitions from [RFC2616].
4227
4228C.2.  Since draft-ietf-httpbis-p1-messaging-00
4229
4230   Closed issues:
4231
4232   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
4233      should be case sensitive"
4234      (<http://purl.org/NET/http-errata#verscase>)
4235
4236   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
4237      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
4238
4239   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
4240      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
4241
4242   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
4243      (<http://purl.org/NET/http-errata#msg-len-chars>)
4244
4245   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
4246      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
4247
4248   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
4249      query" (<http://purl.org/NET/http-errata#uriquery>)
4250
4251
4252
4253
4254
4255Fielding, et al.           Expires May 3, 2012                 [Page 76]
4256
4257Internet-Draft              HTTP/1.1, Part 1                October 2011
4258
4259
4260   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
4261      1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
4262
4263   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
4264      'identity' token references"
4265      (<http://purl.org/NET/http-errata#identity>)
4266
4267   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
4268      BNF"
4269
4270   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
4271
4272   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
4273      Informative references"
4274
4275   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
4276      Compliance"
4277
4278   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
4279      reference"
4280
4281   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
4282      references"
4283
4284   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
4285      in date format explanation"
4286
4287   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
4288      typo"
4289
4290   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
4291      references"
4292
4293   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
4294      Reference"
4295
4296   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
4297      to-date references"
4298
4299   Other changes:
4300
4301   o  Update media type registrations to use RFC4288 template.
4302
4303   o  Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
4304      for chunk-data (work in progress on
4305      <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
4306
4307
4308
4309
4310
4311Fielding, et al.           Expires May 3, 2012                 [Page 77]
4312
4313Internet-Draft              HTTP/1.1, Part 1                October 2011
4314
4315
4316C.3.  Since draft-ietf-httpbis-p1-messaging-01
4317
4318   Closed issues:
4319
4320   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
4321      (and other) requests"
4322
4323   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
4324      RFC4288"
4325
4326   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
4327      and Reason Phrase"
4328
4329   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
4330      used"
4331
4332   Ongoing work on ABNF conversion
4333   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4334
4335   o  Get rid of duplicate BNF rule names ("host" -> "uri-host",
4336      "trailer" -> "trailer-part").
4337
4338   o  Avoid underscore character in rule names ("http_URL" -> "http-
4339      URL", "abs_path" -> "path-absolute").
4340
4341   o  Add rules for terms imported from URI spec ("absoluteURI",
4342      "authority", "path-absolute", "port", "query", "relativeURI",
4343      "host) -- these will have to be updated when switching over to
4344      RFC3986.
4345
4346   o  Synchronize core rules with RFC5234.
4347
4348   o  Get rid of prose rules that span multiple lines.
4349
4350   o  Get rid of unused rules LOALPHA and UPALPHA.
4351
4352   o  Move "Product Tokens" section (back) into Part 1, as "token" is
4353      used in the definition of the Upgrade header field.
4354
4355   o  Add explicit references to BNF syntax and rules imported from
4356      other parts of the specification.
4357
4358   o  Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
4359      "TEXT".
4360
4361
4362
4363
4364
4365
4366
4367Fielding, et al.           Expires May 3, 2012                 [Page 78]
4368
4369Internet-Draft              HTTP/1.1, Part 1                October 2011
4370
4371
4372C.4.  Since draft-ietf-httpbis-p1-messaging-02
4373
4374   Closed issues:
4375
4376   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
4377      rfc1123-date"
4378
4379   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
4380      pair"
4381
4382   Ongoing work on IANA Message Header Field Registration
4383   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
4384
4385   o  Reference RFC 3984, and update header field registrations for
4386      headers defined in this document.
4387
4388   Ongoing work on ABNF conversion
4389   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4390
4391   o  Replace string literals when the string really is case-sensitive
4392      (HTTP-Version).
4393
4394C.5.  Since draft-ietf-httpbis-p1-messaging-03
4395
4396   Closed issues:
4397
4398   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4399      closing"
4400
4401   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
4402      registrations and registry information to IANA Considerations"
4403
4404   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
4405      for PAD1995 reference"
4406
4407   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
4408      Considerations: update HTTP URI scheme registration"
4409
4410   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
4411      URI scheme definition"
4412
4413   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
4414      headers vs Set-Cookie"
4415
4416   Ongoing work on ABNF conversion
4417   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4418
4419
4420
4421
4422
4423Fielding, et al.           Expires May 3, 2012                 [Page 79]
4424
4425Internet-Draft              HTTP/1.1, Part 1                October 2011
4426
4427
4428   o  Replace string literals when the string really is case-sensitive
4429      (HTTP-Date).
4430
4431   o  Replace HEX by HEXDIG for future consistence with RFC 5234's core
4432      rules.
4433
4434C.6.  Since draft-ietf-httpbis-p1-messaging-04
4435
4436   Closed issues:
4437
4438   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
4439      reference for URIs"
4440
4441   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
4442      updated by RFC 5322"
4443
4444   Ongoing work on ABNF conversion
4445   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4446
4447   o  Use "/" instead of "|" for alternatives.
4448
4449   o  Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4450
4451   o  Only reference RFC 5234's core rules.
4452
4453   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4454      whitespace ("OWS") and required whitespace ("RWS").
4455
4456   o  Rewrite ABNFs to spell out whitespace rules, factor out header
4457      field value format definitions.
4458
4459C.7.  Since draft-ietf-httpbis-p1-messaging-05
4460
4461   Closed issues:
4462
4463   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
4464
4465   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
4466      Terminology"
4467
4468   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
4469      encoded words"
4470
4471   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
4472      Encodings in TEXT"
4473
4474   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
4475
4476
4477
4478
4479Fielding, et al.           Expires May 3, 2012                 [Page 80]
4480
4481Internet-Draft              HTTP/1.1, Part 1                October 2011
4482
4483
4484   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4485      proxies"
4486
4487   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
4488      BNF"
4489
4490   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
4491
4492   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
4493      "Differences Between HTTP Entities and RFC 2045 Entities"?"
4494
4495   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
4496      reference left in discussion of date formats"
4497
4498   Final work on ABNF conversion
4499   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4500
4501   o  Rewrite definition of list rules, deprecate empty list elements.
4502
4503   o  Add appendix containing collected and expanded ABNF.
4504
4505   Other changes:
4506
4507   o  Rewrite introduction; add mostly new Architecture Section.
4508
4509   o  Move definition of quality values from Part 3 into Part 1; make TE
4510      request header field grammar independent of accept-params (defined
4511      in Part 3).
4512
4513C.8.  Since draft-ietf-httpbis-p1-messaging-06
4514
4515   Closed issues:
4516
4517   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
4518      numeric protocol elements"
4519
4520   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
4521
4522   Partly resolved issues:
4523
4524   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
4525      (took out language that implied that there might be methods for
4526      which a request body MUST NOT be included)
4527
4528   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
4529      improvements around HTTP-date"
4530
4531
4532
4533
4534
4535Fielding, et al.           Expires May 3, 2012                 [Page 81]
4536
4537Internet-Draft              HTTP/1.1, Part 1                October 2011
4538
4539
4540C.9.  Since draft-ietf-httpbis-p1-messaging-07
4541
4542   Closed issues:
4543
4544   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
4545      single-value headers"
4546
4547   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
4548      connection limit"
4549
4550   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
4551      in URLs"
4552
4553   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over
4554      HTTP Upgrade Token Registry"
4555
4556   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in
4557      chunk extension values"
4558
4559   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9
4560      support"
4561
4562   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
4563      policy (RFC5226) for Transfer Coding / Content Coding"
4564
4565   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
4566      definitions of gzip/deflate/compress to part 1"
4567
4568   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
4569      control characters in quoted-pair"
4570
4571   Partly resolved issues:
4572
4573   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
4574      requirements wrt Transfer-Coding values" (add the IANA
4575      Considerations subsection)
4576
4577C.10.  Since draft-ietf-httpbis-p1-messaging-08
4578
4579   Closed issues:
4580
4581   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
4582      parsing, treatment of leading and trailing OWS"
4583
4584   Partly resolved issues:
4585
4586   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
4587      13.5.1 and 13.5.2"
4588
4589
4590
4591Fielding, et al.           Expires May 3, 2012                 [Page 82]
4592
4593Internet-Draft              HTTP/1.1, Part 1                October 2011
4594
4595
4596   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4597      "word" when talking about header structure"
4598
4599C.11.  Since draft-ietf-httpbis-p1-messaging-09
4600
4601   Closed issues:
4602
4603   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
4604      of the term 'deflate'"
4605
4606   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4607      proxies"
4608
4609   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
4610      not listed in P1, general header fields"
4611
4612   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
4613      for content/transfer encodings"
4614
4615   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
4616      sensitivity of HTTP-date"
4617
4618   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4619      "word" when talking about header structure"
4620
4621   Partly resolved issues:
4622
4623   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
4624      requested resource's URI"
4625
4626C.12.  Since draft-ietf-httpbis-p1-messaging-10
4627
4628   Closed issues:
4629
4630   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4631      Closing"
4632
4633   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
4634      messages with multipart/byteranges"
4635
4636   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4637      multiple Content-Length headers"
4638
4639   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
4640      entity / representation / variant terminology"
4641
4642   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
4643      removing the 'changes from 2068' sections"
4644
4645
4646
4647Fielding, et al.           Expires May 3, 2012                 [Page 83]
4648
4649Internet-Draft              HTTP/1.1, Part 1                October 2011
4650
4651
4652   Partly resolved issues:
4653
4654   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4655      scheme definitions"
4656
4657C.13.  Since draft-ietf-httpbis-p1-messaging-11
4658
4659   Closed issues:
4660
4661   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer
4662      requirements"
4663
4664   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
4665      clock requirement for caches belongs in p6"
4666
4667   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective
4668      request URI: handling of missing host in HTTP/1.0"
4669
4670   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing
4671      Date requirements for clients"
4672
4673   Partly resolved issues:
4674
4675   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4676      multiple Content-Length headers"
4677
4678C.14.  Since draft-ietf-httpbis-p1-messaging-12
4679
4680   Closed issues:
4681
4682   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145
4683      Normative"
4684
4685   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4686      scheme definitions" (tune the requirements on userinfo)
4687
4688   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define
4689      'transparent' proxy"
4690
4691   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
4692      Classification"
4693
4694   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable
4695      as a request-uri for new methods?"
4696
4697   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
4698      Upgrade details from RFC2817"
4699
4700
4701
4702
4703Fielding, et al.           Expires May 3, 2012                 [Page 84]
4704
4705Internet-Draft              HTTP/1.1, Part 1                October 2011
4706
4707
4708   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
4709      ABNFs for header fields"
4710
4711   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
4712      2109 reference"
4713
4714C.15.  Since draft-ietf-httpbis-p1-messaging-13
4715
4716   Closed issues:
4717
4718   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
4719      in 13.5.2"
4720
4721   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4722      multiple Content-Length headers"
4723
4724   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
4725      ABNFs for header fields"
4726
4727   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
4728      Length ABNF broken"
4729
4730C.16.  Since draft-ietf-httpbis-p1-messaging-14
4731
4732   Closed issues:
4733
4734   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version
4735      should be redefined as fixed length pair of DIGIT .  DIGIT"
4736
4737   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
4738      minimum sizes for protocol elements"
4739
4740   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set
4741      expectations around buffering"
4742
4743   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering
4744      messages in isolation"
4745
4746C.17.  Since draft-ietf-httpbis-p1-messaging-15
4747
4748   Closed issues:
4749
4750   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing
4751      / DNS Binding advice"
4752
4753   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs
4754      2145, 2616, 2817 to Historic status"
4755
4756
4757
4758
4759Fielding, et al.           Expires May 3, 2012                 [Page 85]
4760
4761Internet-Draft              HTTP/1.1, Part 1                October 2011
4762
4763
4764   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in
4765      quoted strings"
4766
4767   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close'
4768      should be reserved in the HTTP header field registry"
4769
4770C.18.  Since draft-ietf-httpbis-p1-messaging-16
4771
4772   Closed issues:
4773
4774   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
4775      HTTP's error-handling philosophy"
4776
4777   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain
4778      header registration"
4779
4780   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise
4781      Acknowledgements Sections"
4782
4783   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
4784      Requests"
4785
4786   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
4787      connection on server error"
4788
4789Index
4790
4791   A
4792      absolute-URI form (of request-target)  31
4793      accelerator  13
4794      application/http Media Type  61
4795      asterisk form (of request-target)  31
4796      authority form (of request-target)  32
4797
4798   B
4799      browser  10
4800
4801   C
4802      cache  14
4803      cacheable  15
4804      captive portal  14
4805      chunked (Coding Format)  36
4806      client  10
4807      Coding Format
4808         chunked  36
4809         compress  38
4810         deflate  38
4811         gzip  39
4812
4813
4814
4815Fielding, et al.           Expires May 3, 2012                 [Page 86]
4816
4817Internet-Draft              HTTP/1.1, Part 1                October 2011
4818
4819
4820      compress (Coding Format)  38
4821      connection  10
4822      Connection header field  49
4823      Content-Length header field  51
4824
4825   D
4826      deflate (Coding Format)  38
4827      downstream  13
4828
4829   E
4830      effective request URI  34
4831
4832   G
4833      gateway  13
4834      Grammar
4835         absolute-URI  17
4836         ALPHA  7
4837         attribute  35
4838         authority  17
4839         BWS  9
4840         chunk  36
4841         chunk-data  36
4842         chunk-ext  36
4843         chunk-ext-name  36
4844         chunk-ext-val  36
4845         chunk-size  36
4846         Chunked-Body  36
4847         comment  26
4848         Connection  50
4849         connection-token  50
4850         Content-Length  51
4851         CR  7
4852         CRLF  7
4853         ctext  26
4854         CTL  7
4855         date2  35
4856         date3  35
4857         DIGIT  7
4858         DQUOTE  7
4859         field-content  23
4860         field-name  23
4861         field-value  23
4862         header-field  23
4863         HEXDIG  7
4864         Host  52
4865         HTAB  7
4866         HTTP-message  21
4867         HTTP-Prot-Name  15
4868
4869
4870
4871Fielding, et al.           Expires May 3, 2012                 [Page 87]
4872
4873Internet-Draft              HTTP/1.1, Part 1                October 2011
4874
4875
4876         http-URI  18
4877         HTTP-Version  15
4878         https-URI  19
4879         last-chunk  36
4880         LF  7
4881         message-body  27
4882         Method  22
4883         obs-text  26
4884         OCTET  7
4885         OWS  9
4886         path-absolute  17
4887         port  17
4888         product  39
4889         product-version  39
4890         protocol-name  57
4891         protocol-version  57
4892         pseudonym  57
4893         qdtext  26
4894         qdtext-nf  36
4895         query  17
4896         quoted-cpair  26
4897         quoted-pair  26
4898         quoted-str-nf  36
4899         quoted-string  26
4900         qvalue  40
4901         Reason-Phrase  23
4902         received-by  57
4903         received-protocol  57
4904         Request-Line  22
4905         request-target  22
4906         RWS  9
4907         SP  7
4908         special  26
4909         start-line  21
4910         Status-Code  23
4911         Status-Line  23
4912         t-codings  53
4913         tchar  26
4914         TE  53
4915         te-ext  53
4916         te-params  53
4917         token  26
4918         Trailer  54
4919         trailer-part  36
4920         transfer-coding  35
4921         Transfer-Encoding  54
4922         transfer-extension  35
4923         transfer-parameter  35
4924
4925
4926
4927Fielding, et al.           Expires May 3, 2012                 [Page 88]
4928
4929Internet-Draft              HTTP/1.1, Part 1                October 2011
4930
4931
4932         Upgrade  55
4933         uri-host  17
4934         URI-reference  17
4935         value  35
4936         VCHAR  7
4937         Via  57
4938         word  26
4939      gzip (Coding Format)  39
4940
4941   H
4942      header field  20
4943      Header Fields
4944         Connection  49
4945         Content-Length  51
4946         Host  51
4947         TE  53
4948         Trailer  54
4949         Transfer-Encoding  54
4950         Upgrade  55
4951         Via  57
4952      header section  20
4953      headers  20
4954      Host header field  51
4955      http URI scheme  18
4956      https URI scheme  19
4957
4958   I
4959      inbound  13
4960      interception proxy  14
4961      intermediary  12
4962
4963   M
4964      Media Type
4965         application/http  61
4966         message/http  59
4967      message  10
4968      message/http Media Type  59
4969
4970   N
4971      non-transforming proxy  13
4972
4973   O
4974      origin form (of request-target)  32
4975      origin server  10
4976      outbound  13
4977
4978   P
4979      proxy  13
4980
4981
4982
4983Fielding, et al.           Expires May 3, 2012                 [Page 89]
4984
4985Internet-Draft              HTTP/1.1, Part 1                October 2011
4986
4987
4988   R
4989      recipient  10
4990      request  10
4991      resource  17
4992      response  10
4993      reverse proxy  13
4994
4995   S
4996      sender  10
4997      server  10
4998      spider  10
4999
5000   T
5001      target resource  34
5002      TE header field  53
5003      Trailer header field  54
5004      Transfer-Encoding header field  54
5005      transforming proxy  13
5006      transparent proxy  14
5007      tunnel  14
5008
5009   U
5010      Upgrade header field  55
5011      upstream  13
5012      URI scheme
5013         http  18
5014         https  19
5015      user agent  10
5016
5017   V
5018      Via header field  57
5019
5020Authors' Addresses
5021
5022   Roy T. Fielding (editor)
5023   Adobe Systems Incorporated
5024   345 Park Ave
5025   San Jose, CA  95110
5026   USA
5027
5028   EMail: fielding@gbiv.com
5029   URI:   http://roy.gbiv.com/
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039Fielding, et al.           Expires May 3, 2012                 [Page 90]
5040
5041Internet-Draft              HTTP/1.1, Part 1                October 2011
5042
5043
5044   Jim Gettys
5045   Alcatel-Lucent Bell Labs
5046   21 Oak Knoll Road
5047   Carlisle, MA  01741
5048   USA
5049
5050   EMail: jg@freedesktop.org
5051   URI:   http://gettys.wordpress.com/
5052
5053
5054   Jeffrey C. Mogul
5055   Hewlett-Packard Company
5056   HP Labs, Large Scale Systems Group
5057   1501 Page Mill Road, MS 1177
5058   Palo Alto, CA  94304
5059   USA
5060
5061   EMail: JeffMogul@acm.org
5062
5063
5064   Henrik Frystyk Nielsen
5065   Microsoft Corporation
5066   1 Microsoft Way
5067   Redmond, WA  98052
5068   USA
5069
5070   EMail: henrikn@microsoft.com
5071
5072
5073   Larry Masinter
5074   Adobe Systems Incorporated
5075   345 Park Ave
5076   San Jose, CA  95110
5077   USA
5078
5079   EMail: LMM@acm.org
5080   URI:   http://larry.masinter.net/
5081
5082
5083   Paul J. Leach
5084   Microsoft Corporation
5085   1 Microsoft Way
5086   Redmond, WA  98052
5087
5088   EMail: paulle@microsoft.com
5089
5090
5091
5092
5093
5094
5095Fielding, et al.           Expires May 3, 2012                 [Page 91]
5096
5097Internet-Draft              HTTP/1.1, Part 1                October 2011
5098
5099
5100   Tim Berners-Lee
5101   World Wide Web Consortium
5102   MIT Computer Science and Artificial Intelligence Laboratory
5103   The Stata Center, Building 32
5104   32 Vassar Street
5105   Cambridge, MA  02139
5106   USA
5107
5108   EMail: timbl@w3.org
5109   URI:   http://www.w3.org/People/Berners-Lee/
5110
5111
5112   Yves Lafon (editor)
5113   World Wide Web Consortium
5114   W3C / ERCIM
5115   2004, rte des Lucioles
5116   Sophia-Antipolis, AM  06902
5117   France
5118
5119   EMail: ylafon@w3.org
5120   URI:   http://www.raubacapeu.net/people/yves/
5121
5122
5123   Julian F. Reschke (editor)
5124   greenbytes GmbH
5125   Hafenweg 16
5126   Muenster, NW  48155
5127   Germany
5128
5129   Phone: +49 251 2807760
5130   Fax:   +49 251 2807761
5131   EMail: julian.reschke@greenbytes.de
5132   URI:   http://greenbytes.de/tech/webdav/
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151Fielding, et al.           Expires May 3, 2012                 [Page 92]
5152
Note: See TracBrowser for help on using the repository browser.