source: draft-ietf-httpbis/04/draft-ietf-httpbis-p3-payload-04.txt @ 315

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

prepare publication of draft -04, also remove unneeded cookie drafts

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