source: draft-ietf-httpbis/19/draft-ietf-httpbis-p1-messaging-19.txt @ 1592

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

-19

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