source: draft-ietf-httpbis/00/draft-ietf-httpbis-p1-messaging-00.txt @ 63

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

Update issues list URI and draft names

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