idnits 2.17.1 draft-ietf-httpbis-p3-payload-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1902. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2008) is 5633 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-05 ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: May 20, 2009 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 November 16, 2008 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-05 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 20, 2009. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 3 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines 58 HTTP message content, metadata, and content negotiation. 60 Editorial Note (To be removed by RFC Editor) 62 Discussion of this draft should take place on the HTTPBIS working 63 group mailing list (ietf-http-wg@w3.org). The current issues list is 64 at and related 65 documents (including fancy diffs) can be found at 66 . 68 The changes in this draft are summarized in Appendix D.6. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Notational Conventions and Generic Grammar . . . . . . . . . . 5 75 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 78 3.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 79 3.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 81 3.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 82 3.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 11 83 3.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 84 4. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 86 4.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12 87 4.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 4.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 89 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 90 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 91 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 92 5.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 93 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 94 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 96 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 97 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 98 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 99 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 100 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 101 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 102 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 7.1. Message Header Registration . . . . . . . . . . . . . . . 26 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 106 8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 107 8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 111 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 112 Appendix A. Differences Between HTTP Entities and RFC 2045 113 Entities . . . . . . . . . . . . . . . . . . . . . . 31 114 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 115 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 116 A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 32 117 A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 118 A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 119 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 33 120 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 121 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 122 Appendix C. Compatibility with Previous Versions . . . . . . . . 34 123 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34 124 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 125 Appendix D. Change Log (to be removed by RFC Editor before 126 publication) . . . . . . . . . . . . . . . . . . . . 35 127 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 35 128 D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 129 D.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 130 D.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 131 D.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 132 D.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 133 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 135 Intellectual Property and Copyright Statements . . . . . . . . . . 43 137 1. Introduction 139 This document defines HTTP/1.1 message payloads (a.k.a., content), 140 the associated metadata header fields that define how the payload is 141 intended to be interpreted by a recipient, the request header fields 142 that may influence content selection, and the various selection 143 algorithms that are collectively referred to as HTTP content 144 negotiation. 146 This document is currently disorganized in order to minimize the 147 changes between drafts and enable reviewers to see the smaller errata 148 changes. The next draft will reorganize the sections to better 149 reflect the content. In particular, the sections on entities will be 150 renamed payload and moved to the first half of the document, while 151 the sections on content negotiation and associated request header 152 fields will be moved to the second half. The current mess reflects 153 how widely dispersed these topics and associated requirements had 154 become in [RFC2616]. 156 1.1. Requirements 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 An implementation is not compliant if it fails to satisfy one or more 163 of the MUST or REQUIRED level requirements for the protocols it 164 implements. An implementation that satisfies all the MUST or 165 REQUIRED level and all the SHOULD level requirements for its 166 protocols is said to be "unconditionally compliant"; one that 167 satisfies all the MUST level requirements but not all the SHOULD 168 level requirements for its protocols is said to be "conditionally 169 compliant." 171 2. Notational Conventions and Generic Grammar 173 This specification uses the ABNF syntax defined in Section 2.1 of 174 [Part1] and the core rules defined in Section 2.2 of [Part1]: 176 ALPHA = 177 DIGIT = 178 OCTET = 180 quoted-string = 181 token = 182 OWS = 184 The ABNF rules below are defined in other parts: 186 absolute-URI = 187 Content-Length = 188 relativeURI = 189 message-header = 191 Last-Modified = 193 Content-Range = 195 Expires = 197 3. Protocol Parameters 199 3.1. Character Sets 201 HTTP uses the same definition of the term "character set" as that 202 described for MIME: 204 The term "character set" is used in this document to refer to a 205 method used with one or more tables to convert a sequence of octets 206 into a sequence of characters. Note that unconditional conversion in 207 the other direction is not required, in that not all characters may 208 be available in a given character set and a character set may provide 209 more than one sequence of octets to represent a particular character. 210 This definition is intended to allow various kinds of character 211 encoding, from simple single-table mappings such as US-ASCII to 212 complex table switching methods such as those that use ISO-2022's 213 techniques. However, the definition associated with a MIME character 214 set name MUST fully specify the mapping to be performed from octets 215 to characters. In particular, use of external profiling information 216 to determine the exact mapping is not permitted. 218 Note: This use of the term "character set" is more commonly 219 referred to as a "character encoding." However, since HTTP and 220 MIME share the same registry, it is important that the terminology 221 also be shared. 223 HTTP character sets are identified by case-insensitive tokens. The 224 complete set of tokens is defined by the IANA Character Set registry 225 (). 227 charset = token 229 Although HTTP allows an arbitrary token to be used as a charset 230 value, any token that has a predefined value within the IANA 231 Character Set registry MUST represent the character set defined by 232 that registry. Applications SHOULD limit their use of character sets 233 to those defined by the IANA registry. 235 HTTP uses charset in two contexts: within an Accept-Charset request 236 header (in which the charset value is an unquoted token) and as the 237 value of a parameter in a Content-Type header (within a request or 238 response), in which case the parameter value of the charset parameter 239 may be quoted. 241 Implementors should be aware of IETF character set requirements 242 [RFC3629] [RFC2277]. 244 3.1.1. Missing Charset 246 Some HTTP/1.0 software has interpreted a Content-Type header without 247 charset parameter incorrectly to mean "recipient should guess." 248 Senders wishing to defeat this behavior MAY include a charset 249 parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and 250 SHOULD do so when it is known that it will not confuse the recipient. 252 Unfortunately, some older HTTP/1.0 clients did not deal properly with 253 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 254 charset label provided by the sender; and those user agents that have 255 a provision to "guess" a charset MUST use the charset from the 256 content-type field if they support that charset, rather than the 257 recipient's preference, when initially displaying a document. See 258 Section 3.3.1. 260 3.2. Content Codings 262 Content coding values indicate an encoding transformation that has 263 been or can be applied to an entity. Content codings are primarily 264 used to allow a document to be compressed or otherwise usefully 265 transformed without losing the identity of its underlying media type 266 and without loss of information. Frequently, the entity is stored in 267 coded form, transmitted directly, and only decoded by the recipient. 269 content-coding = token 271 All content-coding values are case-insensitive. HTTP/1.1 uses 272 content-coding values in the Accept-Encoding (Section 6.3) and 273 Content-Encoding (Section 6.5) header fields. Although the value 274 describes the content-coding, what is more important is that it 275 indicates what decoding mechanism will be required to remove the 276 encoding. 278 The Internet Assigned Numbers Authority (IANA) acts as a registry for 279 content-coding value tokens. Initially, the registry contains the 280 following tokens: 282 gzip 284 An encoding format produced by the file compression program "gzip" 285 (GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv 286 coding (LZ77) with a 32 bit CRC. 288 compress 290 The encoding format produced by the common UNIX file compression 291 program "compress". This format is an adaptive Lempel-Ziv-Welch 292 coding (LZW). 294 Use of program names for the identification of encoding formats is 295 not desirable and is discouraged for future encodings. Their use 296 here is representative of historical practice, not good design. 297 For compatibility with previous implementations of HTTP, 298 applications SHOULD consider "x-gzip" and "x-compress" to be 299 equivalent to "gzip" and "compress" respectively. 301 deflate 303 The "zlib" format defined in [RFC1950] in combination with the 304 "deflate" compression mechanism described in [RFC1951]. 306 identity 308 The default (identity) encoding; the use of no transformation 309 whatsoever. This content-coding is used only in the Accept- 310 Encoding header, and SHOULD NOT be used in the Content-Encoding 311 header. 313 New content-coding value tokens SHOULD be registered; to allow 314 interoperability between clients and servers, specifications of the 315 content coding algorithms needed to implement a new value SHOULD be 316 publicly available and adequate for independent implementation, and 317 conform to the purpose of content coding defined in this section. 319 3.3. Media Types 321 HTTP uses Internet Media Types [RFC2046] in the Content-Type 322 (Section 6.9) and Accept (Section 6.1) header fields in order to 323 provide open and extensible data typing and type negotiation. 325 media-type = type "/" subtype *( OWS ";" OWS parameter ) 326 type = token 327 subtype = token 329 Parameters MAY follow the type/subtype in the form of attribute/value 330 pairs. 332 parameter = attribute "=" value 333 attribute = token 334 value = token / quoted-string 336 The type, subtype, and parameter attribute names are case- 337 insensitive. Parameter values might or might not be case-sensitive, 338 depending on the semantics of the parameter name. The presence or 339 absence of a parameter might be significant to the processing of a 340 media-type, depending on its definition within the media type 341 registry. 343 A parameter value that matches the token production may be 344 transmitted as either a token or within a quoted-string. The quoted 345 and unquoted values are equivalent. 347 Note that some older HTTP applications do not recognize media type 348 parameters. When sending data to older HTTP applications, 349 implementations SHOULD only use media type parameters when they are 350 required by that type/subtype definition. 352 Media-type values are registered with the Internet Assigned Number 353 Authority (IANA). The media type registration process is outlined in 354 [RFC4288]. Use of non-registered media types is discouraged. 356 3.3.1. Canonicalization and Text Defaults 358 Internet media types are registered with a canonical form. An 359 entity-body transferred via HTTP messages MUST be represented in the 360 appropriate canonical form prior to its transmission except for 361 "text" types, as defined in the next paragraph. 363 When in canonical form, media subtypes of the "text" type use CRLF as 364 the text line break. HTTP relaxes this requirement and allows the 365 transport of text media with plain CR or LF alone representing a line 366 break when it is done consistently for an entire entity-body. HTTP 367 applications MUST accept CRLF, bare CR, and bare LF as being 368 representative of a line break in text media received via HTTP. In 369 addition, if the text is represented in a character set that does not 370 use octets 13 and 10 for CR and LF respectively, as is the case for 371 some multi-byte character sets, HTTP allows the use of whatever octet 372 sequences are defined by that character set to represent the 373 equivalent of CR and LF for line breaks. This flexibility regarding 374 line breaks applies only to text media in the entity-body; a bare CR 375 or LF MUST NOT be substituted for CRLF within any of the HTTP control 376 structures (such as header fields and multipart boundaries). 378 If an entity-body is encoded with a content-coding, the underlying 379 data MUST be in a form defined above prior to being encoded. 381 The "charset" parameter is used with some media types to define the 382 character set (Section 3.1) of the data. When no explicit charset 383 parameter is provided by the sender, media subtypes of the "text" 384 type are defined to have a default charset value of "ISO-8859-1" when 385 received via HTTP. Data in character sets other than "ISO-8859-1" or 386 its subsets MUST be labeled with an appropriate charset value. See 387 Section 3.1.1 for compatibility problems. 389 3.3.2. Multipart Types 391 MIME provides for a number of "multipart" types -- encapsulations of 392 one or more entities within a single message-body. All multipart 393 types share a common syntax, as defined in Section 5.1.1 of 394 [RFC2046], and MUST include a boundary parameter as part of the media 395 type value. The message body is itself a protocol element and MUST 396 therefore use only CRLF to represent line breaks between body-parts. 397 Unlike in RFC 2046, the epilogue of any multipart message MUST be 398 empty; HTTP applications MUST NOT transmit the epilogue (even if the 399 original multipart contains an epilogue). These restrictions exist 400 in order to preserve the self-delimiting nature of a multipart 401 message-body, wherein the "end" of the message-body is indicated by 402 the ending multipart boundary. 404 In general, HTTP treats a multipart message-body no differently than 405 any other media type: strictly as payload. The one exception is the 406 "multipart/byteranges" type (Appendix A of [Part5]) when it appears 407 in a 206 (Partial Content) response. In all other cases, an HTTP 408 user agent SHOULD follow the same or similar behavior as a MIME user 409 agent would upon receipt of a multipart type. The MIME header fields 410 within each body-part of a multipart message-body do not have any 411 significance to HTTP beyond that defined by their MIME semantics. 413 In general, an HTTP user agent SHOULD follow the same or similar 414 behavior as a MIME user agent would upon receipt of a multipart type. 415 If an application receives an unrecognized multipart subtype, the 416 application MUST treat it as being equivalent to "multipart/mixed". 418 Note: The "multipart/form-data" type has been specifically defined 419 for carrying form data suitable for processing via the POST 420 request method, as described in [RFC2388]. 422 3.4. Quality Values 424 HTTP content negotiation (Section 5) uses short "floating point" 425 numbers to indicate the relative importance ("weight") of various 426 negotiable parameters. A weight is normalized to a real number in 427 the range 0 through 1, where 0 is the minimum and 1 the maximum 428 value. If a parameter has a quality value of 0, then content with 429 this parameter is `not acceptable' for the client. HTTP/1.1 430 applications MUST NOT generate more than three digits after the 431 decimal point. User configuration of these values SHOULD also be 432 limited in this fashion. 434 qvalue = ( "0" [ "." 0*3DIGIT ] ) 435 / ( "1" [ "." 0*3("0") ] ) 437 "Quality values" is a misnomer, since these values merely represent 438 relative degradation in desired quality. 440 3.5. Language Tags 442 A language tag identifies a natural language spoken, written, or 443 otherwise conveyed by human beings for communication of information 444 to other human beings. Computer languages are explicitly excluded. 445 HTTP uses language tags within the Accept-Language and Content- 446 Language fields. 448 The syntax and registry of HTTP language tags is the same as that 449 defined by [RFC1766]. In summary, a language tag is composed of 1 or 450 more parts: A primary language tag and a possibly empty series of 451 subtags: 453 language-tag = primary-tag *( "-" subtag ) 454 primary-tag = 1*8ALPHA 455 subtag = 1*8ALPHA 457 White space is not allowed within the tag and all tags are case- 458 insensitive. The name space of language tags is administered by the 459 IANA. Example tags include: 461 en, en-US, en-cockney, i-cherokee, x-pig-latin 463 where any two-letter primary-tag is an ISO-639 language abbreviation 464 and any two-letter initial subtag is an ISO-3166 country code. (The 465 last three tags above are not registered tags; all but the last are 466 examples of tags which could be registered in future.) 468 4. Entity 470 Request and Response messages MAY transfer an entity if not otherwise 471 restricted by the request method or response status code. An entity 472 consists of entity-header fields and an entity-body, although some 473 responses will only include the entity-headers. 475 In this section, both sender and recipient refer to either the client 476 or the server, depending on who sends and who receives the entity. 478 4.1. Entity Header Fields 480 Entity-header fields define metainformation about the entity-body or, 481 if no body is present, about the resource identified by the request. 483 entity-header = Content-Encoding ; Section 6.5 484 / Content-Language ; Section 6.6 485 / Content-Length ; [Part1], Section 8.2 486 / Content-Location ; Section 6.7 487 / Content-MD5 ; Section 6.8 488 / Content-Range ; [Part5], Section 6.2 489 / Content-Type ; Section 6.9 490 / Expires ; [Part6], Section 16.3 491 / Last-Modified ; [Part4], Section 7.6 492 / extension-header 494 extension-header = message-header 496 The extension-header mechanism allows additional entity-header fields 497 to be defined without changing the protocol, but these fields cannot 498 be assumed to be recognizable by the recipient. Unrecognized header 499 fields SHOULD be ignored by the recipient and MUST be forwarded by 500 transparent proxies. 502 4.2. Entity Body 504 The entity-body (if any) sent with an HTTP request or response is in 505 a format and encoding defined by the entity-header fields. 507 entity-body = *OCTET 509 An entity-body is only present in a message when a message-body is 510 present, as described in Section 4.3 of [Part1]. The entity-body is 511 obtained from the message-body by decoding any Transfer-Encoding that 512 might have been applied to ensure safe and proper transfer of the 513 message. 515 4.2.1. Type 517 When an entity-body is included with a message, the data type of that 518 body is determined via the header fields Content-Type and Content- 519 Encoding. These define a two-layer, ordered encoding model: 521 entity-body := Content-Encoding( Content-Type( data ) ) 523 Content-Type specifies the media type of the underlying data. 524 Content-Encoding may be used to indicate any additional content 525 codings applied to the data, usually for the purpose of data 526 compression, that are a property of the requested resource. There is 527 no default encoding. 529 Any HTTP/1.1 message containing an entity-body SHOULD include a 530 Content-Type header field defining the media type of that body. If 531 and only if the media type is not given by a Content-Type field, the 532 recipient MAY attempt to guess the media type via inspection of its 533 content and/or the name extension(s) of the URI used to identify the 534 resource. If the media type remains unknown, the recipient SHOULD 535 treat it as type "application/octet-stream". 537 4.2.2. Entity Length 539 The entity-length of a message is the length of the message-body 540 before any transfer-codings have been applied. Section 4.4 of 541 [Part1] defines how the transfer-length of a message-body is 542 determined. 544 5. Content Negotiation 546 Most HTTP responses include an entity which contains information for 547 interpretation by a human user. Naturally, it is desirable to supply 548 the user with the "best available" entity corresponding to the 549 request. Unfortunately for servers and caches, not all users have 550 the same preferences for what is "best," and not all user agents are 551 equally capable of rendering all entity types. For that reason, HTTP 552 has provisions for several mechanisms for "content negotiation" -- 553 the process of selecting the best representation for a given response 554 when there are multiple representations available. 556 Note: This is not called "format negotiation" because the 557 alternate representations may be of the same media type, but use 558 different capabilities of that type, be in different languages, 559 etc. 561 Any response containing an entity-body MAY be subject to negotiation, 562 including error responses. 564 There are two kinds of content negotiation which are possible in 565 HTTP: server-driven and agent-driven negotiation. These two kinds of 566 negotiation are orthogonal and thus may be used separately or in 567 combination. One method of combination, referred to as transparent 568 negotiation, occurs when a cache uses the agent-driven negotiation 569 information provided by the origin server in order to provide server- 570 driven negotiation for subsequent requests. 572 5.1. Server-driven Negotiation 574 If the selection of the best representation for a response is made by 575 an algorithm located at the server, it is called server-driven 576 negotiation. Selection is based on the available representations of 577 the response (the dimensions over which it can vary; e.g. language, 578 content-coding, etc.) and the contents of particular header fields in 579 the request message or on other information pertaining to the request 580 (such as the network address of the client). 582 Server-driven negotiation is advantageous when the algorithm for 583 selecting from among the available representations is difficult to 584 describe to the user agent, or when the server desires to send its 585 "best guess" to the client along with the first response (hoping to 586 avoid the round-trip delay of a subsequent request if the "best 587 guess" is good enough for the user). In order to improve the 588 server's guess, the user agent MAY include request header fields 589 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 590 preferences for such a response. 592 Server-driven negotiation has disadvantages: 594 1. It is impossible for the server to accurately determine what 595 might be "best" for any given user, since that would require 596 complete knowledge of both the capabilities of the user agent and 597 the intended use for the response (e.g., does the user want to 598 view it on screen or print it on paper?). 600 2. Having the user agent describe its capabilities in every request 601 can be both very inefficient (given that only a small percentage 602 of responses have multiple representations) and a potential 603 violation of the user's privacy. 605 3. It complicates the implementation of an origin server and the 606 algorithms for generating responses to a request. 608 4. It may limit a public cache's ability to use the same response 609 for multiple user's requests. 611 HTTP/1.1 includes the following request-header fields for enabling 612 server-driven negotiation through description of user agent 613 capabilities and user preferences: Accept (Section 6.1), Accept- 614 Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language 615 (Section 6.4), and User-Agent (Section 10.9 of [Part2]). However, an 616 origin server is not limited to these dimensions and MAY vary the 617 response based on any aspect of the request, including information 618 outside the request-header fields or within extension header fields 619 not defined by this specification. 621 The Vary header field (Section 16.5 of [Part6]) can be used to 622 express the parameters the server uses to select a representation 623 that is subject to server-driven negotiation. 625 5.2. Agent-driven Negotiation 627 With agent-driven negotiation, selection of the best representation 628 for a response is performed by the user agent after receiving an 629 initial response from the origin server. Selection is based on a 630 list of the available representations of the response included within 631 the header fields or entity-body of the initial response, with each 632 representation identified by its own URI. Selection from among the 633 representations may be performed automatically (if the user agent is 634 capable of doing so) or manually by the user selecting from a 635 generated (possibly hypertext) menu. 637 Agent-driven negotiation is advantageous when the response would vary 638 over commonly-used dimensions (such as type, language, or encoding), 639 when the origin server is unable to determine a user agent's 640 capabilities from examining the request, and generally when public 641 caches are used to distribute server load and reduce network usage. 643 Agent-driven negotiation suffers from the disadvantage of needing a 644 second request to obtain the best alternate representation. This 645 second request is only efficient when caching is used. In addition, 646 this specification does not define any mechanism for supporting 647 automatic selection, though it also does not prevent any such 648 mechanism from being developed as an extension and used within 649 HTTP/1.1. 651 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) 652 status codes for enabling agent-driven negotiation when the server is 653 unwilling or unable to provide a varying response using server-driven 654 negotiation. 656 5.3. Transparent Negotiation 658 Transparent negotiation is a combination of both server-driven and 659 agent-driven negotiation. When a cache is supplied with a form of 660 the list of available representations of the response (as in agent- 661 driven negotiation) and the dimensions of variance are completely 662 understood by the cache, then the cache becomes capable of performing 663 server-driven negotiation on behalf of the origin server for 664 subsequent requests on that resource. 666 Transparent negotiation has the advantage of distributing the 667 negotiation work that would otherwise be required of the origin 668 server and also removing the second request delay of agent-driven 669 negotiation when the cache is able to correctly guess the right 670 response. 672 This specification does not define any mechanism for transparent 673 negotiation, though it also does not prevent any such mechanism from 674 being developed as an extension that could be used within HTTP/1.1. 676 6. Header Field Definitions 678 This section defines the syntax and semantics of HTTP/1.1 header 679 fields related to the payload of messages. 681 For entity-header fields, both sender and recipient refer to either 682 the client or the server, depending on who sends and who receives the 683 entity. 685 6.1. Accept 687 The request-header field "Accept" can be used to specify certain 688 media types which are acceptable for the response. Accept headers 689 can be used to indicate that the request is specifically limited to a 690 small set of desired types, as in the case of a request for an in- 691 line image. 693 Accept = "Accept" ":" OWS Accept-v 694 Accept-v = #( media-range [ accept-params ] ) 696 media-range = ( "*/*" 697 / ( type "/" "*" ) 698 / ( type "/" subtype ) 699 ) *( OWS ";" OWS parameter ) 700 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 701 accept-ext = OWS ";" OWS token 702 [ "=" ( token / quoted-string ) ] 704 The asterisk "*" character is used to group media types into ranges, 705 with "*/*" indicating all media types and "type/*" indicating all 706 subtypes of that type. The media-range MAY include media type 707 parameters that are applicable to that range. 709 Each media-range MAY be followed by one or more accept-params, 710 beginning with the "q" parameter for indicating a relative quality 711 factor. The first "q" parameter (if any) separates the media-range 712 parameter(s) from the accept-params. Quality factors allow the user 713 or user agent to indicate the relative degree of preference for that 714 media-range, using the qvalue scale from 0 to 1 (Section 3.4). The 715 default value is q=1. 717 Note: Use of the "q" parameter name to separate media type 718 parameters from Accept extension parameters is due to historical 719 practice. Although this prevents any media type parameter named 720 "q" from being used with a media range, such an event is believed 721 to be unlikely given the lack of any "q" parameters in the IANA 722 media type registry and the rare usage of any media type 723 parameters in Accept. Future media types are discouraged from 724 registering any parameter named "q". 726 The example 728 Accept: audio/*; q=0.2, audio/basic 730 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 731 type if it is the best available after an 80% mark-down in quality." 733 If no Accept header field is present, then it is assumed that the 734 client accepts all media types. If an Accept header field is 735 present, and if the server cannot send a response which is acceptable 736 according to the combined Accept field value, then the server SHOULD 737 send a 406 (Not Acceptable) response. 739 A more elaborate example is 741 Accept: text/plain; q=0.5, text/html, 742 text/x-dvi; q=0.8, text/x-c 744 Verbally, this would be interpreted as "text/html and text/x-c are 745 the preferred media types, but if they do not exist, then send the 746 text/x-dvi entity, and if that does not exist, send the text/plain 747 entity." 749 Media ranges can be overridden by more specific media ranges or 750 specific media types. If more than one media range applies to a 751 given type, the most specific reference has precedence. For example, 752 Accept: text/*, text/html, text/html;level=1, */* 754 have the following precedence: 756 1) text/html;level=1 757 2) text/html 758 3) text/* 759 4) */* 761 The media type quality factor associated with a given type is 762 determined by finding the media range with the highest precedence 763 which matches that type. For example, 765 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 766 text/html;level=2;q=0.4, */*;q=0.5 768 would cause the following values to be associated: 770 text/html;level=1 = 1 771 text/html = 0.7 772 text/plain = 0.3 773 image/jpeg = 0.5 774 text/html;level=2 = 0.4 775 text/html;level=3 = 0.7 777 Note: A user agent might be provided with a default set of quality 778 values for certain media ranges. However, unless the user agent is a 779 closed system which cannot interact with other rendering agents, this 780 default set ought to be configurable by the user. 782 6.2. Accept-Charset 784 The request-header field "Accept-Charset" can be used to indicate 785 what character sets are acceptable for the response. This field 786 allows clients capable of understanding more comprehensive or 787 special-purpose character sets to signal that capability to a server 788 which is capable of representing documents in those character sets. 790 Accept-Charset = "Accept-Charset" ":" OWS 791 Accept-Charset-v 792 Accept-Charset-v = 1#( ( charset / "*" ) 793 [ OWS ";" OWS "q=" qvalue ] ) 795 Character set values are described in Section 3.1. Each charset MAY 796 be given an associated quality value which represents the user's 797 preference for that charset. The default value is q=1. An example 798 is 799 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 801 The special value "*", if present in the Accept-Charset field, 802 matches every character set (including ISO-8859-1) which is not 803 mentioned elsewhere in the Accept-Charset field. If no "*" is 804 present in an Accept-Charset field, then all character sets not 805 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 806 which gets a quality value of 1 if not explicitly mentioned. 808 If no Accept-Charset header is present, the default is that any 809 character set is acceptable. If an Accept-Charset header is present, 810 and if the server cannot send a response which is acceptable 811 according to the Accept-Charset header, then the server SHOULD send 812 an error response with the 406 (Not Acceptable) status code, though 813 the sending of an unacceptable response is also allowed. 815 6.3. Accept-Encoding 817 The request-header field "Accept-Encoding" is similar to Accept, but 818 restricts the content-codings (Section 3.2) that are acceptable in 819 the response. 821 Accept-Encoding = "Accept-Encoding" ":" OWS 822 Accept-Encoding-v 823 Accept-Encoding-v = 824 #( codings [ OWS ";" OWS "q=" qvalue ] ) 825 codings = ( content-coding / "*" ) 827 Each codings value MAY be given an associated quality value which 828 represents the preference for that encoding. The default value is 829 q=1. 831 Examples of its use are: 833 Accept-Encoding: compress, gzip 834 Accept-Encoding: 835 Accept-Encoding: * 836 Accept-Encoding: compress;q=0.5, gzip;q=1.0 837 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 839 A server tests whether a content-coding is acceptable, according to 840 an Accept-Encoding field, using these rules: 842 1. If the content-coding is one of the content-codings listed in the 843 Accept-Encoding field, then it is acceptable, unless it is 844 accompanied by a qvalue of 0. (As defined in Section 3.4, a 845 qvalue of 0 means "not acceptable.") 847 2. The special "*" symbol in an Accept-Encoding field matches any 848 available content-coding not explicitly listed in the header 849 field. 851 3. If multiple content-codings are acceptable, then the acceptable 852 content-coding with the highest non-zero qvalue is preferred. 854 4. The "identity" content-coding is always acceptable, unless 855 specifically refused because the Accept-Encoding field includes 856 "identity;q=0", or because the field includes "*;q=0" and does 857 not explicitly include the "identity" content-coding. If the 858 Accept-Encoding field-value is empty, then only the "identity" 859 encoding is acceptable. 861 If an Accept-Encoding field is present in a request, and if the 862 server cannot send a response which is acceptable according to the 863 Accept-Encoding header, then the server SHOULD send an error response 864 with the 406 (Not Acceptable) status code. 866 If no Accept-Encoding field is present in a request, the server MAY 867 assume that the client will accept any content coding. In this case, 868 if "identity" is one of the available content-codings, then the 869 server SHOULD use the "identity" content-coding, unless it has 870 additional information that a different content-coding is meaningful 871 to the client. 873 Note: If the request does not include an Accept-Encoding field, 874 and if the "identity" content-coding is unavailable, then content- 875 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 876 "compress") are preferred; some older clients improperly display 877 messages sent with other content-codings. The server might also 878 make this decision based on information about the particular user- 879 agent or client. 881 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 882 associated with content-codings. This means that qvalues will not 883 work and are not permitted with x-gzip or x-compress. 885 6.4. Accept-Language 887 The request-header field "Accept-Language" is similar to Accept, but 888 restricts the set of natural languages that are preferred as a 889 response to the request. Language tags are defined in Section 3.5. 891 Accept-Language = "Accept-Language" ":" OWS 892 Accept-Language-v 893 Accept-Language-v = 894 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 895 language-range = 896 898 Each language-range can be given an associated quality value which 899 represents an estimate of the user's preference for the languages 900 specified by that range. The quality value defaults to "q=1". For 901 example, 903 Accept-Language: da, en-gb;q=0.8, en;q=0.7 905 would mean: "I prefer Danish, but will accept British English and 906 other types of English." 908 For matching, the "Basic Filtering" matching scheme, defined in 909 Section 3.3.1 of [RFC4647], is used: 911 A language range matches a particular language tag if, in a case- 912 insensitive comparison, it exactly equals the tag, or if it 913 exactly equals a prefix of the tag such that the first character 914 following the prefix is "-". 916 The special range "*", if present in the Accept-Language field, 917 matches every tag not matched by any other range present in the 918 Accept-Language field. 920 Note: This use of a prefix matching rule does not imply that 921 language tags are assigned to languages in such a way that it is 922 always true that if a user understands a language with a certain 923 tag, then this user will also understand all languages with tags 924 for which this tag is a prefix. The prefix rule simply allows the 925 use of prefix tags if this is the case. 927 The language quality factor assigned to a language-tag by the Accept- 928 Language field is the quality value of the longest language-range in 929 the field that matches the language-tag. If no language-range in the 930 field matches the tag, the language quality factor assigned is 0. If 931 no Accept-Language header is present in the request, the server 932 SHOULD assume that all languages are equally acceptable. If an 933 Accept-Language header is present, then all languages which are 934 assigned a quality factor greater than 0 are acceptable. 936 It might be contrary to the privacy expectations of the user to send 937 an Accept-Language header with the complete linguistic preferences of 938 the user in every request. For a discussion of this issue, see 939 Section 8.1. 941 As intelligibility is highly dependent on the individual user, it is 942 recommended that client applications make the choice of linguistic 943 preference available to the user. If the choice is not made 944 available, then the Accept-Language header field MUST NOT be given in 945 the request. 947 Note: When making the choice of linguistic preference available to 948 the user, we remind implementors of the fact that users are not 949 familiar with the details of language matching as described above, 950 and should provide appropriate guidance. As an example, users 951 might assume that on selecting "en-gb", they will be served any 952 kind of English document if British English is not available. A 953 user agent might suggest in such a case to add "en" to get the 954 best matching behavior. 956 6.5. Content-Encoding 958 The entity-header field "Content-Encoding" is used as a modifier to 959 the media-type. When present, its value indicates what additional 960 content codings have been applied to the entity-body, and thus what 961 decoding mechanisms must be applied in order to obtain the media-type 962 referenced by the Content-Type header field. Content-Encoding is 963 primarily used to allow a document to be compressed without losing 964 the identity of its underlying media type. 966 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 967 Content-Encoding-v = 1#content-coding 969 Content codings are defined in Section 3.2. An example of its use is 971 Content-Encoding: gzip 973 The content-coding is a characteristic of the entity identified by 974 the Request-URI. Typically, the entity-body is stored with this 975 encoding and is only decoded before rendering or analogous usage. 976 However, a non-transparent proxy MAY modify the content-coding if the 977 new coding is known to be acceptable to the recipient, unless the 978 "no-transform" cache-control directive is present in the message. 980 If the content-coding of an entity is not "identity", then the 981 response MUST include a Content-Encoding entity-header (Section 6.5) 982 that lists the non-identity content-coding(s) used. 984 If the content-coding of an entity in a request message is not 985 acceptable to the origin server, the server SHOULD respond with a 986 status code of 415 (Unsupported Media Type). 988 If multiple encodings have been applied to an entity, the content 989 codings MUST be listed in the order in which they were applied. 990 Additional information about the encoding parameters MAY be provided 991 by other entity-header fields not defined by this specification. 993 6.6. Content-Language 995 The entity-header field "Content-Language" describes the natural 996 language(s) of the intended audience for the enclosed entity. Note 997 that this might not be equivalent to all the languages used within 998 the entity-body. 1000 Content-Language = "Content-Language" ":" OWS Content-Language-v 1001 Content-Language-v = 1#language-tag 1003 Language tags are defined in Section 3.5. The primary purpose of 1004 Content-Language is to allow a user to identify and differentiate 1005 entities according to the user's own preferred language. Thus, if 1006 the body content is intended only for a Danish-literate audience, the 1007 appropriate field is 1009 Content-Language: da 1011 If no Content-Language is specified, the default is that the content 1012 is intended for all language audiences. This might mean that the 1013 sender does not consider it to be specific to any natural language, 1014 or that the sender does not know for which language it is intended. 1016 Multiple languages MAY be listed for content that is intended for 1017 multiple audiences. For example, a rendition of the "Treaty of 1018 Waitangi," presented simultaneously in the original Maori and English 1019 versions, would call for 1021 Content-Language: mi, en 1023 However, just because multiple languages are present within an entity 1024 does not mean that it is intended for multiple linguistic audiences. 1025 An example would be a beginner's language primer, such as "A First 1026 Lesson in Latin," which is clearly intended to be used by an English- 1027 literate audience. In this case, the Content-Language would properly 1028 only include "en". 1030 Content-Language MAY be applied to any media type -- it is not 1031 limited to textual documents. 1033 6.7. Content-Location 1035 The entity-header field "Content-Location" MAY be used to supply the 1036 resource location for the entity enclosed in the message when that 1037 entity is accessible from a location separate from the requested 1038 resource's URI. A server SHOULD provide a Content-Location for the 1039 variant corresponding to the response entity; especially in the case 1040 where a resource has multiple entities associated with it, and those 1041 entities actually have separate locations by which they might be 1042 individually accessed, the server SHOULD provide a Content-Location 1043 for the particular variant which is returned. 1045 Content-Location = "Content-Location" ":" OWS 1046 Content-Location-v 1047 Content-Location-v = 1048 absolute-URI / relativeURI 1050 The value of Content-Location also defines the base URI for the 1051 entity. 1053 The Content-Location value is not a replacement for the original 1054 requested URI; it is only a statement of the location of the resource 1055 corresponding to this particular entity at the time of the request. 1056 Future requests MAY specify the Content-Location URI as the request- 1057 URI if the desire is to identify the source of that particular 1058 entity. 1060 A cache cannot assume that an entity with a Content-Location 1061 different from the URI used to retrieve it can be used to respond to 1062 later requests on that Content-Location URI. However, the Content- 1063 Location can be used to differentiate between multiple entities 1064 retrieved from a single requested resource, as described in Section 8 1065 of [Part6]. 1067 If the Content-Location is a relative URI, the relative URI is 1068 interpreted relative to the Request-URI. 1070 The meaning of the Content-Location header in PUT or POST requests is 1071 undefined; servers are free to ignore it in those cases. 1073 6.8. Content-MD5 1075 The entity-header field "Content-MD5", as defined in [RFC1864], is an 1076 MD5 digest of the entity-body for the purpose of providing an end-to- 1077 end message integrity check (MIC) of the entity-body. (Note: a MIC 1078 is good for detecting accidental modification of the entity-body in 1079 transit, but is not proof against malicious attacks.) 1080 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1081 Content-MD5-v = 1083 The Content-MD5 header field MAY be generated by an origin server or 1084 client to function as an integrity check of the entity-body. Only 1085 origin servers or clients MAY generate the Content-MD5 header field; 1086 proxies and gateways MUST NOT generate it, as this would defeat its 1087 value as an end-to-end integrity check. Any recipient of the entity- 1088 body, including gateways and proxies, MAY check that the digest value 1089 in this header field matches that of the entity-body as received. 1091 The MD5 digest is computed based on the content of the entity-body, 1092 including any content-coding that has been applied, but not including 1093 any transfer-encoding applied to the message-body. If the message is 1094 received with a transfer-encoding, that encoding MUST be removed 1095 prior to checking the Content-MD5 value against the received entity. 1097 This has the result that the digest is computed on the octets of the 1098 entity-body exactly as, and in the order that, they would be sent if 1099 no transfer-encoding were being applied. 1101 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1102 composite media-types (e.g., multipart/* and message/rfc822), but 1103 this does not change how the digest is computed as defined in the 1104 preceding paragraph. 1106 There are several consequences of this. The entity-body for 1107 composite types MAY contain many body-parts, each with its own MIME 1108 and HTTP headers (including Content-MD5, Content-Transfer-Encoding, 1109 and Content-Encoding headers). If a body-part has a Content- 1110 Transfer-Encoding or Content-Encoding header, it is assumed that the 1111 content of the body-part has had the encoding applied, and the body- 1112 part is included in the Content-MD5 digest as is -- i.e., after the 1113 application. The Transfer-Encoding header field is not allowed 1114 within body-parts. 1116 Conversion of all line breaks to CRLF MUST NOT be done before 1117 computing or checking the digest: the line break convention used in 1118 the text actually transmitted MUST be left unaltered when computing 1119 the digest. 1121 Note: while the definition of Content-MD5 is exactly the same for 1122 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1123 in which the application of Content-MD5 to HTTP entity-bodies 1124 differs from its application to MIME entity-bodies. One is that 1125 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1126 does use Transfer-Encoding and Content-Encoding. Another is that 1127 HTTP more frequently uses binary content types than MIME, so it is 1128 worth noting that, in such cases, the byte order used to compute 1129 the digest is the transmission byte order defined for the type. 1130 Lastly, HTTP allows transmission of text types with any of several 1131 line break conventions and not just the canonical form using CRLF. 1133 6.9. Content-Type 1135 The entity-header field "Content-Type" indicates the media type of 1136 the entity-body sent to the recipient or, in the case of the HEAD 1137 method, the media type that would have been sent had the request been 1138 a GET. 1140 Content-Type = "Content-Type" ":" OWS Content-Type-v 1141 Content-Type-v = media-type 1143 Media types are defined in Section 3.3. An example of the field is 1145 Content-Type: text/html; charset=ISO-8859-4 1147 Further discussion of methods for identifying the media type of an 1148 entity is provided in Section 4.2.1. 1150 7. IANA Considerations 1152 7.1. Message Header Registration 1154 The Message Header Registry located at should be 1156 updated with the permanent registrations below (see [RFC3864]): 1158 +---------------------+----------+----------+--------------+ 1159 | Header Field Name | Protocol | Status | Reference | 1160 +---------------------+----------+----------+--------------+ 1161 | Accept | http | standard | Section 6.1 | 1162 | Accept-Charset | http | standard | Section 6.2 | 1163 | Accept-Encoding | http | standard | Section 6.3 | 1164 | Accept-Language | http | standard | Section 6.4 | 1165 | Content-Disposition | http | | Appendix B.1 | 1166 | Content-Encoding | http | standard | Section 6.5 | 1167 | Content-Language | http | standard | Section 6.6 | 1168 | Content-Location | http | standard | Section 6.7 | 1169 | Content-MD5 | http | standard | Section 6.8 | 1170 | Content-Type | http | standard | Section 6.9 | 1171 | MIME-Version | http | | Appendix A.1 | 1172 +---------------------+----------+----------+--------------+ 1174 The change controller is: "IETF (iesg@ietf.org) - Internet 1175 Engineering Task Force". 1177 8. Security Considerations 1179 This section is meant to inform application developers, information 1180 providers, and users of the security limitations in HTTP/1.1 as 1181 described by this document. The discussion does not include 1182 definitive solutions to the problems revealed, though it does make 1183 some suggestions for reducing security risks. 1185 8.1. Privacy Issues Connected to Accept Headers 1187 Accept request-headers can reveal information about the user to all 1188 servers which are accessed. The Accept-Language header in particular 1189 can reveal information the user would consider to be of a private 1190 nature, because the understanding of particular languages is often 1191 strongly correlated to the membership of a particular ethnic group. 1192 User agents which offer the option to configure the contents of an 1193 Accept-Language header to be sent in every request are strongly 1194 encouraged to let the configuration process include a message which 1195 makes the user aware of the loss of privacy involved. 1197 An approach that limits the loss of privacy would be for a user agent 1198 to omit the sending of Accept-Language headers by default, and to ask 1199 the user whether or not to start sending Accept-Language headers to a 1200 server if it detects, by looking for any Vary response-header fields 1201 generated by the server, that such sending could improve the quality 1202 of service. 1204 Elaborate user-customized accept header fields sent in every request, 1205 in particular if these include quality values, can be used by servers 1206 as relatively reliable and long-lived user identifiers. Such user 1207 identifiers would allow content providers to do click-trail tracking, 1208 and would allow collaborating content providers to match cross-server 1209 click-trails or form submissions of individual users. Note that for 1210 many users not behind a proxy, the network address of the host 1211 running the user agent will also serve as a long-lived user 1212 identifier. In environments where proxies are used to enhance 1213 privacy, user agents ought to be conservative in offering accept 1214 header configuration options to end users. As an extreme privacy 1215 measure, proxies could filter the accept headers in relayed requests. 1216 General purpose user agents which provide a high degree of header 1217 configurability SHOULD warn users about the loss of privacy which can 1218 be involved. 1220 8.2. Content-Disposition Issues 1222 [RFC2183], from which the often implemented Content-Disposition (see 1223 Appendix B.1) header in HTTP is derived, has a number of very serious 1224 security considerations. Content-Disposition is not part of the HTTP 1225 standard, but since it is widely implemented, we are documenting its 1226 use and risks for implementors. See Section 5 of [RFC2183] for 1227 details. 1229 9. Acknowledgments 1231 10. References 1233 10.1. Normative References 1235 [ISO-8859-1] 1236 International Organization for Standardization, 1237 "Information technology -- 8-bit single-byte coded graphic 1238 character sets -- Part 1: Latin alphabet No. 1", ISO/ 1239 IEC 8859-1:1998, 1998. 1241 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1242 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1243 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1244 and Message Parsing", draft-ietf-httpbis-p1-messaging-05 1245 (work in progress), November 2008. 1247 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1248 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1249 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1250 Semantics", draft-ietf-httpbis-p2-semantics-05 (work in 1251 progress), November 2008. 1253 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1254 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1255 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1256 Requests", draft-ietf-httpbis-p4-conditional-05 (work in 1257 progress), November 2008. 1259 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1260 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1261 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1262 Partial Responses", draft-ietf-httpbis-p5-range-05 (work 1263 in progress), November 2008. 1265 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1266 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1267 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 1268 draft-ietf-httpbis-p6-cache-05 (work in progress), 1269 November 2008. 1271 [RFC1766] Alvestrand, H., "Tags for the Identification of 1272 Languages", RFC 1766, March 1995. 1274 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1275 RFC 1864, October 1995. 1277 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1278 Specification version 3.3", RFC 1950, May 1996. 1280 RFC 1950 is an Informational RFC, thus it may be less 1281 stable than this specification. On the other hand, this 1282 downward reference was present since the publication of 1283 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1284 cause problems in practice. See also [BCP97]. 1286 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1287 version 1.3", RFC 1951, May 1996. 1289 RFC 1951 is an Informational RFC, thus it may be less 1290 stable than this specification. On the other hand, this 1291 downward reference was present since the publication of 1292 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1293 cause problems in practice. See also [BCP97]. 1295 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1296 Randers-Pehrson, "GZIP file format specification version 1297 4.3", RFC 1952, May 1996. 1299 RFC 1952 is an Informational RFC, thus it may be less 1300 stable than this specification. On the other hand, this 1301 downward reference was present since the publication of 1302 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1303 cause problems in practice. See also [BCP97]. 1305 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1306 Extensions (MIME) Part One: Format of Internet Message 1307 Bodies", RFC 2045, November 1996. 1309 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1310 Extensions (MIME) Part Two: Media Types", RFC 2046, 1311 November 1996. 1313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1314 Requirement Levels", BCP 14, RFC 2119, March 1997. 1316 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1317 Tags", BCP 47, RFC 4647, September 2006. 1319 10.2. Informative References 1321 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 1322 to Standards-Track Documents", BCP 97, RFC 4897, 1323 June 2007. 1325 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1326 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1328 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1329 Extensions (MIME) Part Five: Conformance Criteria and 1330 Examples", RFC 2049, November 1996. 1332 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1333 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1334 RFC 2068, January 1997. 1336 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1337 February 1997. 1339 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1340 Presentation Information in Internet Messages: The 1341 Content-Disposition Header Field", RFC 2183, August 1997. 1343 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1344 Languages", BCP 18, RFC 2277, January 1998. 1346 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1347 form-data", RFC 2388, August 1998. 1349 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1350 "MIME Encapsulation of Aggregate Documents, such as HTML 1351 (MHTML)", RFC 2557, March 1999. 1353 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1354 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1355 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1357 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1358 10646", RFC 3629, STD 63, November 2003. 1360 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1361 Procedures for Message Header Fields", BCP 90, RFC 3864, 1362 September 2004. 1364 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1365 Registration Procedures", BCP 13, RFC 4288, December 2005. 1367 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1368 October 2008. 1370 Appendix A. Differences Between HTTP Entities and RFC 2045 Entities 1372 HTTP/1.1 uses many of the constructs defined for Internet Mail 1373 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1374 [RFC2045]) to allow entities to be transmitted in an open variety of 1375 representations and with extensible mechanisms. However, RFC 2045 1376 discusses mail, and HTTP has a few features that are different from 1377 those described in RFC 2045. These differences were carefully chosen 1378 to optimize performance over binary connections, to allow greater 1379 freedom in the use of new media types, to make date comparisons 1380 easier, and to acknowledge the practice of some early HTTP servers 1381 and clients. 1383 This appendix describes specific areas where HTTP differs from RFC 1384 2045. Proxies and gateways to strict MIME environments SHOULD be 1385 aware of these differences and provide the appropriate conversions 1386 where necessary. Proxies and gateways from MIME environments to HTTP 1387 also need to be aware of the differences because some conversions 1388 might be required. 1390 A.1. MIME-Version 1392 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1393 MAY include a single MIME-Version general-header field to indicate 1394 what version of the MIME protocol was used to construct the message. 1395 Use of the MIME-Version header field indicates that the message is in 1396 full compliance with the MIME protocol (as defined in [RFC2045]). 1397 Proxies/gateways are responsible for ensuring full compliance (where 1398 possible) when exporting HTTP messages to strict MIME environments. 1400 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1401 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1403 MIME version "1.0" is the default for use in HTTP/1.1. However, 1404 HTTP/1.1 message parsing and semantics are defined by this document 1405 and not the MIME specification. 1407 A.2. Conversion to Canonical Form 1409 [RFC2045] requires that an Internet mail entity be converted to 1410 canonical form prior to being transferred, as described in Section 4 1411 of [RFC2049]. Section 3.3.1 of this document describes the forms 1412 allowed for subtypes of the "text" media type when transmitted over 1413 HTTP. [RFC2046] requires that content with a type of "text" 1414 represent line breaks as CRLF and forbids the use of CR or LF outside 1415 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1416 indicate a line break within text content when a message is 1417 transmitted over HTTP. 1419 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1420 environment SHOULD translate all line breaks within the text media 1421 types described in Section 3.3.1 of this document to the RFC 2049 1422 canonical form of CRLF. Note, however, that this might be 1423 complicated by the presence of a Content-Encoding and by the fact 1424 that HTTP allows the use of some character sets which do not use 1425 octets 13 and 10 to represent CR and LF, as is the case for some 1426 multi-byte character sets. 1428 Implementors should note that conversion will break any cryptographic 1429 checksums applied to the original content unless the original content 1430 is already in canonical form. Therefore, the canonical form is 1431 recommended for any content that uses such checksums in HTTP. 1433 A.3. Introduction of Content-Encoding 1435 RFC 2045 does not include any concept equivalent to HTTP/1.1's 1436 Content-Encoding header field. Since this acts as a modifier on the 1437 media type, proxies and gateways from HTTP to MIME-compliant 1438 protocols MUST either change the value of the Content-Type header 1439 field or decode the entity-body before forwarding the message. (Some 1440 experimental applications of Content-Type for Internet mail have used 1441 a media-type parameter of ";conversions=" to perform 1442 a function equivalent to Content-Encoding. However, this parameter 1443 is not part of RFC 2045). 1445 A.4. No Content-Transfer-Encoding 1447 HTTP does not use the Content-Transfer-Encoding field of RFC 2045. 1448 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1449 remove any Content-Transfer-Encoding prior to delivering the response 1450 message to an HTTP client. 1452 Proxies and gateways from HTTP to MIME-compliant protocols are 1453 responsible for ensuring that the message is in the correct format 1454 and encoding for safe transport on that protocol, where "safe 1455 transport" is defined by the limitations of the protocol being used. 1456 Such a proxy or gateway SHOULD label the data with an appropriate 1457 Content-Transfer-Encoding if doing so will improve the likelihood of 1458 safe transport over the destination protocol. 1460 A.5. Introduction of Transfer-Encoding 1462 HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 1463 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1464 to forwarding a message via a MIME-compliant protocol. 1466 A.6. MHTML and Line Length Limitations 1468 HTTP implementations which share code with MHTML [RFC2557] 1469 implementations need to be aware of MIME line length limitations. 1470 Since HTTP does not have this limitation, HTTP does not fold long 1471 lines. MHTML messages being transported by HTTP follow all 1472 conventions of MHTML, including line length limitations and folding, 1473 canonicalization, etc., since HTTP transports all message-bodies as 1474 payload (see Section 3.3.2) and does not interpret the content or any 1475 MIME header lines that might be contained therein. 1477 Appendix B. Additional Features 1479 [RFC1945] and [RFC2068] document protocol elements used by some 1480 existing HTTP implementations, but not consistently and correctly 1481 across most HTTP/1.1 applications. Implementors are advised to be 1482 aware of these features, but cannot rely upon their presence in, or 1483 interoperability with, other HTTP/1.1 applications. Some of these 1484 describe proposed experimental features, and some describe features 1485 that experimental deployment found lacking that are now addressed in 1486 the base HTTP/1.1 specification. 1488 A number of other headers, such as Content-Disposition and Title, 1489 from SMTP and MIME are also often implemented (see [RFC2076]). 1491 B.1. Content-Disposition 1493 The Content-Disposition response-header field has been proposed as a 1494 means for the origin server to suggest a default filename if the user 1495 requests that the content is saved to a file. This usage is derived 1496 from the definition of Content-Disposition in [RFC2183]. 1498 content-disposition = "Content-Disposition" ":" OWS 1499 content-disposition-v 1500 content-disposition-v = disposition-type 1501 *( OWS ";" OWS disposition-parm ) 1502 disposition-type = "attachment" / disp-extension-token 1503 disposition-parm = filename-parm / disp-extension-parm 1504 filename-parm = "filename" "=" quoted-string 1505 disp-extension-token = token 1506 disp-extension-parm = token "=" ( token / quoted-string ) 1508 An example is 1510 Content-Disposition: attachment; filename="fname.ext" 1512 The receiving user agent SHOULD NOT respect any directory path 1513 information present in the filename-parm parameter, which is the only 1514 parameter believed to apply to HTTP implementations at this time. 1515 The filename SHOULD be treated as a terminal component only. 1517 If this header is used in a response with the application/ 1518 octet-stream content-type, the implied suggestion is that the user 1519 agent should not display the response, but directly enter a `save 1520 response as...' dialog. 1522 See Section 8.2 for Content-Disposition security issues. 1524 Appendix C. Compatibility with Previous Versions 1526 C.1. Changes from RFC 2068 1528 Transfer-coding and message lengths all interact in ways that 1529 required fixing exactly when chunked encoding is used (to allow for 1530 transfer encoding that may not be self delimiting); it was important 1531 to straighten out exactly how message lengths are computed. 1532 (Section 4.2.2, see also [Part1], [Part5] and [Part6]). 1534 Charset wildcarding is introduced to avoid explosion of character set 1535 names in accept headers. (Section 6.2) 1537 Content-Base was deleted from the specification: it was not 1538 implemented widely, and there is no simple, safe way to introduce it 1539 without a robust extension mechanism. In addition, it is used in a 1540 similar, but not identical fashion in MHTML [RFC2557]. 1542 A content-coding of "identity" was introduced, to solve problems 1543 discovered in caching. (Section 3.2) 1544 Quality Values of zero should indicate that "I don't want something" 1545 to allow clients to refuse a representation. (Section 3.4) 1547 The Alternates, Content-Version, Derived-From, Link, URI, Public and 1548 Content-Base header fields were defined in previous versions of this 1549 specification, but not commonly implemented. See Section 19.6.2 of 1550 [RFC2068]. 1552 C.2. Changes from RFC 2616 1554 Clarify contexts that charset is used in. (Section 3.1) 1556 Remove reference to non-existant identity transfer-coding value 1557 tokens. (Appendix A.4) 1559 Appendix D. Change Log (to be removed by RFC Editor before publication) 1561 D.1. Since RFC2616 1563 Extracted relevant partitions from [RFC2616]. 1565 D.2. Since draft-ietf-httpbis-p3-payload-00 1567 Closed issues: 1569 o : "Media Type 1570 Registrations" () 1572 o : "Clarification 1573 regarding quoting of charset values" 1574 () 1576 o : "Remove 1577 'identity' token references" 1578 () 1580 o : "Accept- 1581 Encoding BNF" 1583 o : "Normative and 1584 Informative references" 1586 o : "RFC1700 1587 references" 1589 o : "Updating to 1590 RFC4288" 1592 o : "Informative 1593 references" 1595 o : "ISO-8859-1 1596 Reference" 1598 o : "Encoding 1599 References Normative" 1601 o : "Normative up- 1602 to-date references" 1604 D.3. Since draft-ietf-httpbis-p3-payload-01 1606 Ongoing work on ABNF conversion 1607 (): 1609 o Add explicit references to BNF syntax and rules imported from 1610 other parts of the specification. 1612 D.4. Since draft-ietf-httpbis-p3-payload-02 1614 Closed issues: 1616 o : "Quoting 1617 Charsets" 1619 o : 1620 "Classification for Allow header" 1622 o : "missing 1623 default for qvalue in description of Accept-Encoding" 1625 Ongoing work on IANA Message Header Registration 1626 (): 1628 o Reference RFC 3984, and update header registrations for headers 1629 defined in this document. 1631 D.5. Since draft-ietf-httpbis-p3-payload-03 1633 Closed issues: 1635 o : "Quoting 1636 Charsets" 1638 o : "language tag 1639 matching (Accept-Language) vs RFC4647" 1641 o : "RFC 1806 has 1642 been replaced by RFC2183" 1644 Other changes: 1646 o : "Encoding 1647 References Normative" -- rephrase the annotation and reference 1648 [BCP97]. 1650 D.6. Since draft-ietf-httpbis-p3-payload-04 1652 Closed issues: 1654 o : "RFC 2822 is 1655 updated by RFC 5322" 1657 Ongoing work on ABNF conversion 1658 (): 1660 o Use "/" instead of "|" for alternatives. 1662 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1663 whitespace ("OWS") and required whitespace ("RWS"). 1665 o Rewrite ABNFs to spell out whitespace rules, factor out header 1666 value format definitions. 1668 Index 1670 A 1671 Accept header 16 1672 Accept-Charset header 18 1673 Accept-Encoding header 19 1674 Accept-Language header 20 1675 Alternates header 35 1677 C 1678 compress 8 1679 Content-Base header 35 1680 Content-Disposition header 33 1681 Content-Encoding header 22 1682 Content-Language header 23 1683 Content-Location header 24 1684 Content-MD5 header 24 1685 Content-Type header 26 1686 Content-Version header 35 1688 D 1689 deflate 8 1690 Derived-From header 35 1692 G 1693 Grammar 1694 Accept 16 1695 Accept-Charset 18 1696 Accept-Charset-v 18 1697 Accept-Encoding 19 1698 Accept-Encoding-v 19 1699 accept-ext 16 1700 Accept-Language 21 1701 Accept-Language-v 21 1702 accept-params 16 1703 Accept-v 16 1704 attribute 9 1705 charset 6 1706 codings 19 1707 content-coding 7 1708 content-disposition 34 1709 content-disposition-v 34 1710 Content-Encoding 22 1711 Content-Encoding-v 22 1712 Content-Language 23 1713 Content-Language-v 23 1714 Content-Location 24 1715 Content-Location-v 24 1716 Content-MD5 25 1717 Content-MD5-v 25 1718 Content-Type 26 1719 Content-Type-v 26 1720 disp-extension-parm 34 1721 disp-extension-token 34 1722 disposition-parm 34 1723 disposition-type 34 1724 entity-body 12 1725 entity-header 12 1726 extension-header 12 1727 filename-parm 34 1728 language-range 21 1729 language-tag 11 1730 media-range 16 1731 media-type 9 1732 MIME-Version 31 1733 MIME-Version-v 31 1734 parameter 9 1735 primary-tag 11 1736 qvalue 11 1737 subtag 11 1738 subtype 9 1739 type 9 1740 value 9 1741 gzip 8 1743 H 1744 Headers 1745 Accept 16 1746 Accept-Charset 18 1747 Accept-Encoding 19 1748 Accept-Language 20 1749 Alternate 35 1750 Content-Base 35 1751 Content-Disposition 33 1752 Content-Encoding 22 1753 Content-Language 23 1754 Content-Location 24 1755 Content-MD5 24 1756 Content-Type 26 1757 Content-Version 35 1758 Derived-From 35 1759 Link 35 1760 MIME-Version 31 1761 Public 35 1762 URI 35 1764 I 1765 identity 8 1767 L 1768 Link header 35 1770 M 1771 MIME-Version header 31 1773 P 1774 Public header 35 1776 U 1777 URI header 35 1779 Authors' Addresses 1781 Roy T. Fielding (editor) 1782 Day Software 1783 23 Corporate Plaza DR, Suite 280 1784 Newport Beach, CA 92660 1785 USA 1787 Phone: +1-949-706-5300 1788 Fax: +1-949-706-5305 1789 Email: fielding@gbiv.com 1790 URI: http://roy.gbiv.com/ 1792 Jim Gettys 1793 One Laptop per Child 1794 21 Oak Knoll Road 1795 Carlisle, MA 01741 1796 USA 1798 Email: jg@laptop.org 1799 URI: http://www.laptop.org/ 1801 Jeffrey C. Mogul 1802 Hewlett-Packard Company 1803 HP Labs, Large Scale Systems Group 1804 1501 Page Mill Road, MS 1177 1805 Palo Alto, CA 94304 1806 USA 1808 Email: JeffMogul@acm.org 1810 Henrik Frystyk Nielsen 1811 Microsoft Corporation 1812 1 Microsoft Way 1813 Redmond, WA 98052 1814 USA 1816 Email: henrikn@microsoft.com 1817 Larry Masinter 1818 Adobe Systems, Incorporated 1819 345 Park Ave 1820 San Jose, CA 95110 1821 USA 1823 Email: LMM@acm.org 1824 URI: http://larry.masinter.net/ 1826 Paul J. Leach 1827 Microsoft Corporation 1828 1 Microsoft Way 1829 Redmond, WA 98052 1831 Email: paulle@microsoft.com 1833 Tim Berners-Lee 1834 World Wide Web Consortium 1835 MIT Computer Science and Artificial Intelligence Laboratory 1836 The Stata Center, Building 32 1837 32 Vassar Street 1838 Cambridge, MA 02139 1839 USA 1841 Email: timbl@w3.org 1842 URI: http://www.w3.org/People/Berners-Lee/ 1844 Yves Lafon (editor) 1845 World Wide Web Consortium 1846 W3C / ERCIM 1847 2004, rte des Lucioles 1848 Sophia-Antipolis, AM 06902 1849 France 1851 Email: ylafon@w3.org 1852 URI: http://www.raubacapeu.net/people/yves/ 1853 Julian F. Reschke (editor) 1854 greenbytes GmbH 1855 Hafenweg 16 1856 Muenster, NW 48155 1857 Germany 1859 Phone: +49 251 2807760 1860 Fax: +49 251 2807761 1861 Email: julian.reschke@greenbytes.de 1862 URI: http://greenbytes.de/tech/webdav/ 1864 Full Copyright Statement 1866 Copyright (C) The IETF Trust (2008). 1868 This document is subject to the rights, licenses and restrictions 1869 contained in BCP 78, and except as set forth therein, the authors 1870 retain all their rights. 1872 This document and the information contained herein are provided on an 1873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1875 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1876 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1877 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1880 Intellectual Property 1882 The IETF takes no position regarding the validity or scope of any 1883 Intellectual Property Rights or other rights that might be claimed to 1884 pertain to the implementation or use of the technology described in 1885 this document or the extent to which any license under such rights 1886 might or might not be available; nor does it represent that it has 1887 made any independent effort to identify any such rights. Information 1888 on the procedures with respect to rights in RFC documents can be 1889 found in BCP 78 and BCP 79. 1891 Copies of IPR disclosures made to the IETF Secretariat and any 1892 assurances of licenses to be made available, or the result of an 1893 attempt made to obtain a general license or permission for the use of 1894 such proprietary rights by implementers or users of this 1895 specification can be obtained from the IETF on-line IPR repository at 1896 http://www.ietf.org/ipr. 1898 The IETF invites any interested party to bring to its attention any 1899 copyrights, patents or patent applications, or other proprietary 1900 rights that may cover technology that may be required to implement 1901 this standard. Please address the information to the IETF at 1902 ietf-ipr@ietf.org.