source: draft-ietf-httpbis/18/draft-ietf-httpbis-p1-messaging-18.txt @ 1499

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

prepare for publication of -18 on Jan 04.

  • 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: July 7, 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                                                         January 4, 2012
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-18
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 July 7, 2012                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1                January 2012
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.19.
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 July 7, 2012.
85
86Copyright Notice
87
88   Copyright (c) 2012 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 July 7, 2012                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1                January 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . 21
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  . . . . . . . . . . . . . . . . . . . . 25
145       3.2.2.  Field Length . . . . . . . . . . . . . . . . . . . . . 25
146       3.2.3.  Common Field ABNF Rules  . . . . . . . . . . . . . . . 26
147     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
148     3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 30
149     3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 31
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 July 7, 2012                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1                January 2012
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 . . . . . . . . . . . . . . . . . . 67
216   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 69
217     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 70
218       A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 70
219       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 71
220
221
222
223Fielding, et al.          Expires July 7, 2012                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1                January 2012
226
227
228     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 71
229   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 72
230   Appendix C.  Change Log (to be removed by RFC Editor before
231                publication)  . . . . . . . . . . . . . . . . . . . . 75
232     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75
233     C.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75
234     C.3.  Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77
235     C.4.  Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78
236     C.5.  Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78
237     C.6.  Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79
238     C.7.  Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79
239     C.8.  Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80
240     C.9.  Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81
241     C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
242     C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82
243     C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82
244     C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83
245     C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83
246     C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84
247     C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84
248     C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
249     C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85
250     C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85
251   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
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 July 7, 2012                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1                January 2012
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      Note: The term 'user agent' covers both those situations where
532      there is a user (human) interacting with the software agent (and
533      for which user interface or interactive suggestions might be made,
534      e.g., warning the user or given the user an option in the case of
535      security or privacy options) and also those where the software
536      agent may act autonomously.
537
538   Most HTTP communication consists of a retrieval request (GET) for a
539   representation of some resource identified by a URI.  In the simplest
540   case, this might be accomplished via a single bidirectional
541   connection (===) between the user agent (UA) and the origin server
542   (O).
543
544            request   >
545       UA ======================================= O
546                                   <   response
547
548   A client sends an HTTP request to the server in the form of a request
549   message, beginning with a request-line that includes a method, URI,
550   and protocol version (Section 3.1.1), followed by MIME-like header
551   fields containing request modifiers, client information, and payload
552   metadata (Section 3.2), an empty line to indicate the end of the
553   header section, and finally a message body containing the payload
554   body (if any, Section 3.3).
555
556
557
558
559Fielding, et al.          Expires July 7, 2012                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1                January 2012
562
563
564   A server responds to the client's request by sending an HTTP response
565   message, beginning with a status line that includes the protocol
566   version, a success or error code, and textual reason phrase
567   (Section 3.1.2), followed by MIME-like header fields containing
568   server information, resource metadata, and payload metadata
569   (Section 3.2), an empty line to indicate the end of the header
570   section, and finally a message body containing the payload body (if
571   any, Section 3.3).
572
573   Note that 1xx responses (Section 7.1 of [Part2]) are not final;
574   therefore, a server can send zero or more 1xx responses, followed by
575   exactly one final response (with any other status code).
576
577   The following example illustrates a typical message exchange for a
578   GET request on the URI "http://www.example.com/hello.txt":
579
580   client request:
581
582     GET /hello.txt HTTP/1.1
583     User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
584     Host: www.example.com
585     Accept: */*
586
587
588   server response:
589
590     HTTP/1.1 200 OK
591     Date: Mon, 27 Jul 2009 12:28:53 GMT
592     Server: Apache
593     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
594     ETag: "34aa387-d-1568eb00"
595     Accept-Ranges: bytes
596     Content-Length: 14
597     Vary: Accept-Encoding
598     Content-Type: text/plain
599
600     Hello World!
601
6022.2.  Message Orientation and Buffering
603
604   Fundamentally, HTTP is a message-based protocol.  Although message
605   bodies can be chunked (Section 5.1.1) and implementations often make
606   parts of a message available progressively, this is not required, and
607   some widely-used implementations only make a message available when
608   it is complete.  Furthermore, while most proxies will progressively
609   stream messages, some amount of buffering will take place, and some
610   proxies might buffer messages to perform transformations, check
611   content or provide other services.
612
613
614
615Fielding, et al.          Expires July 7, 2012                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1                January 2012
618
619
620   Therefore, extensions to and uses of HTTP cannot rely on the
621   availability of a partial message, or assume that messages will not
622   be buffered.  There are strategies that can be used to test for
623   buffering in a given connection, but it should be understood that
624   behaviors can differ across connections, and between requests and
625   responses.
626
627   Recipients MUST consider every message in a connection in isolation;
628   because HTTP is a stateless protocol, it cannot be assumed that two
629   requests on the same connection are from the same client or share any
630   other common attributes.  In particular, intermediaries might mix
631   requests from different clients into a single server connection.
632   Note that some existing HTTP extensions (e.g., [RFC4559]) violate
633   this requirement, thereby potentially causing interoperability and
634   security problems.
635
6362.3.  Connections and Transport Independence
637
638   HTTP messaging is independent of the underlying transport or session-
639   layer connection protocol(s).  HTTP only presumes a reliable
640   transport with in-order delivery of requests and the corresponding
641   in-order delivery of responses.  The mapping of HTTP request and
642   response structures onto the data units of the underlying transport
643   protocol is outside the scope of this specification.
644
645   The specific connection protocols to be used for an interaction are
646   determined by client configuration and the target resource's URI.
647   For example, the "http" URI scheme (Section 2.7.1) indicates a
648   default connection of TCP over IP, with a default TCP port of 80, but
649   the client might be configured to use a proxy via some other
650   connection port or protocol instead of using the defaults.
651
652   A connection might be used for multiple HTTP request/response
653   exchanges, as defined in Section 6.1.
654
6552.4.  Intermediaries
656
657   HTTP enables the use of intermediaries to satisfy requests through a
658   chain of connections.  There are three common forms of HTTP
659   intermediary: proxy, gateway, and tunnel.  In some cases, a single
660   intermediary might act as an origin server, proxy, gateway, or
661   tunnel, switching behavior based on the nature of each request.
662
663            >             >             >             >
664       UA =========== A =========== B =========== C =========== O
665                  <             <             <             <
666
667   The figure above shows three intermediaries (A, B, and C) between the
668
669
670
671Fielding, et al.          Expires July 7, 2012                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1                January 2012
674
675
676   user agent and origin server.  A request or response message that
677   travels the whole chain will pass through four separate connections.
678   Some HTTP communication options might apply only to the connection
679   with the nearest, non-tunnel neighbor, only to the end-points of the
680   chain, or to all connections along the chain.  Although the diagram
681   is linear, each participant might be engaged in multiple,
682   simultaneous communications.  For example, B might be receiving
683   requests from many clients other than A, and/or forwarding requests
684   to servers other than C, at the same time that it is handling A's
685   request.
686
687   We use the terms "upstream" and "downstream" to describe various
688   requirements in relation to the directional flow of a message: all
689   messages flow from upstream to downstream.  Likewise, we use the
690   terms inbound and outbound to refer to directions in relation to the
691   request path: "inbound" means toward the origin server and "outbound"
692   means toward the user agent.
693
694   A "proxy" is a message forwarding agent that is selected by the
695   client, usually via local configuration rules, to receive requests
696   for some type(s) of absolute URI and attempt to satisfy those
697   requests via translation through the HTTP interface.  Some
698   translations are minimal, such as for proxy requests for "http" URIs,
699   whereas other requests might require translation to and from entirely
700   different application-layer protocols.  Proxies are often used to
701   group an organization's HTTP requests through a common intermediary
702   for the sake of security, annotation services, or shared caching.
703
704   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
705   designed or configured to modify request or response messages in a
706   semantically meaningful way (i.e., modifications, beyond those
707   required by normal HTTP processing, that change the message in a way
708   that would be significant to the original sender or potentially
709   significant to downstream recipients).  For example, a transforming
710   proxy might be acting as a shared annotation server (modifying
711   responses to include references to a local annotation database), a
712   malware filter, a format transcoder, or an intranet-to-Internet
713   privacy filter.  Such transformations are presumed to be desired by
714   the client (or client organization) that selected the proxy and are
715   beyond the scope of this specification.  However, when a proxy is not
716   intended to transform a given message, we use the term "non-
717   transforming proxy" to target requirements that preserve HTTP message
718   semantics.  See Section 7.2.4 of [Part2] and Section 3.6 of [Part6]
719   for status and warning codes related to transformations.
720
721   A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
722   as a layer above some other server(s) and translates the received
723   requests to the underlying server's protocol.  Gateways are often
724
725
726
727Fielding, et al.          Expires July 7, 2012                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1                January 2012
730
731
732   used to encapsulate legacy or untrusted information services, to
733   improve server performance through "accelerator" caching, and to
734   enable partitioning or load-balancing of HTTP services across
735   multiple machines.
736
737   A gateway behaves as an origin server on its outbound connection and
738   as a user agent on its inbound connection.  All HTTP requirements
739   applicable to an origin server also apply to the outbound
740   communication of a gateway.  A gateway communicates with inbound
741   servers using any protocol that it desires, including private
742   extensions to HTTP that are outside the scope of this specification.
743   However, an HTTP-to-HTTP gateway that wishes to interoperate with
744   third-party HTTP servers MUST comply with HTTP user agent
745   requirements on the gateway's inbound connection and MUST implement
746   the Connection (Section 8.1) and Via (Section 8.8) header fields for
747   both connections.
748
749   A "tunnel" acts as a blind relay between two connections without
750   changing the messages.  Once active, a tunnel is not considered a
751   party to the HTTP communication, though the tunnel might have been
752   initiated by an HTTP request.  A tunnel ceases to exist when both
753   ends of the relayed connection are closed.  Tunnels are used to
754   extend a virtual connection through an intermediary, such as when
755   transport-layer security is used to establish private communication
756   through a shared firewall proxy.
757
758   In addition, there may exist network intermediaries that are not
759   considered part of the HTTP communication but nevertheless act as
760   filters or redirecting agents (usually violating HTTP semantics,
761   causing security problems, and otherwise making a mess of things).
762   Such a network intermediary, often referred to as an "interception
763   proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal",
764   differs from an HTTP proxy because it has not been selected by the
765   client.  Instead, the network intermediary redirects outgoing TCP
766   port 80 packets (and occasionally other common port traffic) to an
767   internal HTTP server.  Interception proxies are commonly found on
768   public network access points, as a means of enforcing account
769   subscription prior to allowing use of non-local Internet services,
770   and within corporate firewalls to enforce network usage policies.
771   They are indistinguishable from a man-in-the-middle attack.
772
7732.5.  Caches
774
775   A "cache" is a local store of previous response messages and the
776   subsystem that controls its message storage, retrieval, and deletion.
777   A cache stores cacheable responses in order to reduce the response
778   time and network bandwidth consumption on future, equivalent
779   requests.  Any client or server MAY employ a cache, though a cache
780
781
782
783Fielding, et al.          Expires July 7, 2012                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1                January 2012
786
787
788   cannot be used by a server while it is acting as a tunnel.
789
790   The effect of a cache is that the request/response chain is shortened
791   if one of the participants along the chain has a cached response
792   applicable to that request.  The following illustrates the resulting
793   chain if B has a cached copy of an earlier response from O (via C)
794   for a request which has not been cached by UA or A.
795
796               >             >
797          UA =========== A =========== B - - - - - - C - - - - - - O
798                     <             <
799
800   A response is "cacheable" if a cache is allowed to store a copy of
801   the response message for use in answering subsequent requests.  Even
802   when a response is cacheable, there might be additional constraints
803   placed by the client or by the origin server on when that cached
804   response can be used for a particular request.  HTTP requirements for
805   cache behavior and cacheable responses are defined in Section 2 of
806   [Part6].
807
808   There are a wide variety of architectures and configurations of
809   caches and proxies deployed across the World Wide Web and inside
810   large organizations.  These systems include national hierarchies of
811   proxy caches to save transoceanic bandwidth, systems that broadcast
812   or multicast cache entries, organizations that distribute subsets of
813   cached data via optical media, and so on.
814
8152.6.  Protocol Versioning
816
817   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
818   of the protocol.  This specification defines version "1.1".  The
819   protocol version as a whole indicates the sender's compliance with
820   the set of requirements laid out in that version's corresponding
821   specification of HTTP.
822
823   The version of an HTTP message is indicated by an HTTP-Version field
824   in the first line of the message.  HTTP-Version is case-sensitive.
825
826     HTTP-Version   = HTTP-Prot-Name "/" DIGIT "." DIGIT
827     HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
828
829   The HTTP version number consists of two decimal digits separated by a
830   "." (period or decimal point).  The first digit ("major version")
831   indicates the HTTP messaging syntax, whereas the second digit ("minor
832   version") indicates the highest minor version to which the sender is
833   at least conditionally compliant and able to understand for future
834   communication.  The minor version advertises the sender's
835   communication capabilities even when the sender is only using a
836
837
838
839Fielding, et al.          Expires July 7, 2012                 [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1                January 2012
842
843
844   backwards-compatible subset of the protocol, thereby letting the
845   recipient know that more advanced features can be used in response
846   (by servers) or in future requests (by clients).
847
848   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
849   or a recipient whose version is unknown, the HTTP/1.1 message is
850   constructed such that it can be interpreted as a valid HTTP/1.0
851   message if all of the newer features are ignored.  This specification
852   places recipient-version requirements on some new features so that a
853   compliant sender will only use compatible features until it has
854   determined, through configuration or the receipt of a message, that
855   the recipient supports HTTP/1.1.
856
857   The interpretation of an HTTP header field does not change between
858   minor versions of the same major version, though the default behavior
859   of a recipient in the absence of such a field can change.  Unless
860   specified otherwise, header fields defined in HTTP/1.1 are defined
861   for all versions of HTTP/1.x.  In particular, the Host and Connection
862   header fields ought to be implemented by all HTTP/1.x implementations
863   whether or not they advertise compliance with HTTP/1.1.
864
865   New header fields can be defined such that, when they are understood
866   by a recipient, they might override or enhance the interpretation of
867   previously defined header fields.  When an implementation receives an
868   unrecognized header field, the recipient MUST ignore that header
869   field for local processing regardless of the message's HTTP version.
870   An unrecognized header field received by a proxy MUST be forwarded
871   downstream unless the header field's field-name is listed in the
872   message's Connection header-field (see Section 8.1).  These
873   requirements allow HTTP's functionality to be enhanced without
874   requiring prior update of all compliant intermediaries.
875
876   Intermediaries that process HTTP messages (i.e., all intermediaries
877   other than those acting as a tunnel) MUST send their own HTTP-Version
878   in forwarded messages.  In other words, they MUST NOT blindly forward
879   the first line of an HTTP message without ensuring that the protocol
880   version matches what the intermediary understands, and is at least
881   conditionally compliant to, for both the receiving and sending of
882   messages.  Forwarding an HTTP message without rewriting the HTTP-
883   Version might result in communication errors when downstream
884   recipients use the message sender's version to determine what
885   features are safe to use for later communication with that sender.
886
887   An HTTP client SHOULD send a request version equal to the highest
888   version for which the client is at least conditionally compliant and
889   whose major version is no higher than the highest version supported
890   by the server, if this is known.  An HTTP client MUST NOT send a
891   version for which it is not at least conditionally compliant.
892
893
894
895Fielding, et al.          Expires July 7, 2012                 [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1                January 2012
898
899
900   An HTTP client MAY send a lower request version if it is known that
901   the server incorrectly implements the HTTP specification, but only
902   after the client has attempted at least one normal request and
903   determined from the response status or header fields (e.g., Server)
904   that the server improperly handles higher request versions.
905
906   An HTTP server SHOULD send a response version equal to the highest
907   version for which the server is at least conditionally compliant and
908   whose major version is less than or equal to the one received in the
909   request.  An HTTP server MUST NOT send a version for which it is not
910   at least conditionally compliant.  A server MAY send a 505 (HTTP
911   Version Not Supported) response if it cannot send a response using
912   the major version used in the client's request.
913
914   An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
915   if it is known or suspected that the client incorrectly implements
916   the HTTP specification and is incapable of correctly processing later
917   version responses, such as when a client fails to parse the version
918   number correctly or when an intermediary is known to blindly forward
919   the HTTP-Version even when it doesn't comply with the given minor
920   version of the protocol.  Such protocol downgrades SHOULD NOT be
921   performed unless triggered by specific client attributes, such as
922   when one or more of the request header fields (e.g., User-Agent)
923   uniquely match the values sent by a client known to be in error.
924
925   The intention of HTTP's versioning design is that the major number
926   will only be incremented if an incompatible message syntax is
927   introduced, and that the minor number will only be incremented when
928   changes made to the protocol have the effect of adding to the message
929   semantics or implying additional capabilities of the sender.
930   However, the minor version was not incremented for the changes
931   introduced between [RFC2068] and [RFC2616], and this revision is
932   specifically avoiding any such changes to the protocol.
933
9342.7.  Uniform Resource Identifiers
935
936   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
937   HTTP as the means for identifying resources.  URI references are used
938   to target requests, indicate redirects, and define relationships.
939   HTTP does not limit what a resource might be; it merely defines an
940   interface that can be used to interact with a resource via HTTP.
941   More information on the scope of URIs and resources can be found in
942   [RFC3986].
943
944   This specification adopts the definitions of "URI-reference",
945   "absolute-URI", "relative-part", "port", "host", "path-abempty",
946   "path-absolute", "query", and "authority" from the URI generic syntax
947   [RFC3986].  In addition, we define a partial-URI rule for protocol
948
949
950
951Fielding, et al.          Expires July 7, 2012                 [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1                January 2012
954
955
956   elements that allow a relative URI but not a fragment.
957
958     URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
959     absolute-URI  = <absolute-URI, defined in [RFC3986], Section 4.3>
960     relative-part = <relative-part, defined in [RFC3986], Section 4.2>
961     authority     = <authority, defined in [RFC3986], Section 3.2>
962     path-abempty  = <path-abempty, defined in [RFC3986], Section 3.3>
963     path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
964     port          = <port, defined in [RFC3986], Section 3.2.3>
965     query         = <query, defined in [RFC3986], Section 3.4>
966     uri-host      = <host, defined in [RFC3986], Section 3.2.2>
967
968     partial-URI   = relative-part [ "?" query ]
969
970   Each protocol element in HTTP that allows a URI reference will
971   indicate in its ABNF production whether the element allows any form
972   of reference (URI-reference), only a URI in absolute form (absolute-
973   URI), only the path and optional query components, or some
974   combination of the above.  Unless otherwise indicated, URI references
975   are parsed relative to the effective request URI, which defines the
976   default base URI for references in both the request and its
977   corresponding response.
978
9792.7.1.  http URI scheme
980
981   The "http" URI scheme is hereby defined for the purpose of minting
982   identifiers according to their association with the hierarchical
983   namespace governed by a potential HTTP origin server listening for
984   TCP connections on a given port.
985
986     http-URI = "http:" "//" authority path-abempty [ "?" query ]
987
988   The HTTP origin server is identified by the generic syntax's
989   authority component, which includes a host identifier and optional
990   TCP port ([RFC3986], Section 3.2.2).  The remainder of the URI,
991   consisting of both the hierarchical path component and optional query
992   component, serves as an identifier for a potential resource within
993   that origin server's name space.
994
995   If the host identifier is provided as an IP literal or IPv4 address,
996   then the origin server is any listener on the indicated TCP port at
997   that IP address.  If host is a registered name, then that name is
998   considered an indirect identifier and the recipient might use a name
999   resolution service, such as DNS, to find the address of a listener
1000   for that host.  The host MUST NOT be empty; if an "http" URI is
1001   received with an empty host, then it MUST be rejected as invalid.  If
1002   the port subcomponent is empty or not given, then TCP port 80 is
1003   assumed (the default reserved port for WWW services).
1004
1005
1006
1007Fielding, et al.          Expires July 7, 2012                 [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1                January 2012
1010
1011
1012   Regardless of the form of host identifier, access to that host is not
1013   implied by the mere presence of its name or address.  The host might
1014   or might not exist and, even when it does exist, might or might not
1015   be running an HTTP server or listening to the indicated port.  The
1016   "http" URI scheme makes use of the delegated nature of Internet names
1017   and addresses to establish a naming authority (whatever entity has
1018   the ability to place an HTTP server at that Internet name or address)
1019   and allows that authority to determine which names are valid and how
1020   they might be used.
1021
1022   When an "http" URI is used within a context that calls for access to
1023   the indicated resource, a client MAY attempt access by resolving the
1024   host to an IP address, establishing a TCP connection to that address
1025   on the indicated port, and sending an HTTP request message
1026   (Section 3) containing the URI's identifying data (Section 4) to the
1027   server.  If the server responds to that request with a non-interim
1028   HTTP response message, as described in Section 4 of [Part2], then
1029   that response is considered an authoritative answer to the client's
1030   request.
1031
1032   Although HTTP is independent of the transport protocol, the "http"
1033   scheme is specific to TCP-based services because the name delegation
1034   process depends on TCP for establishing authority.  An HTTP service
1035   based on some other underlying connection protocol would presumably
1036   be identified using a different URI scheme, just as the "https"
1037   scheme (below) is used for servers that require an SSL/TLS transport
1038   layer on a connection.  Other protocols might also be used to provide
1039   access to "http" identified resources -- it is only the authoritative
1040   interface used for mapping the namespace that is specific to TCP.
1041
1042   The URI generic syntax for authority also includes a deprecated
1043   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
1044   authentication information in the URI.  Some implementations make use
1045   of the userinfo component for internal configuration of
1046   authentication information, such as within command invocation
1047   options, configuration files, or bookmark lists, even though such
1048   usage might expose a user identifier or password.  Senders MUST NOT
1049   include a userinfo subcomponent (and its "@" delimiter) when
1050   transmitting an "http" URI in a message.  Recipients of HTTP messages
1051   that contain a URI reference SHOULD parse for the existence of
1052   userinfo and treat its presence as an error, likely indicating that
1053   the deprecated subcomponent is being used to obscure the authority
1054   for the sake of phishing attacks.
1055
10562.7.2.  https URI scheme
1057
1058   The "https" URI scheme is hereby defined for the purpose of minting
1059   identifiers according to their association with the hierarchical
1060
1061
1062
1063Fielding, et al.          Expires July 7, 2012                 [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1                January 2012
1066
1067
1068   namespace governed by a potential HTTP origin server listening for
1069   SSL/TLS-secured connections on a given TCP port.
1070
1071   All of the requirements listed above for the "http" scheme are also
1072   requirements for the "https" scheme, except that a default TCP port
1073   of 443 is assumed if the port subcomponent is empty or not given, and
1074   the TCP connection MUST be secured for privacy through the use of
1075   strong encryption prior to sending the first HTTP request.
1076
1077     https-URI = "https:" "//" authority path-abempty [ "?" query ]
1078
1079   Unlike the "http" scheme, responses to "https" identified requests
1080   are never "public" and thus MUST NOT be reused for shared caching.
1081   They can, however, be reused in a private cache if the message is
1082   cacheable by default in HTTP or specifically indicated as such by the
1083   Cache-Control header field (Section 3.2 of [Part6]).
1084
1085   Resources made available via the "https" scheme have no shared
1086   identity with the "http" scheme even if their resource identifiers
1087   indicate the same authority (the same host listening to the same TCP
1088   port).  They are distinct name spaces and are considered to be
1089   distinct origin servers.  However, an extension to HTTP that is
1090   defined to apply to entire host domains, such as the Cookie protocol
1091   [RFC6265], can allow information set by one service to impact
1092   communication with other services within a matching group of host
1093   domains.
1094
1095   The process for authoritative access to an "https" identified
1096   resource is defined in [RFC2818].
1097
10982.7.3.  http and https URI Normalization and Comparison
1099
1100   Since the "http" and "https" schemes conform to the URI generic
1101   syntax, such URIs are normalized and compared according to the
1102   algorithm defined in [RFC3986], Section 6, using the defaults
1103   described above for each scheme.
1104
1105   If the port is equal to the default port for a scheme, the normal
1106   form is to elide the port subcomponent.  Likewise, an empty path
1107   component is equivalent to an absolute path of "/", so the normal
1108   form is to provide a path of "/" instead.  The scheme and host are
1109   case-insensitive and normally provided in lowercase; all other
1110   components are compared in a case-sensitive manner.  Characters other
1111   than those in the "reserved" set are equivalent to their percent-
1112   encoded octets (see [RFC3986], Section 2.1): the normal form is to
1113   not encode them.
1114
1115   For example, the following three URIs are equivalent:
1116
1117
1118
1119Fielding, et al.          Expires July 7, 2012                 [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1                January 2012
1122
1123
1124      http://example.com:80/~smith/home.html
1125      http://EXAMPLE.com/%7Esmith/home.html
1126      http://EXAMPLE.com:/%7esmith/home.html
1127
11283.  Message Format
1129
1130   All HTTP/1.1 messages consist of a start-line followed by a sequence
1131   of octets in a format similar to the Internet Message Format
1132   [RFC5322]: zero or more header fields (collectively referred to as
1133   the "headers" or the "header section"), an empty line indicating the
1134   end of the header section, and an optional message-body.
1135
1136     HTTP-message    = start-line
1137                       *( header-field CRLF )
1138                       CRLF
1139                       [ message-body ]
1140
1141   The normal procedure for parsing an HTTP message is to read the
1142   start-line into a structure, read each header field into a hash table
1143   by field name until the empty line, and then use the parsed data to
1144   determine if a message-body is expected.  If a message-body has been
1145   indicated, then it is read as a stream until an amount of octets
1146   equal to the message-body length is read or the connection is closed.
1147
1148   Recipients MUST parse an HTTP message as a sequence of octets in an
1149   encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
1150   message as a stream of Unicode characters, without regard for the
1151   specific encoding, creates security vulnerabilities due to the
1152   varying ways that string processing libraries handle invalid
1153   multibyte character sequences that contain the octet LF (%x0A).
1154   String-based parsers can only be safely used within protocol elements
1155   after the element has been extracted from the message, such as within
1156   a header field-value after message parsing has delineated the
1157   individual fields.
1158
11593.1.  Start Line
1160
1161   An HTTP message can either be a request from client to server or a
1162   response from server to client.  Syntactically, the two types of
1163   message differ only in the start-line, which is either a Request-Line
1164   (for requests) or a Status-Line (for responses), and in the algorithm
1165   for determining the length of the message-body (Section 3.3).  In
1166   theory, a client could receive requests and a server could receive
1167   responses, distinguishing them by their different start-line formats,
1168   but in practice servers are implemented to only expect a request (a
1169   response is interpreted as an unknown or invalid request method) and
1170   clients are implemented to only expect a response.
1171
1172
1173
1174
1175Fielding, et al.          Expires July 7, 2012                 [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1                January 2012
1178
1179
1180     start-line      = Request-Line / Status-Line
1181
1182   Implementations MUST NOT send whitespace between the start-line and
1183   the first header field.  The presence of such whitespace in a request
1184   might be an attempt to trick a server into ignoring that field or
1185   processing the line after it as a new request, either of which might
1186   result in a security vulnerability if other implementations within
1187   the request chain interpret the same message differently.  Likewise,
1188   the presence of such whitespace in a response might be ignored by
1189   some clients or cause others to cease parsing.
1190
11913.1.1.  Request-Line
1192
1193   The Request-Line begins with a method token, followed by a single
1194   space (SP), the request-target, another single space (SP), the
1195   protocol version, and ending with CRLF.
1196
1197     Request-Line   = Method SP request-target SP HTTP-Version CRLF
1198
11993.1.1.1.  Method
1200
1201   The Method token indicates the request method to be performed on the
1202   target resource.  The request method is case-sensitive.
1203
1204     Method         = token
1205
1206   See Section 2 of [Part2] for further information, such as the list of
1207   methods defined by this specification, the IANA registry, and
1208   considerations for new methods.
1209
12103.1.1.2.  request-target
1211
1212   The request-target identifies the target resource upon which to apply
1213   the request.  The four options for request-target are described in
1214   Section 4.1.
1215
1216     request-target = "*"
1217                    / absolute-URI
1218                    / ( path-absolute [ "?" query ] )
1219                    / authority
1220
1221   HTTP does not place a pre-defined limit on the length of a request-
1222   target.  A server MUST be prepared to receive URIs of unbounded
1223   length and respond with the 414 (URI Too Long) status code if the
1224   received request-target would be longer than the server wishes to
1225   handle (see Section 7.4.15 of [Part2]).
1226
1227   Various ad-hoc limitations on request-target length are found in
1228
1229
1230
1231Fielding, et al.          Expires July 7, 2012                 [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1                January 2012
1234
1235
1236   practice.  It is RECOMMENDED that all HTTP senders and recipients
1237   support request-target lengths of 8000 or more octets.
1238
1239      Note: Fragments ([RFC3986], Section 3.5) are not part of the
1240      request-target and thus will not be transmitted in an HTTP
1241      request.
1242
12433.1.2.  Response Status-Line
1244
1245   The first line of a Response message is the Status-Line, consisting
1246   of the protocol version, a space (SP), the status code, another
1247   space, a possibly-empty textual phrase describing the status code,
1248   and ending with CRLF.
1249
1250     Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1251
12523.1.2.1.  Status Code
1253
1254   The Status-Code element is a 3-digit integer result code of the
1255   attempt to understand and satisfy the request.  See Section 4 of
1256   [Part2] for further information, such as the list of status codes
1257   defined by this specification, the IANA registry, and considerations
1258   for new status codes.
1259
1260     Status-Code    = 3DIGIT
1261
12623.1.2.2.  Reason Phrase
1263
1264   The Reason Phrase exists for the sole purpose of providing a textual
1265   description associated with the numeric status code, out of deference
1266   to earlier Internet application protocols that were more frequently
1267   used with interactive text clients.  A client SHOULD ignore the
1268   content of the Reason Phrase.
1269
1270     Reason-Phrase  = *( HTAB / SP / VCHAR / obs-text )
1271
12723.2.  Header Fields
1273
1274   Each HTTP header field consists of a case-insensitive field name
1275   followed by a colon (":"), optional whitespace, and the field value.
1276
1277     header-field   = field-name ":" OWS field-value BWS
1278     field-name     = token
1279     field-value    = *( field-content / obs-fold )
1280     field-content  = *( HTAB / SP / VCHAR / obs-text )
1281
1282   The field-name token labels the corresponding field-value as having
1283   the semantics defined by that header field.  For example, the Date
1284
1285
1286
1287Fielding, et al.          Expires July 7, 2012                 [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1                January 2012
1290
1291
1292   header field is defined in Section 9.2 of [Part2] as containing the
1293   origination timestamp for the message in which it appears.
1294
1295   HTTP header fields are fully extensible: there is no limit on the
1296   introduction of new field names, each presumably defining new
1297   semantics, or on the number of header fields used in a given message.
1298   Existing fields are defined in each part of this specification and in
1299   many other specifications outside the standards process.  New header
1300   fields can be introduced without changing the protocol version if
1301   their defined semantics allow them to be safely ignored by recipients
1302   that do not recognize them.
1303
1304   New HTTP header fields SHOULD be registered with IANA according to
1305   the procedures in Section 3.1 of [Part2].  Unrecognized header fields
1306   MUST be forwarded by a proxy unless the field-name is listed in the
1307   Connection header field (Section 8.1) or the proxy is specifically
1308   configured to block or otherwise transform such fields.  Unrecognized
1309   header fields SHOULD be ignored by other recipients.
1310
1311   The order in which header fields with differing field names are
1312   received is not significant.  However, it is "good practice" to send
1313   header fields that contain control data first, such as Host on
1314   requests and Date on responses, so that implementations can decide
1315   when not to handle a message as early as possible.  A server MUST
1316   wait until the entire header section is received before interpreting
1317   a request message, since later header fields might include
1318   conditionals, authentication credentials, or deliberately misleading
1319   duplicate header fields that would impact request processing.
1320
1321   Multiple header fields with the same field name MUST NOT be sent in a
1322   message unless the entire field value for that header field is
1323   defined as a comma-separated list [i.e., #(values)].  Multiple header
1324   fields with the same field name can be combined into one "field-name:
1325   field-value" pair, without changing the semantics of the message, by
1326   appending each subsequent field value to the combined field value in
1327   order, separated by a comma.  The order in which header fields with
1328   the same field name are received is therefore significant to the
1329   interpretation of the combined field value; a proxy MUST NOT change
1330   the order of these field values when forwarding a message.
1331
1332      Note: The "Set-Cookie" header field as implemented in practice can
1333      occur multiple times, but does not use the list syntax, and thus
1334      cannot be combined into a single line ([RFC6265]).  (See Appendix
1335      A.2.3 of [Kri2001] for details.)  Also note that the Set-Cookie2
1336      header field specified in [RFC2965] does not share this problem.
1337
1338
1339
1340
1341
1342
1343Fielding, et al.          Expires July 7, 2012                 [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1                January 2012
1346
1347
13483.2.1.  Field Parsing
1349
1350   No whitespace is allowed between the header field-name and colon.  In
1351   the past, differences in the handling of such whitespace have led to
1352   security vulnerabilities in request routing and response handling.
1353   Any received request message that contains whitespace between a
1354   header field-name and colon MUST be rejected with a response code of
1355   400 (Bad Request).  A proxy MUST remove any such whitespace from a
1356   response message before forwarding the message downstream.
1357
1358   A field value MAY be preceded by optional whitespace (OWS); a single
1359   SP is preferred.  The field value does not include any leading or
1360   trailing white space: OWS occurring before the first non-whitespace
1361   octet of the field value or after the last non-whitespace octet of
1362   the field value is ignored and SHOULD be removed before further
1363   processing (as this does not change the meaning of the header field).
1364
1365   Historically, HTTP header field values could be extended over
1366   multiple lines by preceding each extra line with at least one space
1367   or horizontal tab (obs-fold).  This specification deprecates such
1368   line folding except within the message/http media type
1369   (Section 9.3.1).  HTTP senders MUST NOT produce messages that include
1370   line folding (i.e., that contain any field-content that matches the
1371   obs-fold rule) unless the message is intended for packaging within
1372   the message/http media type.  HTTP recipients SHOULD accept line
1373   folding and replace any embedded obs-fold whitespace with either a
1374   single SP or a matching number of SP octets (to avoid buffer copying)
1375   prior to interpreting the field value or forwarding the message
1376   downstream.
1377
1378   Historically, HTTP has allowed field content with text in the ISO-
1379   8859-1 [ISO-8859-1] character encoding and supported other character
1380   sets only through use of [RFC2047] encoding.  In practice, most HTTP
1381   header field values use only a subset of the US-ASCII character
1382   encoding [USASCII].  Newly defined header fields SHOULD limit their
1383   field values to US-ASCII octets.  Recipients SHOULD treat other (obs-
1384   text) octets in field content as opaque data.
1385
13863.2.2.  Field Length
1387
1388   HTTP does not place a pre-defined limit on the length of header
1389   fields, either in isolation or as a set.  A server MUST be prepared
1390   to receive request header fields of unbounded length and respond with
1391   a 4xx status code if the received header field(s) would be longer
1392   than the server wishes to handle.
1393
1394   A client that receives response headers that are longer than it
1395   wishes to handle can only treat it as a server error.
1396
1397
1398
1399Fielding, et al.          Expires July 7, 2012                 [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1                January 2012
1402
1403
1404   Various ad-hoc limitations on header length are found in practice.
1405   It is RECOMMENDED that all HTTP senders and recipients support
1406   messages whose combined header fields have 4000 or more octets.
1407
14083.2.3.  Common Field ABNF Rules
1409
1410   Many HTTP/1.1 header field values consist of words (token or quoted-
1411   string) separated by whitespace or special characters.  These special
1412   characters MUST be in a quoted string to be used within a parameter
1413   value (as defined in Section 5.1).
1414
1415     word           = token / quoted-string
1416
1417     token          = 1*tchar
1418
1419     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1420                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1421                    / DIGIT / ALPHA
1422                    ; any VCHAR, except special
1423
1424     special        = "(" / ")" / "<" / ">" / "@" / ","
1425                    / ";" / ":" / "\" / DQUOTE / "/" / "["
1426                    / "]" / "?" / "=" / "{" / "}"
1427
1428   A string of text is parsed as a single word if it is quoted using
1429   double-quote marks.
1430
1431     quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1432     qdtext         = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
1433     obs-text       = %x80-FF
1434
1435   The backslash octet ("\") can be used as a single-octet quoting
1436   mechanism within quoted-string constructs:
1437
1438     quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
1439
1440   Recipients that process the value of the quoted-string MUST handle a
1441   quoted-pair as if it were replaced by the octet following the
1442   backslash.
1443
1444   Senders SHOULD NOT escape octets in quoted-strings that do not
1445   require escaping (i.e., other than DQUOTE and the backslash octet).
1446
1447   Comments can be included in some HTTP header fields by surrounding
1448   the comment text with parentheses.  Comments are only allowed in
1449   fields containing "comment" as part of their field value definition.
1450
1451     comment        = "(" *( ctext / quoted-cpair / comment ) ")"
1452
1453
1454
1455Fielding, et al.          Expires July 7, 2012                 [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1                January 2012
1458
1459
1460     ctext          = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1461
1462   The backslash octet ("\") can be used as a single-octet quoting
1463   mechanism within comment constructs:
1464
1465     quoted-cpair    = "\" ( HTAB / SP / VCHAR / obs-text )
1466
1467   Senders SHOULD NOT escape octets in comments that do not require
1468   escaping (i.e., other than the backslash octet "\" and the
1469   parentheses "(" and ")").
1470
14713.3.  Message Body
1472
1473   The message-body (if any) of an HTTP message is used to carry the
1474   payload body associated with the request or response.
1475
1476     message-body = *OCTET
1477
1478   The message-body differs from the payload body only when a transfer-
1479   coding has been applied, as indicated by the Transfer-Encoding header
1480   field (Section 8.6).  If more than one Transfer-Encoding header field
1481   is present in a message, the multiple field-values MUST be combined
1482   into one field-value, according to the algorithm defined in
1483   Section 3.2, before determining the message-body length.
1484
1485   When one or more transfer-codings are applied to a payload in order
1486   to form the message-body, the Transfer-Encoding header field MUST
1487   contain the list of transfer-codings applied.  Transfer-Encoding is a
1488   property of the message, not of the payload, and thus MAY be added or
1489   removed by any implementation along the request/response chain under
1490   the constraints found in Section 5.1.
1491
1492   If a message is received that has multiple Content-Length header
1493   fields (Section 8.2) with field-values consisting of the same decimal
1494   value, or a single Content-Length header field with a field value
1495   containing a list of identical decimal values (e.g., "Content-Length:
1496   42, 42"), indicating that duplicate Content-Length header fields have
1497   been generated or combined by an upstream message processor, then the
1498   recipient MUST either reject the message as invalid or replace the
1499   duplicated field-values with a single valid Content-Length field
1500   containing that decimal value prior to determining the message-body
1501   length.
1502
1503   The rules for when a message-body is allowed in a message differ for
1504   requests and responses.
1505
1506   The presence of a message-body in a request is signaled by the
1507   inclusion of a Content-Length or Transfer-Encoding header field in
1508
1509
1510
1511Fielding, et al.          Expires July 7, 2012                 [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1                January 2012
1514
1515
1516   the request's header fields, even if the request method does not
1517   define any use for a message-body.  This allows the request message
1518   framing algorithm to be independent of method semantics.
1519
1520   For response messages, whether or not a message-body is included with
1521   a message is dependent on both the request method and the response
1522   status code (Section 3.1.2.1).  Responses to the HEAD request method
1523   never include a message-body because the associated response header
1524   fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
1525   what their values would have been if the request method had been GET.
1526   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
1527   responses MUST NOT include a message-body.  All other responses do
1528   include a message-body, although the body MAY be of zero length.
1529
1530   The length of the message-body is determined by one of the following
1531   (in order of precedence):
1532
1533   1.  Any response to a HEAD request and any response with a status
1534       code of 100-199, 204, or 304 is always terminated by the first
1535       empty line after the header fields, regardless of the header
1536       fields present in the message, and thus cannot contain a message-
1537       body.
1538
1539   2.  If a Transfer-Encoding header field is present and the "chunked"
1540       transfer-coding (Section 5.1) is the final encoding, the message-
1541       body length is determined by reading and decoding the chunked
1542       data until the transfer-coding indicates the data is complete.
1543
1544       If a Transfer-Encoding header field is present in a response and
1545       the "chunked" transfer-coding is not the final encoding, the
1546       message-body length is determined by reading the connection until
1547       it is closed by the server.  If a Transfer-Encoding header field
1548       is present in a request and the "chunked" transfer-coding is not
1549       the final encoding, the message-body length cannot be determined
1550       reliably; the server MUST respond with the 400 (Bad Request)
1551       status code and then close the connection.
1552
1553       If a message is received with both a Transfer-Encoding header
1554       field and a Content-Length header field, the Transfer-Encoding
1555       overrides the Content-Length.  Such a message might indicate an
1556       attempt to perform request or response smuggling (bypass of
1557       security-related checks on message routing or content) and thus
1558       ought to be handled as an error.  The provided Content-Length
1559       MUST be removed, prior to forwarding the message downstream, or
1560       replaced with the real message-body length after the transfer-
1561       coding is decoded.
1562
1563
1564
1565
1566
1567Fielding, et al.          Expires July 7, 2012                 [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1                January 2012
1570
1571
1572   3.  If a message is received without Transfer-Encoding and with
1573       either multiple Content-Length header fields having differing
1574       field-values or a single Content-Length header field having an
1575       invalid value, then the message framing is invalid and MUST be
1576       treated as an error to prevent request or response smuggling.  If
1577       this is a request message, the server MUST respond with a 400
1578       (Bad Request) status code and then close the connection.  If this
1579       is a response message received by a proxy, the proxy MUST discard
1580       the received response, send a 502 (Bad Gateway) status code as
1581       its downstream response, and then close the connection.  If this
1582       is a response message received by a user-agent, it MUST be
1583       treated as an error by discarding the message and closing the
1584       connection.
1585
1586   4.  If a valid Content-Length header field is present without
1587       Transfer-Encoding, its decimal value defines the message-body
1588       length in octets.  If the actual number of octets sent in the
1589       message is less than the indicated Content-Length, the recipient
1590       MUST consider the message to be incomplete and treat the
1591       connection as no longer usable.  If the actual number of octets
1592       sent in the message is more than the indicated Content-Length,
1593       the recipient MUST only process the message-body up to the field
1594       value's number of octets; the remainder of the message MUST
1595       either be discarded or treated as the next message in a pipeline.
1596       For the sake of robustness, a user-agent MAY attempt to detect
1597       and correct such an error in message framing if it is parsing the
1598       response to the last request on a connection and the connection
1599       has been closed by the server.
1600
1601   5.  If this is a request message and none of the above are true, then
1602       the message-body length is zero (no message-body is present).
1603
1604   6.  Otherwise, this is a response message without a declared message-
1605       body length, so the message-body length is determined by the
1606       number of octets received prior to the server closing the
1607       connection.
1608
1609   Since there is no way to distinguish a successfully completed, close-
1610   delimited message from a partially-received message interrupted by
1611   network failure, implementations SHOULD use encoding or length-
1612   delimited messages whenever possible.  The close-delimiting feature
1613   exists primarily for backwards compatibility with HTTP/1.0.
1614
1615   A server MAY reject a request that contains a message-body but not a
1616   Content-Length by responding with 411 (Length Required).
1617
1618   Unless a transfer-coding other than "chunked" has been applied, a
1619   client that sends a request containing a message-body SHOULD use a
1620
1621
1622
1623Fielding, et al.          Expires July 7, 2012                 [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1                January 2012
1626
1627
1628   valid Content-Length header field if the message-body length is known
1629   in advance, rather than the "chunked" encoding, since some existing
1630   services respond to "chunked" with a 411 (Length Required) status
1631   code even though they understand the chunked encoding.  This is
1632   typically because such services are implemented via a gateway that
1633   requires a content-length in advance of being called and the server
1634   is unable or unwilling to buffer the entire request before
1635   processing.
1636
1637   A client that sends a request containing a message-body MUST include
1638   a valid Content-Length header field if it does not know the server
1639   will handle HTTP/1.1 (or later) requests; such knowledge can be in
1640   the form of specific user configuration or by remembering the version
1641   of a prior received response.
1642
16433.4.  Handling Incomplete Messages
1644
1645   Request messages that are prematurely terminated, possibly due to a
1646   cancelled connection or a server-imposed time-out exception, MUST
1647   result in closure of the connection; sending an HTTP/1.1 error
1648   response prior to closing the connection is OPTIONAL.
1649
1650   Response messages that are prematurely terminated, usually by closure
1651   of the connection prior to receiving the expected number of octets or
1652   by failure to decode a transfer-encoded message-body, MUST be
1653   recorded as incomplete.  A response that terminates in the middle of
1654   the header block (before the empty line is received) cannot be
1655   assumed to convey the full semantics of the response and MUST be
1656   treated as an error.
1657
1658   A message-body that uses the chunked transfer encoding is incomplete
1659   if the zero-sized chunk that terminates the encoding has not been
1660   received.  A message that uses a valid Content-Length is incomplete
1661   if the size of the message-body received (in octets) is less than the
1662   value given by Content-Length.  A response that has neither chunked
1663   transfer encoding nor Content-Length is terminated by closure of the
1664   connection, and thus is considered complete regardless of the number
1665   of message-body octets received, provided that the header block was
1666   received intact.
1667
1668   A user agent MUST NOT render an incomplete response message-body as
1669   if it were complete (i.e., some indication must be given to the user
1670   that an error occurred).  Cache requirements for incomplete responses
1671   are defined in Section 2.1 of [Part6].
1672
1673   A server MUST read the entire request message-body or close the
1674   connection after sending its response, since otherwise the remaining
1675   data on a persistent connection would be misinterpreted as the next
1676
1677
1678
1679Fielding, et al.          Expires July 7, 2012                 [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1                January 2012
1682
1683
1684   request.  Likewise, a client MUST read the entire response message-
1685   body if it intends to reuse the same connection for a subsequent
1686   request.  Pipelining multiple requests on a connection is described
1687   in Section 6.1.2.2.
1688
16893.5.  Message Parsing Robustness
1690
1691   Older HTTP/1.0 client implementations might send an extra CRLF after
1692   a POST request as a lame workaround for some early server
1693   applications that failed to read message-body content that was not
1694   terminated by a line-ending.  An HTTP/1.1 client MUST NOT preface or
1695   follow a request with an extra CRLF.  If terminating the request
1696   message-body with a line-ending is desired, then the client MUST
1697   include the terminating CRLF octets as part of the message-body
1698   length.
1699
1700   In the interest of robustness, servers SHOULD ignore at least one
1701   empty line received where a Request-Line is expected.  In other
1702   words, if the server is reading the protocol stream at the beginning
1703   of a message and receives a CRLF first, it SHOULD ignore the CRLF.
1704   Likewise, although the line terminator for the start-line and header
1705   fields is the sequence CRLF, we recommend that recipients recognize a
1706   single LF as a line terminator and ignore any CR.
1707
1708   When a server listening only for HTTP request messages, or processing
1709   what appears from the start-line to be an HTTP request message,
1710   receives a sequence of octets that does not match the HTTP-message
1711   grammar aside from the robustness exceptions listed above, the server
1712   MUST respond with an HTTP/1.1 400 (Bad Request) response.
1713
17144.  Message Routing
1715
1716   In most cases, the user agent is provided a URI reference from which
1717   it determines an absolute URI for identifying the target resource.
1718   When a request to the resource is initiated, all or part of that URI
1719   is used to construct the HTTP request-target.
1720
17214.1.  Types of Request Target
1722
1723   The four options for request-target are dependent on the nature of
1724   the request.
1725
1726   The asterisk "*" form of request-target, which MUST NOT be used with
1727   any request method other than OPTIONS, means that the request applies
1728   to the server as a whole (the listening process) rather than to a
1729   specific named resource at that server.  For example,
1730
1731     OPTIONS * HTTP/1.1
1732
1733
1734
1735Fielding, et al.          Expires July 7, 2012                 [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1                January 2012
1738
1739
1740   The "absolute-URI" form is REQUIRED when the request is being made to
1741   a proxy.  The proxy is requested to either forward the request or
1742   service it from a valid cache, and then return the response.  Note
1743   that the proxy MAY forward the request on to another proxy or
1744   directly to the server specified by the absolute-URI.  In order to
1745   avoid request loops, a proxy that forwards requests to other proxies
1746   MUST be able to recognize and exclude all of its own server names,
1747   including any aliases, local variations, and the numeric IP address.
1748   An example Request-Line would be:
1749
1750     GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1751
1752   To allow for transition to absolute-URIs in all requests in future
1753   versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
1754   form in requests, even though HTTP/1.1 clients will only generate
1755   them in requests to proxies.
1756
1757   If a proxy receives a host name that is not a fully qualified domain
1758   name, it MAY add its domain to the host name it received.  If a proxy
1759   receives a fully qualified domain name, the proxy MUST NOT change the
1760   host name.
1761
1762   The "authority form" is only used by the CONNECT request method
1763   (Section 6.9 of [Part2]).
1764
1765   The most common form of request-target is that used when making a
1766   request to an origin server ("origin form").  In this case, the
1767   absolute path and query components of the URI MUST be transmitted as
1768   the request-target, and the authority component MUST be transmitted
1769   in a Host header field.  For example, a client wishing to retrieve a
1770   representation of the resource, as identified above, directly from
1771   the origin server would open (or reuse) a TCP connection to port 80
1772   of the host "www.example.org" and send the lines:
1773
1774     GET /pub/WWW/TheProject.html HTTP/1.1
1775     Host: www.example.org
1776
1777   followed by the remainder of the Request.  Note that the origin form
1778   of request-target always starts with an absolute path; if the target
1779   resource's URI path is empty, then an absolute path of "/" MUST be
1780   provided in the request-target.
1781
1782   If a proxy receives an OPTIONS request with an absolute-URI form of
1783   request-target in which the URI has an empty path and no query
1784   component, then the last proxy on the request chain MUST use a
1785   request-target of "*" when it forwards the request to the indicated
1786   origin server.
1787
1788
1789
1790
1791Fielding, et al.          Expires July 7, 2012                 [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1                January 2012
1794
1795
1796   For example, the request
1797
1798     OPTIONS http://www.example.org:8001 HTTP/1.1
1799
1800   would be forwarded by the final proxy as
1801
1802     OPTIONS * HTTP/1.1
1803     Host: www.example.org:8001
1804
1805   after connecting to port 8001 of host "www.example.org".
1806
1807   The request-target is transmitted in the format specified in
1808   Section 2.7.1.  If the request-target is percent-encoded ([RFC3986],
1809   Section 2.1), the origin server MUST decode the request-target in
1810   order to properly interpret the request.  Servers SHOULD respond to
1811   invalid request-targets with an appropriate status code.
1812
1813   A non-transforming proxy MUST NOT rewrite the "path-absolute" and
1814   "query" parts of the received request-target when forwarding it to
1815   the next inbound server, except as noted above to replace a null
1816   path-absolute with "/" or "*".
1817
1818      Note: The "no rewrite" rule prevents the proxy from changing the
1819      meaning of the request when the origin server is improperly using
1820      a non-reserved URI character for a reserved purpose.  Implementors
1821      need to be aware that some pre-HTTP/1.1 proxies have been known to
1822      rewrite the request-target.
1823
18244.2.  The Resource Identified by a Request
1825
1826   The exact resource identified by an Internet request is determined by
1827   examining both the request-target and the Host header field.
1828
1829   An origin server that does not allow resources to differ by the
1830   requested host MAY ignore the Host header field value when
1831   determining the resource identified by an HTTP/1.1 request.  (But see
1832   Appendix A.1.1 for other requirements on Host support in HTTP/1.1.)
1833
1834   An origin server that does differentiate resources based on the host
1835   requested (sometimes referred to as virtual hosts or vanity host
1836   names) MUST use the following rules for determining the requested
1837   resource on an HTTP/1.1 request:
1838
1839   1.  If request-target is an absolute-URI, the host is part of the
1840       request-target.  Any Host header field value in the request MUST
1841       be ignored.
1842
1843
1844
1845
1846
1847Fielding, et al.          Expires July 7, 2012                 [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1                January 2012
1850
1851
1852   2.  If the request-target is not an absolute-URI, and the request
1853       includes a Host header field, the host is determined by the Host
1854       header field value.
1855
1856   3.  If the host as determined by rule 1 or 2 is not a valid host on
1857       the server, the response MUST be a 400 (Bad Request) error
1858       message.
1859
1860   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1861   attempt to use heuristics (e.g., examination of the URI path for
1862   something unique to a particular host) in order to determine what
1863   exact resource is being requested.
1864
18654.3.  Effective Request URI
1866
1867   HTTP requests often do not carry the absolute URI ([RFC3986], Section
1868   4.3) for the target resource; instead, the URI needs to be inferred
1869   from the request-target, Host header field, and connection context.
1870   The result of this process is called the "effective request URI".
1871   The "target resource" is the resource identified by the effective
1872   request URI.
1873
1874   If the request-target is an absolute-URI, then the effective request
1875   URI is the request-target.
1876
1877   If the request-target uses the origin form or the asterisk form, and
1878   the Host header field is present, then the effective request URI is
1879   constructed by concatenating
1880
1881   o  the scheme name: "http" if the request was received over an
1882      insecure TCP connection, or "https" when received over a SSL/
1883      TLS-secured TCP connection,
1884
1885   o  the octet sequence "://",
1886
1887   o  the authority component, as specified in the Host header field
1888      (Section 8.3), and
1889
1890   o  the request-target obtained from the Request-Line, unless the
1891      request-target is just the asterisk "*".
1892
1893   If the request-target uses the origin form or the asterisk form, and
1894   the Host header field is not present, then the effective request URI
1895   is undefined.
1896
1897   Otherwise, when request-target uses the authority form, the effective
1898   request URI is undefined.
1899
1900
1901
1902
1903Fielding, et al.          Expires July 7, 2012                 [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1                January 2012
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 July 7, 2012                 [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1                January 2012
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, Cameron Heavon-Jones, Carl
3621   Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson,
3622   Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave
3623   Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty,
3624   Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot
3625   Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric
3626   Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle,
3627   Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit
3628   Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.
3629   Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo
3630   Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger,
3631   James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff
3632   Hodges (for coming up with the term 'effective Request-URI'), Jeff
3633   Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
3634   Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
3635   Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan
3636
3637
3638
3639Fielding, et al.          Expires July 7, 2012                 [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1                January 2012
3642
3643
3644   Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre,
3645   Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James,
3646   Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen
3647   Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej
3648   Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham
3649   (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson,
3650   Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael
3651   Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin,
3652   Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams,
3653   Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R.
3654   McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint-
3655   Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning
3656   Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak,
3657   Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson,
3658   Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy,
3659   Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam
3660   Ruby, Scott Lawrence (for maintaining the original issues list), Sean
3661   B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos
3662   Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju,
3663   Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin,
3664   Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close,
3665   Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo
3666   Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau,
3667   Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang,
3668   Yutaka Oiwa, and Zed A. Shaw.
3669
367012.  References
3671
367212.1.  Normative References
3673
3674   [ISO-8859-1]  International Organization for Standardization,
3675                 "Information technology -- 8-bit single-byte coded
3676                 graphic character sets -- Part 1: Latin alphabet No.
3677                 1", ISO/IEC 8859-1:1998, 1998.
3678
3679   [Part2]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3680                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3681                 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
3682                 Semantics", draft-ietf-httpbis-p2-semantics-18 (work in
3683                 progress), January 2012.
3684
3685   [Part3]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3686                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3687                 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
3688                 Payload and Content Negotiation",
3689                 draft-ietf-httpbis-p3-payload-18 (work in progress),
3690                 January 2012.
3691
3692
3693
3694
3695Fielding, et al.          Expires July 7, 2012                 [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1                January 2012
3698
3699
3700   [Part6]       Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3701                 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
3702                 Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
3703                 "HTTP/1.1, part 6: Caching",
3704                 draft-ietf-httpbis-p6-cache-18 (work in progress),
3705                 January 2012.
3706
3707   [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
3708                 Format Specification version 3.3", RFC 1950, May 1996.
3709
3710   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
3711                 Specification version 1.3", RFC 1951, May 1996.
3712
3713   [RFC1952]     Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
3714                 G. Randers-Pehrson, "GZIP file format specification
3715                 version 4.3", RFC 1952, May 1996.
3716
3717   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
3718                 Requirement Levels", BCP 14, RFC 2119, March 1997.
3719
3720   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
3721                 "Uniform Resource Identifier (URI): Generic Syntax",
3722                 STD 66, RFC 3986, January 2005.
3723
3724   [RFC5234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
3725                 Syntax Specifications: ABNF", STD 68, RFC 5234,
3726                 January 2008.
3727
3728   [USASCII]     American National Standards Institute, "Coded Character
3729                 Set -- 7-bit American Standard Code for Information
3730                 Interchange", ANSI X3.4, 1986.
3731
373212.2.  Informative References
3733
3734   [Kri2001]     Kristol, D., "HTTP Cookies: Standards, Privacy, and
3735                 Politics", ACM Transactions on Internet Technology Vol.
3736                 1, #2, November 2001,
3737                 <http://arxiv.org/abs/cs.SE/0105018>.
3738
3739   [Nie1997]     Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
3740                 and C. Lilley, "Network Performance Effects of
3741                 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
3742                 SIGCOMM '97 conference on Applications, technologies,
3743                 architectures, and protocols for computer communication
3744                 SIGCOMM '97, September 1997,
3745                 <http://doi.acm.org/10.1145/263105.263157>.
3746
3747   [Pad1995]     Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
3748
3749
3750
3751Fielding, et al.          Expires July 7, 2012                 [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1                January 2012
3754
3755
3756                 Computer Networks and ISDN Systems v. 28, pp. 25-35,
3757                 December 1995,
3758                 <http://portal.acm.org/citation.cfm?id=219094>.
3759
3760   [RFC1919]     Chatel, M., "Classical versus Transparent IP Proxies",
3761                 RFC 1919, March 1996.
3762
3763   [RFC1945]     Berners-Lee, T., Fielding, R., and H. Nielsen,
3764                 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
3765                 May 1996.
3766
3767   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
3768                 Mail Extensions (MIME) Part One: Format of Internet
3769                 Message Bodies", RFC 2045, November 1996.
3770
3771   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
3772                 Extensions) Part Three: Message Header Extensions for
3773                 Non-ASCII Text", RFC 2047, November 1996.
3774
3775   [RFC2068]     Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
3776                 T. Berners-Lee, "Hypertext Transfer Protocol --
3777                 HTTP/1.1", RFC 2068, January 1997.
3778
3779   [RFC2145]     Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
3780                 "Use and Interpretation of HTTP Version Numbers",
3781                 RFC 2145, May 1997.
3782
3783   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3784                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3785                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3786
3787   [RFC2817]     Khare, R. and S. Lawrence, "Upgrading to TLS Within
3788                 HTTP/1.1", RFC 2817, May 2000.
3789
3790   [RFC2818]     Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3791
3792   [RFC2965]     Kristol, D. and L. Montulli, "HTTP State Management
3793                 Mechanism", RFC 2965, October 2000.
3794
3795   [RFC3040]     Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
3796                 Replication and Caching Taxonomy", RFC 3040,
3797                 January 2001.
3798
3799   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
3800                 Procedures for Message Header Fields", BCP 90,
3801                 RFC 3864, September 2004.
3802
3803   [RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
3804
3805
3806
3807Fielding, et al.          Expires July 7, 2012                 [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 1                January 2012
3810
3811
3812                 Rose, "DNS Security Introduction and Requirements",
3813                 RFC 4033, March 2005.
3814
3815   [RFC4288]     Freed, N. and J. Klensin, "Media Type Specifications
3816                 and Registration Procedures", BCP 13, RFC 4288,
3817                 December 2005.
3818
3819   [RFC4395]     Hansen, T., Hardie, T., and L. Masinter, "Guidelines
3820                 and Registration Procedures for New URI Schemes",
3821                 BCP 115, RFC 4395, February 2006.
3822
3823   [RFC4559]     Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
3824                 Kerberos and NTLM HTTP Authentication in Microsoft
3825                 Windows", RFC 4559, June 2006.
3826
3827   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
3828                 an IANA Considerations Section in RFCs", BCP 26,
3829                 RFC 5226, May 2008.
3830
3831   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
3832                 October 2008.
3833
3834   [RFC6265]     Barth, A., "HTTP State Management Mechanism", RFC 6265,
3835                 April 2011.
3836
3837   [Spe]         Spero, S., "Analysis of HTTP Performance Problems",
3838                 <http://sunsite.unc.edu/mdma-release/http-prob.html>.
3839
3840   [Tou1998]     Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
3841                 HTTP Performance", ISI Research Report ISI/RR-98-463,
3842                 Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
3843
3844                 (original report dated Aug. 1996)
3845
3846Appendix A.  HTTP Version History
3847
3848   HTTP has been in use by the World-Wide Web global information
3849   initiative since 1990.  The first version of HTTP, later referred to
3850   as HTTP/0.9, was a simple protocol for hypertext data transfer across
3851   the Internet with only a single request method (GET) and no metadata.
3852   HTTP/1.0, as defined by [RFC1945], added a range of request methods
3853   and MIME-like messaging that could include metadata about the data
3854   transferred and modifiers on the request/response semantics.
3855   However, HTTP/1.0 did not sufficiently take into consideration the
3856   effects of hierarchical proxies, caching, the need for persistent
3857   connections, or name-based virtual hosts.  The proliferation of
3858   incompletely-implemented applications calling themselves "HTTP/1.0"
3859   further necessitated a protocol version change in order for two
3860
3861
3862
3863Fielding, et al.          Expires July 7, 2012                 [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 1                January 2012
3866
3867
3868   communicating applications to determine each other's true
3869   capabilities.
3870
3871   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
3872   requirements that enable reliable implementations, adding only those
3873   new features that will either be safely ignored by an HTTP/1.0
3874   recipient or only sent when communicating with a party advertising
3875   compliance with HTTP/1.1.
3876
3877   It is beyond the scope of a protocol specification to mandate
3878   compliance with previous versions.  HTTP/1.1 was deliberately
3879   designed, however, to make supporting previous versions easy.  We
3880   would expect a general-purpose HTTP/1.1 server to understand any
3881   valid request in the format of HTTP/1.0 and respond appropriately
3882   with an HTTP/1.1 message that only uses features understood (or
3883   safely ignored) by HTTP/1.0 clients.  Likewise, would expect an
3884   HTTP/1.1 client to understand any valid HTTP/1.0 response.
3885
3886   Since HTTP/0.9 did not support header fields in a request, there is
3887   no mechanism for it to support name-based virtual hosts (selection of
3888   resource by inspection of the Host header field).  Any server that
3889   implements name-based virtual hosts ought to disable support for
3890   HTTP/0.9.  Most requests that appear to be HTTP/0.9 are, in fact,
3891   badly constructed HTTP/1.x requests wherein a buggy client failed to
3892   properly encode linear whitespace found in a URI reference and placed
3893   in the request-target.
3894
3895A.1.  Changes from HTTP/1.0
3896
3897   This section summarizes major differences between versions HTTP/1.0
3898   and HTTP/1.1.
3899
3900A.1.1.  Multi-homed Web Servers
3901
3902   The requirements that clients and servers support the Host header
3903   field (Section 8.3), report an error if it is missing from an
3904   HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are
3905   among the most important changes defined by HTTP/1.1.
3906
3907   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3908   addresses and servers; there was no other established mechanism for
3909   distinguishing the intended server of a request than the IP address
3910   to which that request was directed.  The Host header field was
3911   introduced during the development of HTTP/1.1 and, though it was
3912   quickly implemented by most HTTP/1.0 browsers, additional
3913   requirements were placed on all HTTP/1.1 requests in order to ensure
3914   complete adoption.  At the time of this writing, most HTTP-based
3915   services are dependent upon the Host header field for targeting
3916
3917
3918
3919Fielding, et al.          Expires July 7, 2012                 [Page 70]
3920
3921Internet-Draft              HTTP/1.1, Part 1                January 2012
3922
3923
3924   requests.
3925
3926A.1.2.  Keep-Alive Connections
3927
3928   In HTTP/1.0, each connection is established by the client prior to
3929   the request and closed by the server after sending the response.
3930   However, some implementations implement the explicitly negotiated
3931   ("Keep-Alive") version of persistent connections described in Section
3932   19.7.1 of [RFC2068].
3933
3934   Some clients and servers might wish to be compatible with these
3935   previous approaches to persistent connections, by explicitly
3936   negotiating for them with a "Connection: keep-alive" request header
3937   field.  However, some experimental implementations of HTTP/1.0
3938   persistent connections are faulty; for example, if a HTTP/1.0 proxy
3939   server doesn't understand Connection, it will erroneously forward
3940   that header to the next inbound server, which would result in a hung
3941   connection.
3942
3943   One attempted solution was the introduction of a Proxy-Connection
3944   header, targeted specifically at proxies.  In practice, this was also
3945   unworkable, because proxies are often deployed in multiple layers,
3946   bringing about the same problem discussed above.
3947
3948   As a result, clients are encouraged not to send the Proxy-Connection
3949   header in any requests.
3950
3951   Clients are also encouraged to consider the use of Connection: keep-
3952   alive in requests carefully; while they can enable persistent
3953   connections with HTTP/1.0 servers, clients using them need will need
3954   to monitor the connection for "hung" requests (which indicate that
3955   the client ought stop sending the header), and this mechanism ought
3956   not be used by clients at all when a proxy is being used.
3957
3958A.2.  Changes from RFC 2616
3959
3960   Empty list elements in list productions have been deprecated.
3961   (Section 1.2.1)
3962
3963   Rules about implicit linear whitespace between certain grammar
3964   productions have been removed; now it's only allowed when
3965   specifically pointed out in the ABNF.  (Section 1.2.2)
3966
3967   Clarify that the string "HTTP" in the HTTP-Version ABFN production is
3968   case sensitive.  Restrict the version numbers to be single digits due
3969   to the fact that implementations are known to handle multi-digit
3970   version numbers incorrectly.  (Section 2.6)
3971
3972
3973
3974
3975Fielding, et al.          Expires July 7, 2012                 [Page 71]
3976
3977Internet-Draft              HTTP/1.1, Part 1                January 2012
3978
3979
3980   Require that invalid whitespace around field-names be rejected.
3981   (Section 3.2)
3982
3983   The NUL octet is no longer allowed in comment and quoted-string text.
3984   The quoted-pair rule no longer allows escaping control characters
3985   other than HTAB.  Non-ASCII content in header fields and reason
3986   phrase has been obsoleted and made opaque (the TEXT rule was
3987   removed).  (Section 3.2.3)
3988
3989   Require recipients to handle bogus Content-Length header fields as
3990   errors.  (Section 3.3)
3991
3992   Remove reference to non-existent identity transfer-coding value
3993   tokens.  (Sections 3.3 and 5.1)
3994
3995   Update use of abs_path production from RFC 1808 to the path-absolute
3996   + query components of RFC 3986.  State that the asterisk form is
3997   allowed for the OPTIONS request method only.  (Section 3.1.1.2)
3998
3999   Clarification that the chunk length does not include the count of the
4000   octets in the chunk header and trailer.  Furthermore disallowed line
4001   folding in chunk extensions.  (Section 5.1.1)
4002
4003   Remove hard limit of two connections per server.  Remove requirement
4004   to retry a sequence of requests as long it was idempotent.  Remove
4005   requirements about when servers are allowed to close connections
4006   prematurely.  (Section 6.1.4)
4007
4008   Remove requirement to retry requests under certain cirumstances when
4009   the server prematurely closes the connection.  (Section 6.2)
4010
4011   Change ABNF productions for header fields to only define the field
4012   value.  (Section 8)
4013
4014   Clarify exactly when close connection options must be sent.
4015   (Section 8.1)
4016
4017   Define the semantics of the "Upgrade" header field in responses other
4018   than 101 (this was incorporated from [RFC2817]).  (Section 8.7)
4019
4020Appendix B.  Collected ABNF
4021
4022   BWS = OWS
4023
4024   Chunked-Body = *chunk last-chunk trailer-part CRLF
4025   Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
4026    connection-token ] )
4027   Content-Length = 1*DIGIT
4028
4029
4030
4031Fielding, et al.          Expires July 7, 2012                 [Page 72]
4032
4033Internet-Draft              HTTP/1.1, Part 1                January 2012
4034
4035
4036   HTTP-Prot-Name = %x48.54.54.50 ; HTTP
4037   HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT
4038   HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
4039    ]
4040   Host = uri-host [ ":" port ]
4041
4042   Method = token
4043
4044   OWS = *( SP / HTAB / obs-fold )
4045
4046   RWS = 1*( SP / HTAB / obs-fold )
4047   Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
4048   Request-Line = Method SP request-target SP HTTP-Version CRLF
4049
4050   Status-Code = 3DIGIT
4051   Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
4052
4053   TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
4054   Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
4055   Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
4056    transfer-coding ] )
4057
4058   URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
4059   Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
4060
4061   Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
4062    *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
4063    )
4064
4065   absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
4066   attribute = token
4067   authority = <authority, defined in [RFC3986], Section 3.2>
4068
4069   chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
4070   chunk-data = 1*OCTET
4071   chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
4072   chunk-ext-name = token
4073   chunk-ext-val = token / quoted-str-nf
4074   chunk-size = 1*HEXDIG
4075   comment = "(" *( ctext / quoted-cpair / comment ) ")"
4076   connection-token = token
4077   ctext = OWS / %x21-27 ; '!'-'''
4078    / %x2A-5B ; '*'-'['
4079    / %x5D-7E ; ']'-'~'
4080    / obs-text
4081
4082   field-content = *( HTAB / SP / VCHAR / obs-text )
4083   field-name = token
4084
4085
4086
4087Fielding, et al.          Expires July 7, 2012                 [Page 73]
4088
4089Internet-Draft              HTTP/1.1, Part 1                January 2012
4090
4091
4092   field-value = *( field-content / obs-fold )
4093
4094   header-field = field-name ":" OWS field-value BWS
4095   http-URI = "http://" authority path-abempty [ "?" query ]
4096   https-URI = "https://" authority path-abempty [ "?" query ]
4097
4098   last-chunk = 1*"0" [ chunk-ext ] CRLF
4099
4100   message-body = *OCTET
4101
4102   obs-fold = CRLF ( SP / HTAB )
4103   obs-text = %x80-FF
4104
4105   partial-URI = relative-part [ "?" query ]
4106   path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
4107   path-absolute = <path-absolute, defined in [RFC3986], Section 3.3>
4108   port = <port, defined in [RFC3986], Section 3.2.3>
4109   product = token [ "/" product-version ]
4110   product-version = token
4111   protocol-name = token
4112   protocol-version = token
4113   pseudonym = token
4114
4115   qdtext = OWS / "!" / %x23-5B ; '#'-'['
4116    / %x5D-7E ; ']'-'~'
4117    / obs-text
4118   qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'['
4119    / %x5D-7E ; ']'-'~'
4120    / obs-text
4121   query = <query, defined in [RFC3986], Section 3.4>
4122   quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text )
4123   quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
4124   quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
4125   quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
4126   qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
4127
4128   received-by = ( uri-host [ ":" port ] ) / pseudonym
4129   received-protocol = [ protocol-name "/" ] protocol-version
4130   relative-part = <relative-part, defined in [RFC3986], Section 4.2>
4131   request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
4132    / authority
4133
4134   special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
4135    DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
4136   start-line = Request-Line / Status-Line
4137
4138   t-codings = "trailers" / ( transfer-extension [ te-params ] )
4139
4140
4141
4142
4143Fielding, et al.          Expires July 7, 2012                 [Page 74]
4144
4145Internet-Draft              HTTP/1.1, Part 1                January 2012
4146
4147
4148   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
4149    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
4150   te-ext = OWS ";" OWS token [ "=" word ]
4151   te-params = OWS ";" OWS "q=" qvalue *te-ext
4152   token = 1*tchar
4153   trailer-part = *( header-field CRLF )
4154   transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
4155    transfer-extension
4156   transfer-extension = token *( OWS ";" OWS transfer-parameter )
4157   transfer-parameter = attribute BWS "=" BWS value
4158
4159   uri-host = <host, defined in [RFC3986], Section 3.2.2>
4160
4161   value = word
4162
4163   word = token / quoted-string
4164
4165   ABNF diagnostics:
4166
4167   ; Chunked-Body defined but not used
4168   ; Connection defined but not used
4169   ; Content-Length defined but not used
4170   ; HTTP-message defined but not used
4171   ; Host defined but not used
4172   ; TE defined but not used
4173   ; Trailer defined but not used
4174   ; Transfer-Encoding defined but not used
4175   ; URI-reference defined but not used
4176   ; Upgrade defined but not used
4177   ; Via defined but not used
4178   ; http-URI defined but not used
4179   ; https-URI defined but not used
4180   ; partial-URI defined but not used
4181   ; special defined but not used
4182
4183Appendix C.  Change Log (to be removed by RFC Editor before publication)
4184
4185C.1.  Since RFC 2616
4186
4187   Extracted relevant partitions from [RFC2616].
4188
4189C.2.  Since draft-ietf-httpbis-p1-messaging-00
4190
4191   Closed issues:
4192
4193   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version
4194      should be case sensitive"
4195      (<http://purl.org/NET/http-errata#verscase>)
4196
4197
4198
4199Fielding, et al.          Expires July 7, 2012                 [Page 75]
4200
4201Internet-Draft              HTTP/1.1, Part 1                January 2012
4202
4203
4204   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
4205      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
4206
4207   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
4208      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
4209
4210   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length"
4211      (<http://purl.org/NET/http-errata#msg-len-chars>)
4212
4213   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
4214      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
4215
4216   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes
4217      query" (<http://purl.org/NET/http-errata#uriquery>)
4218
4219   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on
4220      1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
4221
4222   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
4223      'identity' token references"
4224      (<http://purl.org/NET/http-errata#identity>)
4225
4226   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query
4227      BNF"
4228
4229   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF"
4230
4231   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
4232      Informative references"
4233
4234   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
4235      Compliance"
4236
4237   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
4238      reference"
4239
4240   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
4241      references"
4242
4243   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency
4244      in date format explanation"
4245
4246   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
4247      typo"
4248
4249   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
4250      references"
4251
4252
4253
4254
4255Fielding, et al.          Expires July 7, 2012                 [Page 76]
4256
4257Internet-Draft              HTTP/1.1, Part 1                January 2012
4258
4259
4260   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
4261      Reference"
4262
4263   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
4264      to-date references"
4265
4266   Other changes:
4267
4268   o  Update media type registrations to use RFC4288 template.
4269
4270   o  Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
4271      for chunk-data (work in progress on
4272      <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
4273
4274C.3.  Since draft-ietf-httpbis-p1-messaging-01
4275
4276   Closed issues:
4277
4278   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET
4279      (and other) requests"
4280
4281   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
4282      RFC4288"
4283
4284   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code
4285      and Reason Phrase"
4286
4287   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
4288      used"
4289
4290   Ongoing work on ABNF conversion
4291   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4292
4293   o  Get rid of duplicate BNF rule names ("host" -> "uri-host",
4294      "trailer" -> "trailer-part").
4295
4296   o  Avoid underscore character in rule names ("http_URL" -> "http-
4297      URL", "abs_path" -> "path-absolute").
4298
4299   o  Add rules for terms imported from URI spec ("absoluteURI",
4300      "authority", "path-absolute", "port", "query", "relativeURI",
4301      "host) -- these will have to be updated when switching over to
4302      RFC3986.
4303
4304   o  Synchronize core rules with RFC5234.
4305
4306   o  Get rid of prose rules that span multiple lines.
4307
4308
4309
4310
4311Fielding, et al.          Expires July 7, 2012                 [Page 77]
4312
4313Internet-Draft              HTTP/1.1, Part 1                January 2012
4314
4315
4316   o  Get rid of unused rules LOALPHA and UPALPHA.
4317
4318   o  Move "Product Tokens" section (back) into Part 1, as "token" is
4319      used in the definition of the Upgrade header field.
4320
4321   o  Add explicit references to BNF syntax and rules imported from
4322      other parts of the specification.
4323
4324   o  Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
4325      "TEXT".
4326
4327C.4.  Since draft-ietf-httpbis-p1-messaging-02
4328
4329   Closed issues:
4330
4331   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs.
4332      rfc1123-date"
4333
4334   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted-
4335      pair"
4336
4337   Ongoing work on IANA Message Header Field Registration
4338   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
4339
4340   o  Reference RFC 3984, and update header field registrations for
4341      headers defined in this document.
4342
4343   Ongoing work on ABNF conversion
4344   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4345
4346   o  Replace string literals when the string really is case-sensitive
4347      (HTTP-Version).
4348
4349C.5.  Since draft-ietf-httpbis-p1-messaging-03
4350
4351   Closed issues:
4352
4353   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4354      closing"
4355
4356   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
4357      registrations and registry information to IANA Considerations"
4358
4359   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL
4360      for PAD1995 reference"
4361
4362   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
4363      Considerations: update HTTP URI scheme registration"
4364
4365
4366
4367Fielding, et al.          Expires July 7, 2012                 [Page 78]
4368
4369Internet-Draft              HTTP/1.1, Part 1                January 2012
4370
4371
4372   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
4373      URI scheme definition"
4374
4375   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type
4376      headers vs Set-Cookie"
4377
4378   Ongoing work on ABNF conversion
4379   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4380
4381   o  Replace string literals when the string really is case-sensitive
4382      (HTTP-Date).
4383
4384   o  Replace HEX by HEXDIG for future consistence with RFC 5234's core
4385      rules.
4386
4387C.6.  Since draft-ietf-httpbis-p1-messaging-04
4388
4389   Closed issues:
4390
4391   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date
4392      reference for URIs"
4393
4394   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
4395      updated by RFC 5322"
4396
4397   Ongoing work on ABNF conversion
4398   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4399
4400   o  Use "/" instead of "|" for alternatives.
4401
4402   o  Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
4403
4404   o  Only reference RFC 5234's core rules.
4405
4406   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
4407      whitespace ("OWS") and required whitespace ("RWS").
4408
4409   o  Rewrite ABNFs to spell out whitespace rules, factor out header
4410      field value format definitions.
4411
4412C.7.  Since draft-ietf-httpbis-p1-messaging-05
4413
4414   Closed issues:
4415
4416   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS"
4417
4418   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3
4419      Terminology"
4420
4421
4422
4423Fielding, et al.          Expires July 7, 2012                 [Page 79]
4424
4425Internet-Draft              HTTP/1.1, Part 1                January 2012
4426
4427
4428   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047
4429      encoded words"
4430
4431   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character
4432      Encodings in TEXT"
4433
4434   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding"
4435
4436   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4437      proxies"
4438
4439   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
4440      BNF"
4441
4442   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT"
4443
4444   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
4445      "Differences Between HTTP Entities and RFC 2045 Entities"?"
4446
4447   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822
4448      reference left in discussion of date formats"
4449
4450   Final work on ABNF conversion
4451   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
4452
4453   o  Rewrite definition of list rules, deprecate empty list elements.
4454
4455   o  Add appendix containing collected and expanded ABNF.
4456
4457   Other changes:
4458
4459   o  Rewrite introduction; add mostly new Architecture Section.
4460
4461   o  Move definition of quality values from Part 3 into Part 1; make TE
4462      request header field grammar independent of accept-params (defined
4463      in Part 3).
4464
4465C.8.  Since draft-ietf-httpbis-p1-messaging-06
4466
4467   Closed issues:
4468
4469   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
4470      numeric protocol elements"
4471
4472   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF"
4473
4474   Partly resolved issues:
4475
4476
4477
4478
4479Fielding, et al.          Expires July 7, 2012                 [Page 80]
4480
4481Internet-Draft              HTTP/1.1, Part 1                January 2012
4482
4483
4484   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
4485      (took out language that implied that there might be methods for
4486      which a request body MUST NOT be included)
4487
4488   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial
4489      improvements around HTTP-date"
4490
4491C.9.  Since draft-ietf-httpbis-p1-messaging-07
4492
4493   Closed issues:
4494
4495   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating
4496      single-value headers"
4497
4498   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase
4499      connection limit"
4500
4501   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses
4502      in URLs"
4503
4504   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over
4505      HTTP Upgrade Token Registry"
4506
4507   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in
4508      chunk extension values"
4509
4510   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9
4511      support"
4512
4513   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
4514      policy (RFC5226) for Transfer Coding / Content Coding"
4515
4516   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
4517      definitions of gzip/deflate/compress to part 1"
4518
4519   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
4520      control characters in quoted-pair"
4521
4522   Partly resolved issues:
4523
4524   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
4525      requirements wrt Transfer-Coding values" (add the IANA
4526      Considerations subsection)
4527
4528
4529
4530
4531
4532
4533
4534
4535Fielding, et al.          Expires July 7, 2012                 [Page 81]
4536
4537Internet-Draft              HTTP/1.1, Part 1                January 2012
4538
4539
4540C.10.  Since draft-ietf-httpbis-p1-messaging-08
4541
4542   Closed issues:
4543
4544   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
4545      parsing, treatment of leading and trailing OWS"
4546
4547   Partly resolved issues:
4548
4549   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
4550      13.5.1 and 13.5.2"
4551
4552   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4553      "word" when talking about header structure"
4554
4555C.11.  Since draft-ietf-httpbis-p1-messaging-09
4556
4557   Closed issues:
4558
4559   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification
4560      of the term 'deflate'"
4561
4562   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and
4563      proxies"
4564
4565   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
4566      not listed in P1, general header fields"
4567
4568   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
4569      for content/transfer encodings"
4570
4571   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case-
4572      sensitivity of HTTP-date"
4573
4574   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
4575      "word" when talking about header structure"
4576
4577   Partly resolved issues:
4578
4579   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
4580      requested resource's URI"
4581
4582C.12.  Since draft-ietf-httpbis-p1-messaging-10
4583
4584   Closed issues:
4585
4586   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection
4587      Closing"
4588
4589
4590
4591Fielding, et al.          Expires July 7, 2012                 [Page 82]
4592
4593Internet-Draft              HTTP/1.1, Part 1                January 2012
4594
4595
4596   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
4597      messages with multipart/byteranges"
4598
4599   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4600      multiple Content-Length headers"
4601
4602   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
4603      entity / representation / variant terminology"
4604
4605   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
4606      removing the 'changes from 2068' sections"
4607
4608   Partly resolved issues:
4609
4610   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4611      scheme definitions"
4612
4613C.13.  Since draft-ietf-httpbis-p1-messaging-11
4614
4615   Closed issues:
4616
4617   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer
4618      requirements"
4619
4620   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
4621      clock requirement for caches belongs in p6"
4622
4623   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective
4624      request URI: handling of missing host in HTTP/1.0"
4625
4626   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing
4627      Date requirements for clients"
4628
4629   Partly resolved issues:
4630
4631   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4632      multiple Content-Length headers"
4633
4634C.14.  Since draft-ietf-httpbis-p1-messaging-12
4635
4636   Closed issues:
4637
4638   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145
4639      Normative"
4640
4641   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI
4642      scheme definitions" (tune the requirements on userinfo)
4643
4644
4645
4646
4647Fielding, et al.          Expires July 7, 2012                 [Page 83]
4648
4649Internet-Draft              HTTP/1.1, Part 1                January 2012
4650
4651
4652   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define
4653      'transparent' proxy"
4654
4655   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
4656      Classification"
4657
4658   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable
4659      as a request-uri for new methods?"
4660
4661   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
4662      Upgrade details from RFC2817"
4663
4664   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
4665      ABNFs for header fields"
4666
4667   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
4668      2109 reference"
4669
4670C.15.  Since draft-ietf-httpbis-p1-messaging-13
4671
4672   Closed issues:
4673
4674   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
4675      in 13.5.2"
4676
4677   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling
4678      multiple Content-Length headers"
4679
4680   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
4681      ABNFs for header fields"
4682
4683   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
4684      Length ABNF broken"
4685
4686C.16.  Since draft-ietf-httpbis-p1-messaging-14
4687
4688   Closed issues:
4689
4690   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-Version
4691      should be redefined as fixed length pair of DIGIT .  DIGIT"
4692
4693   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
4694      minimum sizes for protocol elements"
4695
4696   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set
4697      expectations around buffering"
4698
4699
4700
4701
4702
4703Fielding, et al.          Expires July 7, 2012                 [Page 84]
4704
4705Internet-Draft              HTTP/1.1, Part 1                January 2012
4706
4707
4708   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering
4709      messages in isolation"
4710
4711C.17.  Since draft-ietf-httpbis-p1-messaging-15
4712
4713   Closed issues:
4714
4715   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing
4716      / DNS Binding advice"
4717
4718   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs
4719      2145, 2616, 2817 to Historic status"
4720
4721   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in
4722      quoted strings"
4723
4724   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close'
4725      should be reserved in the HTTP header field registry"
4726
4727C.18.  Since draft-ietf-httpbis-p1-messaging-16
4728
4729   Closed issues:
4730
4731   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
4732      HTTP's error-handling philosophy"
4733
4734   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain
4735      header registration"
4736
4737   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise
4738      Acknowledgements Sections"
4739
4740   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
4741      Requests"
4742
4743   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
4744      connection on server error"
4745
4746C.19.  Since draft-ietf-httpbis-p1-messaging-17
4747
4748   Closed issues:
4749
4750   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User
4751      Agent'"
4752
4753   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non-
4754      final responses"
4755
4756
4757
4758
4759Fielding, et al.          Expires July 7, 2012                 [Page 85]
4760
4761Internet-Draft              HTTP/1.1, Part 1                January 2012
4762
4763
4764   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
4765      maturity level vs normative references"
4766
4767   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary
4768      rewriting of queries"
4769
4770   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
4771      Connection and Keep-Alive"
4772
4773Index
4774
4775   A
4776      absolute-URI form (of request-target)  32
4777      accelerator  13
4778      application/http Media Type  61
4779      asterisk form (of request-target)  31
4780      authority form (of request-target)  32
4781
4782   B
4783      browser  10
4784
4785   C
4786      cache  14
4787      cacheable  15
4788      captive portal  14
4789      chunked (Coding Format)  36
4790      client  10
4791      Coding Format
4792         chunked  36
4793         compress  38
4794         deflate  38
4795         gzip  39
4796      compress (Coding Format)  38
4797      connection  10
4798      Connection header field  49
4799      Content-Length header field  51
4800
4801   D
4802      deflate (Coding Format)  38
4803      downstream  13
4804
4805   E
4806      effective request URI  34
4807
4808   G
4809      gateway  13
4810      Grammar
4811         absolute-URI  18
4812
4813
4814
4815Fielding, et al.          Expires July 7, 2012                 [Page 86]
4816
4817Internet-Draft              HTTP/1.1, Part 1                January 2012
4818
4819
4820         ALPHA  7
4821         attribute  35
4822         authority  18
4823         BWS  9
4824         chunk  36
4825         chunk-data  36
4826         chunk-ext  36
4827         chunk-ext-name  36
4828         chunk-ext-val  36
4829         chunk-size  36
4830         Chunked-Body  36
4831         comment  26
4832         Connection  50
4833         connection-token  50
4834         Content-Length  51
4835         CR  7
4836         CRLF  7
4837         ctext  26
4838         CTL  7
4839         date2  35
4840         date3  35
4841         DIGIT  7
4842         DQUOTE  7
4843         field-content  23
4844         field-name  23
4845         field-value  23
4846         header-field  23
4847         HEXDIG  7
4848         Host  52
4849         HTAB  7
4850         HTTP-message  21
4851         HTTP-Prot-Name  15
4852         http-URI  18
4853         HTTP-Version  15
4854         https-URI  20
4855         last-chunk  36
4856         LF  7
4857         message-body  27
4858         Method  22
4859         obs-text  26
4860         OCTET  7
4861         OWS  9
4862         path-absolute  18
4863         port  18
4864         product  39
4865         product-version  39
4866         protocol-name  57
4867         protocol-version  57
4868
4869
4870
4871Fielding, et al.          Expires July 7, 2012                 [Page 87]
4872
4873Internet-Draft              HTTP/1.1, Part 1                January 2012
4874
4875
4876         pseudonym  57
4877         qdtext  26
4878         qdtext-nf  36
4879         query  18
4880         quoted-cpair  27
4881         quoted-pair  26
4882         quoted-str-nf  36
4883         quoted-string  26
4884         qvalue  40
4885         Reason-Phrase  23
4886         received-by  57
4887         received-protocol  57
4888         Request-Line  22
4889         request-target  22
4890         RWS  9
4891         SP  7
4892         special  26
4893         start-line  21
4894         Status-Code  23
4895         Status-Line  23
4896         t-codings  53
4897         tchar  26
4898         TE  53
4899         te-ext  53
4900         te-params  53
4901         token  26
4902         Trailer  54
4903         trailer-part  36
4904         transfer-coding  35
4905         Transfer-Encoding  54
4906         transfer-extension  35
4907         transfer-parameter  35
4908         Upgrade  55
4909         uri-host  18
4910         URI-reference  18
4911         value  35
4912         VCHAR  7
4913         Via  57
4914         word  26
4915      gzip (Coding Format)  39
4916
4917   H
4918      header field  21
4919      Header Fields
4920         Connection  49
4921         Content-Length  51
4922         Host  51
4923         TE  53
4924
4925
4926
4927Fielding, et al.          Expires July 7, 2012                 [Page 88]
4928
4929Internet-Draft              HTTP/1.1, Part 1                January 2012
4930
4931
4932         Trailer  54
4933         Transfer-Encoding  54
4934         Upgrade  55
4935         Via  57
4936      header section  21
4937      headers  21
4938      Host header field  51
4939      http URI scheme  18
4940      https URI scheme  19
4941
4942   I
4943      inbound  13
4944      interception proxy  14
4945      intermediary  12
4946
4947   M
4948      Media Type
4949         application/http  61
4950         message/http  59
4951      message  10
4952      message/http Media Type  59
4953
4954   N
4955      non-transforming proxy  13
4956
4957   O
4958      origin form (of request-target)  32
4959      origin server  10
4960      outbound  13
4961
4962   P
4963      proxy  13
4964
4965   R
4966      recipient  10
4967      request  10
4968      resource  17
4969      response  10
4970      reverse proxy  13
4971
4972   S
4973      sender  10
4974      server  10
4975      spider  10
4976
4977   T
4978      target resource  34
4979      TE header field  53
4980
4981
4982
4983Fielding, et al.          Expires July 7, 2012                 [Page 89]
4984
4985Internet-Draft              HTTP/1.1, Part 1                January 2012
4986
4987
4988      Trailer header field  54
4989      Transfer-Encoding header field  54
4990      transforming proxy  13
4991      transparent proxy  14
4992      tunnel  14
4993
4994   U
4995      Upgrade header field  55
4996      upstream  13
4997      URI scheme
4998         http  18
4999         https  19
5000      user agent  10
5001
5002   V
5003      Via header field  57
5004
5005Authors' Addresses
5006
5007   Roy T. Fielding (editor)
5008   Adobe Systems Incorporated
5009   345 Park Ave
5010   San Jose, CA  95110
5011   USA
5012
5013   EMail: fielding@gbiv.com
5014   URI:   http://roy.gbiv.com/
5015
5016
5017   Jim Gettys
5018   Alcatel-Lucent Bell Labs
5019   21 Oak Knoll Road
5020   Carlisle, MA  01741
5021   USA
5022
5023   EMail: jg@freedesktop.org
5024   URI:   http://gettys.wordpress.com/
5025
5026
5027   Jeffrey C. Mogul
5028   Hewlett-Packard Company
5029   HP Labs, Large Scale Systems Group
5030   1501 Page Mill Road, MS 1177
5031   Palo Alto, CA  94304
5032   USA
5033
5034   EMail: JeffMogul@acm.org
5035
5036
5037
5038
5039Fielding, et al.          Expires July 7, 2012                 [Page 90]
5040
5041Internet-Draft              HTTP/1.1, Part 1                January 2012
5042
5043
5044   Henrik Frystyk Nielsen
5045   Microsoft Corporation
5046   1 Microsoft Way
5047   Redmond, WA  98052
5048   USA
5049
5050   EMail: henrikn@microsoft.com
5051
5052
5053   Larry Masinter
5054   Adobe Systems Incorporated
5055   345 Park Ave
5056   San Jose, CA  95110
5057   USA
5058
5059   EMail: LMM@acm.org
5060   URI:   http://larry.masinter.net/
5061
5062
5063   Paul J. Leach
5064   Microsoft Corporation
5065   1 Microsoft Way
5066   Redmond, WA  98052
5067
5068   EMail: paulle@microsoft.com
5069
5070
5071   Tim Berners-Lee
5072   World Wide Web Consortium
5073   MIT Computer Science and Artificial Intelligence Laboratory
5074   The Stata Center, Building 32
5075   32 Vassar Street
5076   Cambridge, MA  02139
5077   USA
5078
5079   EMail: timbl@w3.org
5080   URI:   http://www.w3.org/People/Berners-Lee/
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095Fielding, et al.          Expires July 7, 2012                 [Page 91]
5096
5097Internet-Draft              HTTP/1.1, Part 1                January 2012
5098
5099
5100   Yves Lafon (editor)
5101   World Wide Web Consortium
5102   W3C / ERCIM
5103   2004, rte des Lucioles
5104   Sophia-Antipolis, AM  06902
5105   France
5106
5107   EMail: ylafon@w3.org
5108   URI:   http://www.raubacapeu.net/people/yves/
5109
5110
5111   Julian F. Reschke (editor)
5112   greenbytes GmbH
5113   Hafenweg 16
5114   Muenster, NW  48155
5115   Germany
5116
5117   Phone: +49 251 2807760
5118   Fax:   +49 251 2807761
5119   EMail: julian.reschke@greenbytes.de
5120   URI:   http://greenbytes.de/tech/webdav/
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151Fielding, et al.          Expires July 7, 2012                 [Page 92]
5152
Note: See TracBrowser for help on using the repository browser.