source: draft-ietf-httpbis/09/draft-ietf-httpbis-p1-messaging-09.txt @ 847

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

Prepare publication of -09 drafts on March 08

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