source: draft-ietf-httpbis/05/draft-ietf-httpbis-p1-messaging-05.txt @ 559

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

remove executable and set eol-style for earlier drafts

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