source: draft-ietf-httpbis/10/draft-ietf-httpbis-p3-payload-10.txt @ 956

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

forgot to set eol-style

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