source: draft-ietf-httpbis/03/draft-ietf-httpbis-p1-messaging-03.txt @ 872

Last change on this file since 872 was 559, checked in by fielding@…, 11 years ago

remove executable and set eol-style for earlier drafts

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