source: draft-ietf-httpbis/06/draft-ietf-httpbis-p3-payload-06.txt @ 558

Last change on this file since 558 was 558, checked in by fielding@…, 11 years ago

Draft 06 (as recorded by www.ietf.org)

  • Property svn:eol-style set to native
File size: 93.0 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                    One Laptop per Child
8Expires: September 10, 2009                                     J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 9, 2009
23
24
25       HTTP/1.1, part 3: Message Payload and Content Negotiation
26                    draft-ietf-httpbis-p3-payload-06
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 September 10, 2009               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009.
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.7.
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 10, 2009               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 3                  March 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 . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . 31
164
165
166
167Fielding, et al.       Expires September 10, 2009               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 3                  March 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 . . . . . . . . . . . . . . . 32
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  . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . 38
190     E.6.  Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
191     E.7.  Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
192   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
193   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
194
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 September 10, 2009               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 3                  March 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 September 10, 2009              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 3                  March 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.
668
669
670
671Fielding, et al.       Expires September 10, 2009              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 3                  March 2009
674
675
676   Content-Encoding may be used to indicate any additional content
677   codings applied to the data, usually for the purpose of data
678   compression, that are a property of the requested resource.  There is
679   no default encoding.
680
681   Any HTTP/1.1 message containing an entity-body SHOULD include a
682   Content-Type header field defining the media type of that body.  If
683   and only if the media type is not given by a Content-Type field, the
684   recipient MAY attempt to guess the media type via inspection of its
685   content and/or the name extension(s) of the URI used to identify the
686   resource.  If the media type remains unknown, the recipient SHOULD
687   treat it as type "application/octet-stream".
688
6893.2.2.  Entity Length
690
691   The entity-length of a message is the length of the message-body
692   before any transfer-codings have been applied.  Section 4.4 of
693   [Part1] defines how the transfer-length of a message-body is
694   determined.
695
696
6974.  Content Negotiation
698
699   Most HTTP responses include an entity which contains information for
700   interpretation by a human user.  Naturally, it is desirable to supply
701   the user with the "best available" entity corresponding to the
702   request.  Unfortunately for servers and caches, not all users have
703   the same preferences for what is "best," and not all user agents are
704   equally capable of rendering all entity types.  For that reason, HTTP
705   has provisions for several mechanisms for "content negotiation" --
706   the process of selecting the best representation for a given response
707   when there are multiple representations available.
708
709      Note: This is not called "format negotiation" because the
710      alternate representations may be of the same media type, but use
711      different capabilities of that type, be in different languages,
712      etc.
713
714   Any response containing an entity-body MAY be subject to negotiation,
715   including error responses.
716
717   There are two kinds of content negotiation which are possible in
718   HTTP: server-driven and agent-driven negotiation.  These two kinds of
719   negotiation are orthogonal and thus may be used separately or in
720   combination.  One method of combination, referred to as transparent
721   negotiation, occurs when a cache uses the agent-driven negotiation
722   information provided by the origin server in order to provide server-
723   driven negotiation for subsequent requests.
724
725
726
727Fielding, et al.       Expires September 10, 2009              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 3                  March 2009
730
731
7324.1.  Server-driven Negotiation
733
734   If the selection of the best representation for a response is made by
735   an algorithm located at the server, it is called server-driven
736   negotiation.  Selection is based on the available representations of
737   the response (the dimensions over which it can vary; e.g. language,
738   content-coding, etc.) and the contents of particular header fields in
739   the request message or on other information pertaining to the request
740   (such as the network address of the client).
741
742   Server-driven negotiation is advantageous when the algorithm for
743   selecting from among the available representations is difficult to
744   describe to the user agent, or when the server desires to send its
745   "best guess" to the client along with the first response (hoping to
746   avoid the round-trip delay of a subsequent request if the "best
747   guess" is good enough for the user).  In order to improve the
748   server's guess, the user agent MAY include request header fields
749   (Accept, Accept-Language, Accept-Encoding, etc.) which describe its
750   preferences for such a response.
751
752   Server-driven negotiation has disadvantages:
753
754   1.  It is impossible for the server to accurately determine what
755       might be "best" for any given user, since that would require
756       complete knowledge of both the capabilities of the user agent and
757       the intended use for the response (e.g., does the user want to
758       view it on screen or print it on paper?).
759
760   2.  Having the user agent describe its capabilities in every request
761       can be both very inefficient (given that only a small percentage
762       of responses have multiple representations) and a potential
763       violation of the user's privacy.
764
765   3.  It complicates the implementation of an origin server and the
766       algorithms for generating responses to a request.
767
768   4.  It may limit a public cache's ability to use the same response
769       for multiple user's requests.
770
771   HTTP/1.1 includes the following request-header fields for enabling
772   server-driven negotiation through description of user agent
773   capabilities and user preferences: Accept (Section 5.1), Accept-
774   Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
775   (Section 5.4), and User-Agent (Section 9.9 of [Part2]).  However, an
776   origin server is not limited to these dimensions and MAY vary the
777   response based on any aspect of the request, including information
778   outside the request-header fields or within extension header fields
779   not defined by this specification.
780
781
782
783Fielding, et al.       Expires September 10, 2009              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 3                  March 2009
786
787
788   The Vary header field (Section 3.5 of [Part6]) can be used to express
789   the parameters the server uses to select a representation that is
790   subject to server-driven negotiation.
791
7924.2.  Agent-driven Negotiation
793
794   With agent-driven negotiation, selection of the best representation
795   for a response is performed by the user agent after receiving an
796   initial response from the origin server.  Selection is based on a
797   list of the available representations of the response included within
798   the header fields or entity-body of the initial response, with each
799   representation identified by its own URI.  Selection from among the
800   representations may be performed automatically (if the user agent is
801   capable of doing so) or manually by the user selecting from a
802   generated (possibly hypertext) menu.
803
804   Agent-driven negotiation is advantageous when the response would vary
805   over commonly-used dimensions (such as type, language, or encoding),
806   when the origin server is unable to determine a user agent's
807   capabilities from examining the request, and generally when public
808   caches are used to distribute server load and reduce network usage.
809
810   Agent-driven negotiation suffers from the disadvantage of needing a
811   second request to obtain the best alternate representation.  This
812   second request is only efficient when caching is used.  In addition,
813   this specification does not define any mechanism for supporting
814   automatic selection, though it also does not prevent any such
815   mechanism from being developed as an extension and used within
816   HTTP/1.1.
817
818   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
819   status codes for enabling agent-driven negotiation when the server is
820   unwilling or unable to provide a varying response using server-driven
821   negotiation.
822
8234.3.  Transparent Negotiation
824
825   Transparent negotiation is a combination of both server-driven and
826   agent-driven negotiation.  When a cache is supplied with a form of
827   the list of available representations of the response (as in agent-
828   driven negotiation) and the dimensions of variance are completely
829   understood by the cache, then the cache becomes capable of performing
830   server-driven negotiation on behalf of the origin server for
831   subsequent requests on that resource.
832
833   Transparent negotiation has the advantage of distributing the
834   negotiation work that would otherwise be required of the origin
835   server and also removing the second request delay of agent-driven
836
837
838
839Fielding, et al.       Expires September 10, 2009              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 3                  March 2009
842
843
844   negotiation when the cache is able to correctly guess the right
845   response.
846
847   This specification does not define any mechanism for transparent
848   negotiation, though it also does not prevent any such mechanism from
849   being developed as an extension that could be used within HTTP/1.1.
850
851
8525.  Header Field Definitions
853
854   This section defines the syntax and semantics of HTTP/1.1 header
855   fields related to the payload of messages.
856
857   For entity-header fields, both sender and recipient refer to either
858   the client or the server, depending on who sends and who receives the
859   entity.
860
8615.1.  Accept
862
863   The request-header field "Accept" can be used to specify certain
864   media types which are acceptable for the response.  Accept headers
865   can be used to indicate that the request is specifically limited to a
866   small set of desired types, as in the case of a request for an in-
867   line image.
868
869     Accept   = "Accept" ":" OWS Accept-v
870     Accept-v = #( media-range [ accept-params ] )
871
872     media-range    = ( "*/*"
873                      / ( type "/" "*" )
874                      / ( type "/" subtype )
875                      ) *( OWS ";" OWS parameter )
876     accept-params  = OWS ";" OWS "q=" qvalue *( accept-ext )
877     accept-ext     = OWS ";" OWS token
878                      [ "=" ( token / quoted-string ) ]
879
880   The asterisk "*" character is used to group media types into ranges,
881   with "*/*" indicating all media types and "type/*" indicating all
882   subtypes of that type.  The media-range MAY include media type
883   parameters that are applicable to that range.
884
885   Each media-range MAY be followed by one or more accept-params,
886   beginning with the "q" parameter for indicating a relative quality
887   factor.  The first "q" parameter (if any) separates the media-range
888   parameter(s) from the accept-params.  Quality factors allow the user
889   or user agent to indicate the relative degree of preference for that
890   media-range, using the qvalue scale from 0 to 1 (Section 3.5 of
891   [Part1]).  The default value is q=1.
892
893
894
895Fielding, et al.       Expires September 10, 2009              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 3                  March 2009
898
899
900      Note: Use of the "q" parameter name to separate media type
901      parameters from Accept extension parameters is due to historical
902      practice.  Although this prevents any media type parameter named
903      "q" from being used with a media range, such an event is believed
904      to be unlikely given the lack of any "q" parameters in the IANA
905      media type registry and the rare usage of any media type
906      parameters in Accept.  Future media types are discouraged from
907      registering any parameter named "q".
908
909   The example
910
911     Accept: audio/*; q=0.2, audio/basic
912
913   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
914   type if it is the best available after an 80% mark-down in quality."
915
916   If no Accept header field is present, then it is assumed that the
917   client accepts all media types.  If an Accept header field is
918   present, and if the server cannot send a response which is acceptable
919   according to the combined Accept field value, then the server SHOULD
920   send a 406 (Not Acceptable) response.
921
922   A more elaborate example is
923
924     Accept: text/plain; q=0.5, text/html,
925             text/x-dvi; q=0.8, text/x-c
926
927   Verbally, this would be interpreted as "text/html and text/x-c are
928   the preferred media types, but if they do not exist, then send the
929   text/x-dvi entity, and if that does not exist, send the text/plain
930   entity."
931
932   Media ranges can be overridden by more specific media ranges or
933   specific media types.  If more than one media range applies to a
934   given type, the most specific reference has precedence.  For example,
935
936     Accept: text/*, text/html, text/html;level=1, */*
937
938   have the following precedence:
939
940   1.  text/html;level=1
941
942   2.  text/html
943
944   3.  text/*
945
946   4.  */*
947
948
949
950
951Fielding, et al.       Expires September 10, 2009              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 3                  March 2009
954
955
956   The media type quality factor associated with a given type is
957   determined by finding the media range with the highest precedence
958   which matches that type.  For example,
959
960     Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
961             text/html;level=2;q=0.4, */*;q=0.5
962
963   would cause the following values to be associated:
964
965   +-------------------+---------------+
966   | Media Type        | Quality Value |
967   +-------------------+---------------+
968   | text/html;level=1 | 1             |
969   | text/html         | 0.7           |
970   | text/plain        | 0.3           |
971   | image/jpeg        | 0.5           |
972   | text/html;level=2 | 0.4           |
973   | text/html;level=3 | 0.7           |
974   +-------------------+---------------+
975
976   Note: A user agent might be provided with a default set of quality
977   values for certain media ranges.  However, unless the user agent is a
978   closed system which cannot interact with other rendering agents, this
979   default set ought to be configurable by the user.
980
9815.2.  Accept-Charset
982
983   The request-header field "Accept-Charset" can be used to indicate
984   what character sets are acceptable for the response.  This field
985   allows clients capable of understanding more comprehensive or
986   special-purpose character sets to signal that capability to a server
987   which is capable of representing documents in those character sets.
988
989     Accept-Charset   = "Accept-Charset" ":" OWS
990             Accept-Charset-v
991     Accept-Charset-v = 1#( ( charset / "*" )
992                            [ OWS ";" OWS "q=" qvalue ] )
993
994   Character set values are described in Section 2.1.  Each charset MAY
995   be given an associated quality value which represents the user's
996   preference for that charset.  The default value is q=1.  An example
997   is
998
999     Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
1000
1001   The special value "*", if present in the Accept-Charset field,
1002   matches every character set (including ISO-8859-1) which is not
1003   mentioned elsewhere in the Accept-Charset field.  If no "*" is
1004
1005
1006
1007Fielding, et al.       Expires September 10, 2009              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 3                  March 2009
1010
1011
1012   present in an Accept-Charset field, then all character sets not
1013   explicitly mentioned get a quality value of 0, except for ISO-8859-1,
1014   which gets a quality value of 1 if not explicitly mentioned.
1015
1016   If no Accept-Charset header is present, the default is that any
1017   character set is acceptable.  If an Accept-Charset header is present,
1018   and if the server cannot send a response which is acceptable
1019   according to the Accept-Charset header, then the server SHOULD send
1020   an error response with the 406 (Not Acceptable) status code, though
1021   the sending of an unacceptable response is also allowed.
1022
10235.3.  Accept-Encoding
1024
1025   The request-header field "Accept-Encoding" is similar to Accept, but
1026   restricts the content-codings (Section 2.2) that are acceptable in
1027   the response.
1028
1029     Accept-Encoding    = "Accept-Encoding" ":" OWS
1030                        Accept-Encoding-v
1031     Accept-Encoding-v  =
1032                        #( codings [ OWS ";" OWS "q=" qvalue ] )
1033     codings            = ( content-coding / "*" )
1034
1035   Each codings value MAY be given an associated quality value which
1036   represents the preference for that encoding.  The default value is
1037   q=1.
1038
1039   Examples of its use are:
1040
1041     Accept-Encoding: compress, gzip
1042     Accept-Encoding:
1043     Accept-Encoding: *
1044     Accept-Encoding: compress;q=0.5, gzip;q=1.0
1045     Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
1046
1047   A server tests whether a content-coding is acceptable, according to
1048   an Accept-Encoding field, using these rules:
1049
1050   1.  If the content-coding is one of the content-codings listed in the
1051       Accept-Encoding field, then it is acceptable, unless it is
1052       accompanied by a qvalue of 0.  (As defined in Section 3.5 of
1053       [Part1], a qvalue of 0 means "not acceptable.")
1054
1055   2.  The special "*" symbol in an Accept-Encoding field matches any
1056       available content-coding not explicitly listed in the header
1057       field.
1058
1059
1060
1061
1062
1063Fielding, et al.       Expires September 10, 2009              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 3                  March 2009
1066
1067
1068   3.  If multiple content-codings are acceptable, then the acceptable
1069       content-coding with the highest non-zero qvalue is preferred.
1070
1071   4.  The "identity" content-coding is always acceptable, unless
1072       specifically refused because the Accept-Encoding field includes
1073       "identity;q=0", or because the field includes "*;q=0" and does
1074       not explicitly include the "identity" content-coding.  If the
1075       Accept-Encoding field-value is empty, then only the "identity"
1076       encoding is acceptable.
1077
1078   If an Accept-Encoding field is present in a request, and if the
1079   server cannot send a response which is acceptable according to the
1080   Accept-Encoding header, then the server SHOULD send an error response
1081   with the 406 (Not Acceptable) status code.
1082
1083   If no Accept-Encoding field is present in a request, the server MAY
1084   assume that the client will accept any content coding.  In this case,
1085   if "identity" is one of the available content-codings, then the
1086   server SHOULD use the "identity" content-coding, unless it has
1087   additional information that a different content-coding is meaningful
1088   to the client.
1089
1090      Note: If the request does not include an Accept-Encoding field,
1091      and if the "identity" content-coding is unavailable, then content-
1092      codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and
1093      "compress") are preferred; some older clients improperly display
1094      messages sent with other content-codings.  The server might also
1095      make this decision based on information about the particular user-
1096      agent or client.
1097
1098      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
1099      associated with content-codings.  This means that qvalues will not
1100      work and are not permitted with x-gzip or x-compress.
1101
11025.4.  Accept-Language
1103
1104   The request-header field "Accept-Language" is similar to Accept, but
1105   restricts the set of natural languages that are preferred as a
1106   response to the request.  Language tags are defined in Section 2.4.
1107
1108     Accept-Language   = "Accept-Language" ":" OWS
1109                       Accept-Language-v
1110     Accept-Language-v =
1111                       1#( language-range [ OWS ";" OWS "q=" qvalue ] )
1112     language-range    =
1113               <language-range, defined in [RFC4647], Section 2.1>
1114
1115   Each language-range can be given an associated quality value which
1116
1117
1118
1119Fielding, et al.       Expires September 10, 2009              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 3                  March 2009
1122
1123
1124   represents an estimate of the user's preference for the languages
1125   specified by that range.  The quality value defaults to "q=1".  For
1126   example,
1127
1128     Accept-Language: da, en-gb;q=0.8, en;q=0.7
1129
1130   would mean: "I prefer Danish, but will accept British English and
1131   other types of English."
1132
1133   For matching, the "Basic Filtering" matching scheme, defined in
1134   Section 3.3.1 of [RFC4647], is used:
1135
1136      A language range matches a particular language tag if, in a case-
1137      insensitive comparison, it exactly equals the tag, or if it
1138      exactly equals a prefix of the tag such that the first character
1139      following the prefix is "-".
1140
1141   The special range "*", if present in the Accept-Language field,
1142   matches every tag not matched by any other range present in the
1143   Accept-Language field.
1144
1145      Note: This use of a prefix matching rule does not imply that
1146      language tags are assigned to languages in such a way that it is
1147      always true that if a user understands a language with a certain
1148      tag, then this user will also understand all languages with tags
1149      for which this tag is a prefix.  The prefix rule simply allows the
1150      use of prefix tags if this is the case.
1151
1152   The language quality factor assigned to a language-tag by the Accept-
1153   Language field is the quality value of the longest language-range in
1154   the field that matches the language-tag.  If no language-range in the
1155   field matches the tag, the language quality factor assigned is 0.  If
1156   no Accept-Language header is present in the request, the server
1157   SHOULD assume that all languages are equally acceptable.  If an
1158   Accept-Language header is present, then all languages which are
1159   assigned a quality factor greater than 0 are acceptable.
1160
1161   It might be contrary to the privacy expectations of the user to send
1162   an Accept-Language header with the complete linguistic preferences of
1163   the user in every request.  For a discussion of this issue, see
1164   Section 7.1.
1165
1166   As intelligibility is highly dependent on the individual user, it is
1167   recommended that client applications make the choice of linguistic
1168   preference available to the user.  If the choice is not made
1169   available, then the Accept-Language header field MUST NOT be given in
1170   the request.
1171
1172
1173
1174
1175Fielding, et al.       Expires September 10, 2009              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 3                  March 2009
1178
1179
1180      Note: When making the choice of linguistic preference available to
1181      the user, we remind implementors of the fact that users are not
1182      familiar with the details of language matching as described above,
1183      and should provide appropriate guidance.  As an example, users
1184      might assume that on selecting "en-gb", they will be served any
1185      kind of English document if British English is not available.  A
1186      user agent might suggest in such a case to add "en" to get the
1187      best matching behavior.
1188
11895.5.  Content-Encoding
1190
1191   The entity-header field "Content-Encoding" is used as a modifier to
1192   the media-type.  When present, its value indicates what additional
1193   content codings have been applied to the entity-body, and thus what
1194   decoding mechanisms must be applied in order to obtain the media-type
1195   referenced by the Content-Type header field.  Content-Encoding is
1196   primarily used to allow a document to be compressed without losing
1197   the identity of its underlying media type.
1198
1199     Content-Encoding   = "Content-Encoding" ":" OWS Content-Encoding-v
1200     Content-Encoding-v = 1#content-coding
1201
1202   Content codings are defined in Section 2.2.  An example of its use is
1203
1204     Content-Encoding: gzip
1205
1206   The content-coding is a characteristic of the entity identified by
1207   the request-target.  Typically, the entity-body is stored with this
1208   encoding and is only decoded before rendering or analogous usage.
1209   However, a non-transparent proxy MAY modify the content-coding if the
1210   new coding is known to be acceptable to the recipient, unless the
1211   "no-transform" cache-control directive is present in the message.
1212
1213   If the content-coding of an entity is not "identity", then the
1214   response MUST include a Content-Encoding entity-header (Section 5.5)
1215   that lists the non-identity content-coding(s) used.
1216
1217   If the content-coding of an entity in a request message is not
1218   acceptable to the origin server, the server SHOULD respond with a
1219   status code of 415 (Unsupported Media Type).
1220
1221   If multiple encodings have been applied to an entity, the content
1222   codings MUST be listed in the order in which they were applied.
1223   Additional information about the encoding parameters MAY be provided
1224   by other entity-header fields not defined by this specification.
1225
1226
1227
1228
1229
1230
1231Fielding, et al.       Expires September 10, 2009              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 3                  March 2009
1234
1235
12365.6.  Content-Language
1237
1238   The entity-header field "Content-Language" describes the natural
1239   language(s) of the intended audience for the enclosed entity.  Note
1240   that this might not be equivalent to all the languages used within
1241   the entity-body.
1242
1243     Content-Language   = "Content-Language" ":" OWS Content-Language-v
1244     Content-Language-v = 1#language-tag
1245
1246   Language tags are defined in Section 2.4.  The primary purpose of
1247   Content-Language is to allow a user to identify and differentiate
1248   entities according to the user's own preferred language.  Thus, if
1249   the body content is intended only for a Danish-literate audience, the
1250   appropriate field is
1251
1252     Content-Language: da
1253
1254   If no Content-Language is specified, the default is that the content
1255   is intended for all language audiences.  This might mean that the
1256   sender does not consider it to be specific to any natural language,
1257   or that the sender does not know for which language it is intended.
1258
1259   Multiple languages MAY be listed for content that is intended for
1260   multiple audiences.  For example, a rendition of the "Treaty of
1261   Waitangi," presented simultaneously in the original Maori and English
1262   versions, would call for
1263
1264     Content-Language: mi, en
1265
1266   However, just because multiple languages are present within an entity
1267   does not mean that it is intended for multiple linguistic audiences.
1268   An example would be a beginner's language primer, such as "A First
1269   Lesson in Latin," which is clearly intended to be used by an English-
1270   literate audience.  In this case, the Content-Language would properly
1271   only include "en".
1272
1273   Content-Language MAY be applied to any media type -- it is not
1274   limited to textual documents.
1275
12765.7.  Content-Location
1277
1278   The entity-header field "Content-Location" MAY be used to supply the
1279   resource location for the entity enclosed in the message when that
1280   entity is accessible from a location separate from the requested
1281   resource's URI.  A server SHOULD provide a Content-Location for the
1282   variant corresponding to the response entity; especially in the case
1283   where a resource has multiple entities associated with it, and those
1284
1285
1286
1287Fielding, et al.       Expires September 10, 2009              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 3                  March 2009
1290
1291
1292   entities actually have separate locations by which they might be
1293   individually accessed, the server SHOULD provide a Content-Location
1294   for the particular variant which is returned.
1295
1296     Content-Location   = "Content-Location" ":" OWS
1297                       Content-Location-v
1298     Content-Location-v =
1299                       absolute-URI / partial-URI
1300
1301   The value of Content-Location also defines the base URI for the
1302   entity.
1303
1304   The Content-Location value is not a replacement for the original
1305   requested URI; it is only a statement of the location of the resource
1306   corresponding to this particular entity at the time of the request.
1307   Future requests MAY specify the Content-Location URI as the request-
1308   target if the desire is to identify the source of that particular
1309   entity.
1310
1311   A cache cannot assume that an entity with a Content-Location
1312   different from the URI used to retrieve it can be used to respond to
1313   later requests on that Content-Location URI.  However, the Content-
1314   Location can be used to differentiate between multiple entities
1315   retrieved from a single requested resource, as described in Section
1316   2.6 of [Part6].
1317
1318   If the Content-Location is a relative URI, the relative URI is
1319   interpreted relative to the request-target.
1320
1321   The meaning of the Content-Location header in PUT or POST requests is
1322   undefined; servers are free to ignore it in those cases.
1323
13245.8.  Content-MD5
1325
1326   The entity-header field "Content-MD5", as defined in [RFC1864], is an
1327   MD5 digest of the entity-body for the purpose of providing an end-to-
1328   end message integrity check (MIC) of the entity-body.  (Note: a MIC
1329   is good for detecting accidental modification of the entity-body in
1330   transit, but is not proof against malicious attacks.)
1331
1332     Content-MD5   = "Content-MD5" ":" OWS Content-MD5-v
1333     Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
1334
1335   The Content-MD5 header field MAY be generated by an origin server or
1336   client to function as an integrity check of the entity-body.  Only
1337   origin servers or clients MAY generate the Content-MD5 header field;
1338   proxies and gateways MUST NOT generate it, as this would defeat its
1339   value as an end-to-end integrity check.  Any recipient of the entity-
1340
1341
1342
1343Fielding, et al.       Expires September 10, 2009              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 3                  March 2009
1346
1347
1348   body, including gateways and proxies, MAY check that the digest value
1349   in this header field matches that of the entity-body as received.
1350
1351   The MD5 digest is computed based on the content of the entity-body,
1352   including any content-coding that has been applied, but not including
1353   any transfer-encoding applied to the message-body.  If the message is
1354   received with a transfer-encoding, that encoding MUST be removed
1355   prior to checking the Content-MD5 value against the received entity.
1356
1357   This has the result that the digest is computed on the octets of the
1358   entity-body exactly as, and in the order that, they would be sent if
1359   no transfer-encoding were being applied.
1360
1361   HTTP extends RFC 1864 to permit the digest to be computed for MIME
1362   composite media-types (e.g., multipart/* and message/rfc822), but
1363   this does not change how the digest is computed as defined in the
1364   preceding paragraph.
1365
1366   There are several consequences of this.  The entity-body for
1367   composite types MAY contain many body-parts, each with its own MIME
1368   and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
1369   and Content-Encoding headers).  If a body-part has a Content-
1370   Transfer-Encoding or Content-Encoding header, it is assumed that the
1371   content of the body-part has had the encoding applied, and the body-
1372   part is included in the Content-MD5 digest as is -- i.e., after the
1373   application.  The Transfer-Encoding header field is not allowed
1374   within body-parts.
1375
1376   Conversion of all line breaks to CRLF MUST NOT be done before
1377   computing or checking the digest: the line break convention used in
1378   the text actually transmitted MUST be left unaltered when computing
1379   the digest.
1380
1381      Note: while the definition of Content-MD5 is exactly the same for
1382      HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
1383      in which the application of Content-MD5 to HTTP entity-bodies
1384      differs from its application to MIME entity-bodies.  One is that
1385      HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
1386      does use Transfer-Encoding and Content-Encoding.  Another is that
1387      HTTP more frequently uses binary content types than MIME, so it is
1388      worth noting that, in such cases, the byte order used to compute
1389      the digest is the transmission byte order defined for the type.
1390      Lastly, HTTP allows transmission of text types with any of several
1391      line break conventions and not just the canonical form using CRLF.
1392
1393
1394
1395
1396
1397
1398
1399Fielding, et al.       Expires September 10, 2009              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 3                  March 2009
1402
1403
14045.9.  Content-Type
1405
1406   The entity-header field "Content-Type" indicates the media type of
1407   the entity-body sent to the recipient or, in the case of the HEAD
1408   method, the media type that would have been sent had the request been
1409   a GET.
1410
1411     Content-Type   = "Content-Type" ":" OWS Content-Type-v
1412     Content-Type-v = media-type
1413
1414   Media types are defined in Section 2.3.  An example of the field is
1415
1416     Content-Type: text/html; charset=ISO-8859-4
1417
1418   Further discussion of methods for identifying the media type of an
1419   entity is provided in Section 3.2.1.
1420
1421
14226.  IANA Considerations
1423
14246.1.  Message Header Registration
1425
1426   The Message Header Registry located at <http://www.iana.org/
1427   assignments/message-headers/message-header-index.html> should be
1428   updated with the permanent registrations below (see [RFC3864]):
1429
1430   +---------------------+----------+----------+--------------+
1431   | Header Field Name   | Protocol | Status   | Reference    |
1432   +---------------------+----------+----------+--------------+
1433   | Accept              | http     | standard | Section 5.1  |
1434   | Accept-Charset      | http     | standard | Section 5.2  |
1435   | Accept-Encoding     | http     | standard | Section 5.3  |
1436   | Accept-Language     | http     | standard | Section 5.4  |
1437   | Content-Disposition | http     |          | Appendix B.1 |
1438   | Content-Encoding    | http     | standard | Section 5.5  |
1439   | Content-Language    | http     | standard | Section 5.6  |
1440   | Content-Location    | http     | standard | Section 5.7  |
1441   | Content-MD5         | http     | standard | Section 5.8  |
1442   | Content-Type        | http     | standard | Section 5.9  |
1443   | MIME-Version        | http     |          | Appendix A.1 |
1444   +---------------------+----------+----------+--------------+
1445
1446   The change controller is: "IETF (iesg@ietf.org) - Internet
1447   Engineering Task Force".
1448
1449
1450
1451
1452
1453
1454
1455Fielding, et al.       Expires September 10, 2009              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 3                  March 2009
1458
1459
14607.  Security Considerations
1461
1462   This section is meant to inform application developers, information
1463   providers, and users of the security limitations in HTTP/1.1 as
1464   described by this document.  The discussion does not include
1465   definitive solutions to the problems revealed, though it does make
1466   some suggestions for reducing security risks.
1467
14687.1.  Privacy Issues Connected to Accept Headers
1469
1470   Accept request-headers can reveal information about the user to all
1471   servers which are accessed.  The Accept-Language header in particular
1472   can reveal information the user would consider to be of a private
1473   nature, because the understanding of particular languages is often
1474   strongly correlated to the membership of a particular ethnic group.
1475   User agents which offer the option to configure the contents of an
1476   Accept-Language header to be sent in every request are strongly
1477   encouraged to let the configuration process include a message which
1478   makes the user aware of the loss of privacy involved.
1479
1480   An approach that limits the loss of privacy would be for a user agent
1481   to omit the sending of Accept-Language headers by default, and to ask
1482   the user whether or not to start sending Accept-Language headers to a
1483   server if it detects, by looking for any Vary response-header fields
1484   generated by the server, that such sending could improve the quality
1485   of service.
1486
1487   Elaborate user-customized accept header fields sent in every request,
1488   in particular if these include quality values, can be used by servers
1489   as relatively reliable and long-lived user identifiers.  Such user
1490   identifiers would allow content providers to do click-trail tracking,
1491   and would allow collaborating content providers to match cross-server
1492   click-trails or form submissions of individual users.  Note that for
1493   many users not behind a proxy, the network address of the host
1494   running the user agent will also serve as a long-lived user
1495   identifier.  In environments where proxies are used to enhance
1496   privacy, user agents ought to be conservative in offering accept
1497   header configuration options to end users.  As an extreme privacy
1498   measure, proxies could filter the accept headers in relayed requests.
1499   General purpose user agents which provide a high degree of header
1500   configurability SHOULD warn users about the loss of privacy which can
1501   be involved.
1502
15037.2.  Content-Disposition Issues
1504
1505   [RFC2183], from which the often implemented Content-Disposition (see
1506   Appendix B.1) header in HTTP is derived, has a number of very serious
1507   security considerations.  Content-Disposition is not part of the HTTP
1508
1509
1510
1511Fielding, et al.       Expires September 10, 2009              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 3                  March 2009
1514
1515
1516   standard, but since it is widely implemented, we are documenting its
1517   use and risks for implementors.  See Section 5 of [RFC2183] for
1518   details.
1519
1520
15218.  Acknowledgments
1522
1523
15249.  References
1525
15269.1.  Normative References
1527
1528   [ISO-8859-1]
1529              International Organization for Standardization,
1530              "Information technology -- 8-bit single-byte coded graphic
1531              character sets -- Part 1: Latin alphabet No. 1", ISO/
1532              IEC 8859-1:1998, 1998.
1533
1534   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1535              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1536              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
1537              and Message Parsing", draft-ietf-httpbis-p1-messaging-06
1538              (work in progress), March 2009.
1539
1540   [Part2]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1541              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1542              and J. Reschke, Ed., "HTTP/1.1, part 2: Message
1543              Semantics", draft-ietf-httpbis-p2-semantics-06 (work in
1544              progress), March 2009.
1545
1546   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1547              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1548              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
1549              Requests", draft-ietf-httpbis-p4-conditional-06 (work in
1550              progress), March 2009.
1551
1552   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1553              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1554              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
1555              Partial Responses", draft-ietf-httpbis-p5-range-06 (work
1556              in progress), March 2009.
1557
1558   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1559              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1560              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
1561              draft-ietf-httpbis-p6-cache-06 (work in progress),
1562              March 2009.
1563
1564
1565
1566
1567Fielding, et al.       Expires September 10, 2009              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 3                  March 2009
1570
1571
1572   [RFC1766]  Alvestrand, H., "Tags for the Identification of
1573              Languages", RFC 1766, March 1995.
1574
1575   [RFC1864]  Myers, J. and M. Rose, "The Content-MD5 Header Field",
1576              RFC 1864, October 1995.
1577
1578   [RFC1950]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
1579              Specification version 3.3", RFC 1950, May 1996.
1580
1581              RFC 1950 is an Informational RFC, thus it may be less
1582              stable than this specification.  On the other hand, this
1583              downward reference was present since the publication of
1584              RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
1585              cause problems in practice.  See also [BCP97].
1586
1587   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
1588              version 1.3", RFC 1951, May 1996.
1589
1590              RFC 1951 is an Informational RFC, thus it may be less
1591              stable than this specification.  On the other hand, this
1592              downward reference was present since the publication of
1593              RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
1594              cause problems in practice.  See also [BCP97].
1595
1596   [RFC1952]  Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
1597              Randers-Pehrson, "GZIP file format specification version
1598              4.3", RFC 1952, May 1996.
1599
1600              RFC 1952 is an Informational RFC, thus it may be less
1601              stable than this specification.  On the other hand, this
1602              downward reference was present since the publication of
1603              RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
1604              cause problems in practice.  See also [BCP97].
1605
1606   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1607              Extensions (MIME) Part One: Format of Internet Message
1608              Bodies", RFC 2045, November 1996.
1609
1610   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1611              Extensions (MIME) Part Two: Media Types", RFC 2046,
1612              November 1996.
1613
1614   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1615              Requirement Levels", BCP 14, RFC 2119, March 1997.
1616
1617   [RFC4647]  Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
1618              Tags", BCP 47, RFC 4647, September 2006.
1619
1620
1621
1622
1623Fielding, et al.       Expires September 10, 2009              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 3                  March 2009
1626
1627
1628   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1629              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1630
16319.2.  Informative References
1632
1633   [BCP97]    Klensin, J. and S. Hartman, "Handling Normative References
1634              to Standards-Track Documents", BCP 97, RFC 4897,
1635              June 2007.
1636
1637   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
1638              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
1639
1640   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1641              Extensions (MIME) Part Five: Conformance Criteria and
1642              Examples", RFC 2049, November 1996.
1643
1644   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
1645              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
1646              RFC 2068, January 1997.
1647
1648   [RFC2076]  Palme, J., "Common Internet Message Headers", RFC 2076,
1649              February 1997.
1650
1651   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
1652              Presentation Information in Internet Messages: The
1653              Content-Disposition Header Field", RFC 2183, August 1997.
1654
1655   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
1656              Languages", BCP 18, RFC 2277, January 1998.
1657
1658   [RFC2388]  Masinter, L., "Returning Values from Forms:  multipart/
1659              form-data", RFC 2388, August 1998.
1660
1661   [RFC2557]  Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
1662              "MIME Encapsulation of Aggregate Documents, such as HTML
1663              (MHTML)", RFC 2557, March 1999.
1664
1665   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1666              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1667              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1668
1669   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
1670              10646", RFC 3629, STD 63, November 2003.
1671
1672   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1673              Procedures for Message Header Fields", BCP 90, RFC 3864,
1674              September 2004.
1675
1676
1677
1678
1679Fielding, et al.       Expires September 10, 2009              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 3                  March 2009
1682
1683
1684   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
1685              Registration Procedures", BCP 13, RFC 4288, December 2005.
1686
1687   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
1688              October 2008.
1689
1690
1691Appendix A.  Differences Between HTTP Entities and RFC 2045 Entities
1692
1693   HTTP/1.1 uses many of the constructs defined for Internet Mail
1694   ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
1695   [RFC2045]) to allow entities to be transmitted in an open variety of
1696   representations and with extensible mechanisms.  However, RFC 2045
1697   discusses mail, and HTTP has a few features that are different from
1698   those described in RFC 2045.  These differences were carefully chosen
1699   to optimize performance over binary connections, to allow greater
1700   freedom in the use of new media types, to make date comparisons
1701   easier, and to acknowledge the practice of some early HTTP servers
1702   and clients.
1703
1704   This appendix describes specific areas where HTTP differs from RFC
1705   2045.  Proxies and gateways to strict MIME environments SHOULD be
1706   aware of these differences and provide the appropriate conversions
1707   where necessary.  Proxies and gateways from MIME environments to HTTP
1708   also need to be aware of the differences because some conversions
1709   might be required.
1710
1711A.1.  MIME-Version
1712
1713   HTTP is not a MIME-compliant protocol.  However, HTTP/1.1 messages
1714   MAY include a single MIME-Version general-header field to indicate
1715   what version of the MIME protocol was used to construct the message.
1716   Use of the MIME-Version header field indicates that the message is in
1717   full compliance with the MIME protocol (as defined in [RFC2045]).
1718   Proxies/gateways are responsible for ensuring full compliance (where
1719   possible) when exporting HTTP messages to strict MIME environments.
1720
1721     MIME-Version   = "MIME-Version" ":" OWS MIME-Version-v
1722     MIME-Version-v = 1*DIGIT "." 1*DIGIT
1723
1724   MIME version "1.0" is the default for use in HTTP/1.1.  However,
1725   HTTP/1.1 message parsing and semantics are defined by this document
1726   and not the MIME specification.
1727
1728A.2.  Conversion to Canonical Form
1729
1730   [RFC2045] requires that an Internet mail entity be converted to
1731   canonical form prior to being transferred, as described in Section 4
1732
1733
1734
1735Fielding, et al.       Expires September 10, 2009              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 3                  March 2009
1738
1739
1740   of [RFC2049].  Section 2.3.1 of this document describes the forms
1741   allowed for subtypes of the "text" media type when transmitted over
1742   HTTP.  [RFC2046] requires that content with a type of "text"
1743   represent line breaks as CRLF and forbids the use of CR or LF outside
1744   of line break sequences.  HTTP allows CRLF, bare CR, and bare LF to
1745   indicate a line break within text content when a message is
1746   transmitted over HTTP.
1747
1748   Where it is possible, a proxy or gateway from HTTP to a strict MIME
1749   environment SHOULD translate all line breaks within the text media
1750   types described in Section 2.3.1 of this document to the RFC 2049
1751   canonical form of CRLF.  Note, however, that this might be
1752   complicated by the presence of a Content-Encoding and by the fact
1753   that HTTP allows the use of some character sets which do not use
1754   octets 13 and 10 to represent CR and LF, as is the case for some
1755   multi-byte character sets.
1756
1757   Implementors should note that conversion will break any cryptographic
1758   checksums applied to the original content unless the original content
1759   is already in canonical form.  Therefore, the canonical form is
1760   recommended for any content that uses such checksums in HTTP.
1761
1762A.3.  Conversion of Date Formats
1763
1764   HTTP/1.1 uses a restricted set of date formats (Section 3.2.1 of
1765   [Part1]) to simplify the process of date comparison.  Proxies and
1766   gateways from other protocols SHOULD ensure that any Date header
1767   field present in a message conforms to one of the HTTP/1.1 formats
1768   and rewrite the date if necessary.
1769
1770A.4.  Introduction of Content-Encoding
1771
1772   RFC 2045 does not include any concept equivalent to HTTP/1.1's
1773   Content-Encoding header field.  Since this acts as a modifier on the
1774   media type, proxies and gateways from HTTP to MIME-compliant
1775   protocols MUST either change the value of the Content-Type header
1776   field or decode the entity-body before forwarding the message.  (Some
1777   experimental applications of Content-Type for Internet mail have used
1778   a media-type parameter of ";conversions=<content-coding>" to perform
1779   a function equivalent to Content-Encoding.  However, this parameter
1780   is not part of RFC 2045).
1781
1782A.5.  No Content-Transfer-Encoding
1783
1784   HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
1785   Proxies and gateways from MIME-compliant protocols to HTTP MUST
1786   remove any Content-Transfer-Encoding prior to delivering the response
1787   message to an HTTP client.
1788
1789
1790
1791Fielding, et al.       Expires September 10, 2009              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 3                  March 2009
1794
1795
1796   Proxies and gateways from HTTP to MIME-compliant protocols are
1797   responsible for ensuring that the message is in the correct format
1798   and encoding for safe transport on that protocol, where "safe
1799   transport" is defined by the limitations of the protocol being used.
1800   Such a proxy or gateway SHOULD label the data with an appropriate
1801   Content-Transfer-Encoding if doing so will improve the likelihood of
1802   safe transport over the destination protocol.
1803
1804A.6.  Introduction of Transfer-Encoding
1805
1806   HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7
1807   of [Part1]).  Proxies/gateways MUST remove any transfer-coding prior
1808   to forwarding a message via a MIME-compliant protocol.
1809
1810A.7.  MHTML and Line Length Limitations
1811
1812   HTTP implementations which share code with MHTML [RFC2557]
1813   implementations need to be aware of MIME line length limitations.
1814   Since HTTP does not have this limitation, HTTP does not fold long
1815   lines.  MHTML messages being transported by HTTP follow all
1816   conventions of MHTML, including line length limitations and folding,
1817   canonicalization, etc., since HTTP transports all message-bodies as
1818   payload (see Section 2.3.2) and does not interpret the content or any
1819   MIME header lines that might be contained therein.
1820
1821
1822Appendix B.  Additional Features
1823
1824   [RFC1945] and [RFC2068] document protocol elements used by some
1825   existing HTTP implementations, but not consistently and correctly
1826   across most HTTP/1.1 applications.  Implementors are advised to be
1827   aware of these features, but cannot rely upon their presence in, or
1828   interoperability with, other HTTP/1.1 applications.  Some of these
1829   describe proposed experimental features, and some describe features
1830   that experimental deployment found lacking that are now addressed in
1831   the base HTTP/1.1 specification.
1832
1833   A number of other headers, such as Content-Disposition and Title,
1834   from SMTP and MIME are also often implemented (see [RFC2076]).
1835
1836B.1.  Content-Disposition
1837
1838   The Content-Disposition response-header field has been proposed as a
1839   means for the origin server to suggest a default filename if the user
1840   requests that the content is saved to a file.  This usage is derived
1841   from the definition of Content-Disposition in [RFC2183].
1842
1843
1844
1845
1846
1847Fielding, et al.       Expires September 10, 2009              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 3                  March 2009
1850
1851
1852     content-disposition = "Content-Disposition" ":" OWS
1853                           content-disposition-v
1854     content-disposition-v = disposition-type
1855                             *( OWS ";" OWS disposition-parm )
1856     disposition-type = "attachment" / disp-extension-token
1857     disposition-parm = filename-parm / disp-extension-parm
1858     filename-parm = "filename" "=" quoted-string
1859     disp-extension-token = token
1860     disp-extension-parm = token "=" ( token / quoted-string )
1861
1862   An example is
1863
1864     Content-Disposition: attachment; filename="fname.ext"
1865
1866   The receiving user agent SHOULD NOT respect any directory path
1867   information present in the filename-parm parameter, which is the only
1868   parameter believed to apply to HTTP implementations at this time.
1869   The filename SHOULD be treated as a terminal component only.
1870
1871   If this header is used in a response with the application/
1872   octet-stream content-type, the implied suggestion is that the user
1873   agent should not display the response, but directly enter a `save
1874   response as...' dialog.
1875
1876   See Section 7.2 for Content-Disposition security issues.
1877
1878
1879Appendix C.  Compatibility with Previous Versions
1880
1881C.1.  Changes from RFC 2068
1882
1883   Transfer-coding and message lengths all interact in ways that
1884   required fixing exactly when chunked encoding is used (to allow for
1885   transfer encoding that may not be self delimiting); it was important
1886   to straighten out exactly how message lengths are computed.
1887   (Section 3.2.2, see also [Part1], [Part5] and [Part6]).
1888
1889   Charset wildcarding is introduced to avoid explosion of character set
1890   names in accept headers.  (Section 5.2)
1891
1892   Content-Base was deleted from the specification: it was not
1893   implemented widely, and there is no simple, safe way to introduce it
1894   without a robust extension mechanism.  In addition, it is used in a
1895   similar, but not identical fashion in MHTML [RFC2557].
1896
1897   A content-coding of "identity" was introduced, to solve problems
1898   discovered in caching.  (Section 2.2)
1899
1900
1901
1902
1903Fielding, et al.       Expires September 10, 2009              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 3                  March 2009
1906
1907
1908   The Alternates, Content-Version, Derived-From, Link, URI, Public and
1909   Content-Base header fields were defined in previous versions of this
1910   specification, but not commonly implemented.  See Section 19.6.2 of
1911   [RFC2068].
1912
1913C.2.  Changes from RFC 2616
1914
1915   Clarify contexts that charset is used in.  (Section 2.1)
1916
1917   Remove reference to non-existant identity transfer-coding value
1918   tokens.  (Appendix A.5)
1919
1920
1921Appendix D.  Collected ABNF
1922
1923   Accept = "Accept:" OWS Accept-v
1924   Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v
1925   Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
1926    qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
1927    qvalue ] ] )
1928   Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v
1929   Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] )
1930    ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
1931   Accept-Language = "Accept-Language:" OWS Accept-Language-v
1932   Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q="
1933    qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
1934    ] )
1935   Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1936    OWS media-range [ accept-params ] ] ) ]
1937
1938   Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v
1939   Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS
1940    content-coding ] )
1941   Content-Language = "Content-Language:" OWS Content-Language-v
1942   Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
1943    language-tag ] )
1944   Content-Length = <Content-Length, defined in [Part1], Section 8.2>
1945   Content-Location = "Content-Location:" OWS Content-Location-v
1946   Content-Location-v = absolute-URI / partial-URI
1947   Content-MD5 = "Content-MD5:" OWS Content-MD5-v
1948   Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
1949   Content-Range = <Content-Range, defined in [Part5], Section 5.2>
1950   Content-Type = "Content-Type:" OWS Content-Type-v
1951   Content-Type-v = media-type
1952
1953   Expires = <Expires, defined in [Part6], Section 3.3>
1954
1955   Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
1956
1957
1958
1959Fielding, et al.       Expires September 10, 2009              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 3                  March 2009
1962
1963
1964   MIME-Version = "MIME-Version:" OWS MIME-Version-v
1965   MIME-Version-v = 1*DIGIT "." 1*DIGIT
1966
1967   OWS = <OWS, defined in [Part1], Section 1.2.2>
1968
1969   absolute-URI = <absolute-URI, defined in [Part1], Section 2.1>
1970   accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
1971   accept-params = OWS ";" OWS "q=" qvalue *accept-ext
1972   attribute = token
1973
1974   charset = token
1975   codings = ( content-coding / "*" )
1976   content-coding = token
1977   content-disposition = "Content-Disposition:" OWS
1978    content-disposition-v
1979   content-disposition-v = disposition-type *( OWS ";" OWS
1980    disposition-parm )
1981
1982   disp-extension-parm = token "=" ( token / quoted-string )
1983   disp-extension-token = token
1984   disposition-parm = filename-parm / disp-extension-parm
1985   disposition-type = "attachment" / disp-extension-token
1986
1987   entity-body = *OCTET
1988   entity-header = Content-Encoding / Content-Language / Content-Length
1989    / Content-Location / Content-MD5 / Content-Range / Content-Type /
1990    Expires / Last-Modified / extension-header
1991   extension-header = message-header
1992
1993   filename-parm = "filename=" quoted-string
1994
1995   language-range = <language-range, defined in [RFC4647], Section 2.1>
1996   language-tag = primary-tag *( "-" subtag )
1997
1998   media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
1999    ";" OWS parameter )
2000   media-type = type "/" subtype *( OWS ";" OWS parameter )
2001   message-header = <message-header, defined in [Part1], Section 4.2>
2002
2003   parameter = attribute "=" value
2004   partial-URI = <partial-URI, defined in [Part1], Section 2.1>
2005   primary-tag = 1*8ALPHA
2006
2007   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
2008   qvalue = <qvalue, defined in [Part1], Section 3.5>
2009
2010   subtag = 1*8ALPHA
2011   subtype = token
2012
2013
2014
2015Fielding, et al.       Expires September 10, 2009              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 3                  March 2009
2018
2019
2020   token = <token, defined in [Part1], Section 1.2.2>
2021   type = token
2022
2023   value = token / quoted-string
2024
2025
2026
2027   ABNF diagnostics:
2028
2029   ; Accept defined but not used
2030   ; Accept-Charset defined but not used
2031   ; Accept-Encoding defined but not used
2032   ; Accept-Language defined but not used
2033   ; MIME-Version defined but not used
2034   ; content-disposition defined but not used
2035   ; entity-body defined but not used
2036   ; entity-header defined but not used
2037
2038
2039Appendix E.  Change Log (to be removed by RFC Editor before publication)
2040
2041E.1.  Since RFC2616
2042
2043   Extracted relevant partitions from [RFC2616].
2044
2045E.2.  Since draft-ietf-httpbis-p3-payload-00
2046
2047   Closed issues:
2048
2049   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
2050      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
2051
2052   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification
2053      regarding quoting of charset values"
2054      (<http://purl.org/NET/http-errata#charactersets>)
2055
2056   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
2057      'identity' token references"
2058      (<http://purl.org/NET/http-errata#identity>)
2059
2060   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
2061      Encoding BNF"
2062
2063   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
2064      Informative references"
2065
2066   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
2067      references"
2068
2069
2070
2071Fielding, et al.       Expires September 10, 2009              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 3                  March 2009
2074
2075
2076   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
2077      RFC4288"
2078
2079   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
2080      references"
2081
2082   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
2083      Reference"
2084
2085   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
2086      References Normative"
2087
2088   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
2089      to-date references"
2090
2091E.3.  Since draft-ietf-httpbis-p3-payload-01
2092
2093   Ongoing work on ABNF conversion
2094   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2095
2096   o  Add explicit references to BNF syntax and rules imported from
2097      other parts of the specification.
2098
2099E.4.  Since draft-ietf-httpbis-p3-payload-02
2100
2101   Closed issues:
2102
2103   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
2104      Charsets"
2105
2106   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
2107      "Classification for Allow header"
2108
2109   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
2110      default for qvalue in description of Accept-Encoding"
2111
2112   Ongoing work on IANA Message Header Registration
2113   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
2114
2115   o  Reference RFC 3984, and update header registrations for headers
2116      defined in this document.
2117
2118E.5.  Since draft-ietf-httpbis-p3-payload-03
2119
2120   Closed issues:
2121
2122   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
2123      Charsets"
2124
2125
2126
2127Fielding, et al.       Expires September 10, 2009              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 3                  March 2009
2130
2131
2132   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
2133      matching (Accept-Language) vs RFC4647"
2134
2135   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has
2136      been replaced by RFC2183"
2137
2138   Other changes:
2139
2140   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
2141      References Normative" -- rephrase the annotation and reference
2142      [BCP97].
2143
2144E.6.  Since draft-ietf-httpbis-p3-payload-04
2145
2146   Closed issues:
2147
2148   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
2149      updated by RFC 5322"
2150
2151   Ongoing work on ABNF conversion
2152   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2153
2154   o  Use "/" instead of "|" for alternatives.
2155
2156   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2157      whitespace ("OWS") and required whitespace ("RWS").
2158
2159   o  Rewrite ABNFs to spell out whitespace rules, factor out header
2160      value format definitions.
2161
2162E.7.  Since draft-ietf-httpbis-p3-payload-05
2163
2164   Closed issues:
2165
2166   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
2167      "Differences Between HTTP Entities and RFC 2045 Entities"?"
2168
2169   Final work on ABNF conversion
2170   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2171
2172   o  Add appendix containing collected and expanded ABNF, reorganize
2173      ABNF introduction.
2174
2175   Other changes:
2176
2177   o  Move definition of quality values into Part 1.
2178
2179
2180
2181
2182
2183Fielding, et al.       Expires September 10, 2009              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 3                  March 2009
2186
2187
2188Index
2189
2190   A
2191      Accept header  16
2192      Accept-Charset header  18
2193      Accept-Encoding header  19
2194      Accept-Language header  20
2195      Alternates header  35
2196
2197   C
2198      compress  8
2199      Content-Base header  35
2200      Content-Disposition header  33
2201      Content-Encoding header  22
2202      Content-Language header  23
2203      Content-Location header  23
2204      Content-MD5 header  24
2205      Content-Type header  26
2206      Content-Version header  35
2207
2208   D
2209      deflate  8
2210      Derived-From header  35
2211
2212   G
2213      Grammar
2214         Accept  16
2215         Accept-Charset  18
2216         Accept-Charset-v  18
2217         Accept-Encoding  19
2218         Accept-Encoding-v  19
2219         accept-ext  16
2220         Accept-Language  20
2221         Accept-Language-v  20
2222         accept-params  16
2223         Accept-v  16
2224         attribute  9
2225         charset  7
2226         codings  19
2227         content-coding  8
2228         content-disposition  34
2229         content-disposition-v  34
2230         Content-Encoding  22
2231         Content-Encoding-v  22
2232         Content-Language  23
2233         Content-Language-v  23
2234         Content-Location  24
2235         Content-Location-v  24
2236
2237
2238
2239Fielding, et al.       Expires September 10, 2009              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 3                  March 2009
2242
2243
2244         Content-MD5  24
2245         Content-MD5-v  24
2246         Content-Type  26
2247         Content-Type-v  26
2248         disp-extension-parm  34
2249         disp-extension-token  34
2250         disposition-parm  34
2251         disposition-type  34
2252         entity-body  12
2253         entity-header  12
2254         extension-header  12
2255         filename-parm  34
2256         language-range  20
2257         language-tag  11
2258         media-range  16
2259         media-type  9
2260         MIME-Version  31
2261         MIME-Version-v  31
2262         parameter  9
2263         primary-tag  11
2264         subtag  11
2265         subtype  9
2266         type  9
2267         value  9
2268      gzip  8
2269
2270   H
2271      Headers
2272         Accept  16
2273         Accept-Charset  18
2274         Accept-Encoding  19
2275         Accept-Language  20
2276         Alternate  35
2277         Content-Base  35
2278         Content-Disposition  33
2279         Content-Encoding  22
2280         Content-Language  23
2281         Content-Location  23
2282         Content-MD5  24
2283         Content-Type  26
2284         Content-Version  35
2285         Derived-From  35
2286         Link  35
2287         MIME-Version  31
2288         Public  35
2289         URI  35
2290
2291   I
2292
2293
2294
2295Fielding, et al.       Expires September 10, 2009              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 3                  March 2009
2298
2299
2300      identity  8
2301
2302   L
2303      Link header  35
2304
2305   M
2306      MIME-Version header  31
2307
2308   P
2309      Public header  35
2310
2311   U
2312      URI header  35
2313
2314
2315Authors' Addresses
2316
2317   Roy T. Fielding (editor)
2318   Day Software
2319   23 Corporate Plaza DR, Suite 280
2320   Newport Beach, CA  92660
2321   USA
2322
2323   Phone: +1-949-706-5300
2324   Fax:   +1-949-706-5305
2325   Email: fielding@gbiv.com
2326   URI:   http://roy.gbiv.com/
2327
2328
2329   Jim Gettys
2330   One Laptop per Child
2331   21 Oak Knoll Road
2332   Carlisle, MA  01741
2333   USA
2334
2335   Email: jg@laptop.org
2336   URI:   http://www.laptop.org/
2337
2338
2339   Jeffrey C. Mogul
2340   Hewlett-Packard Company
2341   HP Labs, Large Scale Systems Group
2342   1501 Page Mill Road, MS 1177
2343   Palo Alto, CA  94304
2344   USA
2345
2346   Email: JeffMogul@acm.org
2347
2348
2349
2350
2351Fielding, et al.       Expires September 10, 2009              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 3                  March 2009
2354
2355
2356   Henrik Frystyk Nielsen
2357   Microsoft Corporation
2358   1 Microsoft Way
2359   Redmond, WA  98052
2360   USA
2361
2362   Email: henrikn@microsoft.com
2363
2364
2365   Larry Masinter
2366   Adobe Systems, Incorporated
2367   345 Park Ave
2368   San Jose, CA  95110
2369   USA
2370
2371   Email: LMM@acm.org
2372   URI:   http://larry.masinter.net/
2373
2374
2375   Paul J. Leach
2376   Microsoft Corporation
2377   1 Microsoft Way
2378   Redmond, WA  98052
2379
2380   Email: paulle@microsoft.com
2381
2382
2383   Tim Berners-Lee
2384   World Wide Web Consortium
2385   MIT Computer Science and Artificial Intelligence Laboratory
2386   The Stata Center, Building 32
2387   32 Vassar Street
2388   Cambridge, MA  02139
2389   USA
2390
2391   Email: timbl@w3.org
2392   URI:   http://www.w3.org/People/Berners-Lee/
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407Fielding, et al.       Expires September 10, 2009              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 3                  March 2009
2410
2411
2412   Yves Lafon (editor)
2413   World Wide Web Consortium
2414   W3C / ERCIM
2415   2004, rte des Lucioles
2416   Sophia-Antipolis, AM  06902
2417   France
2418
2419   Email: ylafon@w3.org
2420   URI:   http://www.raubacapeu.net/people/yves/
2421
2422
2423   Julian F. Reschke (editor)
2424   greenbytes GmbH
2425   Hafenweg 16
2426   Muenster, NW  48155
2427   Germany
2428
2429   Phone: +49 251 2807760
2430   Fax:   +49 251 2807761
2431   Email: julian.reschke@greenbytes.de
2432   URI:   http://greenbytes.de/tech/webdav/
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463Fielding, et al.       Expires September 10, 2009              [Page 44]
2464
Note: See TracBrowser for help on using the repository browser.