source: draft-ietf-httpbis/07/draft-ietf-httpbis-p3-payload-07.txt @ 605

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

Prepare release of -07 drafts.

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