source: draft-ietf-httpbis/07/draft-ietf-httpbis-p1-messaging-07.txt @ 605

Last change on this file since 605 was 605, checked in by julian.reschke@…, 10 years ago

Prepare release of -07 drafts.

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