source: draft-ietf-httpbis/08/draft-ietf-httpbis-p1-messaging-08.txt @ 1772

Last change on this file since 1772 was 718, checked in by julian.reschke@…, 11 years ago

Prepare for -08 drafts

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