source: draft-ietf-httpbis/01/draft-ietf-httpbis-p1-messaging-01.txt @ 875

Last change on this file since 875 was 166, checked in by fielding@…, 12 years ago

generated draft 01

  • Property svn:eol-style set to native
File size: 144.8 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                    One Laptop per Child
8Expires: July 15, 2008                                          J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                        January 12, 2008
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-01
27
28Status of this Memo
29
30   By submitting this Internet-Draft, each author represents that any
31   applicable patent or other IPR claims of which he or she is aware
32   have been or will be disclosed, and any of which he or she becomes
33   aware will be disclosed, in accordance with Section 6 of BCP 79.
34
35   Internet-Drafts are working documents of the Internet Engineering
36   Task Force (IETF), its areas, and its working groups.  Note that
37   other groups may also distribute working documents as Internet-
38   Drafts.
39
40   Internet-Drafts are draft documents valid for a maximum of six months
41   and may be updated, replaced, or obsoleted by other documents at any
42   time.  It is inappropriate to use Internet-Drafts as reference
43   material or to cite them other than as "work in progress."
44
45   The list of current Internet-Drafts can be accessed at
46   http://www.ietf.org/ietf/1id-abstracts.txt.
47
48   The list of Internet-Draft Shadow Directories can be accessed at
49   http://www.ietf.org/shadow.html.
50
51   This Internet-Draft will expire on July 15, 2008.
52
53
54
55Fielding, et al.          Expires July 15, 2008                 [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1                January 2008
58
59
60Copyright Notice
61
62   Copyright (C) The IETF Trust (2008).
63
64Abstract
65
66   The Hypertext Transfer Protocol (HTTP) is an application-level
67   protocol for distributed, collaborative, hypermedia information
68   systems.  HTTP has been in use by the World Wide Web global
69   information initiative since 1990.  This document is Part 1 of the
70   seven-part specification that defines the protocol referred to as
71   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 1 provides
72   an overview of HTTP and its associated terminology, defines the
73   "http" and "https" Uniform Resource Identifier (URI) schemes, defines
74   the generic message syntax and parsing requirements for HTTP message
75   frames, and describes general security concerns for implementations.
76
77Editorial Note (To be removed by RFC Editor)
78
79   Discussion of this draft should take place on the HTTPBIS working
80   group mailing list (ietf-http-wg@w3.org).  The current issues list is
81   at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
82   documents (including fancy diffs) can be found at
83   <http://www.tools.ietf.org/wg/httpbis/>.
84
85   This draft incorporates those issue resolutions that were either
86   collected in the original RFC2616 errata list
87   (<http://purl.org/NET/http-errata>), or which were agreed upon on the
88   mailing list between October 2006 and November 2007 (as published in
89   "draft-lafon-rfc2616bis-03").
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires July 15, 2008                 [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1                January 2008
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
119     1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  5
120     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
121     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
122     1.4.  Overall Operation  . . . . . . . . . . . . . . . . . . . .  9
123   2.  Notational Conventions and Generic Grammar . . . . . . . . . . 11
124     2.1.  Augmented BNF  . . . . . . . . . . . . . . . . . . . . . . 11
125     2.2.  Basic Rules  . . . . . . . . . . . . . . . . . . . . . . . 13
126   3.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . . 15
127     3.1.  HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15
128     3.2.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
129       3.2.1.  General Syntax . . . . . . . . . . . . . . . . . . . . 17
130       3.2.2.  http URL . . . . . . . . . . . . . . . . . . . . . . . 17
131       3.2.3.  URI Comparison . . . . . . . . . . . . . . . . . . . . 18
132     3.3.  Date/Time Formats  . . . . . . . . . . . . . . . . . . . . 18
133       3.3.1.  Full Date  . . . . . . . . . . . . . . . . . . . . . . 18
134     3.4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19
135       3.4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . 20
136   4.  HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22
137     4.1.  Message Types  . . . . . . . . . . . . . . . . . . . . . . 22
138     4.2.  Message Headers  . . . . . . . . . . . . . . . . . . . . . 23
139     4.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 24
140     4.4.  Message Length . . . . . . . . . . . . . . . . . . . . . . 25
141     4.5.  General Header Fields  . . . . . . . . . . . . . . . . . . 26
142   5.  Request  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
143     5.1.  Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27
144       5.1.1.  Method . . . . . . . . . . . . . . . . . . . . . . . . 27
145       5.1.2.  Request-URI  . . . . . . . . . . . . . . . . . . . . . 27
146     5.2.  The Resource Identified by a Request . . . . . . . . . . . 29
147   6.  Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
148     6.1.  Status-Line  . . . . . . . . . . . . . . . . . . . . . . . 30
149       6.1.1.  Status Code and Reason Phrase  . . . . . . . . . . . . 30
150   7.  Connections  . . . . . . . . . . . . . . . . . . . . . . . . . 30
151     7.1.  Persistent Connections . . . . . . . . . . . . . . . . . . 31
152       7.1.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . 31
153       7.1.2.  Overall Operation  . . . . . . . . . . . . . . . . . . 31
154       7.1.3.  Proxy Servers  . . . . . . . . . . . . . . . . . . . . 33
155       7.1.4.  Practical Considerations . . . . . . . . . . . . . . . 33
156     7.2.  Message Transmission Requirements  . . . . . . . . . . . . 34
157       7.2.1.  Persistent Connections and Flow Control  . . . . . . . 34
158       7.2.2.  Monitoring Connections for Error Status Messages . . . 34
159       7.2.3.  Use of the 100 (Continue) Status . . . . . . . . . . . 35
160       7.2.4.  Client Behavior if Server Prematurely Closes
161               Connection . . . . . . . . . . . . . . . . . . . . . . 37
162   8.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 37
163     8.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 38
164
165
166
167Fielding, et al.          Expires July 15, 2008                 [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1                January 2008
170
171
172     8.2.  Content-Length . . . . . . . . . . . . . . . . . . . . . . 39
173     8.3.  Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
174       8.3.1.  Clockless Origin Server Operation  . . . . . . . . . . 40
175     8.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
176     8.5.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
177     8.6.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 42
178     8.7.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . . . 43
179     8.8.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 43
180     8.9.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
181   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 46
182   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 46
183     10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46
184     10.2. Abuse of Server Log Information  . . . . . . . . . . . . . 46
185     10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47
186     10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47
187     10.5. Proxies and Caching  . . . . . . . . . . . . . . . . . . . 48
188     10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48
189   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 49
190   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
191     12.1. Normative References . . . . . . . . . . . . . . . . . . . 50
192     12.2. Informative References . . . . . . . . . . . . . . . . . . 51
193   Appendix A.  Internet Media Types  . . . . . . . . . . . . . . . . 53
194     A.1.  Internet Media Type message/http . . . . . . . . . . . . . 53
195     A.2.  Internet Media Type application/http . . . . . . . . . . . 54
196   Appendix B.  Tolerant Applications . . . . . . . . . . . . . . . . 55
197   Appendix C.  Conversion of Date Formats  . . . . . . . . . . . . . 56
198   Appendix D.  Compatibility with Previous Versions  . . . . . . . . 56
199     D.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 57
200       D.1.1.  Changes to Simplify Multi-homed Web Servers and
201               Conserve IP Addresses  . . . . . . . . . . . . . . . . 57
202     D.2.  Compatibility with HTTP/1.0 Persistent Connections . . . . 58
203     D.3.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 58
204     D.4.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 59
205   Appendix E.  Change Log (to be removed by RFC Editor before
206                publication)  . . . . . . . . . . . . . . . . . . . . 59
207     E.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 59
208     E.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 59
209   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
210   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
211   Intellectual Property and Copyright Statements . . . . . . . . . . 68
212
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.          Expires July 15, 2008                 [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1                January 2008
226
227
2281.  Introduction
229
230   The Hypertext Transfer Protocol (HTTP) is an application-level
231   protocol for distributed, collaborative, hypermedia information
232   systems.  HTTP has been in use by the World-Wide Web global
233   information initiative since 1990.  The first version of HTTP,
234   commonly referred to as HTTP/0.9, was a simple protocol for raw data
235   transfer across the Internet with only a single method and no
236   metadata.  HTTP/1.0, as defined by [RFC1945], improved the protocol
237   by allowing messages to be in the format of MIME-like messages,
238   containing metadata about the data transferred and modifiers on the
239   request/response semantics.  However, HTTP/1.0 did not sufficiently
240   take into consideration the effects of hierarchical proxies, caching,
241   the need for persistent connections, or name-based virtual hosts.  In
242   addition, the proliferation of incompletely-implemented applications
243   calling themselves "HTTP/1.0" necessitated a protocol version change
244   in order for two communicating applications to determine each other's
245   true capabilities.
246
247   This document is Part 1 of the seven-part specification that defines
248   the protocol referred to as "HTTP/1.1", obsoleting [RFC2616].
249   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
250   requirements that enable reliable implementations and adding only
251   those new features that will either be safely ignored by an HTTP/1.0
252   recipient or only sent when communicating with a party advertising
253   compliance with HTTP/1.1.  Part 1 defines those aspects of HTTP/1.1
254   related to overall network operation, message framing, interaction
255   with transport protocols, and URI schemes.
256
257   This document is currently disorganized in order to minimize the
258   changes between drafts and enable reviewers to see the smaller errata
259   changes.  The next draft will reorganize the sections to better
260   reflect the content.  In particular, the sections will be organized
261   according to the typical process of deciding when to use HTTP (URI
262   schemes), overall network operation, connection management, message
263   framing, and generic message parsing.  The current mess reflects how
264   widely dispersed these topics and associated requirements had become
265   in [RFC2616].
266
2671.1.  Purpose
268
269   Practical information systems require more functionality than simple
270   retrieval, including search, front-end update, and annotation.  HTTP
271   allows an open-ended set of methods and headers that indicate the
272   purpose of a request [RFC2324].  It builds on the discipline of
273   reference provided by the Uniform Resource Identifier (URI)
274   [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for
275   indicating the resource to which a method is to be applied.  Messages
276
277
278
279Fielding, et al.          Expires July 15, 2008                 [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1                January 2008
282
283
284   are passed in a format similar to that used by Internet mail
285   [RFC2822] as defined by the Multipurpose Internet Mail Extensions
286   (MIME) [RFC2045].
287
288   HTTP is also used as a generic protocol for communication between
289   user agents and proxies/gateways to other Internet systems, including
290   those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959],
291   Gopher [RFC1436], and WAIS [WAIS] protocols.  In this way, HTTP
292   allows basic hypermedia access to resources available from diverse
293   applications.
294
2951.2.  Requirements
296
297   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
298   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
299   document are to be interpreted as described in [RFC2119].
300
301   An implementation is not compliant if it fails to satisfy one or more
302   of the MUST or REQUIRED level requirements for the protocols it
303   implements.  An implementation that satisfies all the MUST or
304   REQUIRED level and all the SHOULD level requirements for its
305   protocols is said to be "unconditionally compliant"; one that
306   satisfies all the MUST level requirements but not all the SHOULD
307   level requirements for its protocols is said to be "conditionally
308   compliant."
309
3101.3.  Terminology
311
312   This specification uses a number of terms to refer to the roles
313   played by participants in, and objects of, the HTTP communication.
314
315   connection
316
317      A transport layer virtual circuit established between two programs
318      for the purpose of communication.
319
320   message
321
322      The basic unit of HTTP communication, consisting of a structured
323      sequence of octets matching the syntax defined in Section 4 and
324      transmitted via the connection.
325
326   request
327
328      An HTTP request message, as defined in Section 5.
329
330   response
331
332
333
334
335Fielding, et al.          Expires July 15, 2008                 [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1                January 2008
338
339
340      An HTTP response message, as defined in Section 6.
341
342   resource
343
344      A network data object or service that can be identified by a URI,
345      as defined in Section 3.2.  Resources may be available in multiple
346      representations (e.g. multiple languages, data formats, size, and
347      resolutions) or vary in other ways.
348
349   entity
350
351      The information transferred as the payload of a request or
352      response.  An entity consists of metainformation in the form of
353      entity-header fields and content in the form of an entity-body, as
354      described in Section 3 of [Part3].
355
356   representation
357
358      An entity included with a response that is subject to content
359      negotiation, as described in Section 4 of [Part3].  There may
360      exist multiple representations associated with a particular
361      response status.
362
363   content negotiation
364
365      The mechanism for selecting the appropriate representation when
366      servicing a request, as described in Section 4 of [Part3].  The
367      representation of entities in any response can be negotiated
368      (including error responses).
369
370   variant
371
372      A resource may have one, or more than one, representation(s)
373      associated with it at any given instant.  Each of these
374      representations is termed a `variant'.  Use of the term `variant'
375      does not necessarily imply that the resource is subject to content
376      negotiation.
377
378   client
379
380      A program that establishes connections for the purpose of sending
381      requests.
382
383   user agent
384
385      The client which initiates a request.  These are often browsers,
386      editors, spiders (web-traversing robots), or other end user tools.
387
388
389
390
391Fielding, et al.          Expires July 15, 2008                 [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1                January 2008
394
395
396   server
397
398      An application program that accepts connections in order to
399      service requests by sending back responses.  Any given program may
400      be capable of being both a client and a server; our use of these
401      terms refers only to the role being performed by the program for a
402      particular connection, rather than to the program's capabilities
403      in general.  Likewise, any server may act as an origin server,
404      proxy, gateway, or tunnel, switching behavior based on the nature
405      of each request.
406
407   origin server
408
409      The server on which a given resource resides or is to be created.
410
411   proxy
412
413      An intermediary program which acts as both a server and a client
414      for the purpose of making requests on behalf of other clients.
415      Requests are serviced internally or by passing them on, with
416      possible translation, to other servers.  A proxy MUST implement
417      both the client and server requirements of this specification.  A
418      "transparent proxy" is a proxy that does not modify the request or
419      response beyond what is required for proxy authentication and
420      identification.  A "non-transparent proxy" is a proxy that
421      modifies the request or response in order to provide some added
422      service to the user agent, such as group annotation services,
423      media type transformation, protocol reduction, or anonymity
424      filtering.  Except where either transparent or non-transparent
425      behavior is explicitly stated, the HTTP proxy requirements apply
426      to both types of proxies.
427
428   gateway
429
430      A server which acts as an intermediary for some other server.
431      Unlike a proxy, a gateway receives requests as if it were the
432      origin server for the requested resource; the requesting client
433      may not be aware that it is communicating with a gateway.
434
435   tunnel
436
437      An intermediary program which is acting as a blind relay between
438      two connections.  Once active, a tunnel is not considered a party
439      to the HTTP communication, though the tunnel may have been
440      initiated by an HTTP request.  The tunnel ceases to exist when
441      both ends of the relayed connections are closed.
442
443   cache
444
445
446
447Fielding, et al.          Expires July 15, 2008                 [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1                January 2008
450
451
452      A program's local store of response messages and the subsystem
453      that controls its message storage, retrieval, and deletion.  A
454      cache stores cacheable responses in order to reduce the response
455      time and network bandwidth consumption on future, equivalent
456      requests.  Any client or server may include a cache, though a
457      cache cannot be used by a server that is acting as a tunnel.
458
459   cacheable
460
461      A response is cacheable if a cache is allowed to store a copy of
462      the response message for use in answering subsequent requests.
463      The rules for determining the cacheability of HTTP responses are
464      defined in Section 1 of [Part6].  Even if a resource is cacheable,
465      there may be additional constraints on whether a cache can use the
466      cached copy for a particular request.
467
468   upstream/downstream
469
470      Upstream and downstream describe the flow of a message: all
471      messages flow from upstream to downstream.
472
473   inbound/outbound
474
475      Inbound and outbound refer to the request and response paths for
476      messages: "inbound" means "traveling toward the origin server",
477      and "outbound" means "traveling toward the user agent"
478
4791.4.  Overall Operation
480
481   The HTTP protocol is a request/response protocol.  A client sends a
482   request to the server in the form of a request method, URI, and
483   protocol version, followed by a MIME-like message containing request
484   modifiers, client information, and possible body content over a
485   connection with a server.  The server responds with a status line,
486   including the message's protocol version and a success or error code,
487   followed by a MIME-like message containing server information, entity
488   metainformation, and possible entity-body content.  The relationship
489   between HTTP and MIME is described in Appendix A of [Part3].
490
491   Most HTTP communication is initiated by a user agent and consists of
492   a request to be applied to a resource on some origin server.  In the
493   simplest case, this may be accomplished via a single connection (v)
494   between the user agent (UA) and the origin server (O).
495
496          request chain ------------------------>
497       UA -------------------v------------------- O
498          <----------------------- response chain
499
500
501
502
503Fielding, et al.          Expires July 15, 2008                 [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1                January 2008
506
507
508   A more complicated situation occurs when one or more intermediaries
509   are present in the request/response chain.  There are three common
510   forms of intermediary: proxy, gateway, and tunnel.  A proxy is a
511   forwarding agent, receiving requests for a URI in its absolute form,
512   rewriting all or part of the message, and forwarding the reformatted
513   request toward the server identified by the URI.  A gateway is a
514   receiving agent, acting as a layer above some other server(s) and, if
515   necessary, translating the requests to the underlying server's
516   protocol.  A tunnel acts as a relay point between two connections
517   without changing the messages; tunnels are used when the
518   communication needs to pass through an intermediary (such as a
519   firewall) even when the intermediary cannot understand the contents
520   of the messages.
521
522          request chain -------------------------------------->
523       UA -----v----- A -----v----- B -----v----- C -----v----- O
524          <------------------------------------- response chain
525
526   The figure above shows three intermediaries (A, B, and C) between the
527   user agent and origin server.  A request or response message that
528   travels the whole chain will pass through four separate connections.
529   This distinction is important because some HTTP communication options
530   may apply only to the connection with the nearest, non-tunnel
531   neighbor, only to the end-points of the chain, or to all connections
532   along the chain.  Although the diagram is linear, each participant
533   may be engaged in multiple, simultaneous communications.  For
534   example, B may be receiving requests from many clients other than A,
535   and/or forwarding requests to servers other than C, at the same time
536   that it is handling A's request.
537
538   Any party to the communication which is not acting as a tunnel may
539   employ an internal cache for handling requests.  The effect of a
540   cache is that the request/response chain is shortened if one of the
541   participants along the chain has a cached response applicable to that
542   request.  The following illustrates the resulting chain if B has a
543   cached copy of an earlier response from O (via C) for a request which
544   has not been cached by UA or A.
545
546             request chain ---------->
547          UA -----v----- A -----v----- B - - - - - - C - - - - - - O
548             <--------- response chain
549
550   Not all responses are usefully cacheable, and some requests may
551   contain modifiers which place special requirements on cache behavior.
552   HTTP requirements for cache behavior and cacheable responses are
553   defined in Section 1 of [Part6].
554
555   In fact, there are a wide variety of architectures and configurations
556
557
558
559Fielding, et al.          Expires July 15, 2008                [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1                January 2008
562
563
564   of caches and proxies currently being experimented with or deployed
565   across the World Wide Web. These systems include national hierarchies
566   of proxy caches to save transoceanic bandwidth, systems that
567   broadcast or multicast cache entries, organizations that distribute
568   subsets of cached data via CD-ROM, and so on.  HTTP systems are used
569   in corporate intranets over high-bandwidth links, and for access via
570   PDAs with low-power radio links and intermittent connectivity.  The
571   goal of HTTP/1.1 is to support the wide diversity of configurations
572   already deployed while introducing protocol constructs that meet the
573   needs of those who build web applications that require high
574   reliability and, failing that, at least reliable indications of
575   failure.
576
577   HTTP communication usually takes place over TCP/IP connections.  The
578   default port is TCP 80
579   (<http://www.iana.org/assignments/port-numbers>), but other ports can
580   be used.  This does not preclude HTTP from being implemented on top
581   of any other protocol on the Internet, or on other networks.  HTTP
582   only presumes a reliable transport; any protocol that provides such
583   guarantees can be used; the mapping of the HTTP/1.1 request and
584   response structures onto the transport data units of the protocol in
585   question is outside the scope of this specification.
586
587   In HTTP/1.0, most implementations used a new connection for each
588   request/response exchange.  In HTTP/1.1, a connection may be used for
589   one or more request/response exchanges, although connections may be
590   closed for a variety of reasons (see Section 7.1).
591
592
5932.  Notational Conventions and Generic Grammar
594
5952.1.  Augmented BNF
596
597   All of the mechanisms specified in this document are described in
598   both prose and an augmented Backus-Naur Form (BNF) similar to that
599   used by [RFC822ABNF].  Implementors will need to be familiar with the
600   notation in order to understand this specification.  The augmented
601   BNF includes the following constructs:
602
603   name = definition
604
605      The name of a rule is simply the name itself (without any
606      enclosing "<" and ">") and is separated from its definition by the
607      equal "=" character.  White space is only significant in that
608      indentation of continuation lines is used to indicate a rule
609      definition that spans more than one line.  Certain basic rules are
610      in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
611      Angle brackets are used within definitions whenever their presence
612
613
614
615Fielding, et al.          Expires July 15, 2008                [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1                January 2008
618
619
620      will facilitate discerning the use of rule names.
621
622   "literal"
623
624      Quotation marks surround literal text.  Unless stated otherwise,
625      the text is case-insensitive.
626
627   rule1 | rule2
628
629      Elements separated by a bar ("|") are alternatives, e.g., "yes |
630      no" will accept yes or no.
631
632   (rule1 rule2)
633
634      Elements enclosed in parentheses are treated as a single element.
635      Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
636      foo elem" and "elem bar elem".
637
638   *rule
639
640      The character "*" preceding an element indicates repetition.  The
641      full form is "<n>*<m>element" indicating at least <n> and at most
642      <m> occurrences of element.  Default values are 0 and infinity so
643      that "*(element)" allows any number, including zero; "1*element"
644      requires at least one; and "1*2element" allows one or two.
645
646   [rule]
647
648      Square brackets enclose optional elements; "[foo bar]" is
649      equivalent to "*1(foo bar)".
650
651   N rule
652
653      Specific repetition: "<n>(element)" is equivalent to
654      "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
655      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
656      alphabetic characters.
657
658   #rule
659
660      A construct "#" is defined, similar to "*", for defining lists of
661      elements.  The full form is "<n>#<m>element" indicating at least
662      <n> and at most <m> elements, each separated by one or more commas
663      (",") and OPTIONAL linear white space (LWS).  This makes the usual
664      form of lists very easy; a rule such as
665
666      ( *LWS element *( *LWS "," *LWS element ))
667
668
669
670
671Fielding, et al.          Expires July 15, 2008                [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1                January 2008
674
675
676      can be shown as
677
678      1#element
679
680      Wherever this construct is used, null elements are allowed, but do
681      not contribute to the count of elements present.  That is,
682      "(element), , (element) " is permitted, but counts as only two
683      elements.  Therefore, where at least one element is required, at
684      least one non-null element MUST be present.  Default values are 0
685      and infinity so that "#element" allows any number, including zero;
686      "1#element" requires at least one; and "1#2element" allows one or
687      two.
688
689   ; comment
690
691      A semi-colon, set off some distance to the right of rule text,
692      starts a comment that continues to the end of line.  This is a
693      simple way of including useful notes in parallel with the
694      specifications.
695
696   implied *LWS
697
698      The grammar described by this specification is word-based.  Except
699      where noted otherwise, linear white space (LWS) can be included
700      between any two adjacent words (token or quoted-string), and
701      between adjacent words and separators, without changing the
702      interpretation of a field.  At least one delimiter (LWS and/or
703      separators) MUST exist between any two tokens (for the definition
704      of "token" below), since they would otherwise be interpreted as a
705      single token.
706
7072.2.  Basic Rules
708
709   The following rules are used throughout this specification to
710   describe basic parsing constructs.  The US-ASCII coded character set
711   is defined by ANSI X3.4-1986 [USASCII].
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.          Expires July 15, 2008                [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1                January 2008
730
731
732     OCTET          = <any 8-bit sequence of data>
733     CHAR           = <any US-ASCII character (octets 0 - 127)>
734     UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
735     LOALPHA        = <any US-ASCII lowercase letter "a".."z">
736     ALPHA          = UPALPHA | LOALPHA
737     DIGIT          = <any US-ASCII digit "0".."9">
738     CTL            = <any US-ASCII control character
739                      (octets 0 - 31) and DEL (127)>
740     CR             = <US-ASCII CR, carriage return (13)>
741     LF             = <US-ASCII LF, linefeed (10)>
742     SP             = <US-ASCII SP, space (32)>
743     HTAB           = <US-ASCII HT, horizontal-tab (9)>
744     DQUOTE         = <US-ASCII double-quote mark (34)>
745
746   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
747   protocol elements except the entity-body (see Appendix B for tolerant
748   applications).  The end-of-line marker within an entity-body is
749   defined by its associated media type, as described in Section 2.3 of
750   [Part3].
751
752     CRLF           = CR LF
753
754   HTTP/1.1 header field values can be folded onto multiple lines if the
755   continuation line begins with a space or horizontal tab.  All linear
756   white space, including folding, has the same semantics as SP.  A
757   recipient MAY replace any linear white space with a single SP before
758   interpreting the field value or forwarding the message downstream.
759
760     LWS            = [CRLF] 1*( SP | HTAB )
761
762   The TEXT rule is only used for descriptive field contents and values
763   that are not intended to be interpreted by the message parser.  Words
764   of *TEXT MAY contain characters from character sets other than ISO-
765   8859-1 [ISO-8859-1] only when encoded according to the rules of
766   [RFC2047].
767
768     TEXT           = <any OCTET except CTLs,
769                      but including LWS>
770
771   A CRLF is allowed in the definition of TEXT only as part of a header
772   field continuation.  It is expected that the folding LWS will be
773   replaced with a single SP before interpretation of the TEXT value.
774
775   Hexadecimal numeric characters are used in several protocol elements.
776
777     HEX            = "A" | "B" | "C" | "D" | "E" | "F"
778                    | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
779
780
781
782
783Fielding, et al.          Expires July 15, 2008                [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1                January 2008
786
787
788   Many HTTP/1.1 header field values consist of words separated by LWS
789   or special characters.  These special characters MUST be in a quoted
790   string to be used within a parameter value (as defined in
791   Section 3.4).
792
793     token          = 1*<any CHAR except CTLs or separators>
794     separators     = "(" | ")" | "<" | ">" | "@"
795                    | "," | ";" | ":" | "\" | DQUOTE
796                    | "/" | "[" | "]" | "?" | "="
797                    | "{" | "}" | SP | HTAB
798
799   Comments can be included in some HTTP header fields by surrounding
800   the comment text with parentheses.  Comments are only allowed in
801   fields containing "comment" as part of their field value definition.
802   In all other fields, parentheses are considered part of the field
803   value.
804
805     comment        = "(" *( ctext | quoted-pair | comment ) ")"
806     ctext          = <any TEXT excluding "(" and ")">
807
808   A string of text is parsed as a single word if it is quoted using
809   double-quote marks.
810
811     quoted-string  = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )
812     qdtext         = <any TEXT excluding DQUOTE and "\">
813
814   The backslash character ("\") MAY be used as a single-character
815   quoting mechanism only within quoted-string and comment constructs.
816
817     quoted-pair    = "\" CHAR
818
819
8203.  Protocol Parameters
821
8223.1.  HTTP Version
823
824   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
825   of the protocol.  The protocol versioning policy is intended to allow
826   the sender to indicate the format of a message and its capacity for
827   understanding further HTTP communication, rather than the features
828   obtained via that communication.  No change is made to the version
829   number for the addition of message components which do not affect
830   communication behavior or which only add to extensible field values.
831   The <minor> number is incremented when the changes made to the
832   protocol add features which do not change the general message parsing
833   algorithm, but which may add to the message semantics and imply
834   additional capabilities of the sender.  The <major> number is
835   incremented when the format of a message within the protocol is
836
837
838
839Fielding, et al.          Expires July 15, 2008                [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1                January 2008
842
843
844   changed.  See [RFC2145] for a fuller explanation.
845
846   The version of an HTTP message is indicated by an HTTP-Version field
847   in the first line of the message.  HTTP-Version is case-sensitive.
848
849     HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
850
851   Note that the major and minor numbers MUST be treated as separate
852   integers and that each MAY be incremented higher than a single digit.
853   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
854   lower than HTTP/12.3.  Leading zeros MUST be ignored by recipients
855   and MUST NOT be sent.
856
857   An application that sends a request or response message that includes
858   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
859   with this specification.  Applications that are at least
860   conditionally compliant with this specification SHOULD use an HTTP-
861   Version of "HTTP/1.1" in their messages, and MUST do so for any
862   message that is not compatible with HTTP/1.0.  For more details on
863   when to send specific HTTP-Version values, see [RFC2145].
864
865   The HTTP version of an application is the highest HTTP version for
866   which the application is at least conditionally compliant.
867
868   Proxy and gateway applications need to be careful when forwarding
869   messages in protocol versions different from that of the application.
870   Since the protocol version indicates the protocol capability of the
871   sender, a proxy/gateway MUST NOT send a message with a version
872   indicator which is greater than its actual version.  If a higher
873   version request is received, the proxy/gateway MUST either downgrade
874   the request version, or respond with an error, or switch to tunnel
875   behavior.
876
877   Due to interoperability problems with HTTP/1.0 proxies discovered
878   since the publication of [RFC2068], caching proxies MUST, gateways
879   MAY, and tunnels MUST NOT upgrade the request to the highest version
880   they support.  The proxy/gateway's response to that request MUST be
881   in the same major version as the request.
882
883      Note: Converting between versions of HTTP may involve modification
884      of header fields required or forbidden by the versions involved.
885
8863.2.  Uniform Resource Identifiers
887
888   URIs have been known by many names: WWW addresses, Universal Document
889   Identifiers, Universal Resource Identifiers [RFC1630], and finally
890   the combination of Uniform Resource Locators (URL) [RFC1738] and
891   Names (URN) [RFC1737].  As far as HTTP is concerned, Uniform Resource
892
893
894
895Fielding, et al.          Expires July 15, 2008                [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1                January 2008
898
899
900   Identifiers are simply formatted strings which identify--via name,
901   location, or any other characteristic--a resource.
902
9033.2.1.  General Syntax
904
905   URIs in HTTP can be represented in absolute form or relative to some
906   known base URI [RFC1808], depending upon the context of their use.
907   The two forms are differentiated by the fact that absolute URIs
908   always begin with a scheme name followed by a colon.  For definitive
909   information on URL syntax and semantics, see "Uniform Resource
910   Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which
911   replaces [RFC1738] and [RFC1808]).  This specification adopts the
912   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
913   "host", "abs_path", "rel_path", "query", and "authority" from that
914   specification.
915
916   The HTTP protocol does not place any a priori limit on the length of
917   a URI.  Servers MUST be able to handle the URI of any resource they
918   serve, and SHOULD be able to handle URIs of unbounded length if they
919   provide GET-based forms that could generate such URIs.  A server
920   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
921   than the server can handle (see Section 9.4.15 of [Part2]).
922
923      Note: Servers ought to be cautious about depending on URI lengths
924      above 255 bytes, because some older client or proxy
925      implementations might not properly support these lengths.
926
9273.2.2.  http URL
928
929   The "http" scheme is used to locate network resources via the HTTP
930   protocol.  This section defines the scheme-specific syntax and
931   semantics for http URLs.
932
933     http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
934
935   If the port is empty or not given, port 80 is assumed.  The semantics
936   are that the identified resource is located at the server listening
937   for TCP connections on that port of that host, and the Request-URI
938   for the resource is abs_path (Section 5.1.2).  The use of IP
939   addresses in URLs SHOULD be avoided whenever possible (see
940   [RFC1900]).  If the abs_path is not present in the URL, it MUST be
941   given as "/" when used as a Request-URI for a resource
942   (Section 5.1.2).  If a proxy receives a host name which is not a
943   fully qualified domain name, it MAY add its domain to the host name
944   it received.  If a proxy receives a fully qualified domain name, the
945   proxy MUST NOT change the host name.
946
947
948
949
950
951Fielding, et al.          Expires July 15, 2008                [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1                January 2008
954
955
9563.2.3.  URI Comparison
957
958   When comparing two URIs to decide if they match or not, a client
959   SHOULD use a case-sensitive octet-by-octet comparison of the entire
960   URIs, with these exceptions:
961
962   o  A port that is empty or not given is equivalent to the default
963      port for that URI-reference;
964
965   o  Comparisons of host names MUST be case-insensitive;
966
967   o  Comparisons of scheme names MUST be case-insensitive;
968
969   o  An empty abs_path is equivalent to an abs_path of "/".
970
971   Characters other than those in the "reserved" set (see [RFC2396]) are
972   equivalent to their ""%" HEX HEX" encoding.
973
974   For example, the following three URIs are equivalent:
975
976      http://example.com:80/~smith/home.html
977      http://EXAMPLE.com/%7Esmith/home.html
978      http://EXAMPLE.com:/%7esmith/home.html
979
9803.3.  Date/Time Formats
981
9823.3.1.  Full Date
983
984   HTTP applications have historically allowed three different formats
985   for the representation of date/time stamps:
986
987      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
988      Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
989      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
990
991   The first format is preferred as an Internet standard and represents
992   a fixed-length subset of that defined by [RFC1123] (an update to
993   [RFC822]).  The other formats are described here only for
994   compatibility with obsolete implementations.  HTTP/1.1 clients and
995   servers that parse the date value MUST accept all three formats (for
996   compatibility with HTTP/1.0), though they MUST only generate the RFC
997   1123 format for representing HTTP-date values in header fields.  See
998   Appendix B for further information.
999
1000      Note: Recipients of date values are encouraged to be robust in
1001      accepting date values that may have been sent by non-HTTP
1002      applications, as is sometimes the case when retrieving or posting
1003      messages via proxies/gateways to SMTP or NNTP.
1004
1005
1006
1007Fielding, et al.          Expires July 15, 2008                [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1                January 2008
1010
1011
1012   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1013   (GMT), without exception.  For the purposes of HTTP, GMT is exactly
1014   equal to UTC (Coordinated Universal Time).  This is indicated in the
1015   first two formats by the inclusion of "GMT" as the three-letter
1016   abbreviation for time zone, and MUST be assumed when reading the
1017   asctime format.  HTTP-date is case sensitive and MUST NOT include
1018   additional LWS beyond that specifically included as SP in the
1019   grammar.
1020
1021     HTTP-date    = rfc1123-date | rfc850-date | asctime-date
1022     rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1023     rfc850-date  = weekday "," SP date2 SP time SP "GMT"
1024     asctime-date = wkday SP date3 SP time SP 4DIGIT
1025     date1        = 2DIGIT SP month SP 4DIGIT
1026                    ; day month year (e.g., 02 Jun 1982)
1027     date2        = 2DIGIT "-" month "-" 2DIGIT
1028                    ; day-month-year (e.g., 02-Jun-82)
1029     date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
1030                    ; month day (e.g., Jun  2)
1031     time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1032                    ; 00:00:00 - 23:59:59
1033     wkday        = "Mon" | "Tue" | "Wed"
1034                  | "Thu" | "Fri" | "Sat" | "Sun"
1035     weekday      = "Monday" | "Tuesday" | "Wednesday"
1036                  | "Thursday" | "Friday" | "Saturday" | "Sunday"
1037     month        = "Jan" | "Feb" | "Mar" | "Apr"
1038                  | "May" | "Jun" | "Jul" | "Aug"
1039                  | "Sep" | "Oct" | "Nov" | "Dec"
1040
1041   Note: HTTP requirements for the date/time stamp format apply only to
1042   their usage within the protocol stream.  Clients and servers are not
1043   required to use these formats for user presentation, request logging,
1044   etc.
1045
10463.4.  Transfer Codings
1047
1048   Transfer-coding values are used to indicate an encoding
1049   transformation that has been, can be, or may need to be applied to an
1050   entity-body in order to ensure "safe transport" through the network.
1051   This differs from a content coding in that the transfer-coding is a
1052   property of the message, not of the original entity.
1053
1054     transfer-coding         = "chunked" | transfer-extension
1055     transfer-extension      = token *( ";" parameter )
1056
1057   Parameters are in the form of attribute/value pairs.
1058
1059
1060
1061
1062
1063Fielding, et al.          Expires July 15, 2008                [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1                January 2008
1066
1067
1068     parameter               = attribute "=" value
1069     attribute               = token
1070     value                   = token | quoted-string
1071
1072   All transfer-coding values are case-insensitive.  HTTP/1.1 uses
1073   transfer-coding values in the TE header field (Section 8.5) and in
1074   the Transfer-Encoding header field (Section 8.7).
1075
1076   Whenever a transfer-coding is applied to a message-body, the set of
1077   transfer-codings MUST include "chunked", unless the message is
1078   terminated by closing the connection.  When the "chunked" transfer-
1079   coding is used, it MUST be the last transfer-coding applied to the
1080   message-body.  The "chunked" transfer-coding MUST NOT be applied more
1081   than once to a message-body.  These rules allow the recipient to
1082   determine the transfer-length of the message (Section 4.4).
1083
1084   Transfer-codings are analogous to the Content-Transfer-Encoding
1085   values of MIME [RFC2045], which were designed to enable safe
1086   transport of binary data over a 7-bit transport service.  However,
1087   safe transport has a different focus for an 8bit-clean transfer
1088   protocol.  In HTTP, the only unsafe characteristic of message-bodies
1089   is the difficulty in determining the exact body length (Section 4.4),
1090   or the desire to encrypt data over a shared transport.
1091
1092   The Internet Assigned Numbers Authority (IANA) acts as a registry for
1093   transfer-coding value tokens.  Initially, the registry contains the
1094   following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and
1095   "deflate" (Section 2.2 of [Part3]).
1096
1097   New transfer-coding value tokens SHOULD be registered in the same way
1098   as new content-coding value tokens (Section 2.2 of [Part3]).
1099
1100   A server which receives an entity-body with a transfer-coding it does
1101   not understand SHOULD return 501 (Not Implemented), and close the
1102   connection.  A server MUST NOT send transfer-codings to an HTTP/1.0
1103   client.
1104
11053.4.1.  Chunked Transfer Coding
1106
1107   The chunked encoding modifies the body of a message in order to
1108   transfer it as a series of chunks, each with its own size indicator,
1109   followed by an OPTIONAL trailer containing entity-header fields.
1110   This allows dynamically produced content to be transferred along with
1111   the information necessary for the recipient to verify that it has
1112   received the full message.
1113
1114
1115
1116
1117
1118
1119Fielding, et al.          Expires July 15, 2008                [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1                January 2008
1122
1123
1124     Chunked-Body   = *chunk
1125                      last-chunk
1126                      trailer
1127                      CRLF
1128
1129     chunk          = chunk-size [ chunk-extension ] CRLF
1130                      chunk-data CRLF
1131     chunk-size     = 1*HEX
1132     last-chunk     = 1*("0") [ chunk-extension ] CRLF
1133
1134     chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1135     chunk-ext-name = token
1136     chunk-ext-val  = token | quoted-string
1137     chunk-data     = 1*OCTET ; a sequence of chunk-size octets
1138     trailer        = *(entity-header CRLF)
1139
1140   The chunk-size field is a string of hex digits indicating the size of
1141   the chunk-data in octets.  The chunked encoding is ended by any chunk
1142   whose size is zero, followed by the trailer, which is terminated by
1143   an empty line.
1144
1145   The trailer allows the sender to include additional HTTP header
1146   fields at the end of the message.  The Trailer header field can be
1147   used to indicate which header fields are included in a trailer (see
1148   Section 8.6).
1149
1150   A server using chunked transfer-coding in a response MUST NOT use the
1151   trailer for any header fields unless at least one of the following is
1152   true:
1153
1154   1.  the request included a TE header field that indicates "trailers"
1155       is acceptable in the transfer-coding of the response, as
1156       described in Section 8.5; or,
1157
1158   2.  the server is the origin server for the response, the trailer
1159       fields consist entirely of optional metadata, and the recipient
1160       could use the message (in a manner acceptable to the origin
1161       server) without receiving this metadata.  In other words, the
1162       origin server is willing to accept the possibility that the
1163       trailer fields might be silently discarded along the path to the
1164       client.
1165
1166   This requirement prevents an interoperability failure when the
1167   message is being received by an HTTP/1.1 (or later) proxy and
1168   forwarded to an HTTP/1.0 recipient.  It avoids a situation where
1169   compliance with the protocol would have necessitated a possibly
1170   infinite buffer on the proxy.
1171
1172
1173
1174
1175Fielding, et al.          Expires July 15, 2008                [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1                January 2008
1178
1179
1180   A process for decoding the "chunked" transfer-coding can be
1181   represented in pseudo-code as:
1182
1183       length := 0
1184       read chunk-size, chunk-extension (if any) and CRLF
1185       while (chunk-size > 0) {
1186          read chunk-data and CRLF
1187          append chunk-data to entity-body
1188          length := length + chunk-size
1189          read chunk-size and CRLF
1190       }
1191       read entity-header
1192       while (entity-header not empty) {
1193          append entity-header to existing header fields
1194          read entity-header
1195       }
1196       Content-Length := length
1197       Remove "chunked" from Transfer-Encoding
1198
1199   All HTTP/1.1 applications MUST be able to receive and decode the
1200   "chunked" transfer-coding, and MUST ignore chunk-extension extensions
1201   they do not understand.
1202
1203
12044.  HTTP Message
1205
12064.1.  Message Types
1207
1208   HTTP messages consist of requests from client to server and responses
1209   from server to client.
1210
1211     HTTP-message   = Request | Response     ; HTTP/1.1 messages
1212
1213   Request (Section 5) and Response (Section 6) messages use the generic
1214   message format of [RFC2822] for transferring entities (the payload of
1215   the message).  Both types of message consist of a start-line, zero or
1216   more header fields (also known as "headers"), an empty line (i.e., a
1217   line with nothing preceding the CRLF) indicating the end of the
1218   header fields, and possibly a message-body.
1219
1220     generic-message = start-line
1221                       *(message-header CRLF)
1222                       CRLF
1223                       [ message-body ]
1224     start-line      = Request-Line | Status-Line
1225
1226   In the interest of robustness, servers SHOULD ignore any empty
1227   line(s) received where a Request-Line is expected.  In other words,
1228
1229
1230
1231Fielding, et al.          Expires July 15, 2008                [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1                January 2008
1234
1235
1236   if the server is reading the protocol stream at the beginning of a
1237   message and receives a CRLF first, it should ignore the CRLF.
1238
1239   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1240   after a POST request.  To restate what is explicitly forbidden by the
1241   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1242   extra CRLF.
1243
12444.2.  Message Headers
1245
1246   HTTP header fields, which include general-header (Section 4.5),
1247   request-header (Section 4 of [Part2]), response-header (Section 6 of
1248   [Part2]), and entity-header (Section 3.1 of [Part3]) fields, follow
1249   the same generic format as that given in Section 2.1 of [RFC2822].
1250   Each header field consists of a name followed by a colon (":") and
1251   the field value.  Field names are case-insensitive.  The field value
1252   MAY be preceded by any amount of LWS, though a single SP is
1253   preferred.  Header fields can be extended over multiple lines by
1254   preceding each extra line with at least one SP or HTAB.  Applications
1255   ought to follow "common form", where one is known or indicated, when
1256   generating HTTP constructs, since there might exist some
1257   implementations that fail to accept anything beyond the common forms.
1258
1259     message-header = field-name ":" [ field-value ]
1260     field-name     = token
1261     field-value    = *( field-content | LWS )
1262     field-content  = <the OCTETs making up the field-value
1263                      and consisting of either *TEXT or combinations
1264                      of token, separators, and quoted-string>
1265
1266   The field-content does not include any leading or trailing LWS:
1267   linear white space occurring before the first non-whitespace
1268   character of the field-value or after the last non-whitespace
1269   character of the field-value.  Such leading or trailing LWS MAY be
1270   removed without changing the semantics of the field value.  Any LWS
1271   that occurs between field-content MAY be replaced with a single SP
1272   before interpreting the field value or forwarding the message
1273   downstream.
1274
1275   The order in which header fields with differing field names are
1276   received is not significant.  However, it is "good practice" to send
1277   general-header fields first, followed by request-header or response-
1278   header fields, and ending with the entity-header fields.
1279
1280   Multiple message-header fields with the same field-name MAY be
1281   present in a message if and only if the entire field-value for that
1282   header field is defined as a comma-separated list [i.e., #(values)].
1283   It MUST be possible to combine the multiple header fields into one
1284
1285
1286
1287Fielding, et al.          Expires July 15, 2008                [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1                January 2008
1290
1291
1292   "field-name: field-value" pair, without changing the semantics of the
1293   message, by appending each subsequent field-value to the first, each
1294   separated by a comma.  The order in which header fields with the same
1295   field-name are received is therefore significant to the
1296   interpretation of the combined field value, and thus a proxy MUST NOT
1297   change the order of these field values when a message is forwarded.
1298
12994.3.  Message Body
1300
1301   The message-body (if any) of an HTTP message is used to carry the
1302   entity-body associated with the request or response.  The message-
1303   body differs from the entity-body only when a transfer-coding has
1304   been applied, as indicated by the Transfer-Encoding header field
1305   (Section 8.7).
1306
1307     message-body = entity-body
1308                  | <entity-body encoded as per Transfer-Encoding>
1309
1310   Transfer-Encoding MUST be used to indicate any transfer-codings
1311   applied by an application to ensure safe and proper transfer of the
1312   message.  Transfer-Encoding is a property of the message, not of the
1313   entity, and thus MAY be added or removed by any application along the
1314   request/response chain.  (However, Section 3.4 places restrictions on
1315   when certain transfer-codings may be used.)
1316
1317   The rules for when a message-body is allowed in a message differ for
1318   requests and responses.
1319
1320   The presence of a message-body in a request is signaled by the
1321   inclusion of a Content-Length or Transfer-Encoding header field in
1322   the request's message-headers.  A message-body MUST NOT be included
1323   in a request if the specification of the request method (Section 3 of
1324   [Part2]) does not allow sending an entity-body in requests.  A server
1325   SHOULD read and forward a message-body on any request; if the request
1326   method does not include defined semantics for an entity-body, then
1327   the message-body SHOULD be ignored when handling the request.
1328
1329   For response messages, whether or not a message-body is included with
1330   a message is dependent on both the request method and the response
1331   status code (Section 6.1.1).  All responses to the HEAD request
1332   method MUST NOT include a message-body, even though the presence of
1333   entity-header fields might lead one to believe they do.  All 1xx
1334   (informational), 204 (No Content), and 304 (Not Modified) responses
1335   MUST NOT include a message-body.  All other responses do include a
1336   message-body, although it MAY be of zero length.
1337
1338
1339
1340
1341
1342
1343Fielding, et al.          Expires July 15, 2008                [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1                January 2008
1346
1347
13484.4.  Message Length
1349
1350   The transfer-length of a message is the length of the message-body as
1351   it appears in the message; that is, after any transfer-codings have
1352   been applied.  When a message-body is included with a message, the
1353   transfer-length of that body is determined by one of the following
1354   (in order of precedence):
1355
1356   1.  Any response message which "MUST NOT" include a message-body
1357       (such as the 1xx, 204, and 304 responses and any response to a
1358       HEAD request) is always terminated by the first empty line after
1359       the header fields, regardless of the entity-header fields present
1360       in the message.
1361
1362   2.  If a Transfer-Encoding header field (Section 8.7) is present,
1363       then the transfer-length is defined by use of the "chunked"
1364       transfer-coding (Section 3.4), unless the message is terminated
1365       by closing the connection.
1366
1367   3.  If a Content-Length header field (Section 8.2) is present, its
1368       decimal value in OCTETs represents both the entity-length and the
1369       transfer-length.  The Content-Length header field MUST NOT be
1370       sent if these two lengths are different (i.e., if a Transfer-
1371       Encoding header field is present).  If a message is received with
1372       both a Transfer-Encoding header field and a Content-Length header
1373       field, the latter MUST be ignored.
1374
1375   4.  If the message uses the media type "multipart/byteranges", and
1376       the transfer-length is not otherwise specified, then this self-
1377       delimiting media type defines the transfer-length.  This media
1378       type MUST NOT be used unless the sender knows that the recipient
1379       can parse it; the presence in a request of a Range header with
1380       multiple byte-range specifiers from a 1.1 client implies that the
1381       client can parse multipart/byteranges responses.
1382
1383          A range header might be forwarded by a 1.0 proxy that does not
1384          understand multipart/byteranges; in this case the server MUST
1385          delimit the message using methods defined in items 1, 3 or 5
1386          of this section.
1387
1388   5.  By the server closing the connection.  (Closing the connection
1389       cannot be used to indicate the end of a request body, since that
1390       would leave no possibility for the server to send back a
1391       response.)
1392
1393   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1394   containing a message-body MUST include a valid Content-Length header
1395   field unless the server is known to be HTTP/1.1 compliant.  If a
1396
1397
1398
1399Fielding, et al.          Expires July 15, 2008                [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1                January 2008
1402
1403
1404   request contains a message-body and a Content-Length is not given,
1405   the server SHOULD respond with 400 (Bad Request) if it cannot
1406   determine the length of the message, or with 411 (Length Required) if
1407   it wishes to insist on receiving a valid Content-Length.
1408
1409   All HTTP/1.1 applications that receive entities MUST accept the
1410   "chunked" transfer-coding (Section 3.4), thus allowing this mechanism
1411   to be used for messages when the message length cannot be determined
1412   in advance.
1413
1414   Messages MUST NOT include both a Content-Length header field and a
1415   transfer-coding.  If the message does include a transfer-coding, the
1416   Content-Length MUST be ignored.
1417
1418   When a Content-Length is given in a message where a message-body is
1419   allowed, its field value MUST exactly match the number of OCTETs in
1420   the message-body.  HTTP/1.1 user agents MUST notify the user when an
1421   invalid length is received and detected.
1422
14234.5.  General Header Fields
1424
1425   There are a few header fields which have general applicability for
1426   both request and response messages, but which do not apply to the
1427   entity being transferred.  These header fields apply only to the
1428   message being transmitted.
1429
1430     general-header = Cache-Control            ; [Part6], Section 15.2
1431                    | Connection               ; Section 8.1
1432                    | Date                     ; Section 8.3
1433                    | Pragma                   ; [Part6], Section 15.4
1434                    | Trailer                  ; Section 8.6
1435                    | Transfer-Encoding        ; Section 8.7
1436                    | Upgrade                  ; Section 8.8
1437                    | Via                      ; Section 8.9
1438                    | Warning                  ; [Part6], Section 15.6
1439
1440   General-header field names can be extended reliably only in
1441   combination with a change in the protocol version.  However, new or
1442   experimental header fields may be given the semantics of general
1443   header fields if all parties in the communication recognize them to
1444   be general-header fields.  Unrecognized header fields are treated as
1445   entity-header fields.
1446
1447
14485.  Request
1449
1450   A request message from a client to a server includes, within the
1451   first line of that message, the method to be applied to the resource,
1452
1453
1454
1455Fielding, et al.          Expires July 15, 2008                [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1                January 2008
1458
1459
1460   the identifier of the resource, and the protocol version in use.
1461
1462     Request       = Request-Line              ; Section 5.1
1463                     *(( general-header        ; Section 4.5
1464                      | request-header         ; [Part2], Section 4
1465                      | entity-header ) CRLF)  ; [Part3], Section 3.1
1466                     CRLF
1467                     [ message-body ]          ; Section 4.3
1468
14695.1.  Request-Line
1470
1471   The Request-Line begins with a method token, followed by the Request-
1472   URI and the protocol version, and ending with CRLF.  The elements are
1473   separated by SP characters.  No CR or LF is allowed except in the
1474   final CRLF sequence.
1475
1476     Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
1477
14785.1.1.  Method
1479
1480   The Method token indicates the method to be performed on the resource
1481   identified by the Request-URI.  The method is case-sensitive.
1482
1483     Method         = token
1484
14855.1.2.  Request-URI
1486
1487   The Request-URI is a Uniform Resource Identifier (Section 3.2) and
1488   identifies the resource upon which to apply the request.
1489
1490     Request-URI    = "*"
1491                    | absoluteURI
1492                    | ( abs_path [ "?" query ] )
1493                    | authority
1494
1495   The four options for Request-URI are dependent on the nature of the
1496   request.  The asterisk "*" means that the request does not apply to a
1497   particular resource, but to the server itself, and is only allowed
1498   when the method used does not necessarily apply to a resource.  One
1499   example would be
1500
1501       OPTIONS * HTTP/1.1
1502
1503   The absoluteURI form is REQUIRED when the request is being made to a
1504   proxy.  The proxy is requested to forward the request or service it
1505   from a valid cache, and return the response.  Note that the proxy MAY
1506   forward the request on to another proxy or directly to the server
1507   specified by the absoluteURI.  In order to avoid request loops, a
1508
1509
1510
1511Fielding, et al.          Expires July 15, 2008                [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1                January 2008
1514
1515
1516   proxy MUST be able to recognize all of its server names, including
1517   any aliases, local variations, and the numeric IP address.  An
1518   example Request-Line would be:
1519
1520       GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
1521
1522   To allow for transition to absoluteURIs in all requests in future
1523   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
1524   form in requests, even though HTTP/1.1 clients will only generate
1525   them in requests to proxies.
1526
1527   The authority form is only used by the CONNECT method (Section 8.9 of
1528   [Part2]).
1529
1530   The most common form of Request-URI is that used to identify a
1531   resource on an origin server or gateway.  In this case the absolute
1532   path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as
1533   the Request-URI, and the network location of the URI (authority) MUST
1534   be transmitted in a Host header field.  For example, a client wishing
1535   to retrieve the resource above directly from the origin server would
1536   create a TCP connection to port 80 of the host "www.example.org" and
1537   send the lines:
1538
1539       GET /pub/WWW/TheProject.html HTTP/1.1
1540       Host: www.example.org
1541
1542   followed by the remainder of the Request.  Note that the absolute
1543   path cannot be empty; if none is present in the original URI, it MUST
1544   be given as "/" (the server root).
1545
1546   The Request-URI is transmitted in the format specified in
1547   Section 3.2.1.  If the Request-URI is encoded using the "% HEX HEX"
1548   encoding [RFC2396], the origin server MUST decode the Request-URI in
1549   order to properly interpret the request.  Servers SHOULD respond to
1550   invalid Request-URIs with an appropriate status code.
1551
1552   A transparent proxy MUST NOT rewrite the "abs_path" part of the
1553   received Request-URI when forwarding it to the next inbound server,
1554   except as noted above to replace a null abs_path with "/".
1555
1556      Note: The "no rewrite" rule prevents the proxy from changing the
1557      meaning of the request when the origin server is improperly using
1558      a non-reserved URI character for a reserved purpose.  Implementors
1559      should be aware that some pre-HTTP/1.1 proxies have been known to
1560      rewrite the Request-URI.
1561
1562
1563
1564
1565
1566
1567Fielding, et al.          Expires July 15, 2008                [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1                January 2008
1570
1571
15725.2.  The Resource Identified by a Request
1573
1574   The exact resource identified by an Internet request is determined by
1575   examining both the Request-URI and the Host header field.
1576
1577   An origin server that does not allow resources to differ by the
1578   requested host MAY ignore the Host header field value when
1579   determining the resource identified by an HTTP/1.1 request.  (But see
1580   Appendix D.1.1 for other requirements on Host support in HTTP/1.1.)
1581
1582   An origin server that does differentiate resources based on the host
1583   requested (sometimes referred to as virtual hosts or vanity host
1584   names) MUST use the following rules for determining the requested
1585   resource on an HTTP/1.1 request:
1586
1587   1.  If Request-URI is an absoluteURI, the host is part of the
1588       Request-URI.  Any Host header field value in the request MUST be
1589       ignored.
1590
1591   2.  If the Request-URI is not an absoluteURI, and the request
1592       includes a Host header field, the host is determined by the Host
1593       header field value.
1594
1595   3.  If the host as determined by rule 1 or 2 is not a valid host on
1596       the server, the response MUST be a 400 (Bad Request) error
1597       message.
1598
1599   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
1600   attempt to use heuristics (e.g., examination of the URI path for
1601   something unique to a particular host) in order to determine what
1602   exact resource is being requested.
1603
1604
16056.  Response
1606
1607   After receiving and interpreting a request message, a server responds
1608   with an HTTP response message.
1609
1610     Response      = Status-Line               ; Section 6.1
1611                     *(( general-header        ; Section 4.5
1612                      | response-header        ; [Part2], Section 6
1613                      | entity-header ) CRLF)  ; [Part3], Section 3.1
1614                     CRLF
1615                     [ message-body ]          ; Section 4.3
1616
1617
1618
1619
1620
1621
1622
1623Fielding, et al.          Expires July 15, 2008                [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1                January 2008
1626
1627
16286.1.  Status-Line
1629
1630   The first line of a Response message is the Status-Line, consisting
1631   of the protocol version followed by a numeric status code and its
1632   associated textual phrase, with each element separated by SP
1633   characters.  No CR or LF is allowed except in the final CRLF
1634   sequence.
1635
1636     Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1637
16386.1.1.  Status Code and Reason Phrase
1639
1640   The Status-Code element is a 3-digit integer result code of the
1641   attempt to understand and satisfy the request.  These codes are fully
1642   defined in Section 9 of [Part2].  The Reason-Phrase is intended to
1643   give a short textual description of the Status-Code.  The Status-Code
1644   is intended for use by automata and the Reason-Phrase is intended for
1645   the human user.  The client is not required to examine or display the
1646   Reason-Phrase.
1647
1648   The first digit of the Status-Code defines the class of response.
1649   The last two digits do not have any categorization role.  There are 5
1650   values for the first digit:
1651
1652   o  1xx: Informational - Request received, continuing process
1653
1654   o  2xx: Success - The action was successfully received, understood,
1655      and accepted
1656
1657   o  3xx: Redirection - Further action must be taken in order to
1658      complete the request
1659
1660   o  4xx: Client Error - The request contains bad syntax or cannot be
1661      fulfilled
1662
1663   o  5xx: Server Error - The server failed to fulfill an apparently
1664      valid request
1665
1666
1667     Status-Code    = 3DIGIT
1668     Reason-Phrase  = *<TEXT, excluding CR, LF>
1669
1670
16717.  Connections
1672
1673
1674
1675
1676
1677
1678
1679Fielding, et al.          Expires July 15, 2008                [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1                January 2008
1682
1683
16847.1.  Persistent Connections
1685
16867.1.1.  Purpose
1687
1688   Prior to persistent connections, a separate TCP connection was
1689   established to fetch each URL, increasing the load on HTTP servers
1690   and causing congestion on the Internet.  The use of inline images and
1691   other associated data often require a client to make multiple
1692   requests of the same server in a short amount of time.  Analysis of
1693   these performance problems and results from a prototype
1694   implementation are available [Pad1995] [Spe].  Implementation
1695   experience and measurements of actual HTTP/1.1 (RFC 2068)
1696   implementations show good results [Nie1997].  Alternatives have also
1697   been explored, for example, T/TCP [Tou1998].
1698
1699   Persistent HTTP connections have a number of advantages:
1700
1701   o  By opening and closing fewer TCP connections, CPU time is saved in
1702      routers and hosts (clients, servers, proxies, gateways, tunnels,
1703      or caches), and memory used for TCP protocol control blocks can be
1704      saved in hosts.
1705
1706   o  HTTP requests and responses can be pipelined on a connection.
1707      Pipelining allows a client to make multiple requests without
1708      waiting for each response, allowing a single TCP connection to be
1709      used much more efficiently, with much lower elapsed time.
1710
1711   o  Network congestion is reduced by reducing the number of packets
1712      caused by TCP opens, and by allowing TCP sufficient time to
1713      determine the congestion state of the network.
1714
1715   o  Latency on subsequent requests is reduced since there is no time
1716      spent in TCP's connection opening handshake.
1717
1718   o  HTTP can evolve more gracefully, since errors can be reported
1719      without the penalty of closing the TCP connection.  Clients using
1720      future versions of HTTP might optimistically try a new feature,
1721      but if communicating with an older server, retry with old
1722      semantics after an error is reported.
1723
1724   HTTP implementations SHOULD implement persistent connections.
1725
17267.1.2.  Overall Operation
1727
1728   A significant difference between HTTP/1.1 and earlier versions of
1729   HTTP is that persistent connections are the default behavior of any
1730   HTTP connection.  That is, unless otherwise indicated, the client
1731   SHOULD assume that the server will maintain a persistent connection,
1732
1733
1734
1735Fielding, et al.          Expires July 15, 2008                [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1                January 2008
1738
1739
1740   even after error responses from the server.
1741
1742   Persistent connections provide a mechanism by which a client and a
1743   server can signal the close of a TCP connection.  This signaling
1744   takes place using the Connection header field (Section 8.1).  Once a
1745   close has been signaled, the client MUST NOT send any more requests
1746   on that connection.
1747
17487.1.2.1.  Negotiation
1749
1750   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
1751   maintain a persistent connection unless a Connection header including
1752   the connection-token "close" was sent in the request.  If the server
1753   chooses to close the connection immediately after sending the
1754   response, it SHOULD send a Connection header including the
1755   connection-token close.
1756
1757   An HTTP/1.1 client MAY expect a connection to remain open, but would
1758   decide to keep it open based on whether the response from a server
1759   contains a Connection header with the connection-token close.  In
1760   case the client does not want to maintain a connection for more than
1761   that request, it SHOULD send a Connection header including the
1762   connection-token close.
1763
1764   If either the client or the server sends the close token in the
1765   Connection header, that request becomes the last one for the
1766   connection.
1767
1768   Clients and servers SHOULD NOT assume that a persistent connection is
1769   maintained for HTTP versions less than 1.1 unless it is explicitly
1770   signaled.  See Appendix D.2 for more information on backward
1771   compatibility with HTTP/1.0 clients.
1772
1773   In order to remain persistent, all messages on the connection MUST
1774   have a self-defined message length (i.e., one not defined by closure
1775   of the connection), as described in Section 4.4.
1776
17777.1.2.2.  Pipelining
1778
1779   A client that supports persistent connections MAY "pipeline" its
1780   requests (i.e., send multiple requests without waiting for each
1781   response).  A server MUST send its responses to those requests in the
1782   same order that the requests were received.
1783
1784   Clients which assume persistent connections and pipeline immediately
1785   after connection establishment SHOULD be prepared to retry their
1786   connection if the first pipelined attempt fails.  If a client does
1787   such a retry, it MUST NOT pipeline before it knows the connection is
1788
1789
1790
1791Fielding, et al.          Expires July 15, 2008                [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1                January 2008
1794
1795
1796   persistent.  Clients MUST also be prepared to resend their requests
1797   if the server closes the connection before sending all of the
1798   corresponding responses.
1799
1800   Clients SHOULD NOT pipeline requests using non-idempotent methods or
1801   non-idempotent sequences of methods (see Section 8.1.2 of [Part2]).
1802   Otherwise, a premature termination of the transport connection could
1803   lead to indeterminate results.  A client wishing to send a non-
1804   idempotent request SHOULD wait to send that request until it has
1805   received the response status for the previous request.
1806
18077.1.3.  Proxy Servers
1808
1809   It is especially important that proxies correctly implement the
1810   properties of the Connection header field as specified in
1811   Section 8.1.
1812
1813   The proxy server MUST signal persistent connections separately with
1814   its clients and the origin servers (or other proxy servers) that it
1815   connects to.  Each persistent connection applies to only one
1816   transport link.
1817
1818   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
1819   with an HTTP/1.0 client (but see [RFC2068] for information and
1820   discussion of the problems with the Keep-Alive header implemented by
1821   many HTTP/1.0 clients).
1822
18237.1.4.  Practical Considerations
1824
1825   Servers will usually have some time-out value beyond which they will
1826   no longer maintain an inactive connection.  Proxy servers might make
1827   this a higher value since it is likely that the client will be making
1828   more connections through the same server.  The use of persistent
1829   connections places no requirements on the length (or existence) of
1830   this time-out for either the client or the server.
1831
1832   When a client or server wishes to time-out it SHOULD issue a graceful
1833   close on the transport connection.  Clients and servers SHOULD both
1834   constantly watch for the other side of the transport close, and
1835   respond to it as appropriate.  If a client or server does not detect
1836   the other side's close promptly it could cause unnecessary resource
1837   drain on the network.
1838
1839   A client, server, or proxy MAY close the transport connection at any
1840   time.  For example, a client might have started to send a new request
1841   at the same time that the server has decided to close the "idle"
1842   connection.  From the server's point of view, the connection is being
1843   closed while it was idle, but from the client's point of view, a
1844
1845
1846
1847Fielding, et al.          Expires July 15, 2008                [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1                January 2008
1850
1851
1852   request is in progress.
1853
1854   This means that clients, servers, and proxies MUST be able to recover
1855   from asynchronous close events.  Client software SHOULD reopen the
1856   transport connection and retransmit the aborted sequence of requests
1857   without user interaction so long as the request sequence is
1858   idempotent (see Section 8.1.2 of [Part2]).  Non-idempotent methods or
1859   sequences MUST NOT be automatically retried, although user agents MAY
1860   offer a human operator the choice of retrying the request(s).
1861   Confirmation by user-agent software with semantic understanding of
1862   the application MAY substitute for user confirmation.  The automatic
1863   retry SHOULD NOT be repeated if the second sequence of requests
1864   fails.
1865
1866   Servers SHOULD always respond to at least one request per connection,
1867   if at all possible.  Servers SHOULD NOT close a connection in the
1868   middle of transmitting a response, unless a network or client failure
1869   is suspected.
1870
1871   Clients that use persistent connections SHOULD limit the number of
1872   simultaneous connections that they maintain to a given server.  A
1873   single-user client SHOULD NOT maintain more than 2 connections with
1874   any server or proxy.  A proxy SHOULD use up to 2*N connections to
1875   another server or proxy, where N is the number of simultaneously
1876   active users.  These guidelines are intended to improve HTTP response
1877   times and avoid congestion.
1878
18797.2.  Message Transmission Requirements
1880
18817.2.1.  Persistent Connections and Flow Control
1882
1883   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
1884   flow control mechanisms to resolve temporary overloads, rather than
1885   terminating connections with the expectation that clients will retry.
1886   The latter technique can exacerbate network congestion.
1887
18887.2.2.  Monitoring Connections for Error Status Messages
1889
1890   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
1891   the network connection for an error status while it is transmitting
1892   the request.  If the client sees an error status, it SHOULD
1893   immediately cease transmitting the body.  If the body is being sent
1894   using a "chunked" encoding (Section 3.4), a zero length chunk and
1895   empty trailer MAY be used to prematurely mark the end of the message.
1896   If the body was preceded by a Content-Length header, the client MUST
1897   close the connection.
1898
1899
1900
1901
1902
1903Fielding, et al.          Expires July 15, 2008                [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1                January 2008
1906
1907
19087.2.3.  Use of the 100 (Continue) Status
1909
1910   The purpose of the 100 (Continue) status (see Section 9.1.1 of
1911   [Part2]) is to allow a client that is sending a request message with
1912   a request body to determine if the origin server is willing to accept
1913   the request (based on the request headers) before the client sends
1914   the request body.  In some cases, it might either be inappropriate or
1915   highly inefficient for the client to send the body if the server will
1916   reject the message without looking at the body.
1917
1918   Requirements for HTTP/1.1 clients:
1919
1920   o  If a client will wait for a 100 (Continue) response before sending
1921      the request body, it MUST send an Expect request-header field
1922      (Section 10.2 of [Part2]) with the "100-continue" expectation.
1923
1924   o  A client MUST NOT send an Expect request-header field (Section
1925      10.2 of [Part2]) with the "100-continue" expectation if it does
1926      not intend to send a request body.
1927
1928   Because of the presence of older implementations, the protocol allows
1929   ambiguous situations in which a client may send "Expect: 100-
1930   continue" without receiving either a 417 (Expectation Failed) status
1931   or a 100 (Continue) status.  Therefore, when a client sends this
1932   header field to an origin server (possibly via a proxy) from which it
1933   has never seen a 100 (Continue) status, the client SHOULD NOT wait
1934   for an indefinite period before sending the request body.
1935
1936   Requirements for HTTP/1.1 origin servers:
1937
1938   o  Upon receiving a request which includes an Expect request-header
1939      field with the "100-continue" expectation, an origin server MUST
1940      either respond with 100 (Continue) status and continue to read
1941      from the input stream, or respond with a final status code.  The
1942      origin server MUST NOT wait for the request body before sending
1943      the 100 (Continue) response.  If it responds with a final status
1944      code, it MAY close the transport connection or it MAY continue to
1945      read and discard the rest of the request.  It MUST NOT perform the
1946      requested method if it returns a final status code.
1947
1948   o  An origin server SHOULD NOT send a 100 (Continue) response if the
1949      request message does not include an Expect request-header field
1950      with the "100-continue" expectation, and MUST NOT send a 100
1951      (Continue) response if such a request comes from an HTTP/1.0 (or
1952      earlier) client.  There is an exception to this rule: for
1953      compatibility with [RFC2068], a server MAY send a 100 (Continue)
1954      status in response to an HTTP/1.1 PUT or POST request that does
1955      not include an Expect request-header field with the "100-continue"
1956
1957
1958
1959Fielding, et al.          Expires July 15, 2008                [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1                January 2008
1962
1963
1964      expectation.  This exception, the purpose of which is to minimize
1965      any client processing delays associated with an undeclared wait
1966      for 100 (Continue) status, applies only to HTTP/1.1 requests, and
1967      not to requests with any other HTTP-version value.
1968
1969   o  An origin server MAY omit a 100 (Continue) response if it has
1970      already received some or all of the request body for the
1971      corresponding request.
1972
1973   o  An origin server that sends a 100 (Continue) response MUST
1974      ultimately send a final status code, once the request body is
1975      received and processed, unless it terminates the transport
1976      connection prematurely.
1977
1978   o  If an origin server receives a request that does not include an
1979      Expect request-header field with the "100-continue" expectation,
1980      the request includes a request body, and the server responds with
1981      a final status code before reading the entire request body from
1982      the transport connection, then the server SHOULD NOT close the
1983      transport connection until it has read the entire request, or
1984      until the client closes the connection.  Otherwise, the client
1985      might not reliably receive the response message.  However, this
1986      requirement is not be construed as preventing a server from
1987      defending itself against denial-of-service attacks, or from badly
1988      broken client implementations.
1989
1990   Requirements for HTTP/1.1 proxies:
1991
1992   o  If a proxy receives a request that includes an Expect request-
1993      header field with the "100-continue" expectation, and the proxy
1994      either knows that the next-hop server complies with HTTP/1.1 or
1995      higher, or does not know the HTTP version of the next-hop server,
1996      it MUST forward the request, including the Expect header field.
1997
1998   o  If the proxy knows that the version of the next-hop server is
1999      HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2000      respond with a 417 (Expectation Failed) status.
2001
2002   o  Proxies SHOULD maintain a cache recording the HTTP version numbers
2003      received from recently-referenced next-hop servers.
2004
2005   o  A proxy MUST NOT forward a 100 (Continue) response if the request
2006      message was received from an HTTP/1.0 (or earlier) client and did
2007      not include an Expect request-header field with the "100-continue"
2008      expectation.  This requirement overrides the general rule for
2009      forwarding of 1xx responses (see Section 9.1 of [Part2]).
2010
2011
2012
2013
2014
2015Fielding, et al.          Expires July 15, 2008                [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1                January 2008
2018
2019
20207.2.4.  Client Behavior if Server Prematurely Closes Connection
2021
2022   If an HTTP/1.1 client sends a request which includes a request body,
2023   but which does not include an Expect request-header field with the
2024   "100-continue" expectation, and if the client is not directly
2025   connected to an HTTP/1.1 origin server, and if the client sees the
2026   connection close before receiving any status from the server, the
2027   client SHOULD retry the request.  If the client does retry this
2028   request, it MAY use the following "binary exponential backoff"
2029   algorithm to be assured of obtaining a reliable response:
2030
2031   1.  Initiate a new connection to the server
2032
2033   2.  Transmit the request-headers
2034
2035   3.  Initialize a variable R to the estimated round-trip time to the
2036       server (e.g., based on the time it took to establish the
2037       connection), or to a constant value of 5 seconds if the round-
2038       trip time is not available.
2039
2040   4.  Compute T = R * (2**N), where N is the number of previous retries
2041       of this request.
2042
2043   5.  Wait either for an error response from the server, or for T
2044       seconds (whichever comes first)
2045
2046   6.  If no error response is received, after T seconds transmit the
2047       body of the request.
2048
2049   7.  If client sees that the connection is closed prematurely, repeat
2050       from step 1 until the request is accepted, an error response is
2051       received, or the user becomes impatient and terminates the retry
2052       process.
2053
2054   If at any point an error status is received, the client
2055
2056   o  SHOULD NOT continue and
2057
2058   o  SHOULD close the connection if it has not completed sending the
2059      request message.
2060
2061
20628.  Header Field Definitions
2063
2064   This section defines the syntax and semantics of HTTP/1.1 header
2065   fields related to message framing and transport protocols.
2066
2067   For entity-header fields, both sender and recipient refer to either
2068
2069
2070
2071Fielding, et al.          Expires July 15, 2008                [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1                January 2008
2074
2075
2076   the client or the server, depending on who sends and who receives the
2077   entity.
2078
20798.1.  Connection
2080
2081   The Connection general-header field allows the sender to specify
2082   options that are desired for that particular connection and MUST NOT
2083   be communicated by proxies over further connections.
2084
2085   The Connection header has the following grammar:
2086
2087     Connection = "Connection" ":" 1#(connection-token)
2088     connection-token  = token
2089
2090   HTTP/1.1 proxies MUST parse the Connection header field before a
2091   message is forwarded and, for each connection-token in this field,
2092   remove any header field(s) from the message with the same name as the
2093   connection-token.  Connection options are signaled by the presence of
2094   a connection-token in the Connection header field, not by any
2095   corresponding additional header field(s), since the additional header
2096   field may not be sent if there are no parameters associated with that
2097   connection option.
2098
2099   Message headers listed in the Connection header MUST NOT include end-
2100   to-end headers, such as Cache-Control.
2101
2102   HTTP/1.1 defines the "close" connection option for the sender to
2103   signal that the connection will be closed after completion of the
2104   response.  For example,
2105
2106       Connection: close
2107
2108   in either the request or the response header fields indicates that
2109   the connection SHOULD NOT be considered `persistent' (Section 7.1)
2110   after the current request/response is complete.
2111
2112   An HTTP/1.1 client that does not support persistent connections MUST
2113   include the "close" connection option in every request message.
2114
2115   An HTTP/1.1 server that does not support persistent connections MUST
2116   include the "close" connection option in every response message that
2117   does not have a 1xx (informational) status code.
2118
2119   A system receiving an HTTP/1.0 (or lower-version) message that
2120   includes a Connection header MUST, for each connection-token in this
2121   field, remove and ignore any header field(s) from the message with
2122   the same name as the connection-token.  This protects against
2123   mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
2124
2125
2126
2127Fielding, et al.          Expires July 15, 2008                [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1                January 2008
2130
2131
2132   See Appendix D.2.
2133
21348.2.  Content-Length
2135
2136   The Content-Length entity-header field indicates the size of the
2137   entity-body, in decimal number of OCTETs, sent to the recipient or,
2138   in the case of the HEAD method, the size of the entity-body that
2139   would have been sent had the request been a GET.
2140
2141     Content-Length    = "Content-Length" ":" 1*DIGIT
2142
2143   An example is
2144
2145       Content-Length: 3495
2146
2147   Applications SHOULD use this field to indicate the transfer-length of
2148   the message-body, unless this is prohibited by the rules in
2149   Section 4.4.
2150
2151   Any Content-Length greater than or equal to zero is a valid value.
2152   Section 4.4 describes how to determine the length of a message-body
2153   if a Content-Length is not given.
2154
2155   Note that the meaning of this field is significantly different from
2156   the corresponding definition in MIME, where it is an optional field
2157   used within the "message/external-body" content-type.  In HTTP, it
2158   SHOULD be sent whenever the message's length can be determined prior
2159   to being transferred, unless this is prohibited by the rules in
2160   Section 4.4.
2161
21628.3.  Date
2163
2164   The Date general-header field represents the date and time at which
2165   the message was originated, having the same semantics as orig-date in
2166   Section 3.6.1 of [RFC2822].  The field value is an HTTP-date, as
2167   described in Section 3.3.1; it MUST be sent in rfc1123-date format.
2168
2169     Date  = "Date" ":" HTTP-date
2170
2171   An example is
2172
2173       Date: Tue, 15 Nov 1994 08:12:31 GMT
2174
2175   Origin servers MUST include a Date header field in all responses,
2176   except in these cases:
2177
2178   1.  If the response status code is 100 (Continue) or 101 (Switching
2179       Protocols), the response MAY include a Date header field, at the
2180
2181
2182
2183Fielding, et al.          Expires July 15, 2008                [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1                January 2008
2186
2187
2188       server's option.
2189
2190   2.  If the response status code conveys a server error, e.g. 500
2191       (Internal Server Error) or 503 (Service Unavailable), and it is
2192       inconvenient or impossible to generate a valid Date.
2193
2194   3.  If the server does not have a clock that can provide a reasonable
2195       approximation of the current time, its responses MUST NOT include
2196       a Date header field.  In this case, the rules in Section 8.3.1
2197       MUST be followed.
2198
2199   A received message that does not have a Date header field MUST be
2200   assigned one by the recipient if the message will be cached by that
2201   recipient or gatewayed via a protocol which requires a Date.  An HTTP
2202   implementation without a clock MUST NOT cache responses without
2203   revalidating them on every use.  An HTTP cache, especially a shared
2204   cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
2205   its clock with a reliable external standard.
2206
2207   Clients SHOULD only send a Date header field in messages that include
2208   an entity-body, as in the case of the PUT and POST requests, and even
2209   then it is optional.  A client without a clock MUST NOT send a Date
2210   header field in a request.
2211
2212   The HTTP-date sent in a Date header SHOULD NOT represent a date and
2213   time subsequent to the generation of the message.  It SHOULD
2214   represent the best available approximation of the date and time of
2215   message generation, unless the implementation has no means of
2216   generating a reasonably accurate date and time.  In theory, the date
2217   ought to represent the moment just before the entity is generated.
2218   In practice, the date can be generated at any time during the message
2219   origination without affecting its semantic value.
2220
22218.3.1.  Clockless Origin Server Operation
2222
2223   Some origin server implementations might not have a clock available.
2224   An origin server without a clock MUST NOT assign Expires or Last-
2225   Modified values to a response, unless these values were associated
2226   with the resource by a system or user with a reliable clock.  It MAY
2227   assign an Expires value that is known, at or before server
2228   configuration time, to be in the past (this allows "pre-expiration"
2229   of responses without storing separate Expires values for each
2230   resource).
2231
22328.4.  Host
2233
2234   The Host request-header field specifies the Internet host and port
2235   number of the resource being requested, as obtained from the original
2236
2237
2238
2239Fielding, et al.          Expires July 15, 2008                [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1                January 2008
2242
2243
2244   URI given by the user or referring resource (generally an HTTP URL,
2245   as described in Section 3.2.2).  The Host field value MUST represent
2246   the naming authority of the origin server or gateway given by the
2247   original URL.  This allows the origin server or gateway to
2248   differentiate between internally-ambiguous URLs, such as the root "/"
2249   URL of a server for multiple host names on a single IP address.
2250
2251     Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
2252
2253   A "host" without any trailing port information implies the default
2254   port for the service requested (e.g., "80" for an HTTP URL).  For
2255   example, a request on the origin server for
2256   <http://www.example.org/pub/WWW/> would properly include:
2257
2258       GET /pub/WWW/ HTTP/1.1
2259       Host: www.example.org
2260
2261   A client MUST include a Host header field in all HTTP/1.1 request
2262   messages.  If the requested URI does not include an Internet host
2263   name for the service being requested, then the Host header field MUST
2264   be given with an empty value.  An HTTP/1.1 proxy MUST ensure that any
2265   request message it forwards does contain an appropriate Host header
2266   field that identifies the service being requested by the proxy.  All
2267   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
2268   status code to any HTTP/1.1 request message which lacks a Host header
2269   field.
2270
2271   See Sections 5.2 and D.1.1 for other requirements relating to Host.
2272
22738.5.  TE
2274
2275   The TE request-header field indicates what extension transfer-codings
2276   it is willing to accept in the response and whether or not it is
2277   willing to accept trailer fields in a chunked transfer-coding.  Its
2278   value may consist of the keyword "trailers" and/or a comma-separated
2279   list of extension transfer-coding names with optional accept
2280   parameters (as described in Section 3.4).
2281
2282     TE        = "TE" ":" #( t-codings )
2283     t-codings = "trailers" | ( transfer-extension [ accept-params ] )
2284
2285   The presence of the keyword "trailers" indicates that the client is
2286   willing to accept trailer fields in a chunked transfer-coding, as
2287   defined in Section 3.4.1.  This keyword is reserved for use with
2288   transfer-coding values even though it does not itself represent a
2289   transfer-coding.
2290
2291   Examples of its use are:
2292
2293
2294
2295Fielding, et al.          Expires July 15, 2008                [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1                January 2008
2298
2299
2300       TE: deflate
2301       TE:
2302       TE: trailers, deflate;q=0.5
2303
2304   The TE header field only applies to the immediate connection.
2305   Therefore, the keyword MUST be supplied within a Connection header
2306   field (Section 8.1) whenever TE is present in an HTTP/1.1 message.
2307
2308   A server tests whether a transfer-coding is acceptable, according to
2309   a TE field, using these rules:
2310
2311   1.  The "chunked" transfer-coding is always acceptable.  If the
2312       keyword "trailers" is listed, the client indicates that it is
2313       willing to accept trailer fields in the chunked response on
2314       behalf of itself and any downstream clients.  The implication is
2315       that, if given, the client is stating that either all downstream
2316       clients are willing to accept trailer fields in the forwarded
2317       response, or that it will attempt to buffer the response on
2318       behalf of downstream recipients.
2319
2320       Note: HTTP/1.1 does not define any means to limit the size of a
2321       chunked response such that a client can be assured of buffering
2322       the entire response.
2323
2324   2.  If the transfer-coding being tested is one of the transfer-
2325       codings listed in the TE field, then it is acceptable unless it
2326       is accompanied by a qvalue of 0.  (As defined in Section 2.4 of
2327       [Part3], a qvalue of 0 means "not acceptable.")
2328
2329   3.  If multiple transfer-codings are acceptable, then the acceptable
2330       transfer-coding with the highest non-zero qvalue is preferred.
2331       The "chunked" transfer-coding always has a qvalue of 1.
2332
2333   If the TE field-value is empty or if no TE field is present, the only
2334   transfer-coding is "chunked".  A message with no transfer-coding is
2335   always acceptable.
2336
23378.6.  Trailer
2338
2339   The Trailer general field value indicates that the given set of
2340   header fields is present in the trailer of a message encoded with
2341   chunked transfer-coding.
2342
2343     Trailer  = "Trailer" ":" 1#field-name
2344
2345   An HTTP/1.1 message SHOULD include a Trailer header field in a
2346   message using chunked transfer-coding with a non-empty trailer.
2347   Doing so allows the recipient to know which header fields to expect
2348
2349
2350
2351Fielding, et al.          Expires July 15, 2008                [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1                January 2008
2354
2355
2356   in the trailer.
2357
2358   If no Trailer header field is present, the trailer SHOULD NOT include
2359   any header fields.  See Section 3.4.1 for restrictions on the use of
2360   trailer fields in a "chunked" transfer-coding.
2361
2362   Message header fields listed in the Trailer header field MUST NOT
2363   include the following header fields:
2364
2365   o  Transfer-Encoding
2366
2367   o  Content-Length
2368
2369   o  Trailer
2370
23718.7.  Transfer-Encoding
2372
2373   The Transfer-Encoding general-header field indicates what (if any)
2374   type of transformation has been applied to the message body in order
2375   to safely transfer it between the sender and the recipient.  This
2376   differs from the content-coding in that the transfer-coding is a
2377   property of the message, not of the entity.
2378
2379     Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
2380
2381   Transfer-codings are defined in Section 3.4.  An example is:
2382
2383     Transfer-Encoding: chunked
2384
2385   If multiple encodings have been applied to an entity, the transfer-
2386   codings MUST be listed in the order in which they were applied.
2387   Additional information about the encoding parameters MAY be provided
2388   by other entity-header fields not defined by this specification.
2389
2390   Many older HTTP/1.0 applications do not understand the Transfer-
2391   Encoding header.
2392
23938.8.  Upgrade
2394
2395   The Upgrade general-header allows the client to specify what
2396   additional communication protocols it supports and would like to use
2397   if the server finds it appropriate to switch protocols.  The server
2398   MUST use the Upgrade header field within a 101 (Switching Protocols)
2399   response to indicate which protocol(s) are being switched.
2400
2401     Upgrade        = "Upgrade" ":" 1#product
2402
2403   For example,
2404
2405
2406
2407Fielding, et al.          Expires July 15, 2008                [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1                January 2008
2410
2411
2412       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
2413
2414   The Upgrade header field is intended to provide a simple mechanism
2415   for transition from HTTP/1.1 to some other, incompatible protocol.
2416   It does so by allowing the client to advertise its desire to use
2417   another protocol, such as a later version of HTTP with a higher major
2418   version number, even though the current request has been made using
2419   HTTP/1.1.  This eases the difficult transition between incompatible
2420   protocols by allowing the client to initiate a request in the more
2421   commonly supported protocol while indicating to the server that it
2422   would like to use a "better" protocol if available (where "better" is
2423   determined by the server, possibly according to the nature of the
2424   method and/or resource being requested).
2425
2426   The Upgrade header field only applies to switching application-layer
2427   protocols upon the existing transport-layer connection.  Upgrade
2428   cannot be used to insist on a protocol change; its acceptance and use
2429   by the server is optional.  The capabilities and nature of the
2430   application-layer communication after the protocol change is entirely
2431   dependent upon the new protocol chosen, although the first action
2432   after changing the protocol MUST be a response to the initial HTTP
2433   request containing the Upgrade header field.
2434
2435   The Upgrade header field only applies to the immediate connection.
2436   Therefore, the upgrade keyword MUST be supplied within a Connection
2437   header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1
2438   message.
2439
2440   The Upgrade header field cannot be used to indicate a switch to a
2441   protocol on a different connection.  For that purpose, it is more
2442   appropriate to use a 301, 302, 303, or 305 redirection response.
2443
2444   This specification only defines the protocol name "HTTP" for use by
2445   the family of Hypertext Transfer Protocols, as defined by the HTTP
2446   version rules of Section 3.1 and future updates to this
2447   specification.  Any token can be used as a protocol name; however, it
2448   will only be useful if both the client and server associate the name
2449   with the same protocol.
2450
24518.9.  Via
2452
2453   The Via general-header field MUST be used by gateways and proxies to
2454   indicate the intermediate protocols and recipients between the user
2455   agent and the server on requests, and between the origin server and
2456   the client on responses.  It is analogous to the "Received" field of
2457   [RFC2822] and is intended to be used for tracking message forwards,
2458   avoiding request loops, and identifying the protocol capabilities of
2459   all senders along the request/response chain.
2460
2461
2462
2463Fielding, et al.          Expires July 15, 2008                [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1                January 2008
2466
2467
2468     Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
2469     received-protocol = [ protocol-name "/" ] protocol-version
2470     protocol-name     = token
2471     protocol-version  = token
2472     received-by       = ( host [ ":" port ] ) | pseudonym
2473     pseudonym         = token
2474
2475   The received-protocol indicates the protocol version of the message
2476   received by the server or client along each segment of the request/
2477   response chain.  The received-protocol version is appended to the Via
2478   field value when the message is forwarded so that information about
2479   the protocol capabilities of upstream applications remains visible to
2480   all recipients.
2481
2482   The protocol-name is optional if and only if it would be "HTTP".  The
2483   received-by field is normally the host and optional port number of a
2484   recipient server or client that subsequently forwarded the message.
2485   However, if the real host is considered to be sensitive information,
2486   it MAY be replaced by a pseudonym.  If the port is not given, it MAY
2487   be assumed to be the default port of the received-protocol.
2488
2489   Multiple Via field values represents each proxy or gateway that has
2490   forwarded the message.  Each recipient MUST append its information
2491   such that the end result is ordered according to the sequence of
2492   forwarding applications.
2493
2494   Comments MAY be used in the Via header field to identify the software
2495   of the recipient proxy or gateway, analogous to the User-Agent and
2496   Server header fields.  However, all comments in the Via field are
2497   optional and MAY be removed by any recipient prior to forwarding the
2498   message.
2499
2500   For example, a request message could be sent from an HTTP/1.0 user
2501   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2502   forward the request to a public proxy at p.example.net, which
2503   completes the request by forwarding it to the origin server at
2504   www.example.com.  The request received by www.example.com would then
2505   have the following Via header field:
2506
2507       Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
2508
2509   Proxies and gateways used as a portal through a network firewall
2510   SHOULD NOT, by default, forward the names and ports of hosts within
2511   the firewall region.  This information SHOULD only be propagated if
2512   explicitly enabled.  If not enabled, the received-by host of any host
2513   behind the firewall SHOULD be replaced by an appropriate pseudonym
2514   for that host.
2515
2516
2517
2518
2519Fielding, et al.          Expires July 15, 2008                [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1                January 2008
2522
2523
2524   For organizations that have strong privacy requirements for hiding
2525   internal structures, a proxy MAY combine an ordered subsequence of
2526   Via header field entries with identical received-protocol values into
2527   a single such entry.  For example,
2528
2529       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2530
2531   could be collapsed to
2532
2533       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2534
2535   Applications SHOULD NOT combine multiple entries unless they are all
2536   under the same organizational control and the hosts have already been
2537   replaced by pseudonyms.  Applications MUST NOT combine entries which
2538   have different received-protocol values.
2539
2540
25419.  IANA Considerations
2542
2543   TBD.
2544
2545
254610.  Security Considerations
2547
2548   This section is meant to inform application developers, information
2549   providers, and users of the security limitations in HTTP/1.1 as
2550   described by this document.  The discussion does not include
2551   definitive solutions to the problems revealed, though it does make
2552   some suggestions for reducing security risks.
2553
255410.1.  Personal Information
2555
2556   HTTP clients are often privy to large amounts of personal information
2557   (e.g. the user's name, location, mail address, passwords, encryption
2558   keys, etc.), and SHOULD be very careful to prevent unintentional
2559   leakage of this information via the HTTP protocol to other sources.
2560   We very strongly recommend that a convenient interface be provided
2561   for the user to control dissemination of such information, and that
2562   designers and implementors be particularly careful in this area.
2563   History shows that errors in this area often create serious security
2564   and/or privacy problems and generate highly adverse publicity for the
2565   implementor's company.
2566
256710.2.  Abuse of Server Log Information
2568
2569   A server is in the position to save personal data about a user's
2570   requests which might identify their reading patterns or subjects of
2571   interest.  This information is clearly confidential in nature and its
2572
2573
2574
2575Fielding, et al.          Expires July 15, 2008                [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1                January 2008
2578
2579
2580   handling can be constrained by law in certain countries.  People
2581   using the HTTP protocol to provide data are responsible for ensuring
2582   that such material is not distributed without the permission of any
2583   individuals that are identifiable by the published results.
2584
258510.3.  Attacks Based On File and Path Names
2586
2587   Implementations of HTTP origin servers SHOULD be careful to restrict
2588   the documents returned by HTTP requests to be only those that were
2589   intended by the server administrators.  If an HTTP server translates
2590   HTTP URIs directly into file system calls, the server MUST take
2591   special care not to serve files that were not intended to be
2592   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
2593   other operating systems use ".." as a path component to indicate a
2594   directory level above the current one.  On such a system, an HTTP
2595   server MUST disallow any such construct in the Request-URI if it
2596   would otherwise allow access to a resource outside those intended to
2597   be accessible via the HTTP server.  Similarly, files intended for
2598   reference only internally to the server (such as access control
2599   files, configuration files, and script code) MUST be protected from
2600   inappropriate retrieval, since they might contain sensitive
2601   information.  Experience has shown that minor bugs in such HTTP
2602   server implementations have turned into security risks.
2603
260410.4.  DNS Spoofing
2605
2606   Clients using HTTP rely heavily on the Domain Name Service, and are
2607   thus generally prone to security attacks based on the deliberate mis-
2608   association of IP addresses and DNS names.  Clients need to be
2609   cautious in assuming the continuing validity of an IP number/DNS name
2610   association.
2611
2612   In particular, HTTP clients SHOULD rely on their name resolver for
2613   confirmation of an IP number/DNS name association, rather than
2614   caching the result of previous host name lookups.  Many platforms
2615   already can cache host name lookups locally when appropriate, and
2616   they SHOULD be configured to do so.  It is proper for these lookups
2617   to be cached, however, only when the TTL (Time To Live) information
2618   reported by the name server makes it likely that the cached
2619   information will remain useful.
2620
2621   If HTTP clients cache the results of host name lookups in order to
2622   achieve a performance improvement, they MUST observe the TTL
2623   information reported by DNS.
2624
2625   If HTTP clients do not observe this rule, they could be spoofed when
2626   a previously-accessed server's IP address changes.  As network
2627   renumbering is expected to become increasingly common [RFC1900], the
2628
2629
2630
2631Fielding, et al.          Expires July 15, 2008                [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1                January 2008
2634
2635
2636   possibility of this form of attack will grow.  Observing this
2637   requirement thus reduces this potential security vulnerability.
2638
2639   This requirement also improves the load-balancing behavior of clients
2640   for replicated servers using the same DNS name and reduces the
2641   likelihood of a user's experiencing failure in accessing sites which
2642   use that strategy.
2643
264410.5.  Proxies and Caching
2645
2646   By their very nature, HTTP proxies are men-in-the-middle, and
2647   represent an opportunity for man-in-the-middle attacks.  Compromise
2648   of the systems on which the proxies run can result in serious
2649   security and privacy problems.  Proxies have access to security-
2650   related information, personal information about individual users and
2651   organizations, and proprietary information belonging to users and
2652   content providers.  A compromised proxy, or a proxy implemented or
2653   configured without regard to security and privacy considerations,
2654   might be used in the commission of a wide range of potential attacks.
2655
2656   Proxy operators should protect the systems on which proxies run as
2657   they would protect any system that contains or transports sensitive
2658   information.  In particular, log information gathered at proxies
2659   often contains highly sensitive personal information, and/or
2660   information about organizations.  Log information should be carefully
2661   guarded, and appropriate guidelines for use developed and followed.
2662   (Section 10.2).
2663
2664   Proxy implementors should consider the privacy and security
2665   implications of their design and coding decisions, and of the
2666   configuration options they provide to proxy operators (especially the
2667   default configuration).
2668
2669   Users of a proxy need to be aware that they are no trustworthier than
2670   the people who run the proxy; HTTP itself cannot solve this problem.
2671
2672   The judicious use of cryptography, when appropriate, may suffice to
2673   protect against a broad range of security and privacy attacks.  Such
2674   cryptography is beyond the scope of the HTTP/1.1 specification.
2675
267610.6.  Denial of Service Attacks on Proxies
2677
2678   They exist.  They are hard to defend against.  Research continues.
2679   Beware.
2680
2681
2682
2683
2684
2685
2686
2687Fielding, et al.          Expires July 15, 2008                [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1                January 2008
2690
2691
269211.  Acknowledgments
2693
2694   This specification makes heavy use of the augmented BNF and generic
2695   constructs defined by David H. Crocker for [RFC822ABNF].  Similarly,
2696   it reuses many of the definitions provided by Nathaniel Borenstein
2697   and Ned Freed for MIME [RFC2045].  We hope that their inclusion in
2698   this specification will help reduce past confusion over the
2699   relationship between HTTP and Internet mail message formats.
2700
2701   The HTTP protocol has evolved considerably over the years.  It has
2702   benefited from a large and active developer community--the many
2703   people who have participated on the www-talk mailing list--and it is
2704   that community which has been most responsible for the success of
2705   HTTP and of the World-Wide Web in general.  Marc Andreessen, Robert
2706   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
2707   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
2708   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
2709   VanHeyningen deserve special recognition for their efforts in
2710   defining early aspects of the protocol.
2711
2712   This document has benefited greatly from the comments of all those
2713   participating in the HTTP-WG.  In addition to those already
2714   mentioned, the following individuals have contributed to this
2715   specification:
2716
2717   Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
2718   Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
2719   Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
2720   Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
2721   Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut,
2722   David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert
2723   Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David
2724   Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott
2725   Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich
2726   Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
2727   Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
2728   Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
2729
2730   Thanks to the "cave men" of Palo Alto.  You know who you are.
2731
2732   Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
2733   Fielding, the editor of [RFC2068], along with John Klensin, Jeff
2734   Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
2735   Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
2736   help.  And thanks go particularly to Jeff Mogul and Scott Lawrence
2737   for performing the "MUST/MAY/SHOULD" audit.
2738
2739   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
2740
2741
2742
2743Fielding, et al.          Expires July 15, 2008                [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1                January 2008
2746
2747
2748   Frystyk implemented RFC 2068 early, and we wish to thank them for the
2749   discovery of many of the problems that this document attempts to
2750   rectify.
2751
2752
275312.  References
2754
275512.1.  Normative References
2756
2757   [ISO-8859-1]
2758              International Organization for Standardization,
2759              "Information technology -- 8-bit single-byte coded graphic
2760              character sets -- Part 1: Latin alphabet No. 1", ISO/
2761              IEC 8859-1:1998, 1998.
2762
2763   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2764              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2765              and J. Reschke, Ed., "HTTP/1.1, part 2: Message
2766              Semantics", draft-ietf-httpbis-p2-semantics-01 (work in
2767              progress), January 2008.
2768
2769   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2770              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2771              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2772              and Content Negotiation", draft-ietf-httpbis-p3-payload-01
2773              (work in progress), January 2008.
2774
2775   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2776              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2777              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2778              Partial Responses", draft-ietf-httpbis-p5-range-01 (work
2779              in progress), January 2008.
2780
2781   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2782              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2783              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2784              draft-ietf-httpbis-p6-cache-01 (work in progress),
2785              January 2008.
2786
2787   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2788              Extensions (MIME) Part One: Format of Internet Message
2789              Bodies", RFC 2045, November 1996.
2790
2791   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
2792              Part Three: Message Header Extensions for Non-ASCII Text",
2793              RFC 2047, November 1996.
2794
2795   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2796
2797
2798
2799Fielding, et al.          Expires July 15, 2008                [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1                January 2008
2802
2803
2804              Requirement Levels", BCP 14, RFC 2119, March 1997.
2805
2806   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2807              Resource Identifiers (URI): Generic Syntax", RFC 2396,
2808              August 1998.
2809
2810   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
2811              Registration Procedures", BCP 13, RFC 4288, December 2005.
2812
2813   [RFC822ABNF]
2814              Crocker, D., "Standard for the format of ARPA Internet
2815              text messages", STD 11, RFC 822, August 1982.
2816
2817   [USASCII]  American National Standards Institute, "Coded Character
2818              Set -- 7-bit American Standard Code for Information
2819              Interchange", ANSI X3.4, 1986.
2820
282112.2.  Informative References
2822
2823   [Nie1997]  Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
2824              C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
2825              and PNG", ACM Proceedings of the ACM SIGCOMM '97
2826              conference on Applications, technologies, architectures,
2827              and protocols for computer communication SIGCOMM '97,
2828              September 1997,
2829              <http://doi.acm.org/10.1145/263105.263157>.
2830
2831   [Pad1995]  Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
2832              Computer Networks and ISDN Systems v. 28, pp. 25-35,
2833              December 1995.
2834
2835              Slightly revised version of paper in Proc. 2nd
2836              International WWW Conference '94: Mosaic and the Web, Oct.
2837              1994, which is available at <http://www.ncsa.uiuc.edu/SDG/
2838              IT94/Proceedings/DDay/mogul/HTTPLatency.html>.
2839
2840   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
2841              and Support", STD 3, RFC 1123, October 1989.
2842
2843   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
2844              Specification, Implementation", RFC 1305, March 1992.
2845
2846   [RFC1436]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
2847              Torrey, D., and B. Alberti, "The Internet Gopher Protocol
2848              (a distributed document search and retrieval protocol)",
2849              RFC 1436, March 1993.
2850
2851   [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
2852
2853
2854
2855Fielding, et al.          Expires July 15, 2008                [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1                January 2008
2858
2859
2860              Unifying Syntax for the Expression of Names and Addresses
2861              of Objects on the Network as used in the World-Wide Web",
2862              RFC 1630, June 1994.
2863
2864   [RFC1737]  Masinter, L. and K. Sollins, "Functional Requirements for
2865              Uniform Resource Names", RFC 1737, December 1994.
2866
2867   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
2868              Resource Locators (URL)", RFC 1738, December 1994.
2869
2870   [RFC1808]  Fielding, R., "Relative Uniform Resource Locators",
2871              RFC 1808, June 1995.
2872
2873   [RFC1900]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
2874              RFC 1900, February 1996.
2875
2876   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2877              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2878
2879   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2880              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2881              RFC 2068, January 1997.
2882
2883   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
2884              and Interpretation of HTTP Version Numbers", RFC 2145,
2885              May 1997.
2886
2887   [RFC2324]  Masinter, L., "Hyper Text Coffee Pot Control Protocol
2888              (HTCPCP/1.0)", RFC 2324, April 1998.
2889
2890   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2891              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2892              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2893
2894   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
2895              April 2001.
2896
2897   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
2898              April 2001.
2899
2900   [RFC3977]  Feather, C., "Network News Transfer Protocol (NNTP)",
2901              RFC 3977, October 2006.
2902
2903   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
2904              text messages", STD 11, RFC 822, August 1982.
2905
2906   [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
2907              STD 9, RFC 959, October 1985.
2908
2909
2910
2911Fielding, et al.          Expires July 15, 2008                [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1                January 2008
2914
2915
2916   [Spe]      Spero, S., "Analysis of HTTP Performance Problems",
2917              <http://sunsite.unc.edu/mdma-release/http-prob.html>.
2918
2919   [Tou1998]  Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
2920              HTTP Performance", ISI Research Report ISI/RR-98-463,
2921              Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
2922
2923              (original report dated Aug. 1996)
2924
2925   [WAIS]     Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T.,
2926              Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface
2927              Protocol Prototype Functional Specification (v1.5)",
2928              Thinking Machines Corporation , April 1990.
2929
2930
2931Appendix A.  Internet Media Types
2932
2933   In addition to defining the HTTP/1.1 protocol, this document serves
2934   as the specification for the Internet media type "message/http" and
2935   "application/http".  The following is to be registered with IANA
2936   [RFC4288].
2937
2938A.1.  Internet Media Type message/http
2939
2940   The message/http type can be used to enclose a single HTTP request or
2941   response message, provided that it obeys the MIME restrictions for
2942   all "message" types regarding line length and encodings.
2943
2944   Type name:  message
2945
2946   Subtype name:  http
2947
2948   Required parameters:  none
2949
2950   Optional parameters:  version, msgtype
2951
2952      version:  The HTTP-Version number of the enclosed message (e.g.,
2953         "1.1").  If not present, the version can be determined from the
2954         first line of the body.
2955
2956      msgtype:  The message type -- "request" or "response".  If not
2957         present, the type can be determined from the first line of the
2958         body.
2959
2960
2961
2962
2963
2964
2965
2966
2967Fielding, et al.          Expires July 15, 2008                [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1                January 2008
2970
2971
2972   Encoding considerations:  only "7bit", "8bit", or "binary" are
2973      permitted
2974
2975   Security considerations:  none
2976
2977   Interoperability considerations:  none
2978
2979   Published specification:  This specification (see Appendix A.1).
2980
2981   Applications that use this media type:
2982
2983   Additional information:
2984
2985      Magic number(s):  none
2986
2987      File extension(s):  none
2988
2989      Macintosh file type code(s):  none
2990
2991   Person and email address to contact for further information:  See
2992      Authors Section.
2993
2994   Intended usage:  COMMON
2995
2996   Restrictions on usage:  none
2997
2998   Author/Change controller:  IESG
2999
3000A.2.  Internet Media Type application/http
3001
3002   The application/http type can be used to enclose a pipeline of one or
3003   more HTTP request or response messages (not intermixed).
3004
3005   Type name:  application
3006
3007   Subtype name:  http
3008
3009   Required parameters:  none
3010
3011   Optional parameters:  version, msgtype
3012
3013      version:  The HTTP-Version number of the enclosed messages (e.g.,
3014         "1.1").  If not present, the version can be determined from the
3015         first line of the body.
3016
3017
3018
3019
3020
3021
3022
3023Fielding, et al.          Expires July 15, 2008                [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1                January 2008
3026
3027
3028      msgtype:  The message type -- "request" or "response".  If not
3029         present, the type can be determined from the first line of the
3030         body.
3031
3032   Encoding considerations:  HTTP messages enclosed by this type are in
3033      "binary" format; use of an appropriate Content-Transfer-Encoding
3034      is required when transmitted via E-mail.
3035
3036   Security considerations:  none
3037
3038   Interoperability considerations:  none
3039
3040   Published specification:  This specification (see Appendix A.2).
3041
3042   Applications that use this media type:
3043
3044   Additional information:
3045
3046      Magic number(s):  none
3047
3048      File extension(s):  none
3049
3050      Macintosh file type code(s):  none
3051
3052   Person and email address to contact for further information:  See
3053      Authors Section.
3054
3055   Intended usage:  COMMON
3056
3057   Restrictions on usage:  none
3058
3059   Author/Change controller:  IESG
3060
3061
3062Appendix B.  Tolerant Applications
3063
3064   Although this document specifies the requirements for the generation
3065   of HTTP/1.1 messages, not all applications will be correct in their
3066   implementation.  We therefore recommend that operational applications
3067   be tolerant of deviations whenever those deviations can be
3068   interpreted unambiguously.
3069
3070   Clients SHOULD be tolerant in parsing the Status-Line and servers
3071   tolerant when parsing the Request-Line.  In particular, they SHOULD
3072   accept any amount of SP or HTAB characters between fields, even
3073   though only a single SP is required.
3074
3075   The line terminator for message-header fields is the sequence CRLF.
3076
3077
3078
3079Fielding, et al.          Expires July 15, 2008                [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1                January 2008
3082
3083
3084   However, we recommend that applications, when parsing such headers,
3085   recognize a single LF as a line terminator and ignore the leading CR.
3086
3087   The character set of an entity-body SHOULD be labeled as the lowest
3088   common denominator of the character codes used within that body, with
3089   the exception that not labeling the entity is preferred over labeling
3090   the entity with the labels US-ASCII or ISO-8859-1.  See [Part3].
3091
3092   Additional rules for requirements on parsing and encoding of dates
3093   and other potential problems with date encodings include:
3094
3095   o  HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
3096      which appears to be more than 50 years in the future is in fact in
3097      the past (this helps solve the "year 2000" problem).
3098
3099   o  An HTTP/1.1 implementation MAY internally represent a parsed
3100      Expires date as earlier than the proper value, but MUST NOT
3101      internally represent a parsed Expires date as later than the
3102      proper value.
3103
3104   o  All expiration-related calculations MUST be done in GMT.  The
3105      local time zone MUST NOT influence the calculation or comparison
3106      of an age or expiration time.
3107
3108   o  If an HTTP header incorrectly carries a date value with a time
3109      zone other than GMT, it MUST be converted into GMT using the most
3110      conservative possible conversion.
3111
3112
3113Appendix C.  Conversion of Date Formats
3114
3115   HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to
3116   simplify the process of date comparison.  Proxies and gateways from
3117   other protocols SHOULD ensure that any Date header field present in a
3118   message conforms to one of the HTTP/1.1 formats and rewrite the date
3119   if necessary.
3120
3121
3122Appendix D.  Compatibility with Previous Versions
3123
3124   It is beyond the scope of a protocol specification to mandate
3125   compliance with previous versions.  HTTP/1.1 was deliberately
3126   designed, however, to make supporting previous versions easy.  It is
3127   worth noting that, at the time of composing this specification
3128   (1996), we would expect commercial HTTP/1.1 servers to:
3129
3130   o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and
3131      1.1 requests;
3132
3133
3134
3135Fielding, et al.          Expires July 15, 2008                [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1                January 2008
3138
3139
3140   o  understand any valid request in the format of HTTP/0.9, 1.0, or
3141      1.1;
3142
3143   o  respond appropriately with a message in the same major version
3144      used by the client.
3145
3146   And we would expect HTTP/1.1 clients to:
3147
3148   o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
3149      responses;
3150
3151   o  understand any valid response in the format of HTTP/0.9, 1.0, or
3152      1.1.
3153
3154   For most implementations of HTTP/1.0, each connection is established
3155   by the client prior to the request and closed by the server after
3156   sending the response.  Some implementations implement the Keep-Alive
3157   version of persistent connections described in Section 19.7.1 of
3158   [RFC2068].
3159
3160D.1.  Changes from HTTP/1.0
3161
3162   This section summarizes major differences between versions HTTP/1.0
3163   and HTTP/1.1.
3164
3165D.1.1.  Changes to Simplify Multi-homed Web Servers and Conserve IP
3166        Addresses
3167
3168   The requirements that clients and servers support the Host request-
3169   header, report an error if the Host request-header (Section 8.4) is
3170   missing from an HTTP/1.1 request, and accept absolute URIs
3171   (Section 5.1.2) are among the most important changes defined by this
3172   specification.
3173
3174   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3175   addresses and servers; there was no other established mechanism for
3176   distinguishing the intended server of a request than the IP address
3177   to which that request was directed.  The changes outlined above will
3178   allow the Internet, once older HTTP clients are no longer common, to
3179   support multiple Web sites from a single IP address, greatly
3180   simplifying large operational Web servers, where allocation of many
3181   IP addresses to a single host has created serious problems.  The
3182   Internet will also be able to recover the IP addresses that have been
3183   allocated for the sole purpose of allowing special-purpose domain
3184   names to be used in root-level HTTP URLs.  Given the rate of growth
3185   of the Web, and the number of servers already deployed, it is
3186   extremely important that all implementations of HTTP (including
3187   updates to existing HTTP/1.0 applications) correctly implement these
3188
3189
3190
3191Fielding, et al.          Expires July 15, 2008                [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1                January 2008
3194
3195
3196   requirements:
3197
3198   o  Both clients and servers MUST support the Host request-header.
3199
3200   o  A client that sends an HTTP/1.1 request MUST send a Host header.
3201
3202   o  Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
3203      request does not include a Host request-header.
3204
3205   o  Servers MUST accept absolute URIs.
3206
3207D.2.  Compatibility with HTTP/1.0 Persistent Connections
3208
3209   Some clients and servers might wish to be compatible with some
3210   previous implementations of persistent connections in HTTP/1.0
3211   clients and servers.  Persistent connections in HTTP/1.0 are
3212   explicitly negotiated as they are not the default behavior.  HTTP/1.0
3213   experimental implementations of persistent connections are faulty,
3214   and the new facilities in HTTP/1.1 are designed to rectify these
3215   problems.  The problem was that some existing 1.0 clients may be
3216   sending Keep-Alive to a proxy server that doesn't understand
3217   Connection, which would then erroneously forward it to the next
3218   inbound server, which would establish the Keep-Alive connection and
3219   result in a hung HTTP/1.0 proxy waiting for the close on the
3220   response.  The result is that HTTP/1.0 clients must be prevented from
3221   using Keep-Alive when talking to proxies.
3222
3223   However, talking to proxies is the most important use of persistent
3224   connections, so that prohibition is clearly unacceptable.  Therefore,
3225   we need some other mechanism for indicating a persistent connection
3226   is desired, which is safe to use even when talking to an old proxy
3227   that ignores Connection.  Persistent connections are the default for
3228   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
3229   declaring non-persistence.  See Section 8.1.
3230
3231   The original HTTP/1.0 form of persistent connections (the Connection:
3232   Keep-Alive and Keep-Alive header) is documented in [RFC2068].
3233
3234D.3.  Changes from RFC 2068
3235
3236   This specification has been carefully audited to correct and
3237   disambiguate key word usage; RFC 2068 had many problems in respect to
3238   the conventions laid out in [RFC2119].
3239
3240   Transfer-coding and message lengths all interact in ways that
3241   required fixing exactly when chunked encoding is used (to allow for
3242   transfer encoding that may not be self delimiting); it was important
3243   to straighten out exactly how message lengths are computed.
3244
3245
3246
3247Fielding, et al.          Expires July 15, 2008                [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1                January 2008
3250
3251
3252   (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6])
3253
3254   The use and interpretation of HTTP version numbers has been clarified
3255   by [RFC2145].  Require proxies to upgrade requests to highest
3256   protocol version they support to deal with problems discovered in
3257   HTTP/1.0 implementations (Section 3.1)
3258
3259   Transfer-coding had significant problems, particularly with
3260   interactions with chunked encoding.  The solution is that transfer-
3261   codings become as full fledged as content-codings.  This involves
3262   adding an IANA registry for transfer-codings (separate from content
3263   codings), a new header field (TE) and enabling trailer headers in the
3264   future.  Transfer encoding is a major performance benefit, so it was
3265   worth fixing [Nie1997].  TE also solves another, obscure, downward
3266   interoperability problem that could have occurred due to interactions
3267   between authentication trailers, chunked encoding and HTTP/1.0
3268   clients.(Section 3.4, 3.4.1, and 8.5)
3269
3270D.4.  Changes from RFC 2616
3271
3272   Clarify that HTTP-Version is case sensitive.  (Section 3.1)
3273
3274   Remove reference to non-existant identity transfer-coding value
3275   tokens.  (Sections 3.4 and 4.4)
3276
3277   Clarification that the chunk length does not include the count of the
3278   octets in the chunk header and trailer.  (Section 3.4.1)
3279
3280   Fix BNF to add query, as the abs_path production in Section 3 of
3281   [RFC2396] doesn't define it.  (Section 5.1.2)
3282
3283   Clarify exactly when close connection options must be sent.
3284   (Section 8.1)
3285
3286
3287Appendix E.  Change Log (to be removed by RFC Editor before publication)
3288
3289E.1.  Since RFC2616
3290
3291   Extracted relevant partitions from [RFC2616].
3292
3293E.2.  Since draft-ietf-httpbis-p1-messaging-00
3294
3295   Closed issues:
3296
3297   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP
3298      Version should be case sensitive"
3299      (<http://purl.org/NET/http-errata#verscase>)
3300
3301
3302
3303Fielding, et al.          Expires July 15, 2008                [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1                January 2008
3306
3307
3308   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
3309      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
3310
3311   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
3312      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
3313
3314   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message
3315      Length" (<http://purl.org/NET/http-errata#msg-len-chars>)
3316
3317   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
3318      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
3319
3320   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI
3321      includes query" (<http://purl.org/NET/http-errata#uriquery>)
3322
3323   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close
3324      on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
3325
3326   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
3327      'identity' token references"
3328      (<http://purl.org/NET/http-errata#identity>)
3329
3330   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import
3331      query BNF"
3332
3333   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext
3334      BNF"
3335
3336   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
3337      and Informative references"
3338
3339   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
3340      Compliance"
3341
3342   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
3343      reference"
3344
3345   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
3346      references"
3347
3348   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>:
3349      "inconsistency in date format explanation"
3350
3351   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date
3352      reference typo"
3353
3354   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
3355      "Informative references"
3356
3357
3358
3359Fielding, et al.          Expires July 15, 2008                [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1                January 2008
3362
3363
3364   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:
3365      "ISO-8859-1 Reference"
3366
3367   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
3368      up-to-date references"
3369
3370   Other changes:
3371
3372   o  Update media type registrations to use RFC4288 template.
3373
3374   o  Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
3375      for chunk-data (work in progress on
3376      <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
3377
3378
3379Index
3380
3381   A
3382      application/http Media Type  54
3383
3384   C
3385      cache  8
3386      cacheable  9
3387      client  7
3388      connection  6
3389      Connection header  38
3390      content negotiation  7
3391      Content-Length header  39
3392
3393   D
3394      Date header  39
3395      downstream  9
3396
3397   E
3398      entity  7
3399
3400   G
3401      gateway  8
3402      Grammar
3403         ALPHA  14
3404         asctime-date  19
3405         attribute  20
3406         CHAR  14
3407         chunk  21
3408         chunk-data  21
3409         chunk-ext-name  21
3410         chunk-ext-val  21
3411         chunk-extension  21
3412
3413
3414
3415Fielding, et al.          Expires July 15, 2008                [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1                January 2008
3418
3419
3420         chunk-size  21
3421         Chunked-Body  21
3422         comment  15
3423         Connection  38
3424         connection-token  38
3425         Content-Length  39
3426         CR  14
3427         CRLF  14
3428         ctext  15
3429         CTL  14
3430         Date  39
3431         date1  19
3432         date2  19
3433         date3  19
3434         DIGIT  14
3435         DQUOTE  14
3436         extension-code  30
3437         extension-method  27
3438         field-content  23
3439         field-name  23
3440         field-value  23
3441         general-header  26
3442         generic-message  22
3443         HEX  14
3444         Host  41
3445         HTAB  14
3446         HTTP-date  19
3447         HTTP-message  22
3448         HTTP-Version  16
3449         http_URL  17
3450         last-chunk  21
3451         LF  14
3452         LOALPHA  14
3453         LWS  14
3454         message-body  24
3455         message-header  23
3456         Method  27
3457         month  19
3458         OCTET  14
3459         parameter  20
3460         protocol-name  45
3461         protocol-version  45
3462         pseudonym  45
3463         qdtext  15
3464         quoted-pair  15
3465         quoted-string  15
3466         Reason-Phrase  30
3467         received-by  45
3468
3469
3470
3471Fielding, et al.          Expires July 15, 2008                [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1                January 2008
3474
3475
3476         received-protocol  45
3477         Request  27
3478         Request-Line  27
3479         Request-URI  27
3480         Response  29
3481         rfc850-date  19
3482         rfc1123-date  19
3483         separators  15
3484         SP  14
3485         start-line  22
3486         Status-Code  30
3487         Status-Line  30
3488         t-codings  41
3489         TE  41
3490         TEXT  14
3491         time  19
3492         token  15
3493         Trailer  42
3494         trailer  21
3495         transfer-coding  19
3496         Transfer-Encoding  43
3497         transfer-extension  19
3498         UPALPHA  14
3499         Upgrade  43
3500         value  20
3501         Via  45
3502         weekday  19
3503         wkday  19
3504
3505   H
3506      Headers
3507         Connection  38
3508         Content-Length  39
3509         Date  39
3510         Host  40
3511         TE  41
3512         Trailer  42
3513         Transfer-Encoding  43
3514         Upgrade  43
3515         Via  44
3516      Host header  40
3517
3518   I
3519      inbound  9
3520
3521   M
3522      Media Type
3523         application/http  54
3524
3525
3526
3527Fielding, et al.          Expires July 15, 2008                [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1                January 2008
3530
3531
3532         message/http  53
3533      message  6
3534      message/http Media Type  53
3535
3536   O
3537      origin server  8
3538      outbound  9
3539
3540   P
3541      proxy  8
3542
3543   R
3544      representation  7
3545      request  6
3546      resource  7
3547      response  6
3548
3549   S
3550      server  8
3551
3552   T
3553      TE header  41
3554      Trailer header  42
3555      Transfer-Encoding header  43
3556      tunnel  8
3557
3558   U
3559      Upgrade header  43
3560      upstream  9
3561      user agent  7
3562
3563   V
3564      variant  7
3565      Via header  44
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583Fielding, et al.          Expires July 15, 2008                [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1                January 2008
3586
3587
3588Authors' Addresses
3589
3590   Roy T. Fielding (editor)
3591   Day Software
3592   23 Corporate Plaza DR, Suite 280
3593   Newport Beach, CA  92660
3594   USA
3595
3596   Phone: +1-949-706-5300
3597   Fax:   +1-949-706-5305
3598   Email: fielding@gbiv.com
3599   URI:   http://roy.gbiv.com/
3600
3601
3602   Jim Gettys
3603   One Laptop per Child
3604   21 Oak Knoll Road
3605   Carlisle, MA  01741
3606   USA
3607
3608   Email: jg@laptop.org
3609   URI:   http://www.laptop.org/
3610
3611
3612   Jeffrey C. Mogul
3613   Hewlett-Packard Company
3614   HP Labs, Large Scale Systems Group
3615   1501 Page Mill Road, MS 1177
3616   Palo Alto, CA  94304
3617   USA
3618
3619   Email: JeffMogul@acm.org
3620
3621
3622   Henrik Frystyk Nielsen
3623   Microsoft Corporation
3624   1 Microsoft Way
3625   Redmond, WA  98052
3626   USA
3627
3628   Email: henrikn@microsoft.com
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639Fielding, et al.          Expires July 15, 2008                [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1                January 2008
3642
3643
3644   Larry Masinter
3645   Adobe Systems, Incorporated
3646   345 Park Ave
3647   San Jose, CA  95110
3648   USA
3649
3650   Email: LMM@acm.org
3651   URI:   http://larry.masinter.net/
3652
3653
3654   Paul J. Leach
3655   Microsoft Corporation
3656   1 Microsoft Way
3657   Redmond, WA  98052
3658
3659   Email: paulle@microsoft.com
3660
3661
3662   Tim Berners-Lee
3663   World Wide Web Consortium
3664   MIT Computer Science and Artificial Intelligence Laboratory
3665   The Stata Center, Building 32
3666   32 Vassar Street
3667   Cambridge, MA  02139
3668   USA
3669
3670   Email: timbl@w3.org
3671   URI:   http://www.w3.org/People/Berners-Lee/
3672
3673
3674   Yves Lafon (editor)
3675   World Wide Web Consortium
3676   W3C / ERCIM
3677   2004, rte des Lucioles
3678   Sophia-Antipolis, AM  06902
3679   France
3680
3681   Email: ylafon@w3.org
3682   URI:   http://www.raubacapeu.net/people/yves/
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695Fielding, et al.          Expires July 15, 2008                [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1                January 2008
3698
3699
3700   Julian F. Reschke (editor)
3701   greenbytes GmbH
3702   Hafenweg 16
3703   Muenster, NW  48155
3704   Germany
3705
3706   Phone: +49 251 2807760
3707   Fax:   +49 251 2807761
3708   Email: julian.reschke@greenbytes.de
3709   URI:   http://greenbytes.de/tech/webdav/
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751Fielding, et al.          Expires July 15, 2008                [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1                January 2008
3754
3755
3756Full Copyright Statement
3757
3758   Copyright (C) The IETF Trust (2008).
3759
3760   This document is subject to the rights, licenses and restrictions
3761   contained in BCP 78, and except as set forth therein, the authors
3762   retain all their rights.
3763
3764   This document and the information contained herein are provided on an
3765   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3766   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
3767   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
3768   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
3769   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3770   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3771
3772
3773Intellectual Property
3774
3775   The IETF takes no position regarding the validity or scope of any
3776   Intellectual Property Rights or other rights that might be claimed to
3777   pertain to the implementation or use of the technology described in
3778   this document or the extent to which any license under such rights
3779   might or might not be available; nor does it represent that it has
3780   made any independent effort to identify any such rights.  Information
3781   on the procedures with respect to rights in RFC documents can be
3782   found in BCP 78 and BCP 79.
3783
3784   Copies of IPR disclosures made to the IETF Secretariat and any
3785   assurances of licenses to be made available, or the result of an
3786   attempt made to obtain a general license or permission for the use of
3787   such proprietary rights by implementers or users of this
3788   specification can be obtained from the IETF on-line IPR repository at
3789   http://www.ietf.org/ipr.
3790
3791   The IETF invites any interested party to bring to its attention any
3792   copyrights, patents or patent applications, or other proprietary
3793   rights that may cover technology that may be required to implement
3794   this standard.  Please address the information to the IETF at
3795   ietf-ipr@ietf.org.
3796
3797
3798Acknowledgment
3799
3800   Funding for the RFC Editor function is provided by the IETF
3801   Administrative Support Activity (IASA).
3802
3803
3804
3805
3806
3807Fielding, et al.          Expires July 15, 2008                [Page 68]
3808
Note: See TracBrowser for help on using the repository browser.