idnits 2.17.1 draft-ietf-httpbis-p3-payload-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5295 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-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-08 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis 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: April 29, 2010 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 October 26, 2009 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-08 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on April 29, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents in effect on the date of 64 publication of this document (http://trustee.ietf.org/license-info). 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. 68 Abstract 70 The Hypertext Transfer Protocol (HTTP) is an application-level 71 protocol for distributed, collaborative, hypermedia information 72 systems. HTTP has been in use by the World Wide Web global 73 information initiative since 1990. This document is Part 3 of the 74 seven-part specification that defines the protocol referred to as 75 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines 76 HTTP message content, metadata, and content negotiation. 78 Editorial Note (To be removed by RFC Editor) 80 Discussion of this draft should take place on the HTTPBIS working 81 group mailing list (ietf-http-wg@w3.org). The current issues list is 82 at and related 83 documents (including fancy diffs) can be found at 84 . 86 The changes in this draft are summarized in Appendix E.9. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 91 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 92 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 93 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 94 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 95 1.3.2. ABNF Rules defined in other Parts of the 96 Specification . . . . . . . . . . . . . . . . . . . . 6 97 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 98 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 99 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 100 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 101 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 102 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 103 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 104 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 105 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 106 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 107 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 108 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 109 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 111 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 112 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 113 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 114 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 115 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 116 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 117 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 118 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 119 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 120 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 23 121 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 122 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 123 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 124 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 125 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 126 6.1. Message Header Registration . . . . . . . . . . . . . . . 27 127 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 128 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 129 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 130 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29 131 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 132 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 133 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 134 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 135 Appendix A. Differences Between HTTP Entities and RFC 2045 136 Entities . . . . . . . . . . . . . . . . . . . . . . 32 137 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 138 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 139 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 140 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 141 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 142 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 143 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 144 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 145 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 146 Appendix C. Compatibility with Previous Versions . . . . . . . . 35 147 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 148 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36 149 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 150 Appendix E. Change Log (to be removed by RFC Editor before 151 publication) . . . . . . . . . . . . . . . . . . . . 38 152 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 153 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 154 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 155 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 156 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40 157 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 158 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 159 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41 160 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 161 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 164 1. Introduction 166 This document defines HTTP/1.1 message payloads (a.k.a., content), 167 the associated metadata header fields that define how the payload is 168 intended to be interpreted by a recipient, the request header fields 169 that may influence content selection, and the various selection 170 algorithms that are collectively referred to as HTTP content 171 negotiation. 173 This document is currently disorganized in order to minimize the 174 changes between drafts and enable reviewers to see the smaller errata 175 changes. The next draft will reorganize the sections to better 176 reflect the content. In particular, the sections on entities will be 177 renamed payload and moved to the first half of the document, while 178 the sections on content negotiation and associated request header 179 fields will be moved to the second half. The current mess reflects 180 how widely dispersed these topics and associated requirements had 181 become in [RFC2616]. 183 1.1. Terminology 185 This specification uses a number of terms to refer to the roles 186 played by participants in, and objects of, the HTTP communication. 188 content negotiation 190 The mechanism for selecting the appropriate representation when 191 servicing a request. The representation of entities in any 192 response can be negotiated (including error responses). 194 entity 196 The information transferred as the payload of a request or 197 response. An entity consists of metadata in the form of entity- 198 header fields and content in the form of an entity-body. 200 representation 202 An entity included with a response that is subject to content 203 negotiation. There may exist multiple representations associated 204 with a particular response status. 206 variant 208 A resource may have one, or more than one, representation(s) 209 associated with it at any given instant. Each of these 210 representations is termed a `variant'. Use of the term `variant' 211 does not necessarily imply that the resource is subject to content 212 negotiation. 214 1.2. Requirements 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 An implementation is not compliant if it fails to satisfy one or more 221 of the MUST or REQUIRED level requirements for the protocols it 222 implements. An implementation that satisfies all the MUST or 223 REQUIRED level and all the SHOULD level requirements for its 224 protocols is said to be "unconditionally compliant"; one that 225 satisfies all the MUST level requirements but not all the SHOULD 226 level requirements for its protocols is said to be "conditionally 227 compliant." 229 1.3. Syntax Notation 231 This specification uses the ABNF syntax defined in Section 1.2 of 232 [Part1] (which extends the syntax defined in [RFC5234] with a list 233 rule). Appendix D shows the collected ABNF, with the list rule 234 expanded. 236 The following core rules are included by reference, as defined in 237 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 238 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 239 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 240 sequence of data), SP (space), VCHAR (any visible USASCII character), 241 and WSP (whitespace). 243 1.3.1. Core Rules 245 The core rules below are defined in Section 1.2.2 of [Part1]: 247 quoted-string = 248 token = 249 OWS = 251 1.3.2. ABNF Rules defined in other Parts of the Specification 253 The ABNF rules below are defined in other parts: 255 absolute-URI = 256 Content-Length = 257 header-field = 258 partial-URI = 259 qvalue = 260 Last-Modified = 262 Content-Range = 264 Expires = 266 2. Protocol Parameters 268 2.1. Character Sets 270 HTTP uses the same definition of the term "character set" as that 271 described for MIME: 273 The term "character set" is used in this document to refer to a 274 method used with one or more tables to convert a sequence of octets 275 into a sequence of characters. Note that unconditional conversion in 276 the other direction is not required, in that not all characters may 277 be available in a given character set and a character set may provide 278 more than one sequence of octets to represent a particular character. 279 This definition is intended to allow various kinds of character 280 encoding, from simple single-table mappings such as US-ASCII to 281 complex table switching methods such as those that use ISO-2022's 282 techniques. However, the definition associated with a MIME character 283 set name MUST fully specify the mapping to be performed from octets 284 to characters. In particular, use of external profiling information 285 to determine the exact mapping is not permitted. 287 Note: This use of the term "character set" is more commonly 288 referred to as a "character encoding." However, since HTTP and 289 MIME share the same registry, it is important that the terminology 290 also be shared. 292 HTTP character sets are identified by case-insensitive tokens. The 293 complete set of tokens is defined by the IANA Character Set registry 294 (). 296 charset = token 298 Although HTTP allows an arbitrary token to be used as a charset 299 value, any token that has a predefined value within the IANA 300 Character Set registry MUST represent the character set defined by 301 that registry. Applications SHOULD limit their use of character sets 302 to those defined by the IANA registry. 304 HTTP uses charset in two contexts: within an Accept-Charset request 305 header (in which the charset value is an unquoted token) and as the 306 value of a parameter in a Content-Type header (within a request or 307 response), in which case the parameter value of the charset parameter 308 may be quoted. 310 Implementors should be aware of IETF character set requirements 311 [RFC3629] [RFC2277]. 313 2.1.1. Missing Charset 315 Some HTTP/1.0 software has interpreted a Content-Type header without 316 charset parameter incorrectly to mean "recipient should guess." 317 Senders wishing to defeat this behavior MAY include a charset 318 parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and 319 SHOULD do so when it is known that it will not confuse the recipient. 321 Unfortunately, some older HTTP/1.0 clients did not deal properly with 322 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 323 charset label provided by the sender; and those user agents that have 324 a provision to "guess" a charset MUST use the charset from the 325 content-type field if they support that charset, rather than the 326 recipient's preference, when initially displaying a document. See 327 Section 2.3.1. 329 2.2. Content Codings 331 Content coding values indicate an encoding transformation that has 332 been or can be applied to an entity. Content codings are primarily 333 used to allow a document to be compressed or otherwise usefully 334 transformed without losing the identity of its underlying media type 335 and without loss of information. Frequently, the entity is stored in 336 coded form, transmitted directly, and only decoded by the recipient. 338 content-coding = token 340 All content-coding values are case-insensitive. HTTP/1.1 uses 341 content-coding values in the Accept-Encoding (Section 5.3) and 342 Content-Encoding (Section 5.5) header fields. Although the value 343 describes the content-coding, what is more important is that it 344 indicates what decoding mechanism will be required to remove the 345 encoding. 347 compress 349 See Section 6.2.2.1 of [Part1]. 351 deflate 352 See Section 6.2.2.2 of [Part1]. 354 gzip 356 See Section 6.2.2.3 of [Part1]. 358 identity 360 The default (identity) encoding; the use of no transformation 361 whatsoever. This content-coding is used only in the Accept- 362 Encoding header, and SHOULD NOT be used in the Content-Encoding 363 header. 365 2.2.1. Content Coding Registry 367 The HTTP Content Coding Registry defines the name space for the 368 content coding names. 370 Registrations MUST include the following fields: 372 o Name 374 o Description 376 o Pointer to specification text 378 Values to be added to this name space require expert review and a 379 specification (see "Expert Review" and "Specification Required" in 380 Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 381 coding defined in this section. 383 The registry itself is maintained at 384 . 386 2.3. Media Types 388 HTTP uses Internet Media Types [RFC2046] in the Content-Type 389 (Section 5.9) and Accept (Section 5.1) header fields in order to 390 provide open and extensible data typing and type negotiation. 392 media-type = type "/" subtype *( OWS ";" OWS parameter ) 393 type = token 394 subtype = token 396 Parameters MAY follow the type/subtype in the form of attribute/value 397 pairs. 399 parameter = attribute "=" value 400 attribute = token 401 value = token / quoted-string 403 The type, subtype, and parameter attribute names are case- 404 insensitive. Parameter values might or might not be case-sensitive, 405 depending on the semantics of the parameter name. The presence or 406 absence of a parameter might be significant to the processing of a 407 media-type, depending on its definition within the media type 408 registry. 410 A parameter value that matches the token production may be 411 transmitted as either a token or within a quoted-string. The quoted 412 and unquoted values are equivalent. 414 Note that some older HTTP applications do not recognize media type 415 parameters. When sending data to older HTTP applications, 416 implementations SHOULD only use media type parameters when they are 417 required by that type/subtype definition. 419 Media-type values are registered with the Internet Assigned Number 420 Authority (IANA). The media type registration process is outlined in 421 [RFC4288]. Use of non-registered media types is discouraged. 423 2.3.1. Canonicalization and Text Defaults 425 Internet media types are registered with a canonical form. An 426 entity-body transferred via HTTP messages MUST be represented in the 427 appropriate canonical form prior to its transmission except for 428 "text" types, as defined in the next paragraph. 430 When in canonical form, media subtypes of the "text" type use CRLF as 431 the text line break. HTTP relaxes this requirement and allows the 432 transport of text media with plain CR or LF alone representing a line 433 break when it is done consistently for an entire entity-body. HTTP 434 applications MUST accept CRLF, bare CR, and bare LF as being 435 representative of a line break in text media received via HTTP. In 436 addition, if the text is represented in a character set that does not 437 use octets 13 and 10 for CR and LF respectively, as is the case for 438 some multi-byte character sets, HTTP allows the use of whatever octet 439 sequences are defined by that character set to represent the 440 equivalent of CR and LF for line breaks. This flexibility regarding 441 line breaks applies only to text media in the entity-body; a bare CR 442 or LF MUST NOT be substituted for CRLF within any of the HTTP control 443 structures (such as header fields and multipart boundaries). 445 If an entity-body is encoded with a content-coding, the underlying 446 data MUST be in a form defined above prior to being encoded. 448 The "charset" parameter is used with some media types to define the 449 character set (Section 2.1) of the data. When no explicit charset 450 parameter is provided by the sender, media subtypes of the "text" 451 type are defined to have a default charset value of "ISO-8859-1" when 452 received via HTTP. Data in character sets other than "ISO-8859-1" or 453 its subsets MUST be labeled with an appropriate charset value. See 454 Section 2.1.1 for compatibility problems. 456 2.3.2. Multipart Types 458 MIME provides for a number of "multipart" types -- encapsulations of 459 one or more entities within a single message-body. All multipart 460 types share a common syntax, as defined in Section 5.1.1 of 461 [RFC2046], and MUST include a boundary parameter as part of the media 462 type value. The message body is itself a protocol element and MUST 463 therefore use only CRLF to represent line breaks between body-parts. 464 Unlike in RFC 2046, the epilogue of any multipart message MUST be 465 empty; HTTP applications MUST NOT transmit the epilogue (even if the 466 original multipart contains an epilogue). These restrictions exist 467 in order to preserve the self-delimiting nature of a multipart 468 message-body, wherein the "end" of the message-body is indicated by 469 the ending multipart boundary. 471 In general, HTTP treats a multipart message-body no differently than 472 any other media type: strictly as payload. The one exception is the 473 "multipart/byteranges" type (Appendix A of [Part5]) when it appears 474 in a 206 (Partial Content) response. In all other cases, an HTTP 475 user agent SHOULD follow the same or similar behavior as a MIME user 476 agent would upon receipt of a multipart type. The MIME header fields 477 within each body-part of a multipart message-body do not have any 478 significance to HTTP beyond that defined by their MIME semantics. 480 In general, an HTTP user agent SHOULD follow the same or similar 481 behavior as a MIME user agent would upon receipt of a multipart type. 482 If an application receives an unrecognized multipart subtype, the 483 application MUST treat it as being equivalent to "multipart/mixed". 485 Note: The "multipart/form-data" type has been specifically defined 486 for carrying form data suitable for processing via the POST 487 request method, as described in [RFC2388]. 489 2.4. Language Tags 491 A language tag, as defined in [RFC5646], identifies a natural 492 language spoken, written, or otherwise conveyed by human beings for 493 communication of information to other human beings. Computer 494 languages are explicitly excluded. HTTP uses language tags within 495 the Accept-Language and Content-Language fields. 497 In summary, a language tag is composed of one or more parts: A 498 primary language subtag followed by a possibly empty series of 499 subtags: 501 language-tag = 503 White space is not allowed within the tag and all tags are case- 504 insensitive. The name space of language subtags is administered by 505 the IANA (see 506 ). 508 Example tags include: 510 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 512 See [RFC5646] for further information. 514 3. Entity 516 Request and Response messages MAY transfer an entity if not otherwise 517 restricted by the request method or response status code. An entity 518 consists of entity-header fields and an entity-body, although some 519 responses will only include the entity-headers. 521 In this section, both sender and recipient refer to either the client 522 or the server, depending on who sends and who receives the entity. 524 3.1. Entity Header Fields 526 Entity-header fields define metainformation about the entity-body or, 527 if no body is present, about the resource identified by the request. 529 entity-header = Content-Encoding ; Section 5.5 530 / Content-Language ; Section 5.6 531 / Content-Length ; [Part1], Section 9.2 532 / Content-Location ; Section 5.7 533 / Content-MD5 ; Section 5.8 534 / Content-Range ; [Part5], Section 5.2 535 / Content-Type ; Section 5.9 536 / Expires ; [Part6], Section 3.3 537 / Last-Modified ; [Part4], Section 6.6 538 / extension-header 540 extension-header = header-field 542 The extension-header mechanism allows additional entity-header fields 543 to be defined without changing the protocol, but these fields cannot 544 be assumed to be recognizable by the recipient. Unrecognized header 545 fields SHOULD be ignored by the recipient and MUST be forwarded by 546 transparent proxies. 548 3.2. Entity Body 550 The entity-body (if any) sent with an HTTP request or response is in 551 a format and encoding defined by the entity-header fields. 553 entity-body = *OCTET 555 An entity-body is only present in a message when a message-body is 556 present, as described in Section 3.3 of [Part1]. The entity-body is 557 obtained from the message-body by decoding any Transfer-Encoding that 558 might have been applied to ensure safe and proper transfer of the 559 message. 561 3.2.1. Type 563 When an entity-body is included with a message, the data type of that 564 body is determined via the header fields Content-Type and Content- 565 Encoding. These define a two-layer, ordered encoding model: 567 entity-body := Content-Encoding( Content-Type( data ) ) 569 Content-Type specifies the media type of the underlying data. Any 570 HTTP/1.1 message containing an entity-body SHOULD include a Content- 571 Type header field defining the media type of that body, unless that 572 information is unknown. If the Content-Type header field is not 573 present, it indicates that the sender does not know the media type of 574 the data; recipients MAY either assume that it is "application/ 575 octet-stream" ([RFC2046], Section 4.5.1) or examine the content to 576 determine its type. 578 Content-Encoding may be used to indicate any additional content 579 codings applied to the data, usually for the purpose of data 580 compression, that are a property of the requested resource. There is 581 no default encoding. 583 3.2.2. Entity Length 585 The entity-length of a message is the length of the message-body 586 before any transfer-codings have been applied. Section 3.4 of 587 [Part1] defines how the transfer-length of a message-body is 588 determined. 590 4. Content Negotiation 592 Most HTTP responses include an entity which contains information for 593 interpretation by a human user. Naturally, it is desirable to supply 594 the user with the "best available" entity corresponding to the 595 request. Unfortunately for servers and caches, not all users have 596 the same preferences for what is "best," and not all user agents are 597 equally capable of rendering all entity types. For that reason, HTTP 598 has provisions for several mechanisms for "content negotiation" -- 599 the process of selecting the best representation for a given response 600 when there are multiple representations available. 602 Note: This is not called "format negotiation" because the 603 alternate representations may be of the same media type, but use 604 different capabilities of that type, be in different languages, 605 etc. 607 Any response containing an entity-body MAY be subject to negotiation, 608 including error responses. 610 There are two kinds of content negotiation which are possible in 611 HTTP: server-driven and agent-driven negotiation. These two kinds of 612 negotiation are orthogonal and thus may be used separately or in 613 combination. One method of combination, referred to as transparent 614 negotiation, occurs when a cache uses the agent-driven negotiation 615 information provided by the origin server in order to provide server- 616 driven negotiation for subsequent requests. 618 4.1. Server-driven Negotiation 620 If the selection of the best representation for a response is made by 621 an algorithm located at the server, it is called server-driven 622 negotiation. Selection is based on the available representations of 623 the response (the dimensions over which it can vary; e.g. language, 624 content-coding, etc.) and the contents of particular header fields in 625 the request message or on other information pertaining to the request 626 (such as the network address of the client). 628 Server-driven negotiation is advantageous when the algorithm for 629 selecting from among the available representations is difficult to 630 describe to the user agent, or when the server desires to send its 631 "best guess" to the client along with the first response (hoping to 632 avoid the round-trip delay of a subsequent request if the "best 633 guess" is good enough for the user). In order to improve the 634 server's guess, the user agent MAY include request header fields 635 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 636 preferences for such a response. 638 Server-driven negotiation has disadvantages: 640 1. It is impossible for the server to accurately determine what 641 might be "best" for any given user, since that would require 642 complete knowledge of both the capabilities of the user agent and 643 the intended use for the response (e.g., does the user want to 644 view it on screen or print it on paper?). 646 2. Having the user agent describe its capabilities in every request 647 can be both very inefficient (given that only a small percentage 648 of responses have multiple representations) and a potential 649 violation of the user's privacy. 651 3. It complicates the implementation of an origin server and the 652 algorithms for generating responses to a request. 654 4. It may limit a public cache's ability to use the same response 655 for multiple user's requests. 657 HTTP/1.1 includes the following request-header fields for enabling 658 server-driven negotiation through description of user agent 659 capabilities and user preferences: Accept (Section 5.1), Accept- 660 Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language 661 (Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an 662 origin server is not limited to these dimensions and MAY vary the 663 response based on any aspect of the request, including information 664 outside the request-header fields or within extension header fields 665 not defined by this specification. 667 The Vary header field (Section 3.5 of [Part6]) can be used to express 668 the parameters the server uses to select a representation that is 669 subject to server-driven negotiation. 671 4.2. Agent-driven Negotiation 673 With agent-driven negotiation, selection of the best representation 674 for a response is performed by the user agent after receiving an 675 initial response from the origin server. Selection is based on a 676 list of the available representations of the response included within 677 the header fields or entity-body of the initial response, with each 678 representation identified by its own URI. Selection from among the 679 representations may be performed automatically (if the user agent is 680 capable of doing so) or manually by the user selecting from a 681 generated (possibly hypertext) menu. 683 Agent-driven negotiation is advantageous when the response would vary 684 over commonly-used dimensions (such as type, language, or encoding), 685 when the origin server is unable to determine a user agent's 686 capabilities from examining the request, and generally when public 687 caches are used to distribute server load and reduce network usage. 689 Agent-driven negotiation suffers from the disadvantage of needing a 690 second request to obtain the best alternate representation. This 691 second request is only efficient when caching is used. In addition, 692 this specification does not define any mechanism for supporting 693 automatic selection, though it also does not prevent any such 694 mechanism from being developed as an extension and used within 695 HTTP/1.1. 697 HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) 698 status codes for enabling agent-driven negotiation when the server is 699 unwilling or unable to provide a varying response using server-driven 700 negotiation. 702 4.3. Transparent Negotiation 704 Transparent negotiation is a combination of both server-driven and 705 agent-driven negotiation. When a cache is supplied with a form of 706 the list of available representations of the response (as in agent- 707 driven negotiation) and the dimensions of variance are completely 708 understood by the cache, then the cache becomes capable of performing 709 server-driven negotiation on behalf of the origin server for 710 subsequent requests on that resource. 712 Transparent negotiation has the advantage of distributing the 713 negotiation work that would otherwise be required of the origin 714 server and also removing the second request delay of agent-driven 715 negotiation when the cache is able to correctly guess the right 716 response. 718 This specification does not define any mechanism for transparent 719 negotiation, though it also does not prevent any such mechanism from 720 being developed as an extension that could be used within HTTP/1.1. 722 5. Header Field Definitions 724 This section defines the syntax and semantics of HTTP/1.1 header 725 fields related to the payload of messages. 727 For entity-header fields, both sender and recipient refer to either 728 the client or the server, depending on who sends and who receives the 729 entity. 731 5.1. Accept 733 The "Accept" request-header field can be used by user agents to 734 specify response media types that are acceptable. Accept headers can 735 be used to indicate that the request is specifically limited to a 736 small set of desired types, as in the case of a request for an in- 737 line image. 739 Accept = "Accept" ":" OWS Accept-v 740 Accept-v = #( media-range [ accept-params ] ) 742 media-range = ( "*/*" 743 / ( type "/" "*" ) 744 / ( type "/" subtype ) 745 ) *( OWS ";" OWS parameter ) 746 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 747 accept-ext = OWS ";" OWS token 748 [ "=" ( token / quoted-string ) ] 750 The asterisk "*" character is used to group media types into ranges, 751 with "*/*" indicating all media types and "type/*" indicating all 752 subtypes of that type. The media-range MAY include media type 753 parameters that are applicable to that range. 755 Each media-range MAY be followed by one or more accept-params, 756 beginning with the "q" parameter for indicating a relative quality 757 factor. The first "q" parameter (if any) separates the media-range 758 parameter(s) from the accept-params. Quality factors allow the user 759 or user agent to indicate the relative degree of preference for that 760 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 761 [Part1]). The default value is q=1. 763 Note: Use of the "q" parameter name to separate media type 764 parameters from Accept extension parameters is due to historical 765 practice. Although this prevents any media type parameter named 766 "q" from being used with a media range, such an event is believed 767 to be unlikely given the lack of any "q" parameters in the IANA 768 media type registry and the rare usage of any media type 769 parameters in Accept. Future media types are discouraged from 770 registering any parameter named "q". 772 The example 774 Accept: audio/*; q=0.2, audio/basic 776 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 777 type if it is the best available after an 80% mark-down in quality." 778 If no Accept header field is present, then it is assumed that the 779 client accepts all media types. If an Accept header field is 780 present, and if the server cannot send a response which is acceptable 781 according to the combined Accept field value, then the server SHOULD 782 send a 406 (Not Acceptable) response. 784 A more elaborate example is 786 Accept: text/plain; q=0.5, text/html, 787 text/x-dvi; q=0.8, text/x-c 789 Verbally, this would be interpreted as "text/html and text/x-c are 790 the preferred media types, but if they do not exist, then send the 791 text/x-dvi entity, and if that does not exist, send the text/plain 792 entity." 794 Media ranges can be overridden by more specific media ranges or 795 specific media types. If more than one media range applies to a 796 given type, the most specific reference has precedence. For example, 798 Accept: text/*, text/html, text/html;level=1, */* 800 have the following precedence: 802 1. text/html;level=1 804 2. text/html 806 3. text/* 808 4. */* 810 The media type quality factor associated with a given type is 811 determined by finding the media range with the highest precedence 812 which matches that type. For example, 814 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 815 text/html;level=2;q=0.4, */*;q=0.5 817 would cause the following values to be associated: 819 +-------------------+---------------+ 820 | Media Type | Quality Value | 821 +-------------------+---------------+ 822 | text/html;level=1 | 1 | 823 | text/html | 0.7 | 824 | text/plain | 0.3 | 825 | image/jpeg | 0.5 | 826 | text/html;level=2 | 0.4 | 827 | text/html;level=3 | 0.7 | 828 +-------------------+---------------+ 830 Note: A user agent might be provided with a default set of quality 831 values for certain media ranges. However, unless the user agent is a 832 closed system which cannot interact with other rendering agents, this 833 default set ought to be configurable by the user. 835 5.2. Accept-Charset 837 The "Accept-Charset" request-header field can be used by user agents 838 to indicate what response character sets are acceptable. This field 839 allows clients capable of understanding more comprehensive or 840 special-purpose character sets to signal that capability to a server 841 which is capable of representing documents in those character sets. 843 Accept-Charset = "Accept-Charset" ":" OWS 844 Accept-Charset-v 845 Accept-Charset-v = 1#( ( charset / "*" ) 846 [ OWS ";" OWS "q=" qvalue ] ) 848 Character set values are described in Section 2.1. Each charset MAY 849 be given an associated quality value which represents the user's 850 preference for that charset. The default value is q=1. An example 851 is 853 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 855 The special value "*", if present in the Accept-Charset field, 856 matches every character set (including ISO-8859-1) which is not 857 mentioned elsewhere in the Accept-Charset field. If no "*" is 858 present in an Accept-Charset field, then all character sets not 859 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 860 which gets a quality value of 1 if not explicitly mentioned. 862 If no Accept-Charset header is present, the default is that any 863 character set is acceptable. If an Accept-Charset header is present, 864 and if the server cannot send a response which is acceptable 865 according to the Accept-Charset header, then the server SHOULD send 866 an error response with the 406 (Not Acceptable) status code, though 867 the sending of an unacceptable response is also allowed. 869 5.3. Accept-Encoding 871 The "Accept-Encoding" request-header field can be used by user agents 872 to indicate what response content-codings (Section 2.2) are 873 acceptable in the response. 875 Accept-Encoding = "Accept-Encoding" ":" OWS 876 Accept-Encoding-v 877 Accept-Encoding-v = 878 #( codings [ OWS ";" OWS "q=" qvalue ] ) 879 codings = ( content-coding / "*" ) 881 Each codings value MAY be given an associated quality value which 882 represents the preference for that encoding. The default value is 883 q=1. 885 Examples of its use are: 887 Accept-Encoding: compress, gzip 888 Accept-Encoding: 889 Accept-Encoding: * 890 Accept-Encoding: compress;q=0.5, gzip;q=1.0 891 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 893 A server tests whether a content-coding is acceptable, according to 894 an Accept-Encoding field, using these rules: 896 1. If the content-coding is one of the content-codings listed in the 897 Accept-Encoding field, then it is acceptable, unless it is 898 accompanied by a qvalue of 0. (As defined in Section 6.4 of 899 [Part1], a qvalue of 0 means "not acceptable.") 901 2. The special "*" symbol in an Accept-Encoding field matches any 902 available content-coding not explicitly listed in the header 903 field. 905 3. If multiple content-codings are acceptable, then the acceptable 906 content-coding with the highest non-zero qvalue is preferred. 908 4. The "identity" content-coding is always acceptable, unless 909 specifically refused because the Accept-Encoding field includes 910 "identity;q=0", or because the field includes "*;q=0" and does 911 not explicitly include the "identity" content-coding. If the 912 Accept-Encoding field-value is empty, then only the "identity" 913 encoding is acceptable. 915 If an Accept-Encoding field is present in a request, and if the 916 server cannot send a response which is acceptable according to the 917 Accept-Encoding header, then the server SHOULD send an error response 918 with the 406 (Not Acceptable) status code. 920 If no Accept-Encoding field is present in a request, the server MAY 921 assume that the client will accept any content coding. In this case, 922 if "identity" is one of the available content-codings, then the 923 server SHOULD use the "identity" content-coding, unless it has 924 additional information that a different content-coding is meaningful 925 to the client. 927 Note: If the request does not include an Accept-Encoding field, 928 and if the "identity" content-coding is unavailable, then content- 929 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 930 "compress") are preferred; some older clients improperly display 931 messages sent with other content-codings. The server might also 932 make this decision based on information about the particular user- 933 agent or client. 935 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 936 associated with content-codings. This means that qvalues will not 937 work and are not permitted with x-gzip or x-compress. 939 5.4. Accept-Language 941 The "Accept-Language" request-header field can be used by user agents 942 to indicate the set of natural languages that are preferred in the 943 response. Language tags are defined in Section 2.4. 945 Accept-Language = "Accept-Language" ":" OWS 946 Accept-Language-v 947 Accept-Language-v = 948 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 949 language-range = 950 952 Each language-range can be given an associated quality value which 953 represents an estimate of the user's preference for the languages 954 specified by that range. The quality value defaults to "q=1". For 955 example, 957 Accept-Language: da, en-gb;q=0.8, en;q=0.7 959 would mean: "I prefer Danish, but will accept British English and 960 other types of English." 962 For matching, the "Basic Filtering" matching scheme, defined in 963 Section 3.3.1 of [RFC4647], is used: 965 A language range matches a particular language tag if, in a case- 966 insensitive comparison, it exactly equals the tag, or if it 967 exactly equals a prefix of the tag such that the first character 968 following the prefix is "-". 970 The special range "*", if present in the Accept-Language field, 971 matches every tag not matched by any other range present in the 972 Accept-Language field. 974 Note: This use of a prefix matching rule does not imply that 975 language tags are assigned to languages in such a way that it is 976 always true that if a user understands a language with a certain 977 tag, then this user will also understand all languages with tags 978 for which this tag is a prefix. The prefix rule simply allows the 979 use of prefix tags if this is the case. 981 The language quality factor assigned to a language-tag by the Accept- 982 Language field is the quality value of the longest language-range in 983 the field that matches the language-tag. If no language-range in the 984 field matches the tag, the language quality factor assigned is 0. If 985 no Accept-Language header is present in the request, the server 986 SHOULD assume that all languages are equally acceptable. If an 987 Accept-Language header is present, then all languages which are 988 assigned a quality factor greater than 0 are acceptable. 990 It might be contrary to the privacy expectations of the user to send 991 an Accept-Language header with the complete linguistic preferences of 992 the user in every request. For a discussion of this issue, see 993 Section 7.1. 995 As intelligibility is highly dependent on the individual user, it is 996 recommended that client applications make the choice of linguistic 997 preference available to the user. If the choice is not made 998 available, then the Accept-Language header field MUST NOT be given in 999 the request. 1001 Note: When making the choice of linguistic preference available to 1002 the user, we remind implementors of the fact that users are not 1003 familiar with the details of language matching as described above, 1004 and should provide appropriate guidance. As an example, users 1005 might assume that on selecting "en-gb", they will be served any 1006 kind of English document if British English is not available. A 1007 user agent might suggest in such a case to add "en" to get the 1008 best matching behavior. 1010 5.5. Content-Encoding 1012 The "Content-Encoding" entity-header field indicates what content- 1013 codings have been applied to the entity-body, and thus what decoding 1014 mechanisms must be applied in order to obtain the media-type 1015 referenced by the Content-Type header field. Content-Encoding is 1016 primarily used to allow a document to be compressed without losing 1017 the identity of its underlying media type. 1019 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 1020 Content-Encoding-v = 1#content-coding 1022 Content codings are defined in Section 2.2. An example of its use is 1024 Content-Encoding: gzip 1026 The content-coding is a characteristic of the entity identified by 1027 the request-target. Typically, the entity-body is stored with this 1028 encoding and is only decoded before rendering or analogous usage. 1029 However, a non-transparent proxy MAY modify the content-coding if the 1030 new coding is known to be acceptable to the recipient, unless the 1031 "no-transform" cache-control directive is present in the message. 1033 If the content-coding of an entity is not "identity", then the 1034 response MUST include a Content-Encoding entity-header (Section 5.5) 1035 that lists the non-identity content-coding(s) used. 1037 If the content-coding of an entity in a request message is not 1038 acceptable to the origin server, the server SHOULD respond with a 1039 status code of 415 (Unsupported Media Type). 1041 If multiple encodings have been applied to an entity, the content 1042 codings MUST be listed in the order in which they were applied. 1043 Additional information about the encoding parameters MAY be provided 1044 by other entity-header fields not defined by this specification. 1046 5.6. Content-Language 1048 The "Content-Language" entity-header field describes the natural 1049 language(s) of the intended audience for the entity. Note that this 1050 might not be equivalent to all the languages used within the entity- 1051 body. 1053 Content-Language = "Content-Language" ":" OWS Content-Language-v 1054 Content-Language-v = 1#language-tag 1056 Language tags are defined in Section 2.4. The primary purpose of 1057 Content-Language is to allow a user to identify and differentiate 1058 entities according to the user's own preferred language. Thus, if 1059 the body content is intended only for a Danish-literate audience, the 1060 appropriate field is 1062 Content-Language: da 1064 If no Content-Language is specified, the default is that the content 1065 is intended for all language audiences. This might mean that the 1066 sender does not consider it to be specific to any natural language, 1067 or that the sender does not know for which language it is intended. 1069 Multiple languages MAY be listed for content that is intended for 1070 multiple audiences. For example, a rendition of the "Treaty of 1071 Waitangi," presented simultaneously in the original Maori and English 1072 versions, would call for 1074 Content-Language: mi, en 1076 However, just because multiple languages are present within an entity 1077 does not mean that it is intended for multiple linguistic audiences. 1078 An example would be a beginner's language primer, such as "A First 1079 Lesson in Latin," which is clearly intended to be used by an English- 1080 literate audience. In this case, the Content-Language would properly 1081 only include "en". 1083 Content-Language MAY be applied to any media type -- it is not 1084 limited to textual documents. 1086 5.7. Content-Location 1088 The "Content-Location" entity-header field is used to supply a URI 1089 for the entity in the message when it is accessible from a location 1090 separate from the requested resource's URI. 1092 A server SHOULD provide a Content-Location for the variant 1093 corresponding to the response entity, especially in the case where a 1094 resource has multiple entities associated with it, and those entities 1095 actually have separate locations by which they might be individually 1096 accessed, the server SHOULD provide a Content-Location for the 1097 particular variant which is returned. 1099 Content-Location = "Content-Location" ":" OWS 1100 Content-Location-v 1101 Content-Location-v = 1102 absolute-URI / partial-URI 1104 The Content-Location value is not a replacement for the original 1105 requested URI; it is only a statement of the location of the resource 1106 corresponding to this particular entity at the time of the request. 1107 Future requests MAY specify the Content-Location URI as the request- 1108 target if the desire is to identify the source of that particular 1109 entity. 1111 Section 6.1 of [Part2] describes how clients may process the Content- 1112 Location header field. 1114 A cache cannot assume that an entity with a Content-Location 1115 different from the URI used to retrieve it can be used to respond to 1116 later requests on that Content-Location URI. However, the Content- 1117 Location can be used to differentiate between multiple entities 1118 retrieved from a single requested resource, as described in Section 1119 2.6 of [Part6]. 1121 If the Content-Location is a relative URI, the relative URI is 1122 interpreted relative to the request-target. 1124 The meaning of the Content-Location header in requests is undefined; 1125 servers are free to ignore it in those cases. 1127 5.8. Content-MD5 1129 The "Content-MD5" entity-header field, as defined in [RFC1864], is an 1130 MD5 digest of the entity-body that provides an end-to-end message 1131 integrity check (MIC) of the entity-body. Note that a MIC is good 1132 for detecting accidental modification of the entity-body in transit, 1133 but is not proof against malicious attacks. 1135 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1136 Content-MD5-v = 1138 The Content-MD5 header field MAY be generated by an origin server or 1139 client to function as an integrity check of the entity-body. Only 1140 origin servers or clients MAY generate the Content-MD5 header field; 1141 proxies and gateways MUST NOT generate it, as this would defeat its 1142 value as an end-to-end integrity check. Any recipient of the entity- 1143 body, including gateways and proxies, MAY check that the digest value 1144 in this header field matches that of the entity-body as received. 1146 The MD5 digest is computed based on the content of the entity-body, 1147 including any content-coding that has been applied, but not including 1148 any transfer-encoding applied to the message-body. If the message is 1149 received with a transfer-encoding, that encoding MUST be removed 1150 prior to checking the Content-MD5 value against the received entity. 1152 This has the result that the digest is computed on the octets of the 1153 entity-body exactly as, and in the order that, they would be sent if 1154 no transfer-encoding were being applied. 1156 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1157 composite media-types (e.g., multipart/* and message/rfc822), but 1158 this does not change how the digest is computed as defined in the 1159 preceding paragraph. 1161 There are several consequences of this. The entity-body for 1162 composite types MAY contain many body-parts, each with its own MIME 1163 and HTTP headers (including Content-MD5, Content-Transfer-Encoding, 1164 and Content-Encoding headers). If a body-part has a Content- 1165 Transfer-Encoding or Content-Encoding header, it is assumed that the 1166 content of the body-part has had the encoding applied, and the body- 1167 part is included in the Content-MD5 digest as is -- i.e., after the 1168 application. The Transfer-Encoding header field is not allowed 1169 within body-parts. 1171 Conversion of all line breaks to CRLF MUST NOT be done before 1172 computing or checking the digest: the line break convention used in 1173 the text actually transmitted MUST be left unaltered when computing 1174 the digest. 1176 Note: while the definition of Content-MD5 is exactly the same for 1177 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1178 in which the application of Content-MD5 to HTTP entity-bodies 1179 differs from its application to MIME entity-bodies. One is that 1180 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1181 does use Transfer-Encoding and Content-Encoding. Another is that 1182 HTTP more frequently uses binary content types than MIME, so it is 1183 worth noting that, in such cases, the byte order used to compute 1184 the digest is the transmission byte order defined for the type. 1185 Lastly, HTTP allows transmission of text types with any of several 1186 line break conventions and not just the canonical form using CRLF. 1188 5.9. Content-Type 1190 The "Content-Type" entity-header field indicates the media type of 1191 the entity-body. In the case of responses to the HEAD method, the 1192 media type is that which would have been sent had the request been a 1193 GET. 1195 Content-Type = "Content-Type" ":" OWS Content-Type-v 1196 Content-Type-v = media-type 1198 Media types are defined in Section 2.3. An example of the field is 1200 Content-Type: text/html; charset=ISO-8859-4 1202 Further discussion of methods for identifying the media type of an 1203 entity is provided in Section 3.2.1. 1205 6. IANA Considerations 1207 6.1. Message Header Registration 1209 The Message Header Registry located at should be 1211 updated with the permanent registrations below (see [RFC3864]): 1213 +---------------------+----------+----------+--------------+ 1214 | Header Field Name | Protocol | Status | Reference | 1215 +---------------------+----------+----------+--------------+ 1216 | Accept | http | standard | Section 5.1 | 1217 | Accept-Charset | http | standard | Section 5.2 | 1218 | Accept-Encoding | http | standard | Section 5.3 | 1219 | Accept-Language | http | standard | Section 5.4 | 1220 | Content-Disposition | http | | Appendix B.1 | 1221 | Content-Encoding | http | standard | Section 5.5 | 1222 | Content-Language | http | standard | Section 5.6 | 1223 | Content-Location | http | standard | Section 5.7 | 1224 | Content-MD5 | http | standard | Section 5.8 | 1225 | Content-Type | http | standard | Section 5.9 | 1226 | MIME-Version | http | | Appendix A.1 | 1227 +---------------------+----------+----------+--------------+ 1229 The change controller is: "IETF (iesg@ietf.org) - Internet 1230 Engineering Task Force". 1232 6.2. Content Coding Registry 1234 The registration procedure for HTTP Content Codings is now defined by 1235 Section 2.2.1 of this document. 1237 The HTTP Content Codings Registry located at 1238 should be updated 1239 with the registration below: 1241 +----------+-----------------------------------+--------------------+ 1242 | Name | Description | Reference | 1243 +----------+-----------------------------------+--------------------+ 1244 | compress | UNIX "compress" program method | Section 6.2.2.1 of | 1245 | | | [Part1] | 1246 | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of | 1247 | | "deflate" compression | [Part1] | 1248 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 of | 1249 | | | [Part1] | 1250 | identity | No transformation | Section 2.2 | 1251 +----------+-----------------------------------+--------------------+ 1253 7. Security Considerations 1255 This section is meant to inform application developers, information 1256 providers, and users of the security limitations in HTTP/1.1 as 1257 described by this document. The discussion does not include 1258 definitive solutions to the problems revealed, though it does make 1259 some suggestions for reducing security risks. 1261 7.1. Privacy Issues Connected to Accept Headers 1263 Accept request-headers can reveal information about the user to all 1264 servers which are accessed. The Accept-Language header in particular 1265 can reveal information the user would consider to be of a private 1266 nature, because the understanding of particular languages is often 1267 strongly correlated to the membership of a particular ethnic group. 1268 User agents which offer the option to configure the contents of an 1269 Accept-Language header to be sent in every request are strongly 1270 encouraged to let the configuration process include a message which 1271 makes the user aware of the loss of privacy involved. 1273 An approach that limits the loss of privacy would be for a user agent 1274 to omit the sending of Accept-Language headers by default, and to ask 1275 the user whether or not to start sending Accept-Language headers to a 1276 server if it detects, by looking for any Vary response-header fields 1277 generated by the server, that such sending could improve the quality 1278 of service. 1280 Elaborate user-customized accept header fields sent in every request, 1281 in particular if these include quality values, can be used by servers 1282 as relatively reliable and long-lived user identifiers. Such user 1283 identifiers would allow content providers to do click-trail tracking, 1284 and would allow collaborating content providers to match cross-server 1285 click-trails or form submissions of individual users. Note that for 1286 many users not behind a proxy, the network address of the host 1287 running the user agent will also serve as a long-lived user 1288 identifier. In environments where proxies are used to enhance 1289 privacy, user agents ought to be conservative in offering accept 1290 header configuration options to end users. As an extreme privacy 1291 measure, proxies could filter the accept headers in relayed requests. 1292 General purpose user agents which provide a high degree of header 1293 configurability SHOULD warn users about the loss of privacy which can 1294 be involved. 1296 7.2. Content-Disposition Issues 1298 [RFC2183], from which the often implemented Content-Disposition (see 1299 Appendix B.1) header in HTTP is derived, has a number of very serious 1300 security considerations. Content-Disposition is not part of the HTTP 1301 standard, but since it is widely implemented, we are documenting its 1302 use and risks for implementors. See Section 5 of [RFC2183] for 1303 details. 1305 8. Acknowledgments 1307 9. References 1309 9.1. Normative References 1311 [ISO-8859-1] 1312 International Organization for Standardization, 1313 "Information technology -- 8-bit single-byte coded graphic 1314 character sets -- Part 1: Latin alphabet No. 1", ISO/ 1315 IEC 8859-1:1998, 1998. 1317 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1318 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1319 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1320 and Message Parsing", draft-ietf-httpbis-p1-messaging-08 1321 (work in progress), October 2009. 1323 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1324 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1325 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1326 Semantics", draft-ietf-httpbis-p2-semantics-08 (work in 1327 progress), October 2009. 1329 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1330 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1331 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1332 Requests", draft-ietf-httpbis-p4-conditional-08 (work in 1333 progress), October 2009. 1335 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1336 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1337 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1338 Partial Responses", draft-ietf-httpbis-p5-range-08 (work 1339 in progress), October 2009. 1341 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1342 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1343 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1344 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 1345 progress), October 2009. 1347 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1348 RFC 1864, October 1995. 1350 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1351 Specification version 3.3", RFC 1950, May 1996. 1353 RFC 1950 is an Informational RFC, thus it may be less 1354 stable than this specification. On the other hand, this 1355 downward reference was present since the publication of 1356 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1357 cause problems in practice. See also [BCP97]. 1359 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1360 Randers-Pehrson, "GZIP file format specification version 1361 4.3", RFC 1952, May 1996. 1363 RFC 1952 is an Informational RFC, thus it may be less 1364 stable than this specification. On the other hand, this 1365 downward reference was present since the publication of 1366 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1367 cause problems in practice. See also [BCP97]. 1369 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1370 Extensions (MIME) Part One: Format of Internet Message 1371 Bodies", RFC 2045, November 1996. 1373 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1374 Extensions (MIME) Part Two: Media Types", RFC 2046, 1375 November 1996. 1377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1378 Requirement Levels", BCP 14, RFC 2119, March 1997. 1380 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1381 Tags", BCP 47, RFC 4647, September 2006. 1383 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1384 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1386 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1387 Languages", BCP 47, RFC 5646, September 2009. 1389 9.2. Informative References 1391 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 1392 to Standards-Track Documents", BCP 97, RFC 4897, 1393 June 2007. 1395 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1396 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1398 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1399 Extensions (MIME) Part Five: Conformance Criteria and 1400 Examples", RFC 2049, November 1996. 1402 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1403 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1404 RFC 2068, January 1997. 1406 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1407 February 1997. 1409 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1410 Presentation Information in Internet Messages: The 1411 Content-Disposition Header Field", RFC 2183, August 1997. 1413 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1414 Languages", BCP 18, RFC 2277, January 1998. 1416 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1417 form-data", RFC 2388, August 1998. 1419 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1420 "MIME Encapsulation of Aggregate Documents, such as HTML 1421 (MHTML)", RFC 2557, March 1999. 1423 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1424 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1425 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1427 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1428 10646", RFC 3629, STD 63, November 2003. 1430 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1431 Procedures for Message Header Fields", BCP 90, RFC 3864, 1432 September 2004. 1434 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1435 Registration Procedures", BCP 13, RFC 4288, December 2005. 1437 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1438 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1439 May 2008. 1441 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1442 October 2008. 1444 Appendix A. Differences Between HTTP Entities and RFC 2045 Entities 1446 HTTP/1.1 uses many of the constructs defined for Internet Mail 1447 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1448 [RFC2045]) to allow entities to be transmitted in an open variety of 1449 representations and with extensible mechanisms. However, RFC 2045 1450 discusses mail, and HTTP has a few features that are different from 1451 those described in RFC 2045. These differences were carefully chosen 1452 to optimize performance over binary connections, to allow greater 1453 freedom in the use of new media types, to make date comparisons 1454 easier, and to acknowledge the practice of some early HTTP servers 1455 and clients. 1457 This appendix describes specific areas where HTTP differs from RFC 1458 2045. Proxies and gateways to strict MIME environments SHOULD be 1459 aware of these differences and provide the appropriate conversions 1460 where necessary. Proxies and gateways from MIME environments to HTTP 1461 also need to be aware of the differences because some conversions 1462 might be required. 1464 A.1. MIME-Version 1466 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1467 MAY include a single MIME-Version general-header field to indicate 1468 what version of the MIME protocol was used to construct the message. 1469 Use of the MIME-Version header field indicates that the message is in 1470 full compliance with the MIME protocol (as defined in [RFC2045]). 1471 Proxies/gateways are responsible for ensuring full compliance (where 1472 possible) when exporting HTTP messages to strict MIME environments. 1474 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1475 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1477 MIME version "1.0" is the default for use in HTTP/1.1. However, 1478 HTTP/1.1 message parsing and semantics are defined by this document 1479 and not the MIME specification. 1481 A.2. Conversion to Canonical Form 1483 [RFC2045] requires that an Internet mail entity be converted to 1484 canonical form prior to being transferred, as described in Section 4 1485 of [RFC2049]. Section 2.3.1 of this document describes the forms 1486 allowed for subtypes of the "text" media type when transmitted over 1487 HTTP. [RFC2046] requires that content with a type of "text" 1488 represent line breaks as CRLF and forbids the use of CR or LF outside 1489 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1490 indicate a line break within text content when a message is 1491 transmitted over HTTP. 1493 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1494 environment SHOULD translate all line breaks within the text media 1495 types described in Section 2.3.1 of this document to the RFC 2049 1496 canonical form of CRLF. Note, however, that this might be 1497 complicated by the presence of a Content-Encoding and by the fact 1498 that HTTP allows the use of some character sets which do not use 1499 octets 13 and 10 to represent CR and LF, as is the case for some 1500 multi-byte character sets. 1502 Implementors should note that conversion will break any cryptographic 1503 checksums applied to the original content unless the original content 1504 is already in canonical form. Therefore, the canonical form is 1505 recommended for any content that uses such checksums in HTTP. 1507 A.3. Conversion of Date Formats 1509 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1510 [Part1]) to simplify the process of date comparison. Proxies and 1511 gateways from other protocols SHOULD ensure that any Date header 1512 field present in a message conforms to one of the HTTP/1.1 formats 1513 and rewrite the date if necessary. 1515 A.4. Introduction of Content-Encoding 1517 RFC 2045 does not include any concept equivalent to HTTP/1.1's 1518 Content-Encoding header field. Since this acts as a modifier on the 1519 media type, proxies and gateways from HTTP to MIME-compliant 1520 protocols MUST either change the value of the Content-Type header 1521 field or decode the entity-body before forwarding the message. (Some 1522 experimental applications of Content-Type for Internet mail have used 1523 a media-type parameter of ";conversions=" to perform 1524 a function equivalent to Content-Encoding. However, this parameter 1525 is not part of RFC 2045). 1527 A.5. No Content-Transfer-Encoding 1529 HTTP does not use the Content-Transfer-Encoding field of RFC 2045. 1530 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1531 remove any Content-Transfer-Encoding prior to delivering the response 1532 message to an HTTP client. 1534 Proxies and gateways from HTTP to MIME-compliant protocols are 1535 responsible for ensuring that the message is in the correct format 1536 and encoding for safe transport on that protocol, where "safe 1537 transport" is defined by the limitations of the protocol being used. 1538 Such a proxy or gateway SHOULD label the data with an appropriate 1539 Content-Transfer-Encoding if doing so will improve the likelihood of 1540 safe transport over the destination protocol. 1542 A.6. Introduction of Transfer-Encoding 1544 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1545 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1546 to forwarding a message via a MIME-compliant protocol. 1548 A.7. MHTML and Line Length Limitations 1550 HTTP implementations which share code with MHTML [RFC2557] 1551 implementations need to be aware of MIME line length limitations. 1552 Since HTTP does not have this limitation, HTTP does not fold long 1553 lines. MHTML messages being transported by HTTP follow all 1554 conventions of MHTML, including line length limitations and folding, 1555 canonicalization, etc., since HTTP transports all message-bodies as 1556 payload (see Section 2.3.2) and does not interpret the content or any 1557 MIME header lines that might be contained therein. 1559 Appendix B. Additional Features 1561 [RFC1945] and [RFC2068] document protocol elements used by some 1562 existing HTTP implementations, but not consistently and correctly 1563 across most HTTP/1.1 applications. Implementors are advised to be 1564 aware of these features, but cannot rely upon their presence in, or 1565 interoperability with, other HTTP/1.1 applications. Some of these 1566 describe proposed experimental features, and some describe features 1567 that experimental deployment found lacking that are now addressed in 1568 the base HTTP/1.1 specification. 1570 A number of other headers, such as Content-Disposition and Title, 1571 from SMTP and MIME are also often implemented (see [RFC2076]). 1573 B.1. Content-Disposition 1575 The "Content-Disposition" response-header field has been proposed as 1576 a means for the origin server to suggest a default filename if the 1577 user requests that the content is saved to a file. This usage is 1578 derived from the definition of Content-Disposition in [RFC2183]. 1580 content-disposition = "Content-Disposition" ":" OWS 1581 content-disposition-v 1582 content-disposition-v = disposition-type 1583 *( OWS ";" OWS disposition-parm ) 1584 disposition-type = "attachment" / disp-extension-token 1585 disposition-parm = filename-parm / disp-extension-parm 1586 filename-parm = "filename" "=" quoted-string 1587 disp-extension-token = token 1588 disp-extension-parm = token "=" ( token / quoted-string ) 1590 An example is 1592 Content-Disposition: attachment; filename="fname.ext" 1594 The receiving user agent SHOULD NOT respect any directory path 1595 information present in the filename-parm parameter, which is the only 1596 parameter believed to apply to HTTP implementations at this time. 1597 The filename SHOULD be treated as a terminal component only. 1599 If this header is used in a response with the application/ 1600 octet-stream content-type, the implied suggestion is that the user 1601 agent should not display the response, but directly enter a `save 1602 response as...' dialog. 1604 See Section 7.2 for Content-Disposition security issues. 1606 Appendix C. Compatibility with Previous Versions 1608 C.1. Changes from RFC 2068 1610 Transfer-coding and message lengths all interact in ways that 1611 required fixing exactly when chunked encoding is used (to allow for 1612 transfer encoding that may not be self delimiting); it was important 1613 to straighten out exactly how message lengths are computed. 1614 (Section 3.2.2, see also [Part1], [Part5] and [Part6]). 1616 Charset wildcarding is introduced to avoid explosion of character set 1617 names in accept headers. (Section 5.2) 1619 Content-Base was deleted from the specification: it was not 1620 implemented widely, and there is no simple, safe way to introduce it 1621 without a robust extension mechanism. In addition, it is used in a 1622 similar, but not identical fashion in MHTML [RFC2557]. 1624 A content-coding of "identity" was introduced, to solve problems 1625 discovered in caching. (Section 2.2) 1627 The Alternates, Content-Version, Derived-From, Link, URI, Public and 1628 Content-Base header fields were defined in previous versions of this 1629 specification, but not commonly implemented. See Section 19.6.2 of 1630 [RFC2068]. 1632 C.2. Changes from RFC 2616 1634 Clarify contexts that charset is used in. (Section 2.1) 1636 Remove base URI setting semantics for Content-Location due to poor 1637 implementation support, which was caused by too many broken servers 1638 emitting bogus Content-Location headers, and also the potentially 1639 undesirable effect of potentially breaking relative links in content- 1640 negotiated resources. (Section 5.7) 1642 Remove reference to non-existant identity transfer-coding value 1643 tokens. (Appendix A.5) 1645 Appendix D. Collected ABNF 1647 Accept = "Accept:" OWS Accept-v 1648 Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v 1649 Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1650 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1651 qvalue ] ] ) 1652 Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v 1653 Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) 1654 ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1655 Accept-Language = "Accept-Language:" OWS Accept-Language-v 1656 Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1657 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1658 ] ) 1659 Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1660 OWS media-range [ accept-params ] ] ) ] 1662 Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v 1663 Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS 1664 content-coding ] ) 1665 Content-Language = "Content-Language:" OWS Content-Language-v 1666 Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS 1667 language-tag ] ) 1668 Content-Length = 1669 Content-Location = "Content-Location:" OWS Content-Location-v 1670 Content-Location-v = absolute-URI / partial-URI 1671 Content-MD5 = "Content-MD5:" OWS Content-MD5-v 1672 Content-MD5-v = 1673 Content-Range = 1674 Content-Type = "Content-Type:" OWS Content-Type-v 1675 Content-Type-v = media-type 1677 Expires = 1679 Last-Modified = 1681 MIME-Version = "MIME-Version:" OWS MIME-Version-v 1682 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1684 OWS = 1686 absolute-URI = 1687 accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 1688 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1689 attribute = token 1691 charset = token 1692 codings = ( content-coding / "*" ) 1693 content-coding = token 1694 content-disposition = "Content-Disposition:" OWS 1695 content-disposition-v 1696 content-disposition-v = disposition-type *( OWS ";" OWS 1697 disposition-parm ) 1699 disp-extension-parm = token "=" ( token / quoted-string ) 1700 disp-extension-token = token 1701 disposition-parm = filename-parm / disp-extension-parm 1702 disposition-type = "attachment" / disp-extension-token 1704 entity-body = *OCTET 1705 entity-header = Content-Encoding / Content-Language / Content-Length 1706 / Content-Location / Content-MD5 / Content-Range / Content-Type / 1707 Expires / Last-Modified / extension-header 1708 extension-header = header-field 1710 filename-parm = "filename=" quoted-string 1712 header-field = 1713 language-range = 1714 language-tag = 1716 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1717 ";" OWS parameter ) 1718 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1720 parameter = attribute "=" value 1721 partial-URI = 1723 quoted-string = 1724 qvalue = 1726 subtype = token 1728 token = 1729 type = token 1731 value = token / quoted-string 1733 ABNF diagnostics: 1735 ; Accept defined but not used 1736 ; Accept-Charset defined but not used 1737 ; Accept-Encoding defined but not used 1738 ; Accept-Language defined but not used 1739 ; MIME-Version defined but not used 1740 ; content-disposition defined but not used 1741 ; entity-body defined but not used 1742 ; entity-header defined but not used 1744 Appendix E. Change Log (to be removed by RFC Editor before publication) 1746 E.1. Since RFC2616 1748 Extracted relevant partitions from [RFC2616]. 1750 E.2. Since draft-ietf-httpbis-p3-payload-00 1752 Closed issues: 1754 o : "Media Type 1755 Registrations" () 1757 o : "Clarification 1758 regarding quoting of charset values" 1759 () 1761 o : "Remove 1762 'identity' token references" 1763 () 1765 o : "Accept- 1766 Encoding BNF" 1768 o : "Normative and 1769 Informative references" 1771 o : "RFC1700 1772 references" 1774 o : "Updating to 1775 RFC4288" 1777 o : "Informative 1778 references" 1780 o : "ISO-8859-1 1781 Reference" 1783 o : "Encoding 1784 References Normative" 1786 o : "Normative up- 1787 to-date references" 1789 E.3. Since draft-ietf-httpbis-p3-payload-01 1791 Ongoing work on ABNF conversion 1792 (): 1794 o Add explicit references to BNF syntax and rules imported from 1795 other parts of the specification. 1797 E.4. Since draft-ietf-httpbis-p3-payload-02 1799 Closed issues: 1801 o : "Quoting 1802 Charsets" 1804 o : 1805 "Classification for Allow header" 1807 o : "missing 1808 default for qvalue in description of Accept-Encoding" 1810 Ongoing work on IANA Message Header Registration 1811 (): 1813 o Reference RFC 3984, and update header registrations for headers 1814 defined in this document. 1816 E.5. Since draft-ietf-httpbis-p3-payload-03 1818 Closed issues: 1820 o : "Quoting 1821 Charsets" 1823 o : "language tag 1824 matching (Accept-Language) vs RFC4647" 1826 o : "RFC 1806 has 1827 been replaced by RFC2183" 1829 Other changes: 1831 o : "Encoding 1832 References Normative" -- rephrase the annotation and reference 1833 [BCP97]. 1835 E.6. Since draft-ietf-httpbis-p3-payload-04 1837 Closed issues: 1839 o : "RFC 2822 is 1840 updated by RFC 5322" 1842 Ongoing work on ABNF conversion 1843 (): 1845 o Use "/" instead of "|" for alternatives. 1847 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1848 whitespace ("OWS") and required whitespace ("RWS"). 1850 o Rewrite ABNFs to spell out whitespace rules, factor out header 1851 value format definitions. 1853 E.7. Since draft-ietf-httpbis-p3-payload-05 1855 Closed issues: 1857 o : "Join 1858 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1860 Final work on ABNF conversion 1861 (): 1863 o Add appendix containing collected and expanded ABNF, reorganize 1864 ABNF introduction. 1866 Other changes: 1868 o Move definition of quality values into Part 1. 1870 E.8. Since draft-ietf-httpbis-p3-payload-06 1872 Closed issues: 1874 o : "Content- 1875 Location isn't special" 1877 o : "Content 1878 Sniffing" 1880 E.9. Since draft-ietf-httpbis-p3-payload-07 1882 Closed issues: 1884 o : "Updated 1885 reference for language tags" 1887 o : "Clarify rules 1888 for determining what entities a response carries" 1890 o : "Content- 1891 Location base-setting problems" 1893 o : "Content 1894 Sniffing" 1896 o : "pick IANA 1897 policy (RFC5226) for Transfer Coding / Content Coding" 1899 o : "move 1900 definitions of gzip/deflate/compress to part 1" 1902 Partly resolved issues: 1904 o : "update IANA 1905 requirements wrt Transfer-Coding values" (add the IANA 1906 Considerations subsection) 1908 o : "update IANA 1909 requirements wrt Content-Coding values" (add the IANA 1910 Considerations subsection) 1912 Index 1914 A 1915 Accept header 17 1916 Accept-Charset header 19 1917 Accept-Encoding header 20 1918 Accept-Language header 21 1919 Alternates header 36 1921 C 1922 Coding Format 1923 compress 8 1924 deflate 8 1925 gzip 9 1926 identity 9 1927 compress (Coding Format) 8 1928 content negotiation 5 1929 Content-Base header 36 1930 Content-Disposition header 35 1931 Content-Encoding header 23 1932 Content-Language header 23 1933 Content-Location header 24 1934 Content-MD5 header 25 1935 Content-Type header 26 1936 Content-Version header 36 1938 D 1939 deflate (Coding Format) 8 1940 Derived-From header 36 1942 E 1943 entity 5 1945 G 1946 Grammar 1947 Accept 17 1948 Accept-Charset 19 1949 Accept-Charset-v 19 1950 Accept-Encoding 20 1951 Accept-Encoding-v 20 1952 accept-ext 17 1953 Accept-Language 21 1954 Accept-Language-v 21 1955 accept-params 17 1956 Accept-v 17 1957 attribute 10 1958 charset 7 1959 codings 20 1960 content-coding 8 1961 content-disposition 35 1962 content-disposition-v 35 1963 Content-Encoding 23 1964 Content-Encoding-v 23 1965 Content-Language 23 1966 Content-Language-v 23 1967 Content-Location 24 1968 Content-Location-v 24 1969 Content-MD5 25 1970 Content-MD5-v 25 1971 Content-Type 26 1972 Content-Type-v 26 1973 disp-extension-parm 35 1974 disp-extension-token 35 1975 disposition-parm 35 1976 disposition-type 35 1977 entity-body 13 1978 entity-header 12 1979 extension-header 12 1980 filename-parm 35 1981 language-range 21 1982 language-tag 12 1983 media-range 17 1984 media-type 9 1985 MIME-Version 32 1986 MIME-Version-v 32 1987 parameter 10 1988 subtype 9 1989 type 9 1990 value 10 1991 gzip (Coding Format) 9 1993 H 1994 Headers 1995 Accept 17 1996 Accept-Charset 19 1997 Accept-Encoding 20 1998 Accept-Language 21 1999 Alternate 36 2000 Content-Base 36 2001 Content-Disposition 35 2002 Content-Encoding 23 2003 Content-Language 23 2004 Content-Location 24 2005 Content-MD5 25 2006 Content-Type 26 2007 Content-Version 36 2008 Derived-From 36 2009 Link 36 2010 MIME-Version 32 2011 Public 36 2012 URI 36 2014 I 2015 identity (Coding Format) 9 2017 L 2018 Link header 36 2020 M 2021 MIME-Version header 32 2023 P 2024 Public header 36 2026 R 2027 representation 5 2029 U 2030 URI header 36 2032 V 2033 variant 5 2035 Authors' Addresses 2037 Roy T. Fielding (editor) 2038 Day Software 2039 23 Corporate Plaza DR, Suite 280 2040 Newport Beach, CA 92660 2041 USA 2043 Phone: +1-949-706-5300 2044 Fax: +1-949-706-5305 2045 Email: fielding@gbiv.com 2046 URI: http://roy.gbiv.com/ 2048 Jim Gettys 2049 One Laptop per Child 2050 21 Oak Knoll Road 2051 Carlisle, MA 01741 2052 USA 2054 Email: jg@laptop.org 2055 URI: http://www.laptop.org/ 2057 Jeffrey C. Mogul 2058 Hewlett-Packard Company 2059 HP Labs, Large Scale Systems Group 2060 1501 Page Mill Road, MS 1177 2061 Palo Alto, CA 94304 2062 USA 2064 Email: JeffMogul@acm.org 2066 Henrik Frystyk Nielsen 2067 Microsoft Corporation 2068 1 Microsoft Way 2069 Redmond, WA 98052 2070 USA 2072 Email: henrikn@microsoft.com 2073 Larry Masinter 2074 Adobe Systems, Incorporated 2075 345 Park Ave 2076 San Jose, CA 95110 2077 USA 2079 Email: LMM@acm.org 2080 URI: http://larry.masinter.net/ 2082 Paul J. Leach 2083 Microsoft Corporation 2084 1 Microsoft Way 2085 Redmond, WA 98052 2087 Email: paulle@microsoft.com 2089 Tim Berners-Lee 2090 World Wide Web Consortium 2091 MIT Computer Science and Artificial Intelligence Laboratory 2092 The Stata Center, Building 32 2093 32 Vassar Street 2094 Cambridge, MA 02139 2095 USA 2097 Email: timbl@w3.org 2098 URI: http://www.w3.org/People/Berners-Lee/ 2100 Yves Lafon (editor) 2101 World Wide Web Consortium 2102 W3C / ERCIM 2103 2004, rte des Lucioles 2104 Sophia-Antipolis, AM 06902 2105 France 2107 Email: ylafon@w3.org 2108 URI: http://www.raubacapeu.net/people/yves/ 2109 Julian F. Reschke (editor) 2110 greenbytes GmbH 2111 Hafenweg 16 2112 Muenster, NW 48155 2113 Germany 2115 Phone: +49 251 2807760 2116 Fax: +49 251 2807761 2117 Email: julian.reschke@greenbytes.de 2118 URI: http://greenbytes.de/tech/webdav/