source: draft-ietf-httpbis/02/draft-ietf-httpbis-p1-messaging-02.txt @ 377

Last change on this file since 377 was 219, checked in by julian.reschke@…, 12 years ago

Prepare for release of draft 02 on Monday, Feb 24.

  • Property svn:executable set to *
File size: 153.6 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: August 27, 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                                                       February 24, 2008
23
24
25        HTTP/1.1, part 1: URIs, Connections, and Message Parsing
26                   draft-ietf-httpbis-p1-messaging-02
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 August 27, 2008.
52
53
54
55Fielding, et al.         Expires August 27, 2008                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 1               February 2008
58
59
60Copyright Notice
61
62   Copyright (C) The IETF Trust (2008).
63
64Abstract
65
66   The Hypertext Transfer Protocol (HTTP) is an application-level
67   protocol for distributed, collaborative, hypermedia information
68   systems.  HTTP has been in use by the World Wide Web global
69   information initiative since 1990.  This document is Part 1 of the
70   seven-part specification that defines the protocol referred to as
71   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 1 provides
72   an overview of HTTP and its associated terminology, defines the
73   "http" and "https" Uniform Resource Identifier (URI) schemes, defines
74   the generic message syntax and parsing requirements for HTTP message
75   frames, and describes general security concerns for implementations.
76
77Editorial Note (To be removed by RFC Editor)
78
79   Discussion of this draft should take place on the HTTPBIS working
80   group mailing list (ietf-http-wg@w3.org).  The current issues list is
81   at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
82   documents (including fancy diffs) can be found at
83   <http://www.tools.ietf.org/wg/httpbis/>.
84
85   This draft incorporates those issue resolutions that were either
86   collected in the original RFC2616 errata list
87   (<http://purl.org/NET/http-errata>), or which were agreed upon on the
88   mailing list between October 2006 and November 2007 (as published in
89   "draft-lafon-rfc2616bis-03").
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.         Expires August 27, 2008                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 1               February 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   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 47
185     10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48
186     10.2. Abuse of Server Log Information  . . . . . . . . . . . . . 48
187     10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48
188     10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49
189     10.5. Proxies and Caching  . . . . . . . . . . . . . . . . . . . 49
190     10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50
191   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 50
192   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
193     12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
194     12.2. Informative References . . . . . . . . . . . . . . . . . . 52
195   Appendix A.  Internet Media Types  . . . . . . . . . . . . . . . . 54
196     A.1.  Internet Media Type message/http . . . . . . . . . . . . . 54
197     A.2.  Internet Media Type application/http . . . . . . . . . . . 56
198   Appendix B.  Tolerant Applications . . . . . . . . . . . . . . . . 57
199   Appendix C.  Conversion of Date Formats  . . . . . . . . . . . . . 58
200   Appendix D.  Compatibility with Previous Versions  . . . . . . . . 58
201     D.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 58
202       D.1.1.  Changes to Simplify Multi-homed Web Servers and
203               Conserve IP Addresses  . . . . . . . . . . . . . . . . 59
204     D.2.  Compatibility with HTTP/1.0 Persistent Connections . . . . 59
205     D.3.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 60
206     D.4.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 60
207   Appendix E.  Change Log (to be removed by RFC Editor before
208                publication)  . . . . . . . . . . . . . . . . . . . . 61
209     E.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 61
210     E.2.  Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
211     E.3.  Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62
212   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
213   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
214   Intellectual Property and Copyright Statements . . . . . . . . . . 70
215
216
217
218
219
220
221
222
223Fielding, et al.         Expires August 27, 2008                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 1               February 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-pair    = "\" CHAR
831
832
833
834
835
836
837
838
839Fielding, et al.         Expires August 27, 2008               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 1               February 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" "/" 1*DIGIT "." 1*DIGIT
884
885   Note that the major and minor numbers MUST be treated as separate
886   integers and that each MAY be incremented higher than a single digit.
887   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
888   lower than HTTP/12.3.  Leading zeros MUST be ignored by recipients
889   and MUST NOT be sent.
890
891   An application that sends a request or response message that includes
892
893
894
895Fielding, et al.         Expires August 27, 2008               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 1               February 2008
898
899
900   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
901   with this specification.  Applications that are at least
902   conditionally compliant with this specification SHOULD use an HTTP-
903   Version of "HTTP/1.1" in their messages, and MUST do so for any
904   message that is not compatible with HTTP/1.0.  For more details on
905   when to send specific HTTP-Version values, see [RFC2145].
906
907   The HTTP version of an application is the highest HTTP version for
908   which the application is at least conditionally compliant.
909
910   Proxy and gateway applications need to be careful when forwarding
911   messages in protocol versions different from that of the application.
912   Since the protocol version indicates the protocol capability of the
913   sender, a proxy/gateway MUST NOT send a message with a version
914   indicator which is greater than its actual version.  If a higher
915   version request is received, the proxy/gateway MUST either downgrade
916   the request version, or respond with an error, or switch to tunnel
917   behavior.
918
919   Due to interoperability problems with HTTP/1.0 proxies discovered
920   since the publication of [RFC2068], caching proxies MUST, gateways
921   MAY, and tunnels MUST NOT upgrade the request to the highest version
922   they support.  The proxy/gateway's response to that request MUST be
923   in the same major version as the request.
924
925      Note: Converting between versions of HTTP may involve modification
926      of header fields required or forbidden by the versions involved.
927
9283.2.  Uniform Resource Identifiers
929
930   URIs have been known by many names: WWW addresses, Universal Document
931   Identifiers, Universal Resource Identifiers [RFC1630], and finally
932   the combination of Uniform Resource Locators (URL) [RFC1738] and
933   Names (URN) [RFC1737].  As far as HTTP is concerned, Uniform Resource
934   Identifiers are simply formatted strings which identify--via name,
935   location, or any other characteristic--a resource.
936
9373.2.1.  General Syntax
938
939   URIs in HTTP can be represented in absolute form or relative to some
940   known base URI [RFC1808], depending upon the context of their use.
941   The two forms are differentiated by the fact that absolute URIs
942   always begin with a scheme name followed by a colon.  For definitive
943   information on URL syntax and semantics, see "Uniform Resource
944   Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which
945   replaces [RFC1738] and [RFC1808]).  This specification adopts the
946   definitions of "URI-reference", "absoluteURI", "fragment",
947   "relativeURI", "port", "host", "abs_path", "query", and "authority"
948
949
950
951Fielding, et al.         Expires August 27, 2008               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 1               February 2008
954
955
956   from that specification:
957
958     absoluteURI   = <absoluteURI, defined in [RFC2396], Section 3>
959     authority     = <authority, defined in [RFC2396], Section 3.2>
960     fragment      = <fragment, defined in [RFC2396], Section 4.1>
961     path-absolute = <abs_path, defined in [RFC2396], Section 3>
962     port          = <port, defined in [RFC2396], Section 3.2.2>
963     query         = <query, defined in [RFC2396], Section 3.4>
964     relativeURI   = <relativeURI, defined in [RFC2396], Section 5>
965     uri-host      = <host, defined in [RFC2396], Section 3.2.2>
966
967   HTTP does not place any a priori limit on the length of a URI.
968   Servers MUST be able to handle the URI of any resource they serve,
969   and SHOULD be able to handle URIs of unbounded length if they provide
970   GET-based forms that could generate such URIs.  A server SHOULD
971   return 414 (Request-URI Too Long) status if a URI is longer than the
972   server can handle (see Section 9.4.15 of [Part2]).
973
974      Note: Servers ought to be cautious about depending on URI lengths
975      above 255 bytes, because some older client or proxy
976      implementations might not properly support these lengths.
977
9783.2.2.  http URL
979
980   The "http" scheme is used to locate network resources via the HTTP
981   protocol.  This section defines the scheme-specific syntax and
982   semantics for http URLs.
983
984     http-URL = "http:" "//" uri-host [ ":" port ]
985                [ path-absolute [ "?" query ]]
986
987   If the port is empty or not given, port 80 is assumed.  The semantics
988   are that the identified resource is located at the server listening
989   for TCP connections on that port of that host, and the Request-URI
990   for the resource is path-absolute (Section 5.1.2).  The use of IP
991   addresses in URLs SHOULD be avoided whenever possible (see
992   [RFC1900]).  If the path-absolute is not present in the URL, it MUST
993   be given as "/" when used as a Request-URI for a resource
994   (Section 5.1.2).  If a proxy receives a host name which is not a
995   fully qualified domain name, it MAY add its domain to the host name
996   it received.  If a proxy receives a fully qualified domain name, the
997   proxy MUST NOT change the host name.
998
9993.2.3.  URI Comparison
1000
1001   When comparing two URIs to decide if they match or not, a client
1002   SHOULD use a case-sensitive octet-by-octet comparison of the entire
1003   URIs, with these exceptions:
1004
1005
1006
1007Fielding, et al.         Expires August 27, 2008               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 1               February 2008
1010
1011
1012   o  A port that is empty or not given is equivalent to the default
1013      port for that URI-reference;
1014
1015   o  Comparisons of host names MUST be case-insensitive;
1016
1017   o  Comparisons of scheme names MUST be case-insensitive;
1018
1019   o  An empty path-absolute is equivalent to an path-absolute of "/".
1020
1021   Characters other than those in the "reserved" set (see [RFC2396]) are
1022   equivalent to their ""%" HEX HEX" encoding.
1023
1024   For example, the following three URIs are equivalent:
1025
1026      http://example.com:80/~smith/home.html
1027      http://EXAMPLE.com/%7Esmith/home.html
1028      http://EXAMPLE.com:/%7esmith/home.html
1029
10303.3.  Date/Time Formats
1031
10323.3.1.  Full Date
1033
1034   HTTP applications have historically allowed three different formats
1035   for the representation of date/time stamps:
1036
1037      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
1038      Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1039      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
1040
1041   The first format is preferred as an Internet standard and represents
1042   a fixed-length subset of that defined by [RFC1123] (an update to
1043   [RFC822]).  The other formats are described here only for
1044   compatibility with obsolete implementations.  HTTP/1.1 clients and
1045   servers that parse the date value MUST accept all three formats (for
1046   compatibility with HTTP/1.0), though they MUST only generate the RFC
1047   1123 format for representing HTTP-date values in header fields.  See
1048   Appendix B for further information.
1049
1050      Note: Recipients of date values are encouraged to be robust in
1051      accepting date values that may have been sent by non-HTTP
1052      applications, as is sometimes the case when retrieving or posting
1053      messages via proxies/gateways to SMTP or NNTP.
1054
1055   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1056   (GMT), without exception.  For the purposes of HTTP, GMT is exactly
1057   equal to UTC (Coordinated Universal Time).  This is indicated in the
1058   first two formats by the inclusion of "GMT" as the three-letter
1059   abbreviation for time zone, and MUST be assumed when reading the
1060
1061
1062
1063Fielding, et al.         Expires August 27, 2008               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 1               February 2008
1066
1067
1068   asctime format.  HTTP-date is case sensitive and MUST NOT include
1069   additional LWS beyond that specifically included as SP in the
1070   grammar.
1071
1072     HTTP-date    = rfc1123-date | rfc850-date | asctime-date
1073     rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1074     rfc850-date  = weekday "," SP date2 SP time SP "GMT"
1075     asctime-date = wkday SP date3 SP time SP 4DIGIT
1076     date1        = 2DIGIT SP month SP 4DIGIT
1077                    ; day month year (e.g., 02 Jun 1982)
1078     date2        = 2DIGIT "-" month "-" 2DIGIT
1079                    ; day-month-year (e.g., 02-Jun-82)
1080     date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
1081                    ; month day (e.g., Jun  2)
1082     time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1083                    ; 00:00:00 - 23:59:59
1084     wkday        = "Mon" | "Tue" | "Wed"
1085                  | "Thu" | "Fri" | "Sat" | "Sun"
1086     weekday      = "Monday" | "Tuesday" | "Wednesday"
1087                  | "Thursday" | "Friday" | "Saturday" | "Sunday"
1088     month        = "Jan" | "Feb" | "Mar" | "Apr"
1089                  | "May" | "Jun" | "Jul" | "Aug"
1090                  | "Sep" | "Oct" | "Nov" | "Dec"
1091
1092   Note: HTTP requirements for the date/time stamp format apply only to
1093   their usage within the protocol stream.  Clients and servers are not
1094   required to use these formats for user presentation, request logging,
1095   etc.
1096
10973.4.  Transfer Codings
1098
1099   Transfer-coding values are used to indicate an encoding
1100   transformation that has been, can be, or may need to be applied to an
1101   entity-body in order to ensure "safe transport" through the network.
1102   This differs from a content coding in that the transfer-coding is a
1103   property of the message, not of the original entity.
1104
1105     transfer-coding         = "chunked" | transfer-extension
1106     transfer-extension      = token *( ";" parameter )
1107
1108   Parameters are in the form of attribute/value pairs.
1109
1110     parameter               = attribute "=" value
1111     attribute               = token
1112     value                   = token | quoted-string
1113
1114   All transfer-coding values are case-insensitive.  HTTP/1.1 uses
1115   transfer-coding values in the TE header field (Section 8.5) and in
1116
1117
1118
1119Fielding, et al.         Expires August 27, 2008               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 1               February 2008
1122
1123
1124   the Transfer-Encoding header field (Section 8.7).
1125
1126   Whenever a transfer-coding is applied to a message-body, the set of
1127   transfer-codings MUST include "chunked", unless the message is
1128   terminated by closing the connection.  When the "chunked" transfer-
1129   coding is used, it MUST be the last transfer-coding applied to the
1130   message-body.  The "chunked" transfer-coding MUST NOT be applied more
1131   than once to a message-body.  These rules allow the recipient to
1132   determine the transfer-length of the message (Section 4.4).
1133
1134   Transfer-codings are analogous to the Content-Transfer-Encoding
1135   values of MIME [RFC2045], which were designed to enable safe
1136   transport of binary data over a 7-bit transport service.  However,
1137   safe transport has a different focus for an 8bit-clean transfer
1138   protocol.  In HTTP, the only unsafe characteristic of message-bodies
1139   is the difficulty in determining the exact body length (Section 4.4),
1140   or the desire to encrypt data over a shared transport.
1141
1142   The Internet Assigned Numbers Authority (IANA) acts as a registry for
1143   transfer-coding value tokens.  Initially, the registry contains the
1144   following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and
1145   "deflate" (Section 3.2 of [Part3]).
1146
1147   New transfer-coding value tokens SHOULD be registered in the same way
1148   as new content-coding value tokens (Section 3.2 of [Part3]).
1149
1150   A server which receives an entity-body with a transfer-coding it does
1151   not understand SHOULD return 501 (Not Implemented), and close the
1152   connection.  A server MUST NOT send transfer-codings to an HTTP/1.0
1153   client.
1154
11553.4.1.  Chunked Transfer Coding
1156
1157   The chunked encoding modifies the body of a message in order to
1158   transfer it as a series of chunks, each with its own size indicator,
1159   followed by an OPTIONAL trailer containing entity-header fields.
1160   This allows dynamically produced content to be transferred along with
1161   the information necessary for the recipient to verify that it has
1162   received the full message.
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175Fielding, et al.         Expires August 27, 2008               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 1               February 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 August 27, 2008               [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 1               February 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 of
2543   [RFC2822] and is intended to be used for tracking message forwards,
2544   avoiding request loops, and identifying the protocol capabilities of
2545   all senders along the request/response chain.
2546
2547     Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
2548     received-protocol = [ protocol-name "/" ] protocol-version
2549     protocol-name     = token
2550     protocol-version  = token
2551     received-by       = ( uri-host [ ":" port ] ) | pseudonym
2552     pseudonym         = token
2553
2554   The received-protocol indicates the protocol version of the message
2555   received by the server or client along each segment of the request/
2556   response chain.  The received-protocol version is appended to the Via
2557   field value when the message is forwarded so that information about
2558   the protocol capabilities of upstream applications remains visible to
2559   all recipients.
2560
2561   The protocol-name is optional if and only if it would be "HTTP".  The
2562   received-by field is normally the host and optional port number of a
2563   recipient server or client that subsequently forwarded the message.
2564   However, if the real host is considered to be sensitive information,
2565   it MAY be replaced by a pseudonym.  If the port is not given, it MAY
2566   be assumed to be the default port of the received-protocol.
2567
2568   Multiple Via field values represents each proxy or gateway that has
2569   forwarded the message.  Each recipient MUST append its information
2570   such that the end result is ordered according to the sequence of
2571   forwarding applications.
2572
2573
2574
2575Fielding, et al.         Expires August 27, 2008               [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 1               February 2008
2578
2579
2580   Comments MAY be used in the Via header field to identify the software
2581   of the recipient proxy or gateway, analogous to the User-Agent and
2582   Server header fields.  However, all comments in the Via field are
2583   optional and MAY be removed by any recipient prior to forwarding the
2584   message.
2585
2586   For example, a request message could be sent from an HTTP/1.0 user
2587   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2588   forward the request to a public proxy at p.example.net, which
2589   completes the request by forwarding it to the origin server at
2590   www.example.com.  The request received by www.example.com would then
2591   have the following Via header field:
2592
2593       Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
2594
2595   Proxies and gateways used as a portal through a network firewall
2596   SHOULD NOT, by default, forward the names and ports of hosts within
2597   the firewall region.  This information SHOULD only be propagated if
2598   explicitly enabled.  If not enabled, the received-by host of any host
2599   behind the firewall SHOULD be replaced by an appropriate pseudonym
2600   for that host.
2601
2602   For organizations that have strong privacy requirements for hiding
2603   internal structures, a proxy MAY combine an ordered subsequence of
2604   Via header field entries with identical received-protocol values into
2605   a single such entry.  For example,
2606
2607       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2608
2609   could be collapsed to
2610
2611       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2612
2613   Applications SHOULD NOT combine multiple entries unless they are all
2614   under the same organizational control and the hosts have already been
2615   replaced by pseudonyms.  Applications MUST NOT combine entries which
2616   have different received-protocol values.
2617
2618
26199.  IANA Considerations
2620
2621   [[anchor1: TBD.]]
2622
2623
262410.  Security Considerations
2625
2626   This section is meant to inform application developers, information
2627   providers, and users of the security limitations in HTTP/1.1 as
2628
2629
2630
2631Fielding, et al.         Expires August 27, 2008               [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 1               February 2008
2634
2635
2636   described by this document.  The discussion does not include
2637   definitive solutions to the problems revealed, though it does make
2638   some suggestions for reducing security risks.
2639
264010.1.  Personal Information
2641
2642   HTTP clients are often privy to large amounts of personal information
2643   (e.g. the user's name, location, mail address, passwords, encryption
2644   keys, etc.), and SHOULD be very careful to prevent unintentional
2645   leakage of this information.  We very strongly recommend that a
2646   convenient interface be provided for the user to control
2647   dissemination of such information, and that designers and
2648   implementors be particularly careful in this area.  History shows
2649   that errors in this area often create serious security and/or privacy
2650   problems and generate highly adverse publicity for the implementor's
2651   company.
2652
265310.2.  Abuse of Server Log Information
2654
2655   A server is in the position to save personal data about a user's
2656   requests which might identify their reading patterns or subjects of
2657   interest.  This information is clearly confidential in nature and its
2658   handling can be constrained by law in certain countries.  People
2659   using HTTP to provide data are responsible for ensuring that such
2660   material is not distributed without the permission of any individuals
2661   that are identifiable by the published results.
2662
266310.3.  Attacks Based On File and Path Names
2664
2665   Implementations of HTTP origin servers SHOULD be careful to restrict
2666   the documents returned by HTTP requests to be only those that were
2667   intended by the server administrators.  If an HTTP server translates
2668   HTTP URIs directly into file system calls, the server MUST take
2669   special care not to serve files that were not intended to be
2670   delivered to HTTP clients.  For example, UNIX, Microsoft Windows, and
2671   other operating systems use ".." as a path component to indicate a
2672   directory level above the current one.  On such a system, an HTTP
2673   server MUST disallow any such construct in the Request-URI if it
2674   would otherwise allow access to a resource outside those intended to
2675   be accessible via the HTTP server.  Similarly, files intended for
2676   reference only internally to the server (such as access control
2677   files, configuration files, and script code) MUST be protected from
2678   inappropriate retrieval, since they might contain sensitive
2679   information.  Experience has shown that minor bugs in such HTTP
2680   server implementations have turned into security risks.
2681
2682
2683
2684
2685
2686
2687Fielding, et al.         Expires August 27, 2008               [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 1               February 2008
2690
2691
269210.4.  DNS Spoofing
2693
2694   Clients using HTTP rely heavily on the Domain Name Service, and are
2695   thus generally prone to security attacks based on the deliberate mis-
2696   association of IP addresses and DNS names.  Clients need to be
2697   cautious in assuming the continuing validity of an IP number/DNS name
2698   association.
2699
2700   In particular, HTTP clients SHOULD rely on their name resolver for
2701   confirmation of an IP number/DNS name association, rather than
2702   caching the result of previous host name lookups.  Many platforms
2703   already can cache host name lookups locally when appropriate, and
2704   they SHOULD be configured to do so.  It is proper for these lookups
2705   to be cached, however, only when the TTL (Time To Live) information
2706   reported by the name server makes it likely that the cached
2707   information will remain useful.
2708
2709   If HTTP clients cache the results of host name lookups in order to
2710   achieve a performance improvement, they MUST observe the TTL
2711   information reported by DNS.
2712
2713   If HTTP clients do not observe this rule, they could be spoofed when
2714   a previously-accessed server's IP address changes.  As network
2715   renumbering is expected to become increasingly common [RFC1900], the
2716   possibility of this form of attack will grow.  Observing this
2717   requirement thus reduces this potential security vulnerability.
2718
2719   This requirement also improves the load-balancing behavior of clients
2720   for replicated servers using the same DNS name and reduces the
2721   likelihood of a user's experiencing failure in accessing sites which
2722   use that strategy.
2723
272410.5.  Proxies and Caching
2725
2726   By their very nature, HTTP proxies are men-in-the-middle, and
2727   represent an opportunity for man-in-the-middle attacks.  Compromise
2728   of the systems on which the proxies run can result in serious
2729   security and privacy problems.  Proxies have access to security-
2730   related information, personal information about individual users and
2731   organizations, and proprietary information belonging to users and
2732   content providers.  A compromised proxy, or a proxy implemented or
2733   configured without regard to security and privacy considerations,
2734   might be used in the commission of a wide range of potential attacks.
2735
2736   Proxy operators should protect the systems on which proxies run as
2737   they would protect any system that contains or transports sensitive
2738   information.  In particular, log information gathered at proxies
2739   often contains highly sensitive personal information, and/or
2740
2741
2742
2743Fielding, et al.         Expires August 27, 2008               [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 1               February 2008
2746
2747
2748   information about organizations.  Log information should be carefully
2749   guarded, and appropriate guidelines for use developed and followed.
2750   (Section 10.2).
2751
2752   Proxy implementors should consider the privacy and security
2753   implications of their design and coding decisions, and of the
2754   configuration options they provide to proxy operators (especially the
2755   default configuration).
2756
2757   Users of a proxy need to be aware that they are no trustworthier than
2758   the people who run the proxy; HTTP itself cannot solve this problem.
2759
2760   The judicious use of cryptography, when appropriate, may suffice to
2761   protect against a broad range of security and privacy attacks.  Such
2762   cryptography is beyond the scope of the HTTP/1.1 specification.
2763
276410.6.  Denial of Service Attacks on Proxies
2765
2766   They exist.  They are hard to defend against.  Research continues.
2767   Beware.
2768
2769
277011.  Acknowledgments
2771
2772   This specification makes heavy use of the augmented BNF and generic
2773   constructs defined by David H. Crocker for [RFC822ABNF].  Similarly,
2774   it reuses many of the definitions provided by Nathaniel Borenstein
2775   and Ned Freed for MIME [RFC2045].  We hope that their inclusion in
2776   this specification will help reduce past confusion over the
2777   relationship between HTTP and Internet mail message formats.
2778
2779   HTTP has evolved considerably over the years.  It has benefited from
2780   a large and active developer community--the many people who have
2781   participated on the www-talk mailing list--and it is that community
2782   which has been most responsible for the success of HTTP and of the
2783   World-Wide Web in general.  Marc Andreessen, Robert Cailliau, Daniel
2784   W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
2785   Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
2786   Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
2787   recognition for their efforts in defining early aspects of the
2788   protocol.
2789
2790   This document has benefited greatly from the comments of all those
2791   participating in the HTTP-WG.  In addition to those already
2792   mentioned, the following individuals have contributed to this
2793   specification:
2794
2795   Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
2796
2797
2798
2799Fielding, et al.         Expires August 27, 2008               [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 1               February 2008
2802
2803
2804   Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
2805   Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
2806   Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
2807   Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut,
2808   David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert
2809   Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David
2810   Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott
2811   Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich
2812   Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
2813   Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
2814   Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
2815
2816   Thanks to the "cave men" of Palo Alto.  You know who you are.
2817
2818   Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
2819   Fielding, the editor of [RFC2068], along with John Klensin, Jeff
2820   Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
2821   Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
2822   help.  And thanks go particularly to Jeff Mogul and Scott Lawrence
2823   for performing the "MUST/MAY/SHOULD" audit.
2824
2825   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
2826   Frystyk implemented RFC 2068 early, and we wish to thank them for the
2827   discovery of many of the problems that this document attempts to
2828   rectify.
2829
2830
283112.  References
2832
283312.1.  Normative References
2834
2835   [ISO-8859-1]
2836              International Organization for Standardization,
2837              "Information technology -- 8-bit single-byte coded graphic
2838              character sets -- Part 1: Latin alphabet No. 1", ISO/
2839              IEC 8859-1:1998, 1998.
2840
2841   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2842              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2843              and J. Reschke, Ed., "HTTP/1.1, part 2: Message
2844              Semantics", draft-ietf-httpbis-p2-semantics-02 (work in
2845              progress), February 2008.
2846
2847   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2848              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2849              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2850              and Content Negotiation", draft-ietf-httpbis-p3-payload-02
2851              (work in progress), February 2008.
2852
2853
2854
2855Fielding, et al.         Expires August 27, 2008               [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 1               February 2008
2858
2859
2860   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2861              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2862              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2863              Partial Responses", draft-ietf-httpbis-p5-range-02 (work
2864              in progress), February 2008.
2865
2866   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2867              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2868              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2869              draft-ietf-httpbis-p6-cache-02 (work in progress),
2870              February 2008.
2871
2872   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2873              Extensions (MIME) Part One: Format of Internet Message
2874              Bodies", RFC 2045, November 1996.
2875
2876   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
2877              Part Three: Message Header Extensions for Non-ASCII Text",
2878              RFC 2047, November 1996.
2879
2880   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2881              Requirement Levels", BCP 14, RFC 2119, March 1997.
2882
2883   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2884              Resource Identifiers (URI): Generic Syntax", RFC 2396,
2885              August 1998.
2886
2887   [RFC822ABNF]
2888              Crocker, D., "Standard for the format of ARPA Internet
2889              text messages", STD 11, RFC 822, August 1982.
2890
2891   [USASCII]  American National Standards Institute, "Coded Character
2892              Set -- 7-bit American Standard Code for Information
2893              Interchange", ANSI X3.4, 1986.
2894
289512.2.  Informative References
2896
2897   [Nie1997]  Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
2898              C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
2899              and PNG", ACM Proceedings of the ACM SIGCOMM '97
2900              conference on Applications, technologies, architectures,
2901              and protocols for computer communication SIGCOMM '97,
2902              September 1997,
2903              <http://doi.acm.org/10.1145/263105.263157>.
2904
2905   [Pad1995]  Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
2906              Computer Networks and ISDN Systems v. 28, pp. 25-35,
2907              December 1995.
2908
2909
2910
2911Fielding, et al.         Expires August 27, 2008               [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 1               February 2008
2914
2915
2916              Slightly revised version of paper in Proc. 2nd
2917              International WWW Conference '94: Mosaic and the Web, Oct.
2918              1994, which is available at <http://www.ncsa.uiuc.edu/SDG/
2919              IT94/Proceedings/DDay/mogul/HTTPLatency.html>.
2920
2921   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
2922              and Support", STD 3, RFC 1123, October 1989.
2923
2924   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
2925              Specification, Implementation", RFC 1305, March 1992.
2926
2927   [RFC1436]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
2928              Torrey, D., and B. Alberti, "The Internet Gopher Protocol
2929              (a distributed document search and retrieval protocol)",
2930              RFC 1436, March 1993.
2931
2932   [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
2933              Unifying Syntax for the Expression of Names and Addresses
2934              of Objects on the Network as used in the World-Wide Web",
2935              RFC 1630, June 1994.
2936
2937   [RFC1737]  Masinter, L. and K. Sollins, "Functional Requirements for
2938              Uniform Resource Names", RFC 1737, December 1994.
2939
2940   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
2941              Resource Locators (URL)", RFC 1738, December 1994.
2942
2943   [RFC1808]  Fielding, R., "Relative Uniform Resource Locators",
2944              RFC 1808, June 1995.
2945
2946   [RFC1900]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
2947              RFC 1900, February 1996.
2948
2949   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2950              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2951
2952   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2953              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2954              RFC 2068, January 1997.
2955
2956   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
2957              and Interpretation of HTTP Version Numbers", RFC 2145,
2958              May 1997.
2959
2960   [RFC2324]  Masinter, L., "Hyper Text Coffee Pot Control Protocol
2961              (HTCPCP/1.0)", RFC 2324, April 1998.
2962
2963   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2964
2965
2966
2967Fielding, et al.         Expires August 27, 2008               [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 1               February 2008
2970
2971
2972              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2973              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2974
2975   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
2976              April 2001.
2977
2978   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
2979              April 2001.
2980
2981   [RFC3977]  Feather, C., "Network News Transfer Protocol (NNTP)",
2982              RFC 3977, October 2006.
2983
2984   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
2985              Registration Procedures", BCP 13, RFC 4288, December 2005.
2986
2987   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
2988              text messages", STD 11, RFC 822, August 1982.
2989
2990   [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
2991              STD 9, RFC 959, October 1985.
2992
2993   [Spe]      Spero, S., "Analysis of HTTP Performance Problems",
2994              <http://sunsite.unc.edu/mdma-release/http-prob.html>.
2995
2996   [Tou1998]  Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
2997              HTTP Performance", ISI Research Report ISI/RR-98-463,
2998              Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
2999
3000              (original report dated Aug. 1996)
3001
3002   [WAIS]     Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T.,
3003              Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface
3004              Protocol Prototype Functional Specification (v1.5)",
3005              Thinking Machines Corporation , April 1990.
3006
3007
3008Appendix A.  Internet Media Types
3009
3010   In addition to defining HTTP/1.1, this document serves as the
3011   specification for the Internet media type "message/http" and
3012   "application/http".  The following is to be registered with IANA
3013   [RFC4288].
3014
3015A.1.  Internet Media Type message/http
3016
3017   The message/http type can be used to enclose a single HTTP request or
3018   response message, provided that it obeys the MIME restrictions for
3019   all "message" types regarding line length and encodings.
3020
3021
3022
3023Fielding, et al.         Expires August 27, 2008               [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 1               February 2008
3026
3027
3028   Type name:  message
3029
3030   Subtype name:  http
3031
3032   Required parameters:  none
3033
3034   Optional parameters:  version, msgtype
3035
3036      version:  The HTTP-Version number of the enclosed message (e.g.,
3037         "1.1").  If not present, the version can be determined from the
3038         first line of the body.
3039
3040      msgtype:  The message type -- "request" or "response".  If not
3041         present, the type can be determined from the first line of the
3042         body.
3043
3044   Encoding considerations:  only "7bit", "8bit", or "binary" are
3045      permitted
3046
3047   Security considerations:  none
3048
3049   Interoperability considerations:  none
3050
3051   Published specification:  This specification (see Appendix A.1).
3052
3053   Applications that use this media type:
3054
3055   Additional information:
3056
3057      Magic number(s):  none
3058
3059      File extension(s):  none
3060
3061      Macintosh file type code(s):  none
3062
3063   Person and email address to contact for further information:  See
3064      Authors Section.
3065
3066   Intended usage:  COMMON
3067
3068   Restrictions on usage:  none
3069
3070   Author/Change controller:  IESG
3071
3072
3073
3074
3075
3076
3077
3078
3079Fielding, et al.         Expires August 27, 2008               [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 1               February 2008
3082
3083
3084A.2.  Internet Media Type application/http
3085
3086   The application/http type can be used to enclose a pipeline of one or
3087   more HTTP request or response messages (not intermixed).
3088
3089   Type name:  application
3090
3091   Subtype name:  http
3092
3093   Required parameters:  none
3094
3095   Optional parameters:  version, msgtype
3096
3097      version:  The HTTP-Version number of the enclosed messages (e.g.,
3098         "1.1").  If not present, the version can be determined from the
3099         first line of the body.
3100
3101      msgtype:  The message type -- "request" or "response".  If not
3102         present, the type can be determined from the first line of the
3103         body.
3104
3105   Encoding considerations:  HTTP messages enclosed by this type are in
3106      "binary" format; use of an appropriate Content-Transfer-Encoding
3107      is required when transmitted via E-mail.
3108
3109   Security considerations:  none
3110
3111   Interoperability considerations:  none
3112
3113   Published specification:  This specification (see Appendix A.2).
3114
3115   Applications that use this media type:
3116
3117   Additional information:
3118
3119      Magic number(s):  none
3120
3121      File extension(s):  none
3122
3123      Macintosh file type code(s):  none
3124
3125   Person and email address to contact for further information:  See
3126      Authors Section.
3127
3128   Intended usage:  COMMON
3129
3130
3131
3132
3133
3134
3135Fielding, et al.         Expires August 27, 2008               [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 1               February 2008
3138
3139
3140   Restrictions on usage:  none
3141
3142   Author/Change controller:  IESG
3143
3144
3145Appendix B.  Tolerant Applications
3146
3147   Although this document specifies the requirements for the generation
3148   of HTTP/1.1 messages, not all applications will be correct in their
3149   implementation.  We therefore recommend that operational applications
3150   be tolerant of deviations whenever those deviations can be
3151   interpreted unambiguously.
3152
3153   Clients SHOULD be tolerant in parsing the Status-Line and servers
3154   tolerant when parsing the Request-Line.  In particular, they SHOULD
3155   accept any amount of SP or HTAB characters between fields, even
3156   though only a single SP is required.
3157
3158   The line terminator for message-header fields is the sequence CRLF.
3159   However, we recommend that applications, when parsing such headers,
3160   recognize a single LF as a line terminator and ignore the leading CR.
3161
3162   The character set of an entity-body SHOULD be labeled as the lowest
3163   common denominator of the character codes used within that body, with
3164   the exception that not labeling the entity is preferred over labeling
3165   the entity with the labels US-ASCII or ISO-8859-1.  See [Part3].
3166
3167   Additional rules for requirements on parsing and encoding of dates
3168   and other potential problems with date encodings include:
3169
3170   o  HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
3171      which appears to be more than 50 years in the future is in fact in
3172      the past (this helps solve the "year 2000" problem).
3173
3174   o  An HTTP/1.1 implementation MAY internally represent a parsed
3175      Expires date as earlier than the proper value, but MUST NOT
3176      internally represent a parsed Expires date as later than the
3177      proper value.
3178
3179   o  All expiration-related calculations MUST be done in GMT.  The
3180      local time zone MUST NOT influence the calculation or comparison
3181      of an age or expiration time.
3182
3183   o  If an HTTP header incorrectly carries a date value with a time
3184      zone other than GMT, it MUST be converted into GMT using the most
3185      conservative possible conversion.
3186
3187
3188
3189
3190
3191Fielding, et al.         Expires August 27, 2008               [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 1               February 2008
3194
3195
3196Appendix C.  Conversion of Date Formats
3197
3198   HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to
3199   simplify the process of date comparison.  Proxies and gateways from
3200   other protocols SHOULD ensure that any Date header field present in a
3201   message conforms to one of the HTTP/1.1 formats and rewrite the date
3202   if necessary.
3203
3204
3205Appendix D.  Compatibility with Previous Versions
3206
3207   It is beyond the scope of a protocol specification to mandate
3208   compliance with previous versions.  HTTP/1.1 was deliberately
3209   designed, however, to make supporting previous versions easy.  It is
3210   worth noting that, at the time of composing this specification
3211   (1996), we would expect commercial HTTP/1.1 servers to:
3212
3213   o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and
3214      1.1 requests;
3215
3216   o  understand any valid request in the format of HTTP/0.9, 1.0, or
3217      1.1;
3218
3219   o  respond appropriately with a message in the same major version
3220      used by the client.
3221
3222   And we would expect HTTP/1.1 clients to:
3223
3224   o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
3225      responses;
3226
3227   o  understand any valid response in the format of HTTP/0.9, 1.0, or
3228      1.1.
3229
3230   For most implementations of HTTP/1.0, each connection is established
3231   by the client prior to the request and closed by the server after
3232   sending the response.  Some implementations implement the Keep-Alive
3233   version of persistent connections described in Section 19.7.1 of
3234   [RFC2068].
3235
3236D.1.  Changes from HTTP/1.0
3237
3238   This section summarizes major differences between versions HTTP/1.0
3239   and HTTP/1.1.
3240
3241
3242
3243
3244
3245
3246
3247Fielding, et al.         Expires August 27, 2008               [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 1               February 2008
3250
3251
3252D.1.1.  Changes to Simplify Multi-homed Web Servers and Conserve IP
3253        Addresses
3254
3255   The requirements that clients and servers support the Host request-
3256   header, report an error if the Host request-header (Section 8.4) is
3257   missing from an HTTP/1.1 request, and accept absolute URIs
3258   (Section 5.1.2) are among the most important changes defined by this
3259   specification.
3260
3261   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
3262   addresses and servers; there was no other established mechanism for
3263   distinguishing the intended server of a request than the IP address
3264   to which that request was directed.  The changes outlined above will
3265   allow the Internet, once older HTTP clients are no longer common, to
3266   support multiple Web sites from a single IP address, greatly
3267   simplifying large operational Web servers, where allocation of many
3268   IP addresses to a single host has created serious problems.  The
3269   Internet will also be able to recover the IP addresses that have been
3270   allocated for the sole purpose of allowing special-purpose domain
3271   names to be used in root-level HTTP URLs.  Given the rate of growth
3272   of the Web, and the number of servers already deployed, it is
3273   extremely important that all implementations of HTTP (including
3274   updates to existing HTTP/1.0 applications) correctly implement these
3275   requirements:
3276
3277   o  Both clients and servers MUST support the Host request-header.
3278
3279   o  A client that sends an HTTP/1.1 request MUST send a Host header.
3280
3281   o  Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
3282      request does not include a Host request-header.
3283
3284   o  Servers MUST accept absolute URIs.
3285
3286D.2.  Compatibility with HTTP/1.0 Persistent Connections
3287
3288   Some clients and servers might wish to be compatible with some
3289   previous implementations of persistent connections in HTTP/1.0
3290   clients and servers.  Persistent connections in HTTP/1.0 are
3291   explicitly negotiated as they are not the default behavior.  HTTP/1.0
3292   experimental implementations of persistent connections are faulty,
3293   and the new facilities in HTTP/1.1 are designed to rectify these
3294   problems.  The problem was that some existing 1.0 clients may be
3295   sending Keep-Alive to a proxy server that doesn't understand
3296   Connection, which would then erroneously forward it to the next
3297   inbound server, which would establish the Keep-Alive connection and
3298   result in a hung HTTP/1.0 proxy waiting for the close on the
3299   response.  The result is that HTTP/1.0 clients must be prevented from
3300
3301
3302
3303Fielding, et al.         Expires August 27, 2008               [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 1               February 2008
3306
3307
3308   using Keep-Alive when talking to proxies.
3309
3310   However, talking to proxies is the most important use of persistent
3311   connections, so that prohibition is clearly unacceptable.  Therefore,
3312   we need some other mechanism for indicating a persistent connection
3313   is desired, which is safe to use even when talking to an old proxy
3314   that ignores Connection.  Persistent connections are the default for
3315   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
3316   declaring non-persistence.  See Section 8.1.
3317
3318   The original HTTP/1.0 form of persistent connections (the Connection:
3319   Keep-Alive and Keep-Alive header) is documented in [RFC2068].
3320
3321D.3.  Changes from RFC 2068
3322
3323   This specification has been carefully audited to correct and
3324   disambiguate key word usage; RFC 2068 had many problems in respect to
3325   the conventions laid out in [RFC2119].
3326
3327   Transfer-coding and message lengths all interact in ways that
3328   required fixing exactly when chunked encoding is used (to allow for
3329   transfer encoding that may not be self delimiting); it was important
3330   to straighten out exactly how message lengths are computed.
3331   (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6])
3332
3333   The use and interpretation of HTTP version numbers has been clarified
3334   by [RFC2145].  Require proxies to upgrade requests to highest
3335   protocol version they support to deal with problems discovered in
3336   HTTP/1.0 implementations (Section 3.1)
3337
3338   Transfer-coding had significant problems, particularly with
3339   interactions with chunked encoding.  The solution is that transfer-
3340   codings become as full fledged as content-codings.  This involves
3341   adding an IANA registry for transfer-codings (separate from content
3342   codings), a new header field (TE) and enabling trailer headers in the
3343   future.  Transfer encoding is a major performance benefit, so it was
3344   worth fixing [Nie1997].  TE also solves another, obscure, downward
3345   interoperability problem that could have occurred due to interactions
3346   between authentication trailers, chunked encoding and HTTP/1.0
3347   clients.(Section 3.4, 3.4.1, and 8.5)
3348
3349D.4.  Changes from RFC 2616
3350
3351   The CHAR rule does not allow the NUL character anymore (this affects
3352   the comment and quoted-string rules).  (Section 2.2)
3353
3354   Clarify that HTTP-Version is case sensitive.  (Section 3.1)
3355
3356
3357
3358
3359Fielding, et al.         Expires August 27, 2008               [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 1               February 2008
3362
3363
3364   Remove reference to non-existant identity transfer-coding value
3365   tokens.  (Sections 3.4 and 4.4)
3366
3367   Clarification that the chunk length does not include the count of the
3368   octets in the chunk header and trailer.  (Section 3.4.1)
3369
3370   Fix BNF to add query, as the abs_path production in Section 3 of
3371   [RFC2396] doesn't define it.  (Section 5.1.2)
3372
3373   Clarify exactly when close connection options must be sent.
3374   (Section 8.1)
3375
3376
3377Appendix E.  Change Log (to be removed by RFC Editor before publication)
3378
3379E.1.  Since RFC2616
3380
3381   Extracted relevant partitions from [RFC2616].
3382
3383E.2.  Since draft-ietf-httpbis-p1-messaging-00
3384
3385   Closed issues:
3386
3387   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP
3388      Version should be case sensitive"
3389      (<http://purl.org/NET/http-errata#verscase>)
3390
3391   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
3392      characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
3393
3394   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
3395      Definition" (<http://purl.org/NET/http-errata#chunk-size>)
3396
3397   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message
3398      Length" (<http://purl.org/NET/http-errata#msg-len-chars>)
3399
3400   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
3401      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
3402
3403   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI
3404      includes query" (<http://purl.org/NET/http-errata#uriquery>)
3405
3406   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close
3407      on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
3408
3409   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
3410      'identity' token references"
3411      (<http://purl.org/NET/http-errata#identity>)
3412
3413
3414
3415Fielding, et al.         Expires August 27, 2008               [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 1               February 2008
3418
3419
3420   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import
3421      query BNF"
3422
3423   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext
3424      BNF"
3425
3426   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
3427      and Informative references"
3428
3429   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
3430      Compliance"
3431
3432   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
3433      reference"
3434
3435   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
3436      references"
3437
3438   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>:
3439      "inconsistency in date format explanation"
3440
3441   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date
3442      reference typo"
3443
3444   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
3445      "Informative references"
3446
3447   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:
3448      "ISO-8859-1 Reference"
3449
3450   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
3451      up-to-date references"
3452
3453   Other changes:
3454
3455   o  Update media type registrations to use RFC4288 template.
3456
3457   o  Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
3458      for chunk-data (work in progress on
3459      <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
3460
3461E.3.  Since draft-ietf-httpbis-p1-messaging-01
3462
3463   Closed issues:
3464
3465   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on
3466      GET (and other) requests"
3467
3468
3469
3470
3471Fielding, et al.         Expires August 27, 2008               [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 1               February 2008
3474
3475
3476   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating
3477      to RFC4288"
3478
3479   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status
3480      Code and Reason Phrase"
3481
3482   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path
3483      not used"
3484
3485   Ongoing work on ABNF conversion
3486   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
3487
3488   o  Get rid of duplicate BNF rule names ("host" -> "uri-host",
3489      "trailer" -> "trailer-part").
3490
3491   o  Avoid underscore character in rule names ("http_URL" -> "http-
3492      URL", "abs_path" -> "path-absolute").
3493
3494   o  Add rules for terms imported from URI spec ("absoluteURI",
3495      "authority", "path-absolute", "port", "query", "relativeURI",
3496      "host) -- these will have to be updated when switching over to
3497      RFC3986.
3498
3499   o  Synchronize core rules with RFC5234 (this includes a change to
3500      CHAR which now excludes NUL).
3501
3502   o  Get rid of prose rules that span multiple lines.
3503
3504   o  Get rid of unused rules LOALPHA and UPALPHA.
3505
3506   o  Move "Product Tokens" section (back) into Part 1, as "token" is
3507      used in the definition of the Upgrade header.
3508
3509   o  Add explicit references to BNF syntax and rules imported from
3510      other parts of the specification.
3511
3512   o  Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
3513      "TEXT".
3514
3515
3516Index
3517
3518   A
3519      application/http Media Type  56
3520
3521   C
3522      cache  8
3523      cacheable  9
3524
3525
3526
3527Fielding, et al.         Expires August 27, 2008               [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 1               February 2008
3530
3531
3532      client  7
3533      connection  6
3534      Connection header  39
3535      content negotiation  7
3536      Content-Length header  40
3537
3538   D
3539      Date header  41
3540      downstream  9
3541
3542   E
3543      entity  7
3544
3545   G
3546      gateway  8
3547      Grammar
3548         absoluteURI  18
3549         ALPHA  14
3550         asctime-date  20
3551         attribute  20
3552         authority  18
3553         CHAR  14
3554         chunk  22
3555         chunk-data  22
3556         chunk-ext-name  22
3557         chunk-ext-val  22
3558         chunk-extension  22
3559         chunk-size  22
3560         Chunked-Body  22
3561         comment  15
3562         Connection  39
3563         connection-token  39
3564         Content-Length  40
3565         CR  14
3566         CRLF  14
3567         ctext  15
3568         CTL  14
3569         Date  41
3570         date1  20
3571         date2  20
3572         date3  20
3573         DIGIT  14
3574         DQUOTE  14
3575         extension-code  32
3576         extension-method  29
3577         field-content  25
3578         field-name  25
3579         field-value  25
3580
3581
3582
3583Fielding, et al.         Expires August 27, 2008               [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 1               February 2008
3586
3587
3588         general-header  28
3589         generic-message  24
3590         HEX  15
3591         Host  42
3592         HTAB  14
3593         HTTP-date  20
3594         HTTP-message  24
3595         http-URL  18
3596         HTTP-Version  16
3597         last-chunk  22
3598         LF  14
3599         LWS  14
3600         message-body  25
3601         message-header  25
3602         Method  29
3603         month  20
3604         OCTET  14
3605         parameter  20
3606         path-absolute  18
3607         port  18
3608         product  23
3609         product-version  23
3610         protocol-name  46
3611         protocol-version  46
3612         pseudonym  46
3613         qdtext  15
3614         query  18
3615         quoted-pair  15
3616         quoted-string  15
3617         Reason-Phrase  32
3618         received-by  46
3619         received-protocol  46
3620         relativeURI  18
3621         Request  28
3622         Request-Line  28
3623         Request-URI  29
3624         Response  31
3625         rfc850-date  20
3626         rfc1123-date  20
3627         separators  15
3628         SP  14
3629         start-line  24
3630         Status-Code  32
3631         Status-Line  31
3632         t-codings  43
3633         tchar  15
3634         TE  43
3635         TEXT  14
3636
3637
3638
3639Fielding, et al.         Expires August 27, 2008               [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 1               February 2008
3642
3643
3644         time  20
3645         token  15
3646         Trailer  44
3647         trailer-part  22
3648         transfer-coding  20
3649         Transfer-Encoding  44
3650         transfer-extension  20
3651         Upgrade  45
3652         uri-host  18
3653         value  20
3654         Via  46
3655         weekday  20
3656         wkday  20
3657
3658   H
3659      Headers
3660         Connection  39
3661         Content-Length  40
3662         Date  41
3663         Host  42
3664         TE  43
3665         Trailer  44
3666         Transfer-Encoding  44
3667         Upgrade  45
3668         Via  46
3669      Host header  42
3670
3671   I
3672      inbound  9
3673
3674   M
3675      Media Type
3676         application/http  56
3677         message/http  54
3678      message  6
3679      message/http Media Type  54
3680
3681   O
3682      origin server  8
3683      outbound  9
3684
3685   P
3686      proxy  8
3687
3688   R
3689      representation  7
3690      request  6
3691      resource  7
3692
3693
3694
3695Fielding, et al.         Expires August 27, 2008               [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 1               February 2008
3698
3699
3700      response  6
3701
3702   S
3703      server  8
3704
3705   T
3706      TE header  43
3707      Trailer header  44
3708      Transfer-Encoding header  44
3709      tunnel  8
3710
3711   U
3712      Upgrade header  45
3713      upstream  9
3714      user agent  7
3715
3716   V
3717      variant  7
3718      Via header  46
3719
3720
3721Authors' Addresses
3722
3723   Roy T. Fielding (editor)
3724   Day Software
3725   23 Corporate Plaza DR, Suite 280
3726   Newport Beach, CA  92660
3727   USA
3728
3729   Phone: +1-949-706-5300
3730   Fax:   +1-949-706-5305
3731   Email: fielding@gbiv.com
3732   URI:   http://roy.gbiv.com/
3733
3734
3735   Jim Gettys
3736   One Laptop per Child
3737   21 Oak Knoll Road
3738   Carlisle, MA  01741
3739   USA
3740
3741   Email: jg@laptop.org
3742   URI:   http://www.laptop.org/
3743
3744
3745
3746
3747
3748
3749
3750
3751Fielding, et al.         Expires August 27, 2008               [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 1               February 2008
3754
3755
3756   Jeffrey C. Mogul
3757   Hewlett-Packard Company
3758   HP Labs, Large Scale Systems Group
3759   1501 Page Mill Road, MS 1177
3760   Palo Alto, CA  94304
3761   USA
3762
3763   Email: JeffMogul@acm.org
3764
3765
3766   Henrik Frystyk Nielsen
3767   Microsoft Corporation
3768   1 Microsoft Way
3769   Redmond, WA  98052
3770   USA
3771
3772   Email: henrikn@microsoft.com
3773
3774
3775   Larry Masinter
3776   Adobe Systems, Incorporated
3777   345 Park Ave
3778   San Jose, CA  95110
3779   USA
3780
3781   Email: LMM@acm.org
3782   URI:   http://larry.masinter.net/
3783
3784
3785   Paul J. Leach
3786   Microsoft Corporation
3787   1 Microsoft Way
3788   Redmond, WA  98052
3789
3790   Email: paulle@microsoft.com
3791
3792
3793   Tim Berners-Lee
3794   World Wide Web Consortium
3795   MIT Computer Science and Artificial Intelligence Laboratory
3796   The Stata Center, Building 32
3797   32 Vassar Street
3798   Cambridge, MA  02139
3799   USA
3800
3801   Email: timbl@w3.org
3802   URI:   http://www.w3.org/People/Berners-Lee/
3803
3804
3805
3806
3807Fielding, et al.         Expires August 27, 2008               [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 1               February 2008
3810
3811
3812   Yves Lafon (editor)
3813   World Wide Web Consortium
3814   W3C / ERCIM
3815   2004, rte des Lucioles
3816   Sophia-Antipolis, AM  06902
3817   France
3818
3819   Email: ylafon@w3.org
3820   URI:   http://www.raubacapeu.net/people/yves/
3821
3822
3823   Julian F. Reschke (editor)
3824   greenbytes GmbH
3825   Hafenweg 16
3826   Muenster, NW  48155
3827   Germany
3828
3829   Phone: +49 251 2807760
3830   Fax:   +49 251 2807761
3831   Email: julian.reschke@greenbytes.de
3832   URI:   http://greenbytes.de/tech/webdav/
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863Fielding, et al.         Expires August 27, 2008               [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 1               February 2008
3866
3867
3868Full Copyright Statement
3869
3870   Copyright (C) The IETF Trust (2008).
3871
3872   This document is subject to the rights, licenses and restrictions
3873   contained in BCP 78, and except as set forth therein, the authors
3874   retain all their rights.
3875
3876   This document and the information contained herein are provided on an
3877   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3878   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
3879   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
3880   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
3881   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3882   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3883
3884
3885Intellectual Property
3886
3887   The IETF takes no position regarding the validity or scope of any
3888   Intellectual Property Rights or other rights that might be claimed to
3889   pertain to the implementation or use of the technology described in
3890   this document or the extent to which any license under such rights
3891   might or might not be available; nor does it represent that it has
3892   made any independent effort to identify any such rights.  Information
3893   on the procedures with respect to rights in RFC documents can be
3894   found in BCP 78 and BCP 79.
3895
3896   Copies of IPR disclosures made to the IETF Secretariat and any
3897   assurances of licenses to be made available, or the result of an
3898   attempt made to obtain a general license or permission for the use of
3899   such proprietary rights by implementers or users of this
3900   specification can be obtained from the IETF on-line IPR repository at
3901   http://www.ietf.org/ipr.
3902
3903   The IETF invites any interested party to bring to its attention any
3904   copyrights, patents or patent applications, or other proprietary
3905   rights that may cover technology that may be required to implement
3906   this standard.  Please address the information to the IETF at
3907   ietf-ipr@ietf.org.
3908
3909
3910Acknowledgment
3911
3912   Funding for the RFC Editor function is provided by the IETF
3913   Administrative Support Activity (IASA).
3914
3915
3916
3917
3918
3919Fielding, et al.         Expires August 27, 2008               [Page 70]
3920
Note: See TracBrowser for help on using the repository browser.