source: draft-ietf-httpbis/11/draft-ietf-httpbis-p3-payload-11.txt @ 973

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

prepare publication of -11 drafts on 2010-08-04.

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