source: draft-ietf-httpbis/09/draft-ietf-httpbis-p3-payload-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: 98.1 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                    One Laptop per Child
8Expires: September 9, 2010                                      J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 8, 2010
23
24
25       HTTP/1.1, part 3: Message Payload and Content Negotiation
26                    draft-ietf-httpbis-p3-payload-09
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 3 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 3 defines
36   HTTP message content, metadata, and content negotiation.
37
38Editorial Note (To be removed by RFC Editor)
39
40   Discussion of this draft should take place on the HTTPBIS working
41   group mailing list (ietf-http-wg@w3.org).  The current issues list is
42   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
43   documents (including fancy diffs) can be found at
44   <http://tools.ietf.org/wg/httpbis/>.
45
46   The changes in this draft are summarized in Appendix E.10.
47
48Status of this Memo
49
50   This Internet-Draft is submitted to IETF in full conformance with the
51   provisions of BCP 78 and BCP 79.
52
53
54
55Fielding, et al.        Expires September 9, 2010               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 3                  March 2010
58
59
60   Internet-Drafts are working documents of the Internet Engineering
61   Task Force (IETF), its areas, and its working groups.  Note that
62   other groups may also distribute working documents as Internet-
63   Drafts.
64
65   Internet-Drafts are draft documents valid for a maximum of six months
66   and may be updated, replaced, or obsoleted by other documents at any
67   time.  It is inappropriate to use Internet-Drafts as reference
68   material or to cite them other than as "work in progress."
69
70   The list of current Internet-Drafts can be accessed at
71   http://www.ietf.org/ietf/1id-abstracts.txt.
72
73   The list of Internet-Draft Shadow Directories can be accessed at
74   http://www.ietf.org/shadow.html.
75
76   This Internet-Draft will expire on September 9, 2010.
77
78Copyright Notice
79
80   Copyright (c) 2010 IETF Trust and the persons identified as the
81   document authors.  All rights reserved.
82
83   This document is subject to BCP 78 and the IETF Trust's Legal
84   Provisions Relating to IETF Documents
85   (http://trustee.ietf.org/license-info) in effect on the date of
86   publication of this document.  Please review these documents
87   carefully, as they describe your rights and restrictions with respect
88   to this document.  Code Components extracted from this document must
89   include Simplified BSD License text as described in Section 4.e of
90   the Trust Legal Provisions and are provided without warranty as
91   described in the BSD License.
92
93   This document may contain material from IETF Documents or IETF
94   Contributions published or made publicly available before November
95   10, 2008.  The person(s) controlling the copyright in some of this
96   material may not have granted the IETF Trust the right to allow
97   modifications of such material outside the IETF Standards Process.
98   Without obtaining an adequate license from the person(s) controlling
99   the copyright in such materials, this document may not be modified
100   outside the IETF Standards Process, and derivative works of it may
101   not be created outside the IETF Standards Process, except to format
102   it for publication as an RFC or to translate it into languages other
103   than English.
104
105
106
107
108
109
110
111Fielding, et al.        Expires September 9, 2010               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 3                  March 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
119     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
120     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
121     1.3.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
122       1.3.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  6
123       1.3.2.  ABNF Rules defined in other Parts of the
124               Specification  . . . . . . . . . . . . . . . . . . . .  6
125   2.  Protocol Parameters  . . . . . . . . . . . . . . . . . . . . .  7
126     2.1.  Character Sets . . . . . . . . . . . . . . . . . . . . . .  7
127       2.1.1.  Missing Charset  . . . . . . . . . . . . . . . . . . .  8
128     2.2.  Content Codings  . . . . . . . . . . . . . . . . . . . . .  8
129       2.2.1.  Content Coding Registry  . . . . . . . . . . . . . . .  9
130     2.3.  Media Types  . . . . . . . . . . . . . . . . . . . . . . .  9
131       2.3.1.  Canonicalization and Text Defaults . . . . . . . . . . 10
132       2.3.2.  Multipart Types  . . . . . . . . . . . . . . . . . . . 11
133     2.4.  Language Tags  . . . . . . . . . . . . . . . . . . . . . . 11
134   3.  Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
135     3.1.  Entity Header Fields . . . . . . . . . . . . . . . . . . . 12
136     3.2.  Entity Body  . . . . . . . . . . . . . . . . . . . . . . . 13
137       3.2.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
138       3.2.2.  Entity Length  . . . . . . . . . . . . . . . . . . . . 13
139   4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . . . 14
140     4.1.  Server-driven Negotiation  . . . . . . . . . . . . . . . . 14
141     4.2.  Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
142   5.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
143     5.1.  Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
144     5.2.  Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
145     5.3.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . . . 19
146     5.4.  Accept-Language  . . . . . . . . . . . . . . . . . . . . . 21
147     5.5.  Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
148     5.6.  Content-Language . . . . . . . . . . . . . . . . . . . . . 23
149     5.7.  Content-Location . . . . . . . . . . . . . . . . . . . . . 23
150     5.8.  Content-MD5  . . . . . . . . . . . . . . . . . . . . . . . 24
151     5.9.  Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
152   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
153     6.1.  Message Header Registration  . . . . . . . . . . . . . . . 26
154     6.2.  Content Coding Registry  . . . . . . . . . . . . . . . . . 27
155   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
156     7.1.  Privacy Issues Connected to Accept Headers . . . . . . . . 27
157     7.2.  Content-Disposition Issues . . . . . . . . . . . . . . . . 28
158   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
159   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
160     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
161     9.2.  Informative References . . . . . . . . . . . . . . . . . . 30
162   Appendix A.  Differences Between HTTP Entities and RFC 2045
163                Entities  . . . . . . . . . . . . . . . . . . . . . . 31
164
165
166
167Fielding, et al.        Expires September 9, 2010               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 3                  March 2010
170
171
172     A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32
173     A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 32
174     A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 32
175     A.4.  Introduction of Content-Encoding . . . . . . . . . . . . . 33
176     A.5.  No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
177     A.6.  Introduction of Transfer-Encoding  . . . . . . . . . . . . 33
178     A.7.  MHTML and Line Length Limitations  . . . . . . . . . . . . 33
179   Appendix B.  Additional Features . . . . . . . . . . . . . . . . . 34
180     B.1.  Content-Disposition  . . . . . . . . . . . . . . . . . . . 34
181   Appendix C.  Compatibility with Previous Versions  . . . . . . . . 35
182     C.1.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 35
183     C.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 35
184   Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 35
185   Appendix E.  Change Log (to be removed by RFC Editor before
186                publication)  . . . . . . . . . . . . . . . . . . . . 38
187     E.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 38
188     E.2.  Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38
189     E.3.  Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39
190     E.4.  Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39
191     E.5.  Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39
192     E.6.  Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40
193     E.7.  Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40
194     E.8.  Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
195     E.9.  Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41
196     E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 41
197   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
198   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.        Expires September 9, 2010               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 3                  March 2010
226
227
2281.  Introduction
229
230   This document defines HTTP/1.1 message payloads (a.k.a., content),
231   the associated metadata header fields that define how the payload is
232   intended to be interpreted by a recipient, the request header fields
233   that may influence content selection, and the various selection
234   algorithms that are collectively referred to as HTTP content
235   negotiation.
236
237   This document is currently disorganized in order to minimize the
238   changes between drafts and enable reviewers to see the smaller errata
239   changes.  The next draft will reorganize the sections to better
240   reflect the content.  In particular, the sections on entities will be
241   renamed payload and moved to the first half of the document, while
242   the sections on content negotiation and associated request header
243   fields will be moved to the second half.  The current mess reflects
244   how widely dispersed these topics and associated requirements had
245   become in [RFC2616].
246
2471.1.  Terminology
248
249   This specification uses a number of terms to refer to the roles
250   played by participants in, and objects of, the HTTP communication.
251
252   content negotiation
253
254      The mechanism for selecting the appropriate representation when
255      servicing a request.  The representation of entities in any
256      response can be negotiated (including error responses).
257
258   entity
259
260      The information transferred as the payload of a request or
261      response.  An entity consists of metadata in the form of entity-
262      header fields and content in the form of an entity-body.
263
264   representation
265
266      An entity included with a response that is subject to content
267      negotiation.  There may exist multiple representations associated
268      with a particular response status.
269
270   variant
271
272      A resource may have one, or more than one, representation(s)
273      associated with it at any given instant.  Each of these
274      representations is termed a "variant".  Use of the term "variant"
275      does not necessarily imply that the resource is subject to content
276
277
278
279Fielding, et al.        Expires September 9, 2010               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 3                  March 2010
282
283
284      negotiation.
285
2861.2.  Requirements
287
288   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
289   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
290   document are to be interpreted as described in [RFC2119].
291
292   An implementation is not compliant if it fails to satisfy one or more
293   of the MUST or REQUIRED level requirements for the protocols it
294   implements.  An implementation that satisfies all the MUST or
295   REQUIRED level and all the SHOULD level requirements for its
296   protocols is said to be "unconditionally compliant"; one that
297   satisfies all the MUST level requirements but not all the SHOULD
298   level requirements for its protocols is said to be "conditionally
299   compliant."
300
3011.3.  Syntax Notation
302
303   This specification uses the ABNF syntax defined in Section 1.2 of
304   [Part1] (which extends the syntax defined in [RFC5234] with a list
305   rule).  Appendix D shows the collected ABNF, with the list rule
306   expanded.
307
308   The following core rules are included by reference, as defined in
309   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
310   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
311   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
312   sequence of data), SP (space), VCHAR (any visible USASCII character),
313   and WSP (whitespace).
314
3151.3.1.  Core Rules
316
317   The core rules below are defined in Section 1.2.2 of [Part1]:
318
319     quoted-string  = <quoted-string, defined in [Part1], Section 1.2.2>
320     token          = <token, defined in [Part1], Section 1.2.2>
321     OWS            = <OWS, defined in [Part1], Section 1.2.2>
322
3231.3.2.  ABNF Rules defined in other Parts of the Specification
324
325   The ABNF rules below are defined in other parts:
326
327     absolute-URI   = <absolute-URI, defined in [Part1], Section 2.6>
328     Content-Length = <Content-Length, defined in [Part1], Section 9.2>
329     header-field   = <header-field, defined in [Part1], Section 3.2>
330     partial-URI    = <partial-URI, defined in [Part1], Section 2.6>
331     qvalue         = <qvalue, defined in [Part1], Section 6.4>
332
333
334
335Fielding, et al.        Expires September 9, 2010               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 3                  March 2010
338
339
340     Last-Modified  = <Last-Modified, defined in [Part4], Section 6.6>
341
342
343     Content-Range  = <Content-Range, defined in [Part5], Section 5.2>
344
345
346     Expires        = <Expires, defined in [Part6], Section 3.3>
347
348
3492.  Protocol Parameters
350
3512.1.  Character Sets
352
353   HTTP uses the same definition of the term "character set" as that
354   described for MIME:
355
356   The term "character set" is used in this document to refer to a
357   method used with one or more tables to convert a sequence of octets
358   into a sequence of characters.  Note that unconditional conversion in
359   the other direction is not required, in that not all characters may
360   be available in a given character set and a character set may provide
361   more than one sequence of octets to represent a particular character.
362   This definition is intended to allow various kinds of character
363   encoding, from simple single-table mappings such as US-ASCII to
364   complex table switching methods such as those that use ISO-2022's
365   techniques.  However, the definition associated with a MIME character
366   set name MUST fully specify the mapping to be performed from octets
367   to characters.  In particular, use of external profiling information
368   to determine the exact mapping is not permitted.
369
370      Note: This use of the term "character set" is more commonly
371      referred to as a "character encoding."  However, since HTTP and
372      MIME share the same registry, it is important that the terminology
373      also be shared.
374
375   HTTP character sets are identified by case-insensitive tokens.  The
376   complete set of tokens is defined by the IANA Character Set registry
377   (<http://www.iana.org/assignments/character-sets>).
378
379     charset = token
380
381   Although HTTP allows an arbitrary token to be used as a charset
382   value, any token that has a predefined value within the IANA
383   Character Set registry MUST represent the character set defined by
384   that registry.  Applications SHOULD limit their use of character sets
385   to those defined by the IANA registry.
386
387   HTTP uses charset in two contexts: within an Accept-Charset request
388
389
390
391Fielding, et al.        Expires September 9, 2010               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 3                  March 2010
394
395
396   header (in which the charset value is an unquoted token) and as the
397   value of a parameter in a Content-Type header (within a request or
398   response), in which case the parameter value of the charset parameter
399   may be quoted.
400
401   Implementors should be aware of IETF character set requirements
402   [RFC3629] [RFC2277].
403
4042.1.1.  Missing Charset
405
406   Some HTTP/1.0 software has interpreted a Content-Type header without
407   charset parameter incorrectly to mean "recipient should guess."
408   Senders wishing to defeat this behavior MAY include a charset
409   parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and
410   SHOULD do so when it is known that it will not confuse the recipient.
411
412   Unfortunately, some older HTTP/1.0 clients did not deal properly with
413   an explicit charset parameter.  HTTP/1.1 recipients MUST respect the
414   charset label provided by the sender; and those user agents that have
415   a provision to "guess" a charset MUST use the charset from the
416   content-type field if they support that charset, rather than the
417   recipient's preference, when initially displaying a document.  See
418   Section 2.3.1.
419
4202.2.  Content Codings
421
422   Content coding values indicate an encoding transformation that has
423   been or can be applied to an entity.  Content codings are primarily
424   used to allow a document to be compressed or otherwise usefully
425   transformed without losing the identity of its underlying media type
426   and without loss of information.  Frequently, the entity is stored in
427   coded form, transmitted directly, and only decoded by the recipient.
428
429     content-coding   = token
430
431   All content-coding values are case-insensitive.  HTTP/1.1 uses
432   content-coding values in the Accept-Encoding (Section 5.3) and
433   Content-Encoding (Section 5.5) header fields.  Although the value
434   describes the content-coding, what is more important is that it
435   indicates what decoding mechanism will be required to remove the
436   encoding.
437
438   compress
439
440      See Section 6.2.2.1 of [Part1].
441
442   deflate
443
444
445
446
447Fielding, et al.        Expires September 9, 2010               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 3                  March 2010
450
451
452      See Section 6.2.2.2 of [Part1].
453
454   gzip
455
456      See Section 6.2.2.3 of [Part1].
457
458   identity
459
460      The default (identity) encoding; the use of no transformation
461      whatsoever.  This content-coding is used only in the Accept-
462      Encoding header, and SHOULD NOT be used in the Content-Encoding
463      header.
464
4652.2.1.  Content Coding Registry
466
467   The HTTP Content Coding Registry defines the name space for the
468   content coding names.
469
470   Registrations MUST include the following fields:
471
472   o  Name
473
474   o  Description
475
476   o  Pointer to specification text
477
478   Values to be added to this name space require expert review and a
479   specification (see "Expert Review" and "Specification Required" in
480   Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
481   coding defined in this section.
482
483   The registry itself is maintained at
484   <http://www.iana.org/assignments/http-parameters>.
485
4862.3.  Media Types
487
488   HTTP uses Internet Media Types [RFC2046] in the Content-Type
489   (Section 5.9) and Accept (Section 5.1) header fields in order to
490   provide open and extensible data typing and type negotiation.
491
492     media-type = type "/" subtype *( OWS ";" OWS parameter )
493     type       = token
494     subtype    = token
495
496   Parameters MAY follow the type/subtype in the form of attribute/value
497   pairs.
498
499
500
501
502
503Fielding, et al.        Expires September 9, 2010               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 3                  March 2010
506
507
508     parameter      = attribute "=" value
509     attribute      = token
510     value          = token / quoted-string
511
512   The type, subtype, and parameter attribute names are case-
513   insensitive.  Parameter values might or might not be case-sensitive,
514   depending on the semantics of the parameter name.  The presence or
515   absence of a parameter might be significant to the processing of a
516   media-type, depending on its definition within the media type
517   registry.
518
519   A parameter value that matches the token production may be
520   transmitted as either a token or within a quoted-string.  The quoted
521   and unquoted values are equivalent.
522
523   Note that some older HTTP applications do not recognize media type
524   parameters.  When sending data to older HTTP applications,
525   implementations SHOULD only use media type parameters when they are
526   required by that type/subtype definition.
527
528   Media-type values are registered with the Internet Assigned Number
529   Authority (IANA).  The media type registration process is outlined in
530   [RFC4288].  Use of non-registered media types is discouraged.
531
5322.3.1.  Canonicalization and Text Defaults
533
534   Internet media types are registered with a canonical form.  An
535   entity-body transferred via HTTP messages MUST be represented in the
536   appropriate canonical form prior to its transmission except for
537   "text" types, as defined in the next paragraph.
538
539   When in canonical form, media subtypes of the "text" type use CRLF as
540   the text line break.  HTTP relaxes this requirement and allows the
541   transport of text media with plain CR or LF alone representing a line
542   break when it is done consistently for an entire entity-body.  HTTP
543   applications MUST accept CRLF, bare CR, and bare LF as being
544   representative of a line break in text media received via HTTP.  In
545   addition, if the text is represented in a character set that does not
546   use octets 13 and 10 for CR and LF respectively, as is the case for
547   some multi-byte character sets, HTTP allows the use of whatever octet
548   sequences are defined by that character set to represent the
549   equivalent of CR and LF for line breaks.  This flexibility regarding
550   line breaks applies only to text media in the entity-body; a bare CR
551   or LF MUST NOT be substituted for CRLF within any of the HTTP control
552   structures (such as header fields and multipart boundaries).
553
554   If an entity-body is encoded with a content-coding, the underlying
555   data MUST be in a form defined above prior to being encoded.
556
557
558
559Fielding, et al.        Expires September 9, 2010              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 3                  March 2010
562
563
564   The "charset" parameter is used with some media types to define the
565   character set (Section 2.1) of the data.  When no explicit charset
566   parameter is provided by the sender, media subtypes of the "text"
567   type are defined to have a default charset value of "ISO-8859-1" when
568   received via HTTP.  Data in character sets other than "ISO-8859-1" or
569   its subsets MUST be labeled with an appropriate charset value.  See
570   Section 2.1.1 for compatibility problems.
571
5722.3.2.  Multipart Types
573
574   MIME provides for a number of "multipart" types -- encapsulations of
575   one or more entities within a single message-body.  All multipart
576   types share a common syntax, as defined in Section 5.1.1 of
577   [RFC2046], and MUST include a boundary parameter as part of the media
578   type value.  The message body is itself a protocol element and MUST
579   therefore use only CRLF to represent line breaks between body-parts.
580   Unlike in RFC 2046, the epilogue of any multipart message MUST be
581   empty; HTTP applications MUST NOT transmit the epilogue (even if the
582   original multipart contains an epilogue).  These restrictions exist
583   in order to preserve the self-delimiting nature of a multipart
584   message-body, wherein the "end" of the message-body is indicated by
585   the ending multipart boundary.
586
587   In general, HTTP treats a multipart message-body no differently than
588   any other media type: strictly as payload.  The one exception is the
589   "multipart/byteranges" type (Appendix A of [Part5]) when it appears
590   in a 206 (Partial Content) response.  In all other cases, an HTTP
591   user agent SHOULD follow the same or similar behavior as a MIME user
592   agent would upon receipt of a multipart type.  The MIME header fields
593   within each body-part of a multipart message-body do not have any
594   significance to HTTP beyond that defined by their MIME semantics.
595
596   In general, an HTTP user agent SHOULD follow the same or similar
597   behavior as a MIME user agent would upon receipt of a multipart type.
598   If an application receives an unrecognized multipart subtype, the
599   application MUST treat it as being equivalent to "multipart/mixed".
600
601      Note: The "multipart/form-data" type has been specifically defined
602      for carrying form data suitable for processing via the POST
603      request method, as described in [RFC2388].
604
6052.4.  Language Tags
606
607   A language tag, as defined in [RFC5646], identifies a natural
608   language spoken, written, or otherwise conveyed by human beings for
609   communication of information to other human beings.  Computer
610   languages are explicitly excluded.  HTTP uses language tags within
611   the Accept-Language and Content-Language fields.
612
613
614
615Fielding, et al.        Expires September 9, 2010              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 3                  March 2010
618
619
620   In summary, a language tag is composed of one or more parts: A
621   primary language subtag followed by a possibly empty series of
622   subtags:
623
624     language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
625
626   White space is not allowed within the tag and all tags are case-
627   insensitive.  The name space of language subtags is administered by
628   the IANA (see
629   <http://www.iana.org/assignments/language-subtag-registry>).
630
631   Example tags include:
632
633     en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
634
635   See [RFC5646] for further information.
636
637
6383.  Entity
639
640   Request and Response messages MAY transfer an entity if not otherwise
641   restricted by the request method or response status code.  An entity
642   consists of entity-header fields and an entity-body, although some
643   responses will only include the entity-headers.
644
645   In this section, both sender and recipient refer to either the client
646   or the server, depending on who sends and who receives the entity.
647
6483.1.  Entity Header Fields
649
650   Entity-header fields define metainformation about the entity-body or,
651   if no body is present, about the resource identified by the request.
652
653     entity-header  = Content-Encoding         ; Section 5.5
654                    / Content-Language         ; Section 5.6
655                    / Content-Length           ; [Part1], Section 9.2
656                    / Content-Location         ; Section 5.7
657                    / Content-MD5              ; Section 5.8
658                    / Content-Range            ; [Part5], Section 5.2
659                    / Content-Type             ; Section 5.9
660                    / Expires                  ; [Part6], Section 3.3
661                    / Last-Modified            ; [Part4], Section 6.6
662                    / extension-header
663
664     extension-header = header-field
665
666   The extension-header mechanism allows additional entity-header fields
667   to be defined without changing the protocol, but these fields cannot
668
669
670
671Fielding, et al.        Expires September 9, 2010              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 3                  March 2010
674
675
676   be assumed to be recognizable by the recipient.  Unrecognized header
677   fields SHOULD be ignored by the recipient and MUST be forwarded by
678   transparent proxies.
679
6803.2.  Entity Body
681
682   The entity-body (if any) sent with an HTTP request or response is in
683   a format and encoding defined by the entity-header fields.
684
685     entity-body    = *OCTET
686
687   An entity-body is only present in a message when a message-body is
688   present, as described in Section 3.3 of [Part1].  The entity-body is
689   obtained from the message-body by decoding any Transfer-Encoding that
690   might have been applied to ensure safe and proper transfer of the
691   message.
692
6933.2.1.  Type
694
695   When an entity-body is included with a message, the data type of that
696   body is determined via the header fields Content-Type and Content-
697   Encoding.  These define a two-layer, ordered encoding model:
698
699     entity-body := Content-Encoding( Content-Type( data ) )
700
701   Content-Type specifies the media type of the underlying data.  Any
702   HTTP/1.1 message containing an entity-body SHOULD include a Content-
703   Type header field defining the media type of that body, unless that
704   information is unknown.  If the Content-Type header field is not
705   present, it indicates that the sender does not know the media type of
706   the data; recipients MAY either assume that it is "application/
707   octet-stream" ([RFC2046], Section 4.5.1) or examine the content to
708   determine its type.
709
710   Content-Encoding may be used to indicate any additional content
711   codings applied to the data, usually for the purpose of data
712   compression, that are a property of the requested resource.  There is
713   no default encoding.
714
7153.2.2.  Entity Length
716
717   The entity-length of a message is the length of the message-body
718   before any transfer-codings have been applied.  Section 3.4 of
719   [Part1] defines how the transfer-length of a message-body is
720   determined.
721
722
723
724
725
726
727Fielding, et al.        Expires September 9, 2010              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 3                  March 2010
730
731
7324.  Content Negotiation
733
734   HTTP responses include a representation which contains information
735   for interpretation, whether by a human user or for further
736   processing.  Often, the server has different ways of representing the
737   same information; for example, in different formats, languages, or
738   using different character encodings.
739
740   HTTP clients and their users might have different or variable
741   capabilities, characteristics or preferences which would influence
742   which representation, among those available from the server, would be
743   best for the server to deliver.  For this reason, HTTP provides
744   mechanisms for "content negotiation" -- a process of allowing
745   selection of a representation of a given resource, when more than one
746   is available.
747
748   This specification defines two patterns of content negotiation;
749   "server-driven", where the server selects the representation based
750   upon the client's stated preferences, and "agent-driven" negotiation,
751   where the server provides a list of representations for the client to
752   choose from, based upon their metadata.  In addition, there are other
753   patterns: some applications use an "active content" pattern, where
754   the server returns active content which runs on the client and, based
755   on client available parameters, selects additional resources to
756   invoke.  "Transparent Content Negotiation" ([RFC2295]) has also been
757   proposed.
758
759   These patterns are all widely used, and have trade-offs in
760   applicability and practicality.  In particular, when the number of
761   preferences or capabilities to be expressed by a client are large
762   (such as when many different formats are supported by a user-agent),
763   server-driven negotiation becomes unwieldy, and may not be
764   appropriate.  Conversely, when the number of representations to
765   choose from is very large, agent-driven negotiation may not be
766   appropriate.
767
768   Note that in all cases, the supplier of representations has the
769   responsibility for determining which representations might be
770   considered to be the "same information".
771
7724.1.  Server-driven Negotiation
773
774   If the selection of the best representation for a response is made by
775   an algorithm located at the server, it is called server-driven
776   negotiation.  Selection is based on the available representations of
777   the response (the dimensions over which it can vary; e.g., language,
778   content-coding, etc.) and the contents of particular header fields in
779   the request message or on other information pertaining to the request
780
781
782
783Fielding, et al.        Expires September 9, 2010              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 3                  March 2010
786
787
788   (such as the network address of the client).
789
790   Server-driven negotiation is advantageous when the algorithm for
791   selecting from among the available representations is difficult to
792   describe to the user agent, or when the server desires to send its
793   "best guess" to the client along with the first response (hoping to
794   avoid the round-trip delay of a subsequent request if the "best
795   guess" is good enough for the user).  In order to improve the
796   server's guess, the user agent MAY include request header fields
797   (Accept, Accept-Language, Accept-Encoding, etc.) which describe its
798   preferences for such a response.
799
800   Server-driven negotiation has disadvantages:
801
802   1.  It is impossible for the server to accurately determine what
803       might be "best" for any given user, since that would require
804       complete knowledge of both the capabilities of the user agent and
805       the intended use for the response (e.g., does the user want to
806       view it on screen or print it on paper?).
807
808   2.  Having the user agent describe its capabilities in every request
809       can be both very inefficient (given that only a small percentage
810       of responses have multiple representations) and a potential
811       violation of the user's privacy.
812
813   3.  It complicates the implementation of an origin server and the
814       algorithms for generating responses to a request.
815
816   4.  It may limit a public cache's ability to use the same response
817       for multiple user's requests.
818
819   HTTP/1.1 includes the following request-header fields for enabling
820   server-driven negotiation through description of user agent
821   capabilities and user preferences: Accept (Section 5.1), Accept-
822   Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
823   (Section 5.4), and User-Agent (Section 9.9 of [Part2]).  However, an
824   origin server is not limited to these dimensions and MAY vary the
825   response based on any aspect of the request, including information
826   outside the request-header fields or within extension header fields
827   not defined by this specification.
828
829      Note: In practice, User-Agent based negotiation is fragile,
830      because new clients might not be recognized.
831
832   The Vary header field (Section 3.5 of [Part6]) can be used to express
833   the parameters the server uses to select a representation that is
834   subject to server-driven negotiation.
835
836
837
838
839Fielding, et al.        Expires September 9, 2010              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 3                  March 2010
842
843
8444.2.  Agent-driven Negotiation
845
846   With agent-driven negotiation, selection of the best representation
847   for a response is performed by the user agent after receiving an
848   initial response from the origin server.  Selection is based on a
849   list of the available representations of the response included within
850   the header fields or entity-body of the initial response, with each
851   representation identified by its own URI.  Selection from among the
852   representations may be performed automatically (if the user agent is
853   capable of doing so) or manually by the user selecting from a
854   generated (possibly hypertext) menu.
855
856   Agent-driven negotiation is advantageous when the response would vary
857   over commonly-used dimensions (such as type, language, or encoding),
858   when the origin server is unable to determine a user agent's
859   capabilities from examining the request, and generally when public
860   caches are used to distribute server load and reduce network usage.
861
862   Agent-driven negotiation suffers from the disadvantage of needing a
863   second request to obtain the best alternate representation.  This
864   second request is only efficient when caching is used.  In addition,
865   this specification does not define any mechanism for supporting
866   automatic selection, though it also does not prevent any such
867   mechanism from being developed as an extension and used within
868   HTTP/1.1.
869
870   This specification defines the 300 (Multiple Choices) and 406 (Not
871   Acceptable) status codes for enabling agent-driven negotiation when
872   the server is unwilling or unable to provide a varying response using
873   server-driven negotiation.
874
875
8765.  Header Field Definitions
877
878   This section defines the syntax and semantics of HTTP/1.1 header
879   fields related to the payload of messages.
880
881   For entity-header fields, both sender and recipient refer to either
882   the client or the server, depending on who sends and who receives the
883   entity.
884
8855.1.  Accept
886
887   The "Accept" request-header field can be used by user agents to
888   specify response media types that are acceptable.  Accept headers can
889   be used to indicate that the request is specifically limited to a
890   small set of desired types, as in the case of a request for an in-
891   line image.
892
893
894
895Fielding, et al.        Expires September 9, 2010              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 3                  March 2010
898
899
900     Accept   = "Accept" ":" OWS Accept-v
901     Accept-v = #( media-range [ accept-params ] )
902
903     media-range    = ( "*/*"
904                      / ( type "/" "*" )
905                      / ( type "/" subtype )
906                      ) *( OWS ";" OWS parameter )
907     accept-params  = OWS ";" OWS "q=" qvalue *( accept-ext )
908     accept-ext     = OWS ";" OWS token
909                      [ "=" ( token / quoted-string ) ]
910
911   The asterisk "*" character is used to group media types into ranges,
912   with "*/*" indicating all media types and "type/*" indicating all
913   subtypes of that type.  The media-range MAY include media type
914   parameters that are applicable to that range.
915
916   Each media-range MAY be followed by one or more accept-params,
917   beginning with the "q" parameter for indicating a relative quality
918   factor.  The first "q" parameter (if any) separates the media-range
919   parameter(s) from the accept-params.  Quality factors allow the user
920   or user agent to indicate the relative degree of preference for that
921   media-range, using the qvalue scale from 0 to 1 (Section 6.4 of
922   [Part1]).  The default value is q=1.
923
924      Note: Use of the "q" parameter name to separate media type
925      parameters from Accept extension parameters is due to historical
926      practice.  Although this prevents any media type parameter named
927      "q" from being used with a media range, such an event is believed
928      to be unlikely given the lack of any "q" parameters in the IANA
929      media type registry and the rare usage of any media type
930      parameters in Accept.  Future media types are discouraged from
931      registering any parameter named "q".
932
933   The example
934
935     Accept: audio/*; q=0.2, audio/basic
936
937   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
938   type if it is the best available after an 80% mark-down in quality."
939
940   If no Accept header field is present, then it is assumed that the
941   client accepts all media types.  If an Accept header field is
942   present, and if the server cannot send a response which is acceptable
943   according to the combined Accept field value, then the server SHOULD
944   send a 406 (Not Acceptable) response.
945
946   A more elaborate example is
947
948
949
950
951Fielding, et al.        Expires September 9, 2010              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 3                  March 2010
954
955
956     Accept: text/plain; q=0.5, text/html,
957             text/x-dvi; q=0.8, text/x-c
958
959   Verbally, this would be interpreted as "text/html and text/x-c are
960   the preferred media types, but if they do not exist, then send the
961   text/x-dvi entity, and if that does not exist, send the text/plain
962   entity."
963
964   Media ranges can be overridden by more specific media ranges or
965   specific media types.  If more than one media range applies to a
966   given type, the most specific reference has precedence.  For example,
967
968     Accept: text/*, text/html, text/html;level=1, */*
969
970   have the following precedence:
971
972   1.  text/html;level=1
973
974   2.  text/html
975
976   3.  text/*
977
978   4.  */*
979
980   The media type quality factor associated with a given type is
981   determined by finding the media range with the highest precedence
982   which matches that type.  For example,
983
984     Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
985             text/html;level=2;q=0.4, */*;q=0.5
986
987   would cause the following values to be associated:
988
989   +-------------------+---------------+
990   | Media Type        | Quality Value |
991   +-------------------+---------------+
992   | text/html;level=1 | 1             |
993   | text/html         | 0.7           |
994   | text/plain        | 0.3           |
995   | image/jpeg        | 0.5           |
996   | text/html;level=2 | 0.4           |
997   | text/html;level=3 | 0.7           |
998   +-------------------+---------------+
999
1000   Note: A user agent might be provided with a default set of quality
1001   values for certain media ranges.  However, unless the user agent is a
1002   closed system which cannot interact with other rendering agents, this
1003   default set ought to be configurable by the user.
1004
1005
1006
1007Fielding, et al.        Expires September 9, 2010              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 3                  March 2010
1010
1011
10125.2.  Accept-Charset
1013
1014   The "Accept-Charset" request-header field can be used by user agents
1015   to indicate what response character sets are acceptable.  This field
1016   allows clients capable of understanding more comprehensive or
1017   special-purpose character sets to signal that capability to a server
1018   which is capable of representing documents in those character sets.
1019
1020     Accept-Charset   = "Accept-Charset" ":" OWS
1021             Accept-Charset-v
1022     Accept-Charset-v = 1#( ( charset / "*" )
1023                            [ OWS ";" OWS "q=" qvalue ] )
1024
1025   Character set values are described in Section 2.1.  Each charset MAY
1026   be given an associated quality value which represents the user's
1027   preference for that charset.  The default value is q=1.  An example
1028   is
1029
1030     Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
1031
1032   The special value "*", if present in the Accept-Charset field,
1033   matches every character set (including ISO-8859-1) which is not
1034   mentioned elsewhere in the Accept-Charset field.  If no "*" is
1035   present in an Accept-Charset field, then all character sets not
1036   explicitly mentioned get a quality value of 0, except for ISO-8859-1,
1037   which gets a quality value of 1 if not explicitly mentioned.
1038
1039   If no Accept-Charset header is present, the default is that any
1040   character set is acceptable.  If an Accept-Charset header is present,
1041   and if the server cannot send a response which is acceptable
1042   according to the Accept-Charset header, then the server SHOULD send
1043   an error response with the 406 (Not Acceptable) status code, though
1044   the sending of an unacceptable response is also allowed.
1045
10465.3.  Accept-Encoding
1047
1048   The "Accept-Encoding" request-header field can be used by user agents
1049   to indicate what response content-codings (Section 2.2) are
1050   acceptable in the response.
1051
1052     Accept-Encoding    = "Accept-Encoding" ":" OWS
1053                        Accept-Encoding-v
1054     Accept-Encoding-v  =
1055                        #( codings [ OWS ";" OWS "q=" qvalue ] )
1056     codings            = ( content-coding / "*" )
1057
1058   Each codings value MAY be given an associated quality value which
1059   represents the preference for that encoding.  The default value is
1060
1061
1062
1063Fielding, et al.        Expires September 9, 2010              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 3                  March 2010
1066
1067
1068   q=1.
1069
1070   Examples of its use are:
1071
1072     Accept-Encoding: compress, gzip
1073     Accept-Encoding:
1074     Accept-Encoding: *
1075     Accept-Encoding: compress;q=0.5, gzip;q=1.0
1076     Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
1077
1078   A server tests whether a content-coding is acceptable, according to
1079   an Accept-Encoding field, using these rules:
1080
1081   1.  If the content-coding is one of the content-codings listed in the
1082       Accept-Encoding field, then it is acceptable, unless it is
1083       accompanied by a qvalue of 0.  (As defined in Section 6.4 of
1084       [Part1], a qvalue of 0 means "not acceptable.")
1085
1086   2.  The special "*" symbol in an Accept-Encoding field matches any
1087       available content-coding not explicitly listed in the header
1088       field.
1089
1090   3.  If multiple content-codings are acceptable, then the acceptable
1091       content-coding with the highest non-zero qvalue is preferred.
1092
1093   4.  The "identity" content-coding is always acceptable, unless
1094       specifically refused because the Accept-Encoding field includes
1095       "identity;q=0", or because the field includes "*;q=0" and does
1096       not explicitly include the "identity" content-coding.  If the
1097       Accept-Encoding field-value is empty, then only the "identity"
1098       encoding is acceptable.
1099
1100   If an Accept-Encoding field is present in a request, and if the
1101   server cannot send a response which is acceptable according to the
1102   Accept-Encoding header, then the server SHOULD send an error response
1103   with the 406 (Not Acceptable) status code.
1104
1105   If no Accept-Encoding field is present in a request, the server MAY
1106   assume that the client will accept any content coding.  In this case,
1107   if "identity" is one of the available content-codings, then the
1108   server SHOULD use the "identity" content-coding, unless it has
1109   additional information that a different content-coding is meaningful
1110   to the client.
1111
1112      Note: If the request does not include an Accept-Encoding field,
1113      and if the "identity" content-coding is unavailable, then content-
1114      codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and
1115      "compress") are preferred; some older clients improperly display
1116
1117
1118
1119Fielding, et al.        Expires September 9, 2010              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 3                  March 2010
1122
1123
1124      messages sent with other content-codings.  The server might also
1125      make this decision based on information about the particular user-
1126      agent or client.
1127
1128      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
1129      associated with content-codings.  This means that qvalues will not
1130      work and are not permitted with x-gzip or x-compress.
1131
11325.4.  Accept-Language
1133
1134   The "Accept-Language" request-header field can be used by user agents
1135   to indicate the set of natural languages that are preferred in the
1136   response.  Language tags are defined in Section 2.4.
1137
1138     Accept-Language   = "Accept-Language" ":" OWS
1139                       Accept-Language-v
1140     Accept-Language-v =
1141                       1#( language-range [ OWS ";" OWS "q=" qvalue ] )
1142     language-range    =
1143               <language-range, defined in [RFC4647], Section 2.1>
1144
1145   Each language-range can be given an associated quality value which
1146   represents an estimate of the user's preference for the languages
1147   specified by that range.  The quality value defaults to "q=1".  For
1148   example,
1149
1150     Accept-Language: da, en-gb;q=0.8, en;q=0.7
1151
1152   would mean: "I prefer Danish, but will accept British English and
1153   other types of English." (see also Section 2.3 of [RFC4647])
1154
1155   For matching, Section 3 of [RFC4647] defines several matching
1156   schemes.  Implementations can offer the most appropriate matching
1157   scheme for their requirements.
1158
1159      Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
1160      identical to the matching scheme that was previously defined in
1161      Section 14.4 of [RFC2616].
1162
1163   It might be contrary to the privacy expectations of the user to send
1164   an Accept-Language header with the complete linguistic preferences of
1165   the user in every request.  For a discussion of this issue, see
1166   Section 7.1.
1167
1168   As intelligibility is highly dependent on the individual user, it is
1169   recommended that client applications make the choice of linguistic
1170   preference available to the user.  If the choice is not made
1171   available, then the Accept-Language header field MUST NOT be given in
1172
1173
1174
1175Fielding, et al.        Expires September 9, 2010              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 3                  March 2010
1178
1179
1180   the request.
1181
1182      Note: When making the choice of linguistic preference available to
1183      the user, we remind implementors of the fact that users are not
1184      familiar with the details of language matching as described above,
1185      and should provide appropriate guidance.  As an example, users
1186      might assume that on selecting "en-gb", they will be served any
1187      kind of English document if British English is not available.  A
1188      user agent might suggest in such a case to add "en" to get the
1189      best matching behavior.
1190
11915.5.  Content-Encoding
1192
1193   The "Content-Encoding" entity-header field indicates what content-
1194   codings have been applied to the entity-body, and thus what decoding
1195   mechanisms must be applied in order to obtain the media-type
1196   referenced by the Content-Type header field.  Content-Encoding is
1197   primarily used to allow a document to be compressed without losing
1198   the identity of its underlying media type.
1199
1200     Content-Encoding   = "Content-Encoding" ":" OWS Content-Encoding-v
1201     Content-Encoding-v = 1#content-coding
1202
1203   Content codings are defined in Section 2.2.  An example of its use is
1204
1205     Content-Encoding: gzip
1206
1207   The content-coding is a characteristic of the entity identified by
1208   the request-target.  Typically, the entity-body is stored with this
1209   encoding and is only decoded before rendering or analogous usage.
1210   However, a non-transparent proxy MAY modify the content-coding if the
1211   new coding is known to be acceptable to the recipient, unless the
1212   "no-transform" cache-control directive is present in the message.
1213
1214   If the content-coding of an entity is not "identity", then the
1215   response MUST include a Content-Encoding entity-header (Section 5.5)
1216   that lists the non-identity content-coding(s) used.
1217
1218   If the content-coding of an entity in a request message is not
1219   acceptable to the origin server, the server SHOULD respond with a
1220   status code of 415 (Unsupported Media Type).
1221
1222   If multiple encodings have been applied to an entity, the content
1223   codings MUST be listed in the order in which they were applied.
1224   Additional information about the encoding parameters MAY be provided
1225   by other entity-header fields not defined by this specification.
1226
1227
1228
1229
1230
1231Fielding, et al.        Expires September 9, 2010              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 3                  March 2010
1234
1235
12365.6.  Content-Language
1237
1238   The "Content-Language" entity-header field describes the natural
1239   language(s) of the intended audience for the entity.  Note that this
1240   might not be equivalent to all the languages used within the entity-
1241   body.
1242
1243     Content-Language   = "Content-Language" ":" OWS Content-Language-v
1244     Content-Language-v = 1#language-tag
1245
1246   Language tags are defined in Section 2.4.  The primary purpose of
1247   Content-Language is to allow a user to identify and differentiate
1248   entities according to the user's own preferred language.  Thus, if
1249   the body content is intended only for a Danish-literate audience, the
1250   appropriate field is
1251
1252     Content-Language: da
1253
1254   If no Content-Language is specified, the default is that the content
1255   is intended for all language audiences.  This might mean that the
1256   sender does not consider it to be specific to any natural language,
1257   or that the sender does not know for which language it is intended.
1258
1259   Multiple languages MAY be listed for content that is intended for
1260   multiple audiences.  For example, a rendition of the "Treaty of
1261   Waitangi," presented simultaneously in the original Maori and English
1262   versions, would call for
1263
1264     Content-Language: mi, en
1265
1266   However, just because multiple languages are present within an entity
1267   does not mean that it is intended for multiple linguistic audiences.
1268   An example would be a beginner's language primer, such as "A First
1269   Lesson in Latin," which is clearly intended to be used by an English-
1270   literate audience.  In this case, the Content-Language would properly
1271   only include "en".
1272
1273   Content-Language MAY be applied to any media type -- it is not
1274   limited to textual documents.
1275
12765.7.  Content-Location
1277
1278   The "Content-Location" entity-header field is used to supply a URI
1279   for the entity in the message when it is accessible from a location
1280   separate from the requested resource's URI.
1281
1282   A server SHOULD provide a Content-Location for the variant
1283   corresponding to the response entity, especially in the case where a
1284
1285
1286
1287Fielding, et al.        Expires September 9, 2010              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 3                  March 2010
1290
1291
1292   resource has multiple entities associated with it, and those entities
1293   actually have separate locations by which they might be individually
1294   accessed, the server SHOULD provide a Content-Location for the
1295   particular variant which is returned.
1296
1297     Content-Location   = "Content-Location" ":" OWS
1298                       Content-Location-v
1299     Content-Location-v =
1300                       absolute-URI / partial-URI
1301
1302   The Content-Location value is not a replacement for the original
1303   requested URI; it is only a statement of the location of the resource
1304   corresponding to this particular entity at the time of the request.
1305   Future requests MAY specify the Content-Location URI as the request-
1306   target if the desire is to identify the source of that particular
1307   entity.
1308
1309   Section 6.1 of [Part2] describes how clients may process the Content-
1310   Location header field.
1311
1312   A cache cannot assume that an entity with a Content-Location
1313   different from the URI used to retrieve it can be used to respond to
1314   later requests on that Content-Location URI.  However, the Content-
1315   Location can be used to differentiate between multiple entities
1316   retrieved from a single requested resource, as described in Section
1317   2.6 of [Part6].
1318
1319   If the Content-Location is a relative URI, the relative URI is
1320   interpreted relative to the request-target.
1321
1322   The meaning of the Content-Location header in requests is undefined;
1323   servers are free to ignore it in those cases.
1324
13255.8.  Content-MD5
1326
1327   The "Content-MD5" entity-header field, as defined in [RFC1864], is an
1328   MD5 digest of the entity-body that provides an end-to-end message
1329   integrity check (MIC) of the entity-body.  Note that a MIC is good
1330   for detecting accidental modification of the entity-body in transit,
1331   but is not proof against malicious attacks.
1332
1333     Content-MD5   = "Content-MD5" ":" OWS Content-MD5-v
1334     Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
1335
1336   The Content-MD5 header field MAY be generated by an origin server or
1337   client to function as an integrity check of the entity-body.  Only
1338   origin servers or clients MAY generate the Content-MD5 header field;
1339   proxies and gateways MUST NOT generate it, as this would defeat its
1340
1341
1342
1343Fielding, et al.        Expires September 9, 2010              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 3                  March 2010
1346
1347
1348   value as an end-to-end integrity check.  Any recipient of the entity-
1349   body, including gateways and proxies, MAY check that the digest value
1350   in this header field matches that of the entity-body as received.
1351
1352   The MD5 digest is computed based on the content of the entity-body,
1353   including any content-coding that has been applied, but not including
1354   any transfer-encoding applied to the message-body.  If the message is
1355   received with a transfer-encoding, that encoding MUST be removed
1356   prior to checking the Content-MD5 value against the received entity.
1357
1358   This has the result that the digest is computed on the octets of the
1359   entity-body exactly as, and in the order that, they would be sent if
1360   no transfer-encoding were being applied.
1361
1362   HTTP extends RFC 1864 to permit the digest to be computed for MIME
1363   composite media-types (e.g., multipart/* and message/rfc822), but
1364   this does not change how the digest is computed as defined in the
1365   preceding paragraph.
1366
1367   There are several consequences of this.  The entity-body for
1368   composite types MAY contain many body-parts, each with its own MIME
1369   and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
1370   and Content-Encoding headers).  If a body-part has a Content-
1371   Transfer-Encoding or Content-Encoding header, it is assumed that the
1372   content of the body-part has had the encoding applied, and the body-
1373   part is included in the Content-MD5 digest as is -- i.e., after the
1374   application.  The Transfer-Encoding header field is not allowed
1375   within body-parts.
1376
1377   Conversion of all line breaks to CRLF MUST NOT be done before
1378   computing or checking the digest: the line break convention used in
1379   the text actually transmitted MUST be left unaltered when computing
1380   the digest.
1381
1382      Note: While the definition of Content-MD5 is exactly the same for
1383      HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
1384      in which the application of Content-MD5 to HTTP entity-bodies
1385      differs from its application to MIME entity-bodies.  One is that
1386      HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
1387      does use Transfer-Encoding and Content-Encoding.  Another is that
1388      HTTP more frequently uses binary content types than MIME, so it is
1389      worth noting that, in such cases, the byte order used to compute
1390      the digest is the transmission byte order defined for the type.
1391      Lastly, HTTP allows transmission of text types with any of several
1392      line break conventions and not just the canonical form using CRLF.
1393
1394
1395
1396
1397
1398
1399Fielding, et al.        Expires September 9, 2010              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 3                  March 2010
1402
1403
14045.9.  Content-Type
1405
1406   The "Content-Type" entity-header field indicates the media type of
1407   the entity-body.  In the case of responses to the HEAD method, the
1408   media type is that which would have been sent had the request been a
1409   GET.
1410
1411     Content-Type   = "Content-Type" ":" OWS Content-Type-v
1412     Content-Type-v = media-type
1413
1414   Media types are defined in Section 2.3.  An example of the field is
1415
1416     Content-Type: text/html; charset=ISO-8859-4
1417
1418   Further discussion of methods for identifying the media type of an
1419   entity is provided in Section 3.2.1.
1420
1421
14226.  IANA Considerations
1423
14246.1.  Message Header Registration
1425
1426   The Message Header Registry located at <http://www.iana.org/
1427   assignments/message-headers/message-header-index.html> should be
1428   updated with the permanent registrations below (see [RFC3864]):
1429
1430   +---------------------+----------+----------+--------------+
1431   | Header Field Name   | Protocol | Status   | Reference    |
1432   +---------------------+----------+----------+--------------+
1433   | Accept              | http     | standard | Section 5.1  |
1434   | Accept-Charset      | http     | standard | Section 5.2  |
1435   | Accept-Encoding     | http     | standard | Section 5.3  |
1436   | Accept-Language     | http     | standard | Section 5.4  |
1437   | Content-Disposition | http     |          | Appendix B.1 |
1438   | Content-Encoding    | http     | standard | Section 5.5  |
1439   | Content-Language    | http     | standard | Section 5.6  |
1440   | Content-Location    | http     | standard | Section 5.7  |
1441   | Content-MD5         | http     | standard | Section 5.8  |
1442   | Content-Type        | http     | standard | Section 5.9  |
1443   | MIME-Version        | http     |          | Appendix A.1 |
1444   +---------------------+----------+----------+--------------+
1445
1446   The change controller is: "IETF (iesg@ietf.org) - Internet
1447   Engineering Task Force".
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.        Expires September 9, 2010              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 3                  March 2010
1458
1459
14606.2.  Content Coding Registry
1461
1462   The registration procedure for HTTP Content Codings is now defined by
1463   Section 2.2.1 of this document.
1464
1465   The HTTP Content Codings Registry located at
1466   <http://www.iana.org/assignments/http-parameters> should be updated
1467   with the registration below:
1468
1469   +----------+-----------------------------------+--------------------+
1470   | Name     | Description                       | Reference          |
1471   +----------+-----------------------------------+--------------------+
1472   | compress | UNIX "compress" program method    | Section 6.2.2.1 of |
1473   |          |                                   | [Part1]            |
1474   | deflate  | "zlib" format [RFC1950] with      | Section 6.2.2.2 of |
1475   |          | "deflate" compression             | [Part1]            |
1476   | gzip     | Same as GNU zip [RFC1952]         | Section 6.2.2.3 of |
1477   |          |                                   | [Part1]            |
1478   | identity | No transformation                 | Section 2.2        |
1479   +----------+-----------------------------------+--------------------+
1480
1481
14827.  Security Considerations
1483
1484   This section is meant to inform application developers, information
1485   providers, and users of the security limitations in HTTP/1.1 as
1486   described by this document.  The discussion does not include
1487   definitive solutions to the problems revealed, though it does make
1488   some suggestions for reducing security risks.
1489
14907.1.  Privacy Issues Connected to Accept Headers
1491
1492   Accept request-headers can reveal information about the user to all
1493   servers which are accessed.  The Accept-Language header in particular
1494   can reveal information the user would consider to be of a private
1495   nature, because the understanding of particular languages is often
1496   strongly correlated to the membership of a particular ethnic group.
1497   User agents which offer the option to configure the contents of an
1498   Accept-Language header to be sent in every request are strongly
1499   encouraged to let the configuration process include a message which
1500   makes the user aware of the loss of privacy involved.
1501
1502   An approach that limits the loss of privacy would be for a user agent
1503   to omit the sending of Accept-Language headers by default, and to ask
1504   the user whether or not to start sending Accept-Language headers to a
1505   server if it detects, by looking for any Vary response-header fields
1506   generated by the server, that such sending could improve the quality
1507   of service.
1508
1509
1510
1511Fielding, et al.        Expires September 9, 2010              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 3                  March 2010
1514
1515
1516   Elaborate user-customized accept header fields sent in every request,
1517   in particular if these include quality values, can be used by servers
1518   as relatively reliable and long-lived user identifiers.  Such user
1519   identifiers would allow content providers to do click-trail tracking,
1520   and would allow collaborating content providers to match cross-server
1521   click-trails or form submissions of individual users.  Note that for
1522   many users not behind a proxy, the network address of the host
1523   running the user agent will also serve as a long-lived user
1524   identifier.  In environments where proxies are used to enhance
1525   privacy, user agents ought to be conservative in offering accept
1526   header configuration options to end users.  As an extreme privacy
1527   measure, proxies could filter the accept headers in relayed requests.
1528   General purpose user agents which provide a high degree of header
1529   configurability SHOULD warn users about the loss of privacy which can
1530   be involved.
1531
15327.2.  Content-Disposition Issues
1533
1534   [RFC2183], from which the often implemented Content-Disposition (see
1535   Appendix B.1) header in HTTP is derived, has a number of very serious
1536   security considerations.  Content-Disposition is not part of the HTTP
1537   standard, but since it is widely implemented, we are documenting its
1538   use and risks for implementors.  See Section 5 of [RFC2183] for
1539   details.
1540
1541
15428.  Acknowledgments
1543
1544
15459.  References
1546
15479.1.  Normative References
1548
1549   [ISO-8859-1]
1550              International Organization for Standardization,
1551              "Information technology -- 8-bit single-byte coded graphic
1552              character sets -- Part 1: Latin alphabet No. 1", ISO/
1553              IEC 8859-1:1998, 1998.
1554
1555   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1556              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1557              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
1558              and Message Parsing", draft-ietf-httpbis-p1-messaging-09
1559              (work in progress), March 2010.
1560
1561   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1562              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1563              and J. Reschke, Ed., "HTTP/1.1, part 2: Message
1564
1565
1566
1567Fielding, et al.        Expires September 9, 2010              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 3                  March 2010
1570
1571
1572              Semantics", draft-ietf-httpbis-p2-semantics-09 (work in
1573              progress), March 2010.
1574
1575   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1576              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1577              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
1578              Requests", draft-ietf-httpbis-p4-conditional-09 (work in
1579              progress), March 2010.
1580
1581   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1582              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1583              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
1584              Partial Responses", draft-ietf-httpbis-p5-range-09 (work
1585              in progress), March 2010.
1586
1587   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1588              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1589              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
1590              6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
1591              progress), March 2010.
1592
1593   [RFC1864]  Myers, J. and M. Rose, "The Content-MD5 Header Field",
1594              RFC 1864, October 1995.
1595
1596   [RFC1950]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
1597              Specification version 3.3", RFC 1950, May 1996.
1598
1599              RFC 1950 is an Informational RFC, thus it may be less
1600              stable than this specification.  On the other hand, this
1601              downward reference was present since the publication of
1602              RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
1603              cause problems in practice.  See also [BCP97].
1604
1605   [RFC1952]  Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
1606              Randers-Pehrson, "GZIP file format specification version
1607              4.3", RFC 1952, May 1996.
1608
1609              RFC 1952 is an Informational RFC, thus it may be less
1610              stable than this specification.  On the other hand, this
1611              downward reference was present since the publication of
1612              RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
1613              cause problems in practice.  See also [BCP97].
1614
1615   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1616              Extensions (MIME) Part One: Format of Internet Message
1617              Bodies", RFC 2045, November 1996.
1618
1619   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1620
1621
1622
1623Fielding, et al.        Expires September 9, 2010              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 3                  March 2010
1626
1627
1628              Extensions (MIME) Part Two: Media Types", RFC 2046,
1629              November 1996.
1630
1631   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1632              Requirement Levels", BCP 14, RFC 2119, March 1997.
1633
1634   [RFC4647]  Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
1635              Tags", BCP 47, RFC 4647, September 2006.
1636
1637   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1638              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1639
1640   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
1641              Languages", BCP 47, RFC 5646, September 2009.
1642
16439.2.  Informative References
1644
1645   [BCP97]    Klensin, J. and S. Hartman, "Handling Normative References
1646              to Standards-Track Documents", BCP 97, RFC 4897,
1647              June 2007.
1648
1649   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
1650              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
1651
1652   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1653              Extensions (MIME) Part Five: Conformance Criteria and
1654              Examples", RFC 2049, November 1996.
1655
1656   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
1657              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
1658              RFC 2068, January 1997.
1659
1660   [RFC2076]  Palme, J., "Common Internet Message Headers", RFC 2076,
1661              February 1997.
1662
1663   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
1664              Presentation Information in Internet Messages: The
1665              Content-Disposition Header Field", RFC 2183, August 1997.
1666
1667   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
1668              Languages", BCP 18, RFC 2277, January 1998.
1669
1670   [RFC2295]  Holtman, K. and A. Mutz, "Transparent Content Negotiation
1671              in HTTP", RFC 2295, March 1998.
1672
1673   [RFC2388]  Masinter, L., "Returning Values from Forms:  multipart/
1674              form-data", RFC 2388, August 1998.
1675
1676
1677
1678
1679Fielding, et al.        Expires September 9, 2010              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 3                  March 2010
1682
1683
1684   [RFC2557]  Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
1685              "MIME Encapsulation of Aggregate Documents, such as HTML
1686              (MHTML)", RFC 2557, March 1999.
1687
1688   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1689              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1690              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1691
1692   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
1693              10646", RFC 3629, STD 63, November 2003.
1694
1695   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1696              Procedures for Message Header Fields", BCP 90, RFC 3864,
1697              September 2004.
1698
1699   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
1700              Registration Procedures", BCP 13, RFC 4288, December 2005.
1701
1702   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
1703              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1704              May 2008.
1705
1706   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
1707              October 2008.
1708
1709
1710Appendix A.  Differences Between HTTP Entities and RFC 2045 Entities
1711
1712   HTTP/1.1 uses many of the constructs defined for Internet Mail
1713   ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
1714   [RFC2045]) to allow entities to be transmitted in an open variety of
1715   representations and with extensible mechanisms.  However, RFC 2045
1716   discusses mail, and HTTP has a few features that are different from
1717   those described in RFC 2045.  These differences were carefully chosen
1718   to optimize performance over binary connections, to allow greater
1719   freedom in the use of new media types, to make date comparisons
1720   easier, and to acknowledge the practice of some early HTTP servers
1721   and clients.
1722
1723   This appendix describes specific areas where HTTP differs from RFC
1724   2045.  Proxies and gateways to strict MIME environments SHOULD be
1725   aware of these differences and provide the appropriate conversions
1726   where necessary.  Proxies and gateways from MIME environments to HTTP
1727   also need to be aware of the differences because some conversions
1728   might be required.
1729
1730
1731
1732
1733
1734
1735Fielding, et al.        Expires September 9, 2010              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 3                  March 2010
1738
1739
1740A.1.  MIME-Version
1741
1742   HTTP is not a MIME-compliant protocol.  However, HTTP/1.1 messages
1743   MAY include a single MIME-Version general-header field to indicate
1744   what version of the MIME protocol was used to construct the message.
1745   Use of the MIME-Version header field indicates that the message is in
1746   full compliance with the MIME protocol (as defined in [RFC2045]).
1747   Proxies/gateways are responsible for ensuring full compliance (where
1748   possible) when exporting HTTP messages to strict MIME environments.
1749
1750     MIME-Version   = "MIME-Version" ":" OWS MIME-Version-v
1751     MIME-Version-v = 1*DIGIT "." 1*DIGIT
1752
1753   MIME version "1.0" is the default for use in HTTP/1.1.  However,
1754   HTTP/1.1 message parsing and semantics are defined by this document
1755   and not the MIME specification.
1756
1757A.2.  Conversion to Canonical Form
1758
1759   [RFC2045] requires that an Internet mail entity be converted to
1760   canonical form prior to being transferred, as described in Section 4
1761   of [RFC2049].  Section 2.3.1 of this document describes the forms
1762   allowed for subtypes of the "text" media type when transmitted over
1763   HTTP.  [RFC2046] requires that content with a type of "text"
1764   represent line breaks as CRLF and forbids the use of CR or LF outside
1765   of line break sequences.  HTTP allows CRLF, bare CR, and bare LF to
1766   indicate a line break within text content when a message is
1767   transmitted over HTTP.
1768
1769   Where it is possible, a proxy or gateway from HTTP to a strict MIME
1770   environment SHOULD translate all line breaks within the text media
1771   types described in Section 2.3.1 of this document to the RFC 2049
1772   canonical form of CRLF.  Note, however, that this might be
1773   complicated by the presence of a Content-Encoding and by the fact
1774   that HTTP allows the use of some character sets which do not use
1775   octets 13 and 10 to represent CR and LF, as is the case for some
1776   multi-byte character sets.
1777
1778   Implementors should note that conversion will break any cryptographic
1779   checksums applied to the original content unless the original content
1780   is already in canonical form.  Therefore, the canonical form is
1781   recommended for any content that uses such checksums in HTTP.
1782
1783A.3.  Conversion of Date Formats
1784
1785   HTTP/1.1 uses a restricted set of date formats (Section 6.1 of
1786   [Part1]) to simplify the process of date comparison.  Proxies and
1787   gateways from other protocols SHOULD ensure that any Date header
1788
1789
1790
1791Fielding, et al.        Expires September 9, 2010              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 3                  March 2010
1794
1795
1796   field present in a message conforms to one of the HTTP/1.1 formats
1797   and rewrite the date if necessary.
1798
1799A.4.  Introduction of Content-Encoding
1800
1801   RFC 2045 does not include any concept equivalent to HTTP/1.1's
1802   Content-Encoding header field.  Since this acts as a modifier on the
1803   media type, proxies and gateways from HTTP to MIME-compliant
1804   protocols MUST either change the value of the Content-Type header
1805   field or decode the entity-body before forwarding the message.  (Some
1806   experimental applications of Content-Type for Internet mail have used
1807   a media-type parameter of ";conversions=<content-coding>" to perform
1808   a function equivalent to Content-Encoding.  However, this parameter
1809   is not part of RFC 2045).
1810
1811A.5.  No Content-Transfer-Encoding
1812
1813   HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
1814   Proxies and gateways from MIME-compliant protocols to HTTP MUST
1815   remove any Content-Transfer-Encoding prior to delivering the response
1816   message to an HTTP client.
1817
1818   Proxies and gateways from HTTP to MIME-compliant protocols are
1819   responsible for ensuring that the message is in the correct format
1820   and encoding for safe transport on that protocol, where "safe
1821   transport" is defined by the limitations of the protocol being used.
1822   Such a proxy or gateway SHOULD label the data with an appropriate
1823   Content-Transfer-Encoding if doing so will improve the likelihood of
1824   safe transport over the destination protocol.
1825
1826A.6.  Introduction of Transfer-Encoding
1827
1828   HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7
1829   of [Part1]).  Proxies/gateways MUST remove any transfer-coding prior
1830   to forwarding a message via a MIME-compliant protocol.
1831
1832A.7.  MHTML and Line Length Limitations
1833
1834   HTTP implementations which share code with MHTML [RFC2557]
1835   implementations need to be aware of MIME line length limitations.
1836   Since HTTP does not have this limitation, HTTP does not fold long
1837   lines.  MHTML messages being transported by HTTP follow all
1838   conventions of MHTML, including line length limitations and folding,
1839   canonicalization, etc., since HTTP transports all message-bodies as
1840   payload (see Section 2.3.2) and does not interpret the content or any
1841   MIME header lines that might be contained therein.
1842
1843
1844
1845
1846
1847Fielding, et al.        Expires September 9, 2010              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 3                  March 2010
1850
1851
1852Appendix B.  Additional Features
1853
1854   [RFC1945] and [RFC2068] document protocol elements used by some
1855   existing HTTP implementations, but not consistently and correctly
1856   across most HTTP/1.1 applications.  Implementors are advised to be
1857   aware of these features, but cannot rely upon their presence in, or
1858   interoperability with, other HTTP/1.1 applications.  Some of these
1859   describe proposed experimental features, and some describe features
1860   that experimental deployment found lacking that are now addressed in
1861   the base HTTP/1.1 specification.
1862
1863   A number of other headers, such as Content-Disposition and Title,
1864   from SMTP and MIME are also often implemented (see [RFC2076]).
1865
1866B.1.  Content-Disposition
1867
1868   The "Content-Disposition" response-header field has been proposed as
1869   a means for the origin server to suggest a default filename if the
1870   user requests that the content is saved to a file.  This usage is
1871   derived from the definition of Content-Disposition in [RFC2183].
1872
1873     content-disposition = "Content-Disposition" ":" OWS
1874                           content-disposition-v
1875     content-disposition-v = disposition-type
1876                             *( OWS ";" OWS disposition-parm )
1877     disposition-type = "attachment" / disp-extension-token
1878     disposition-parm = filename-parm / disp-extension-parm
1879     filename-parm = "filename" "=" quoted-string
1880     disp-extension-token = token
1881     disp-extension-parm = token "=" ( token / quoted-string )
1882
1883   An example is
1884
1885     Content-Disposition: attachment; filename="fname.ext"
1886
1887   The receiving user agent SHOULD NOT respect any directory path
1888   information present in the filename-parm parameter, which is the only
1889   parameter believed to apply to HTTP implementations at this time.
1890   The filename SHOULD be treated as a terminal component only.
1891
1892   If this header is used in a response with the application/
1893   octet-stream content-type, the implied suggestion is that the user
1894   agent should not display the response, but directly enter a "save
1895   response as..." dialog.
1896
1897   See Section 7.2 for Content-Disposition security issues.
1898
1899
1900
1901
1902
1903Fielding, et al.        Expires September 9, 2010              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 3                  March 2010
1906
1907
1908Appendix C.  Compatibility with Previous Versions
1909
1910C.1.  Changes from RFC 2068
1911
1912   Transfer-coding and message lengths all interact in ways that
1913   required fixing exactly when chunked encoding is used (to allow for
1914   transfer encoding that may not be self delimiting); it was important
1915   to straighten out exactly how message lengths are computed.
1916   (Section 3.2.2, see also [Part1], [Part5] and [Part6]).
1917
1918   Charset wildcarding is introduced to avoid explosion of character set
1919   names in accept headers.  (Section 5.2)
1920
1921   Content-Base was deleted from the specification: it was not
1922   implemented widely, and there is no simple, safe way to introduce it
1923   without a robust extension mechanism.  In addition, it is used in a
1924   similar, but not identical fashion in MHTML [RFC2557].
1925
1926   A content-coding of "identity" was introduced, to solve problems
1927   discovered in caching.  (Section 2.2)
1928
1929   The Alternates, Content-Version, Derived-From, Link, URI, Public and
1930   Content-Base header fields were defined in previous versions of this
1931   specification, but not commonly implemented.  See Section 19.6.2 of
1932   [RFC2068].
1933
1934C.2.  Changes from RFC 2616
1935
1936   Clarify contexts that charset is used in.  (Section 2.1)
1937
1938   Remove base URI setting semantics for Content-Location due to poor
1939   implementation support, which was caused by too many broken servers
1940   emitting bogus Content-Location headers, and also the potentially
1941   undesirable effect of potentially breaking relative links in content-
1942   negotiated resources.  (Section 5.7)
1943
1944   Remove reference to non-existant identity transfer-coding value
1945   tokens.  (Appendix A.5)
1946
1947
1948Appendix D.  Collected ABNF
1949
1950   Accept = "Accept:" OWS Accept-v
1951   Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v
1952   Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
1953    qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
1954    qvalue ] ] )
1955   Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v
1956
1957
1958
1959Fielding, et al.        Expires September 9, 2010              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 3                  March 2010
1962
1963
1964   Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] )
1965    ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
1966   Accept-Language = "Accept-Language:" OWS Accept-Language-v
1967   Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q="
1968    qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
1969    ] )
1970   Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1971    OWS media-range [ accept-params ] ] ) ]
1972
1973   Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v
1974   Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS
1975    content-coding ] )
1976   Content-Language = "Content-Language:" OWS Content-Language-v
1977   Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
1978    language-tag ] )
1979   Content-Length = <Content-Length, defined in [Part1], Section 9.2>
1980   Content-Location = "Content-Location:" OWS Content-Location-v
1981   Content-Location-v = absolute-URI / partial-URI
1982   Content-MD5 = "Content-MD5:" OWS Content-MD5-v
1983   Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
1984   Content-Range = <Content-Range, defined in [Part5], Section 5.2>
1985   Content-Type = "Content-Type:" OWS Content-Type-v
1986   Content-Type-v = media-type
1987
1988   Expires = <Expires, defined in [Part6], Section 3.3>
1989
1990   Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
1991
1992   MIME-Version = "MIME-Version:" OWS MIME-Version-v
1993   MIME-Version-v = 1*DIGIT "." 1*DIGIT
1994
1995   OWS = <OWS, defined in [Part1], Section 1.2.2>
1996
1997   absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
1998   accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
1999   accept-params = OWS ";" OWS "q=" qvalue *accept-ext
2000   attribute = token
2001
2002   charset = token
2003   codings = ( content-coding / "*" )
2004   content-coding = token
2005   content-disposition = "Content-Disposition:" OWS
2006    content-disposition-v
2007   content-disposition-v = disposition-type *( OWS ";" OWS
2008    disposition-parm )
2009
2010   disp-extension-parm = token "=" ( token / quoted-string )
2011   disp-extension-token = token
2012
2013
2014
2015Fielding, et al.        Expires September 9, 2010              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 3                  March 2010
2018
2019
2020   disposition-parm = filename-parm / disp-extension-parm
2021   disposition-type = "attachment" / disp-extension-token
2022
2023   entity-body = *OCTET
2024   entity-header = Content-Encoding / Content-Language / Content-Length
2025    / Content-Location / Content-MD5 / Content-Range / Content-Type /
2026    Expires / Last-Modified / extension-header
2027   extension-header = header-field
2028
2029   filename-parm = "filename=" quoted-string
2030
2031   header-field = <header-field, defined in [Part1], Section 3.2>
2032
2033   language-range = <language-range, defined in [RFC4647], Section 2.1>
2034   language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
2035
2036   media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
2037    ";" OWS parameter )
2038   media-type = type "/" subtype *( OWS ";" OWS parameter )
2039
2040   parameter = attribute "=" value
2041   partial-URI = <partial-URI, defined in [Part1], Section 2.6>
2042
2043   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
2044   qvalue = <qvalue, defined in [Part1], Section 6.4>
2045
2046   subtype = token
2047
2048   token = <token, defined in [Part1], Section 1.2.2>
2049   type = token
2050
2051   value = token / quoted-string
2052
2053   ABNF diagnostics:
2054
2055   ; Accept defined but not used
2056   ; Accept-Charset defined but not used
2057   ; Accept-Encoding defined but not used
2058   ; Accept-Language defined but not used
2059   ; MIME-Version defined but not used
2060   ; content-disposition defined but not used
2061   ; entity-body defined but not used
2062   ; entity-header defined but not used
2063
2064
2065
2066
2067
2068
2069
2070
2071Fielding, et al.        Expires September 9, 2010              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 3                  March 2010
2074
2075
2076Appendix E.  Change Log (to be removed by RFC Editor before publication)
2077
2078E.1.  Since RFC2616
2079
2080   Extracted relevant partitions from [RFC2616].
2081
2082E.2.  Since draft-ietf-httpbis-p3-payload-00
2083
2084   Closed issues:
2085
2086   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
2087      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
2088
2089   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification
2090      regarding quoting of charset values"
2091      (<http://purl.org/NET/http-errata#charactersets>)
2092
2093   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
2094      'identity' token references"
2095      (<http://purl.org/NET/http-errata#identity>)
2096
2097   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
2098      Encoding BNF"
2099
2100   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
2101      Informative references"
2102
2103   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
2104      references"
2105
2106   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
2107      RFC4288"
2108
2109   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
2110      references"
2111
2112   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
2113      Reference"
2114
2115   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
2116      References Normative"
2117
2118   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
2119      to-date references"
2120
2121
2122
2123
2124
2125
2126
2127Fielding, et al.        Expires September 9, 2010              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 3                  March 2010
2130
2131
2132E.3.  Since draft-ietf-httpbis-p3-payload-01
2133
2134   Ongoing work on ABNF conversion
2135   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2136
2137   o  Add explicit references to BNF syntax and rules imported from
2138      other parts of the specification.
2139
2140E.4.  Since draft-ietf-httpbis-p3-payload-02
2141
2142   Closed issues:
2143
2144   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
2145      Charsets"
2146
2147   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
2148      "Classification for Allow header"
2149
2150   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
2151      default for qvalue in description of Accept-Encoding"
2152
2153   Ongoing work on IANA Message Header Registration
2154   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
2155
2156   o  Reference RFC 3984, and update header registrations for headers
2157      defined in this document.
2158
2159E.5.  Since draft-ietf-httpbis-p3-payload-03
2160
2161   Closed issues:
2162
2163   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
2164      Charsets"
2165
2166   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
2167      matching (Accept-Language) vs RFC4647"
2168
2169   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has
2170      been replaced by RFC2183"
2171
2172   Other changes:
2173
2174   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
2175      References Normative" -- rephrase the annotation and reference
2176      [BCP97].
2177
2178
2179
2180
2181
2182
2183Fielding, et al.        Expires September 9, 2010              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 3                  March 2010
2186
2187
2188E.6.  Since draft-ietf-httpbis-p3-payload-04
2189
2190   Closed issues:
2191
2192   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
2193      updated by RFC 5322"
2194
2195   Ongoing work on ABNF conversion
2196   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2197
2198   o  Use "/" instead of "|" for alternatives.
2199
2200   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2201      whitespace ("OWS") and required whitespace ("RWS").
2202
2203   o  Rewrite ABNFs to spell out whitespace rules, factor out header
2204      value format definitions.
2205
2206E.7.  Since draft-ietf-httpbis-p3-payload-05
2207
2208   Closed issues:
2209
2210   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
2211      "Differences Between HTTP Entities and RFC 2045 Entities"?"
2212
2213   Final work on ABNF conversion
2214   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2215
2216   o  Add appendix containing collected and expanded ABNF, reorganize
2217      ABNF introduction.
2218
2219   Other changes:
2220
2221   o  Move definition of quality values into Part 1.
2222
2223E.8.  Since draft-ietf-httpbis-p3-payload-06
2224
2225   Closed issues:
2226
2227   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
2228      Location isn't special"
2229
2230   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
2231      Sniffing"
2232
2233
2234
2235
2236
2237
2238
2239Fielding, et al.        Expires September 9, 2010              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 3                  March 2010
2242
2243
2244E.9.  Since draft-ietf-httpbis-p3-payload-07
2245
2246   Closed issues:
2247
2248   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated
2249      reference for language tags"
2250
2251   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
2252      for determining what entities a response carries"
2253
2254   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content-
2255      Location base-setting problems"
2256
2257   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
2258      Sniffing"
2259
2260   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
2261      policy (RFC5226) for Transfer Coding / Content Coding"
2262
2263   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
2264      definitions of gzip/deflate/compress to part 1"
2265
2266   Partly resolved issues:
2267
2268   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
2269      requirements wrt Transfer-Coding values" (add the IANA
2270      Considerations subsection)
2271
2272   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA
2273      requirements wrt Content-Coding values" (add the IANA
2274      Considerations subsection)
2275
2276E.10.  Since draft-ietf-httpbis-p3-payload-08
2277
2278   Closed issues:
2279
2280   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
2281      Negotiation for media types"
2282
2283   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
2284      Language: which RFC4647 filtering?"
2285
2286
2287Index
2288
2289   A
2290      Accept header  16
2291      Accept-Charset header  19
2292
2293
2294
2295Fielding, et al.        Expires September 9, 2010              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 3                  March 2010
2298
2299
2300      Accept-Encoding header  19
2301      Accept-Language header  21
2302      Alternates header  35
2303
2304   C
2305      Coding Format
2306         compress  8
2307         deflate  8
2308         gzip  9
2309         identity  9
2310      compress (Coding Format)  8
2311      content negotiation  5
2312      Content-Base header  35
2313      Content-Disposition header  34
2314      Content-Encoding header  22
2315      Content-Language header  23
2316      Content-Location header  23
2317      Content-MD5 header  24
2318      Content-Type header  26
2319      Content-Version header  35
2320
2321   D
2322      deflate (Coding Format)  8
2323      Derived-From header  35
2324
2325   E
2326      entity  5
2327
2328   G
2329      Grammar
2330         Accept  17
2331         Accept-Charset  19
2332         Accept-Charset-v  19
2333         Accept-Encoding  19
2334         Accept-Encoding-v  19
2335         accept-ext  17
2336         Accept-Language  21
2337         Accept-Language-v  21
2338         accept-params  17
2339         Accept-v  17
2340         attribute  10
2341         charset  7
2342         codings  19
2343         content-coding  8
2344         content-disposition  34
2345         content-disposition-v  34
2346         Content-Encoding  22
2347         Content-Encoding-v  22
2348
2349
2350
2351Fielding, et al.        Expires September 9, 2010              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 3                  March 2010
2354
2355
2356         Content-Language  23
2357         Content-Language-v  23
2358         Content-Location  24
2359         Content-Location-v  24
2360         Content-MD5  24
2361         Content-MD5-v  24
2362         Content-Type  26
2363         Content-Type-v  26
2364         disp-extension-parm  34
2365         disp-extension-token  34
2366         disposition-parm  34
2367         disposition-type  34
2368         entity-body  13
2369         entity-header  12
2370         extension-header  12
2371         filename-parm  34
2372         language-range  21
2373         language-tag  12
2374         media-range  17
2375         media-type  9
2376         MIME-Version  32
2377         MIME-Version-v  32
2378         parameter  10
2379         subtype  9
2380         type  9
2381         value  10
2382      gzip (Coding Format)  9
2383
2384   H
2385      Headers
2386         Accept  16
2387         Accept-Charset  19
2388         Accept-Encoding  19
2389         Accept-Language  21
2390         Alternate  35
2391         Content-Base  35
2392         Content-Disposition  34
2393         Content-Encoding  22
2394         Content-Language  23
2395         Content-Location  23
2396         Content-MD5  24
2397         Content-Type  26
2398         Content-Version  35
2399         Derived-From  35
2400         Link  35
2401         MIME-Version  32
2402         Public  35
2403         URI  35
2404
2405
2406
2407Fielding, et al.        Expires September 9, 2010              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 3                  March 2010
2410
2411
2412   I
2413      identity (Coding Format)  9
2414
2415   L
2416      Link header  35
2417
2418   M
2419      MIME-Version header  32
2420
2421   P
2422      Public header  35
2423
2424   R
2425      representation  5
2426
2427   U
2428      URI header  35
2429
2430   V
2431      variant  5
2432
2433
2434Authors' Addresses
2435
2436   Roy T. Fielding (editor)
2437   Day Software
2438   23 Corporate Plaza DR, Suite 280
2439   Newport Beach, CA  92660
2440   USA
2441
2442   Phone: +1-949-706-5300
2443   Fax:   +1-949-706-5305
2444   Email: fielding@gbiv.com
2445   URI:   http://roy.gbiv.com/
2446
2447
2448   Jim Gettys
2449   One Laptop per Child
2450   21 Oak Knoll Road
2451   Carlisle, MA  01741
2452   USA
2453
2454   Email: jg@laptop.org
2455   URI:   http://www.laptop.org/
2456
2457
2458
2459
2460
2461
2462
2463Fielding, et al.        Expires September 9, 2010              [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 3                  March 2010
2466
2467
2468   Jeffrey C. Mogul
2469   Hewlett-Packard Company
2470   HP Labs, Large Scale Systems Group
2471   1501 Page Mill Road, MS 1177
2472   Palo Alto, CA  94304
2473   USA
2474
2475   Email: JeffMogul@acm.org
2476
2477
2478   Henrik Frystyk Nielsen
2479   Microsoft Corporation
2480   1 Microsoft Way
2481   Redmond, WA  98052
2482   USA
2483
2484   Email: henrikn@microsoft.com
2485
2486
2487   Larry Masinter
2488   Adobe Systems, Incorporated
2489   345 Park Ave
2490   San Jose, CA  95110
2491   USA
2492
2493   Email: LMM@acm.org
2494   URI:   http://larry.masinter.net/
2495
2496
2497   Paul J. Leach
2498   Microsoft Corporation
2499   1 Microsoft Way
2500   Redmond, WA  98052
2501
2502   Email: paulle@microsoft.com
2503
2504
2505   Tim Berners-Lee
2506   World Wide Web Consortium
2507   MIT Computer Science and Artificial Intelligence Laboratory
2508   The Stata Center, Building 32
2509   32 Vassar Street
2510   Cambridge, MA  02139
2511   USA
2512
2513   Email: timbl@w3.org
2514   URI:   http://www.w3.org/People/Berners-Lee/
2515
2516
2517
2518
2519Fielding, et al.        Expires September 9, 2010              [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 3                  March 2010
2522
2523
2524   Yves Lafon (editor)
2525   World Wide Web Consortium
2526   W3C / ERCIM
2527   2004, rte des Lucioles
2528   Sophia-Antipolis, AM  06902
2529   France
2530
2531   Email: ylafon@w3.org
2532   URI:   http://www.raubacapeu.net/people/yves/
2533
2534
2535   Julian F. Reschke (editor)
2536   greenbytes GmbH
2537   Hafenweg 16
2538   Muenster, NW  48155
2539   Germany
2540
2541   Phone: +49 251 2807760
2542   Fax:   +49 251 2807761
2543   Email: julian.reschke@greenbytes.de
2544   URI:   http://greenbytes.de/tech/webdav/
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575Fielding, et al.        Expires September 9, 2010              [Page 46]
2576
Note: See TracBrowser for help on using the repository browser.