source: draft-ietf-httpbis/01/draft-ietf-httpbis-p3-payload-01.txt @ 377

Last change on this file since 377 was 166, checked in by fielding@…, 12 years ago

generated draft 01

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