idnits 2.17.1 draft-ietf-httpbis-p3-payload-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 8, 2010) is 5163 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-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-09 ** 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: September 9, 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 March 8, 2010 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-09 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypermedia information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 3 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines 33 HTTP message content, metadata, and content negotiation. 35 Editorial Note (To be removed by RFC Editor) 37 Discussion of this draft should take place on the HTTPBIS working 38 group mailing list (ietf-http-wg@w3.org). The current issues list is 39 at and related 40 documents (including fancy diffs) can be found at 41 . 43 The changes in this draft are summarized in Appendix E.10. 45 Status of this Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt. 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 This Internet-Draft will expire on September 9, 2010. 68 Copyright Notice 70 Copyright (c) 2010 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 97 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 98 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 99 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 100 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 101 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 102 1.3.2. ABNF Rules defined in other Parts of the 103 Specification . . . . . . . . . . . . . . . . . . . . 6 104 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 105 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 106 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 107 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 108 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 109 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 110 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 111 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 112 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 113 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 114 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 115 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 116 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 117 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 118 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 119 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 120 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 121 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 122 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 123 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 124 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 125 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 126 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 127 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 128 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 129 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 130 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 131 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 132 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 133 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 134 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 135 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 136 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 137 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 138 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 139 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 140 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 141 Appendix A. Differences Between HTTP Entities and RFC 2045 142 Entities . . . . . . . . . . . . . . . . . . . . . . 31 144 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 145 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 146 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 147 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 148 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33 149 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 150 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 151 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 152 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34 153 Appendix C. Compatibility with Previous Versions . . . . . . . . 35 154 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 155 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 156 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 157 Appendix E. Change Log (to be removed by RFC Editor before 158 publication) . . . . . . . . . . . . . . . . . . . . 38 159 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 160 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 161 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 162 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 163 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39 164 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 165 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 166 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 167 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 168 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 41 169 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 172 1. Introduction 174 This document defines HTTP/1.1 message payloads (a.k.a., content), 175 the associated metadata header fields that define how the payload is 176 intended to be interpreted by a recipient, the request header fields 177 that may influence content selection, and the various selection 178 algorithms that are collectively referred to as HTTP content 179 negotiation. 181 This document is currently disorganized in order to minimize the 182 changes between drafts and enable reviewers to see the smaller errata 183 changes. The next draft will reorganize the sections to better 184 reflect the content. In particular, the sections on entities will be 185 renamed payload and moved to the first half of the document, while 186 the sections on content negotiation and associated request header 187 fields will be moved to the second half. The current mess reflects 188 how widely dispersed these topics and associated requirements had 189 become in [RFC2616]. 191 1.1. Terminology 193 This specification uses a number of terms to refer to the roles 194 played by participants in, and objects of, the HTTP communication. 196 content negotiation 198 The mechanism for selecting the appropriate representation when 199 servicing a request. The representation of entities in any 200 response can be negotiated (including error responses). 202 entity 204 The information transferred as the payload of a request or 205 response. An entity consists of metadata in the form of entity- 206 header fields and content in the form of an entity-body. 208 representation 210 An entity included with a response that is subject to content 211 negotiation. There may exist multiple representations associated 212 with a particular response status. 214 variant 216 A resource may have one, or more than one, representation(s) 217 associated with it at any given instant. Each of these 218 representations is termed a "variant". Use of the term "variant" 219 does not necessarily imply that the resource is subject to content 220 negotiation. 222 1.2. Requirements 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 An implementation is not compliant if it fails to satisfy one or more 229 of the MUST or REQUIRED level requirements for the protocols it 230 implements. An implementation that satisfies all the MUST or 231 REQUIRED level and all the SHOULD level requirements for its 232 protocols is said to be "unconditionally compliant"; one that 233 satisfies all the MUST level requirements but not all the SHOULD 234 level requirements for its protocols is said to be "conditionally 235 compliant." 237 1.3. Syntax Notation 239 This specification uses the ABNF syntax defined in Section 1.2 of 240 [Part1] (which extends the syntax defined in [RFC5234] with a list 241 rule). Appendix D shows the collected ABNF, with the list rule 242 expanded. 244 The following core rules are included by reference, as defined in 245 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 246 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 247 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 248 sequence of data), SP (space), VCHAR (any visible USASCII character), 249 and WSP (whitespace). 251 1.3.1. Core Rules 253 The core rules below are defined in Section 1.2.2 of [Part1]: 255 quoted-string = 256 token = 257 OWS = 259 1.3.2. ABNF Rules defined in other Parts of the Specification 261 The ABNF rules below are defined in other parts: 263 absolute-URI = 264 Content-Length = 265 header-field = 266 partial-URI = 267 qvalue = 268 Last-Modified = 270 Content-Range = 272 Expires = 274 2. Protocol Parameters 276 2.1. Character Sets 278 HTTP uses the same definition of the term "character set" as that 279 described for MIME: 281 The term "character set" is used in this document to refer to a 282 method used with one or more tables to convert a sequence of octets 283 into a sequence of characters. Note that unconditional conversion in 284 the other direction is not required, in that not all characters may 285 be available in a given character set and a character set may provide 286 more than one sequence of octets to represent a particular character. 287 This definition is intended to allow various kinds of character 288 encoding, from simple single-table mappings such as US-ASCII to 289 complex table switching methods such as those that use ISO-2022's 290 techniques. However, the definition associated with a MIME character 291 set name MUST fully specify the mapping to be performed from octets 292 to characters. In particular, use of external profiling information 293 to determine the exact mapping is not permitted. 295 Note: This use of the term "character set" is more commonly 296 referred to as a "character encoding." However, since HTTP and 297 MIME share the same registry, it is important that the terminology 298 also be shared. 300 HTTP character sets are identified by case-insensitive tokens. The 301 complete set of tokens is defined by the IANA Character Set registry 302 (). 304 charset = token 306 Although HTTP allows an arbitrary token to be used as a charset 307 value, any token that has a predefined value within the IANA 308 Character Set registry MUST represent the character set defined by 309 that registry. Applications SHOULD limit their use of character sets 310 to those defined by the IANA registry. 312 HTTP uses charset in two contexts: within an Accept-Charset request 313 header (in which the charset value is an unquoted token) and as the 314 value of a parameter in a Content-Type header (within a request or 315 response), in which case the parameter value of the charset parameter 316 may be quoted. 318 Implementors should be aware of IETF character set requirements 319 [RFC3629] [RFC2277]. 321 2.1.1. Missing Charset 323 Some HTTP/1.0 software has interpreted a Content-Type header without 324 charset parameter incorrectly to mean "recipient should guess." 325 Senders wishing to defeat this behavior MAY include a charset 326 parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and 327 SHOULD do so when it is known that it will not confuse the recipient. 329 Unfortunately, some older HTTP/1.0 clients did not deal properly with 330 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 331 charset label provided by the sender; and those user agents that have 332 a provision to "guess" a charset MUST use the charset from the 333 content-type field if they support that charset, rather than the 334 recipient's preference, when initially displaying a document. See 335 Section 2.3.1. 337 2.2. Content Codings 339 Content coding values indicate an encoding transformation that has 340 been or can be applied to an entity. Content codings are primarily 341 used to allow a document to be compressed or otherwise usefully 342 transformed without losing the identity of its underlying media type 343 and without loss of information. Frequently, the entity is stored in 344 coded form, transmitted directly, and only decoded by the recipient. 346 content-coding = token 348 All content-coding values are case-insensitive. HTTP/1.1 uses 349 content-coding values in the Accept-Encoding (Section 5.3) and 350 Content-Encoding (Section 5.5) header fields. Although the value 351 describes the content-coding, what is more important is that it 352 indicates what decoding mechanism will be required to remove the 353 encoding. 355 compress 357 See Section 6.2.2.1 of [Part1]. 359 deflate 360 See Section 6.2.2.2 of [Part1]. 362 gzip 364 See Section 6.2.2.3 of [Part1]. 366 identity 368 The default (identity) encoding; the use of no transformation 369 whatsoever. This content-coding is used only in the Accept- 370 Encoding header, and SHOULD NOT be used in the Content-Encoding 371 header. 373 2.2.1. Content Coding Registry 375 The HTTP Content Coding Registry defines the name space for the 376 content coding names. 378 Registrations MUST include the following fields: 380 o Name 382 o Description 384 o Pointer to specification text 386 Values to be added to this name space require expert review and a 387 specification (see "Expert Review" and "Specification Required" in 388 Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 389 coding defined in this section. 391 The registry itself is maintained at 392 . 394 2.3. Media Types 396 HTTP uses Internet Media Types [RFC2046] in the Content-Type 397 (Section 5.9) and Accept (Section 5.1) header fields in order to 398 provide open and extensible data typing and type negotiation. 400 media-type = type "/" subtype *( OWS ";" OWS parameter ) 401 type = token 402 subtype = token 404 Parameters MAY follow the type/subtype in the form of attribute/value 405 pairs. 407 parameter = attribute "=" value 408 attribute = token 409 value = token / quoted-string 411 The type, subtype, and parameter attribute names are case- 412 insensitive. Parameter values might or might not be case-sensitive, 413 depending on the semantics of the parameter name. The presence or 414 absence of a parameter might be significant to the processing of a 415 media-type, depending on its definition within the media type 416 registry. 418 A parameter value that matches the token production may be 419 transmitted as either a token or within a quoted-string. The quoted 420 and unquoted values are equivalent. 422 Note that some older HTTP applications do not recognize media type 423 parameters. When sending data to older HTTP applications, 424 implementations SHOULD only use media type parameters when they are 425 required by that type/subtype definition. 427 Media-type values are registered with the Internet Assigned Number 428 Authority (IANA). The media type registration process is outlined in 429 [RFC4288]. Use of non-registered media types is discouraged. 431 2.3.1. Canonicalization and Text Defaults 433 Internet media types are registered with a canonical form. An 434 entity-body transferred via HTTP messages MUST be represented in the 435 appropriate canonical form prior to its transmission except for 436 "text" types, as defined in the next paragraph. 438 When in canonical form, media subtypes of the "text" type use CRLF as 439 the text line break. HTTP relaxes this requirement and allows the 440 transport of text media with plain CR or LF alone representing a line 441 break when it is done consistently for an entire entity-body. HTTP 442 applications MUST accept CRLF, bare CR, and bare LF as being 443 representative of a line break in text media received via HTTP. In 444 addition, if the text is represented in a character set that does not 445 use octets 13 and 10 for CR and LF respectively, as is the case for 446 some multi-byte character sets, HTTP allows the use of whatever octet 447 sequences are defined by that character set to represent the 448 equivalent of CR and LF for line breaks. This flexibility regarding 449 line breaks applies only to text media in the entity-body; a bare CR 450 or LF MUST NOT be substituted for CRLF within any of the HTTP control 451 structures (such as header fields and multipart boundaries). 453 If an entity-body is encoded with a content-coding, the underlying 454 data MUST be in a form defined above prior to being encoded. 456 The "charset" parameter is used with some media types to define the 457 character set (Section 2.1) of the data. When no explicit charset 458 parameter is provided by the sender, media subtypes of the "text" 459 type are defined to have a default charset value of "ISO-8859-1" when 460 received via HTTP. Data in character sets other than "ISO-8859-1" or 461 its subsets MUST be labeled with an appropriate charset value. See 462 Section 2.1.1 for compatibility problems. 464 2.3.2. Multipart Types 466 MIME provides for a number of "multipart" types -- encapsulations of 467 one or more entities within a single message-body. All multipart 468 types share a common syntax, as defined in Section 5.1.1 of 469 [RFC2046], and MUST include a boundary parameter as part of the media 470 type value. The message body is itself a protocol element and MUST 471 therefore use only CRLF to represent line breaks between body-parts. 472 Unlike in RFC 2046, the epilogue of any multipart message MUST be 473 empty; HTTP applications MUST NOT transmit the epilogue (even if the 474 original multipart contains an epilogue). These restrictions exist 475 in order to preserve the self-delimiting nature of a multipart 476 message-body, wherein the "end" of the message-body is indicated by 477 the ending multipart boundary. 479 In general, HTTP treats a multipart message-body no differently than 480 any other media type: strictly as payload. The one exception is the 481 "multipart/byteranges" type (Appendix A of [Part5]) when it appears 482 in a 206 (Partial Content) response. In all other cases, an HTTP 483 user agent SHOULD follow the same or similar behavior as a MIME user 484 agent would upon receipt of a multipart type. The MIME header fields 485 within each body-part of a multipart message-body do not have any 486 significance to HTTP beyond that defined by their MIME semantics. 488 In general, an HTTP user agent SHOULD follow the same or similar 489 behavior as a MIME user agent would upon receipt of a multipart type. 490 If an application receives an unrecognized multipart subtype, the 491 application MUST treat it as being equivalent to "multipart/mixed". 493 Note: The "multipart/form-data" type has been specifically defined 494 for carrying form data suitable for processing via the POST 495 request method, as described in [RFC2388]. 497 2.4. Language Tags 499 A language tag, as defined in [RFC5646], identifies a natural 500 language spoken, written, or otherwise conveyed by human beings for 501 communication of information to other human beings. Computer 502 languages are explicitly excluded. HTTP uses language tags within 503 the Accept-Language and Content-Language fields. 505 In summary, a language tag is composed of one or more parts: A 506 primary language subtag followed by a possibly empty series of 507 subtags: 509 language-tag = 511 White space is not allowed within the tag and all tags are case- 512 insensitive. The name space of language subtags is administered by 513 the IANA (see 514 ). 516 Example tags include: 518 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 520 See [RFC5646] for further information. 522 3. Entity 524 Request and Response messages MAY transfer an entity if not otherwise 525 restricted by the request method or response status code. An entity 526 consists of entity-header fields and an entity-body, although some 527 responses will only include the entity-headers. 529 In this section, both sender and recipient refer to either the client 530 or the server, depending on who sends and who receives the entity. 532 3.1. Entity Header Fields 534 Entity-header fields define metainformation about the entity-body or, 535 if no body is present, about the resource identified by the request. 537 entity-header = Content-Encoding ; Section 5.5 538 / Content-Language ; Section 5.6 539 / Content-Length ; [Part1], Section 9.2 540 / Content-Location ; Section 5.7 541 / Content-MD5 ; Section 5.8 542 / Content-Range ; [Part5], Section 5.2 543 / Content-Type ; Section 5.9 544 / Expires ; [Part6], Section 3.3 545 / Last-Modified ; [Part4], Section 6.6 546 / extension-header 548 extension-header = header-field 550 The extension-header mechanism allows additional entity-header fields 551 to be defined without changing the protocol, but these fields cannot 552 be assumed to be recognizable by the recipient. Unrecognized header 553 fields SHOULD be ignored by the recipient and MUST be forwarded by 554 transparent proxies. 556 3.2. Entity Body 558 The entity-body (if any) sent with an HTTP request or response is in 559 a format and encoding defined by the entity-header fields. 561 entity-body = *OCTET 563 An entity-body is only present in a message when a message-body is 564 present, as described in Section 3.3 of [Part1]. The entity-body is 565 obtained from the message-body by decoding any Transfer-Encoding that 566 might have been applied to ensure safe and proper transfer of the 567 message. 569 3.2.1. Type 571 When an entity-body is included with a message, the data type of that 572 body is determined via the header fields Content-Type and Content- 573 Encoding. These define a two-layer, ordered encoding model: 575 entity-body := Content-Encoding( Content-Type( data ) ) 577 Content-Type specifies the media type of the underlying data. Any 578 HTTP/1.1 message containing an entity-body SHOULD include a Content- 579 Type header field defining the media type of that body, unless that 580 information is unknown. If the Content-Type header field is not 581 present, it indicates that the sender does not know the media type of 582 the data; recipients MAY either assume that it is "application/ 583 octet-stream" ([RFC2046], Section 4.5.1) or examine the content to 584 determine its type. 586 Content-Encoding may be used to indicate any additional content 587 codings applied to the data, usually for the purpose of data 588 compression, that are a property of the requested resource. There is 589 no default encoding. 591 3.2.2. Entity Length 593 The entity-length of a message is the length of the message-body 594 before any transfer-codings have been applied. Section 3.4 of 595 [Part1] defines how the transfer-length of a message-body is 596 determined. 598 4. Content Negotiation 600 HTTP responses include a representation which contains information 601 for interpretation, whether by a human user or for further 602 processing. Often, the server has different ways of representing the 603 same information; for example, in different formats, languages, or 604 using different character encodings. 606 HTTP clients and their users might have different or variable 607 capabilities, characteristics or preferences which would influence 608 which representation, among those available from the server, would be 609 best for the server to deliver. For this reason, HTTP provides 610 mechanisms for "content negotiation" -- a process of allowing 611 selection of a representation of a given resource, when more than one 612 is available. 614 This specification defines two patterns of content negotiation; 615 "server-driven", where the server selects the representation based 616 upon the client's stated preferences, and "agent-driven" negotiation, 617 where the server provides a list of representations for the client to 618 choose from, based upon their metadata. In addition, there are other 619 patterns: some applications use an "active content" pattern, where 620 the server returns active content which runs on the client and, based 621 on client available parameters, selects additional resources to 622 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 623 proposed. 625 These patterns are all widely used, and have trade-offs in 626 applicability and practicality. In particular, when the number of 627 preferences or capabilities to be expressed by a client are large 628 (such as when many different formats are supported by a user-agent), 629 server-driven negotiation becomes unwieldy, and may not be 630 appropriate. Conversely, when the number of representations to 631 choose from is very large, agent-driven negotiation may not be 632 appropriate. 634 Note that in all cases, the supplier of representations has the 635 responsibility for determining which representations might be 636 considered to be the "same information". 638 4.1. Server-driven Negotiation 640 If the selection of the best representation for a response is made by 641 an algorithm located at the server, it is called server-driven 642 negotiation. Selection is based on the available representations of 643 the response (the dimensions over which it can vary; e.g., language, 644 content-coding, etc.) and the contents of particular header fields in 645 the request message or on other information pertaining to the request 646 (such as the network address of the client). 648 Server-driven negotiation is advantageous when the algorithm for 649 selecting from among the available representations is difficult to 650 describe to the user agent, or when the server desires to send its 651 "best guess" to the client along with the first response (hoping to 652 avoid the round-trip delay of a subsequent request if the "best 653 guess" is good enough for the user). In order to improve the 654 server's guess, the user agent MAY include request header fields 655 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 656 preferences for such a response. 658 Server-driven negotiation has disadvantages: 660 1. It is impossible for the server to accurately determine what 661 might be "best" for any given user, since that would require 662 complete knowledge of both the capabilities of the user agent and 663 the intended use for the response (e.g., does the user want to 664 view it on screen or print it on paper?). 666 2. Having the user agent describe its capabilities in every request 667 can be both very inefficient (given that only a small percentage 668 of responses have multiple representations) and a potential 669 violation of the user's privacy. 671 3. It complicates the implementation of an origin server and the 672 algorithms for generating responses to a request. 674 4. It may limit a public cache's ability to use the same response 675 for multiple user's requests. 677 HTTP/1.1 includes the following request-header fields for enabling 678 server-driven negotiation through description of user agent 679 capabilities and user preferences: Accept (Section 5.1), Accept- 680 Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language 681 (Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an 682 origin server is not limited to these dimensions and MAY vary the 683 response based on any aspect of the request, including information 684 outside the request-header fields or within extension header fields 685 not defined by this specification. 687 Note: In practice, User-Agent based negotiation is fragile, 688 because new clients might not be recognized. 690 The Vary header field (Section 3.5 of [Part6]) can be used to express 691 the parameters the server uses to select a representation that is 692 subject to server-driven negotiation. 694 4.2. Agent-driven Negotiation 696 With agent-driven negotiation, selection of the best representation 697 for a response is performed by the user agent after receiving an 698 initial response from the origin server. Selection is based on a 699 list of the available representations of the response included within 700 the header fields or entity-body of the initial response, with each 701 representation identified by its own URI. Selection from among the 702 representations may be performed automatically (if the user agent is 703 capable of doing so) or manually by the user selecting from a 704 generated (possibly hypertext) menu. 706 Agent-driven negotiation is advantageous when the response would vary 707 over commonly-used dimensions (such as type, language, or encoding), 708 when the origin server is unable to determine a user agent's 709 capabilities from examining the request, and generally when public 710 caches are used to distribute server load and reduce network usage. 712 Agent-driven negotiation suffers from the disadvantage of needing a 713 second request to obtain the best alternate representation. This 714 second request is only efficient when caching is used. In addition, 715 this specification does not define any mechanism for supporting 716 automatic selection, though it also does not prevent any such 717 mechanism from being developed as an extension and used within 718 HTTP/1.1. 720 This specification defines the 300 (Multiple Choices) and 406 (Not 721 Acceptable) status codes for enabling agent-driven negotiation when 722 the server is unwilling or unable to provide a varying response using 723 server-driven negotiation. 725 5. Header Field Definitions 727 This section defines the syntax and semantics of HTTP/1.1 header 728 fields related to the payload of messages. 730 For entity-header fields, both sender and recipient refer to either 731 the client or the server, depending on who sends and who receives the 732 entity. 734 5.1. Accept 736 The "Accept" request-header field can be used by user agents to 737 specify response media types that are acceptable. Accept headers can 738 be used to indicate that the request is specifically limited to a 739 small set of desired types, as in the case of a request for an in- 740 line image. 742 Accept = "Accept" ":" OWS Accept-v 743 Accept-v = #( media-range [ accept-params ] ) 745 media-range = ( "*/*" 746 / ( type "/" "*" ) 747 / ( type "/" subtype ) 748 ) *( OWS ";" OWS parameter ) 749 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 750 accept-ext = OWS ";" OWS token 751 [ "=" ( token / quoted-string ) ] 753 The asterisk "*" character is used to group media types into ranges, 754 with "*/*" indicating all media types and "type/*" indicating all 755 subtypes of that type. The media-range MAY include media type 756 parameters that are applicable to that range. 758 Each media-range MAY be followed by one or more accept-params, 759 beginning with the "q" parameter for indicating a relative quality 760 factor. The first "q" parameter (if any) separates the media-range 761 parameter(s) from the accept-params. Quality factors allow the user 762 or user agent to indicate the relative degree of preference for that 763 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 764 [Part1]). The default value is q=1. 766 Note: Use of the "q" parameter name to separate media type 767 parameters from Accept extension parameters is due to historical 768 practice. Although this prevents any media type parameter named 769 "q" from being used with a media range, such an event is believed 770 to be unlikely given the lack of any "q" parameters in the IANA 771 media type registry and the rare usage of any media type 772 parameters in Accept. Future media types are discouraged from 773 registering any parameter named "q". 775 The example 777 Accept: audio/*; q=0.2, audio/basic 779 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 780 type if it is the best available after an 80% mark-down in quality." 782 If no Accept header field is present, then it is assumed that the 783 client accepts all media types. If an Accept header field is 784 present, and if the server cannot send a response which is acceptable 785 according to the combined Accept field value, then the server SHOULD 786 send a 406 (Not Acceptable) response. 788 A more elaborate example is 789 Accept: text/plain; q=0.5, text/html, 790 text/x-dvi; q=0.8, text/x-c 792 Verbally, this would be interpreted as "text/html and text/x-c are 793 the preferred media types, but if they do not exist, then send the 794 text/x-dvi entity, and if that does not exist, send the text/plain 795 entity." 797 Media ranges can be overridden by more specific media ranges or 798 specific media types. If more than one media range applies to a 799 given type, the most specific reference has precedence. For example, 801 Accept: text/*, text/html, text/html;level=1, */* 803 have the following precedence: 805 1. text/html;level=1 807 2. text/html 809 3. text/* 811 4. */* 813 The media type quality factor associated with a given type is 814 determined by finding the media range with the highest precedence 815 which matches that type. For example, 817 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 818 text/html;level=2;q=0.4, */*;q=0.5 820 would cause the following values to be associated: 822 +-------------------+---------------+ 823 | Media Type | Quality Value | 824 +-------------------+---------------+ 825 | text/html;level=1 | 1 | 826 | text/html | 0.7 | 827 | text/plain | 0.3 | 828 | image/jpeg | 0.5 | 829 | text/html;level=2 | 0.4 | 830 | text/html;level=3 | 0.7 | 831 +-------------------+---------------+ 833 Note: A user agent might be provided with a default set of quality 834 values for certain media ranges. However, unless the user agent is a 835 closed system which cannot interact with other rendering agents, this 836 default set ought to be configurable by the user. 838 5.2. Accept-Charset 840 The "Accept-Charset" request-header field can be used by user agents 841 to indicate what response character sets are acceptable. This field 842 allows clients capable of understanding more comprehensive or 843 special-purpose character sets to signal that capability to a server 844 which is capable of representing documents in those character sets. 846 Accept-Charset = "Accept-Charset" ":" OWS 847 Accept-Charset-v 848 Accept-Charset-v = 1#( ( charset / "*" ) 849 [ OWS ";" OWS "q=" qvalue ] ) 851 Character set values are described in Section 2.1. Each charset MAY 852 be given an associated quality value which represents the user's 853 preference for that charset. The default value is q=1. An example 854 is 856 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 858 The special value "*", if present in the Accept-Charset field, 859 matches every character set (including ISO-8859-1) which is not 860 mentioned elsewhere in the Accept-Charset field. If no "*" is 861 present in an Accept-Charset field, then all character sets not 862 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 863 which gets a quality value of 1 if not explicitly mentioned. 865 If no Accept-Charset header is present, the default is that any 866 character set is acceptable. If an Accept-Charset header is present, 867 and if the server cannot send a response which is acceptable 868 according to the Accept-Charset header, then the server SHOULD send 869 an error response with the 406 (Not Acceptable) status code, though 870 the sending of an unacceptable response is also allowed. 872 5.3. Accept-Encoding 874 The "Accept-Encoding" request-header field can be used by user agents 875 to indicate what response content-codings (Section 2.2) are 876 acceptable in the response. 878 Accept-Encoding = "Accept-Encoding" ":" OWS 879 Accept-Encoding-v 880 Accept-Encoding-v = 881 #( codings [ OWS ";" OWS "q=" qvalue ] ) 882 codings = ( content-coding / "*" ) 884 Each codings value MAY be given an associated quality value which 885 represents the preference for that encoding. The default value is 886 q=1. 888 Examples of its use are: 890 Accept-Encoding: compress, gzip 891 Accept-Encoding: 892 Accept-Encoding: * 893 Accept-Encoding: compress;q=0.5, gzip;q=1.0 894 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 896 A server tests whether a content-coding is acceptable, according to 897 an Accept-Encoding field, using these rules: 899 1. If the content-coding is one of the content-codings listed in the 900 Accept-Encoding field, then it is acceptable, unless it is 901 accompanied by a qvalue of 0. (As defined in Section 6.4 of 902 [Part1], a qvalue of 0 means "not acceptable.") 904 2. The special "*" symbol in an Accept-Encoding field matches any 905 available content-coding not explicitly listed in the header 906 field. 908 3. If multiple content-codings are acceptable, then the acceptable 909 content-coding with the highest non-zero qvalue is preferred. 911 4. The "identity" content-coding is always acceptable, unless 912 specifically refused because the Accept-Encoding field includes 913 "identity;q=0", or because the field includes "*;q=0" and does 914 not explicitly include the "identity" content-coding. If the 915 Accept-Encoding field-value is empty, then only the "identity" 916 encoding is acceptable. 918 If an Accept-Encoding field is present in a request, and if the 919 server cannot send a response which is acceptable according to the 920 Accept-Encoding header, then the server SHOULD send an error response 921 with the 406 (Not Acceptable) status code. 923 If no Accept-Encoding field is present in a request, the server MAY 924 assume that the client will accept any content coding. In this case, 925 if "identity" is one of the available content-codings, then the 926 server SHOULD use the "identity" content-coding, unless it has 927 additional information that a different content-coding is meaningful 928 to the client. 930 Note: If the request does not include an Accept-Encoding field, 931 and if the "identity" content-coding is unavailable, then content- 932 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 933 "compress") are preferred; some older clients improperly display 934 messages sent with other content-codings. The server might also 935 make this decision based on information about the particular user- 936 agent or client. 938 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 939 associated with content-codings. This means that qvalues will not 940 work and are not permitted with x-gzip or x-compress. 942 5.4. Accept-Language 944 The "Accept-Language" request-header field can be used by user agents 945 to indicate the set of natural languages that are preferred in the 946 response. Language tags are defined in Section 2.4. 948 Accept-Language = "Accept-Language" ":" OWS 949 Accept-Language-v 950 Accept-Language-v = 951 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 952 language-range = 953 955 Each language-range can be given an associated quality value which 956 represents an estimate of the user's preference for the languages 957 specified by that range. The quality value defaults to "q=1". For 958 example, 960 Accept-Language: da, en-gb;q=0.8, en;q=0.7 962 would mean: "I prefer Danish, but will accept British English and 963 other types of English." (see also Section 2.3 of [RFC4647]) 965 For matching, Section 3 of [RFC4647] defines several matching 966 schemes. Implementations can offer the most appropriate matching 967 scheme for their requirements. 969 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 970 identical to the matching scheme that was previously defined in 971 Section 14.4 of [RFC2616]. 973 It might be contrary to the privacy expectations of the user to send 974 an Accept-Language header with the complete linguistic preferences of 975 the user in every request. For a discussion of this issue, see 976 Section 7.1. 978 As intelligibility is highly dependent on the individual user, it is 979 recommended that client applications make the choice of linguistic 980 preference available to the user. If the choice is not made 981 available, then the Accept-Language header field MUST NOT be given in 982 the request. 984 Note: When making the choice of linguistic preference available to 985 the user, we remind implementors of the fact that users are not 986 familiar with the details of language matching as described above, 987 and should provide appropriate guidance. As an example, users 988 might assume that on selecting "en-gb", they will be served any 989 kind of English document if British English is not available. A 990 user agent might suggest in such a case to add "en" to get the 991 best matching behavior. 993 5.5. Content-Encoding 995 The "Content-Encoding" entity-header field indicates what content- 996 codings have been applied to the entity-body, and thus what decoding 997 mechanisms must be applied in order to obtain the media-type 998 referenced by the Content-Type header field. Content-Encoding is 999 primarily used to allow a document to be compressed without losing 1000 the identity of its underlying media type. 1002 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 1003 Content-Encoding-v = 1#content-coding 1005 Content codings are defined in Section 2.2. An example of its use is 1007 Content-Encoding: gzip 1009 The content-coding is a characteristic of the entity identified by 1010 the request-target. Typically, the entity-body is stored with this 1011 encoding and is only decoded before rendering or analogous usage. 1012 However, a non-transparent proxy MAY modify the content-coding if the 1013 new coding is known to be acceptable to the recipient, unless the 1014 "no-transform" cache-control directive is present in the message. 1016 If the content-coding of an entity is not "identity", then the 1017 response MUST include a Content-Encoding entity-header (Section 5.5) 1018 that lists the non-identity content-coding(s) used. 1020 If the content-coding of an entity in a request message is not 1021 acceptable to the origin server, the server SHOULD respond with a 1022 status code of 415 (Unsupported Media Type). 1024 If multiple encodings have been applied to an entity, the content 1025 codings MUST be listed in the order in which they were applied. 1026 Additional information about the encoding parameters MAY be provided 1027 by other entity-header fields not defined by this specification. 1029 5.6. Content-Language 1031 The "Content-Language" entity-header field describes the natural 1032 language(s) of the intended audience for the entity. Note that this 1033 might not be equivalent to all the languages used within the entity- 1034 body. 1036 Content-Language = "Content-Language" ":" OWS Content-Language-v 1037 Content-Language-v = 1#language-tag 1039 Language tags are defined in Section 2.4. The primary purpose of 1040 Content-Language is to allow a user to identify and differentiate 1041 entities according to the user's own preferred language. Thus, if 1042 the body content is intended only for a Danish-literate audience, the 1043 appropriate field is 1045 Content-Language: da 1047 If no Content-Language is specified, the default is that the content 1048 is intended for all language audiences. This might mean that the 1049 sender does not consider it to be specific to any natural language, 1050 or that the sender does not know for which language it is intended. 1052 Multiple languages MAY be listed for content that is intended for 1053 multiple audiences. For example, a rendition of the "Treaty of 1054 Waitangi," presented simultaneously in the original Maori and English 1055 versions, would call for 1057 Content-Language: mi, en 1059 However, just because multiple languages are present within an entity 1060 does not mean that it is intended for multiple linguistic audiences. 1061 An example would be a beginner's language primer, such as "A First 1062 Lesson in Latin," which is clearly intended to be used by an English- 1063 literate audience. In this case, the Content-Language would properly 1064 only include "en". 1066 Content-Language MAY be applied to any media type -- it is not 1067 limited to textual documents. 1069 5.7. Content-Location 1071 The "Content-Location" entity-header field is used to supply a URI 1072 for the entity in the message when it is accessible from a location 1073 separate from the requested resource's URI. 1075 A server SHOULD provide a Content-Location for the variant 1076 corresponding to the response entity, especially in the case where a 1077 resource has multiple entities associated with it, and those entities 1078 actually have separate locations by which they might be individually 1079 accessed, the server SHOULD provide a Content-Location for the 1080 particular variant which is returned. 1082 Content-Location = "Content-Location" ":" OWS 1083 Content-Location-v 1084 Content-Location-v = 1085 absolute-URI / partial-URI 1087 The Content-Location value is not a replacement for the original 1088 requested URI; it is only a statement of the location of the resource 1089 corresponding to this particular entity at the time of the request. 1090 Future requests MAY specify the Content-Location URI as the request- 1091 target if the desire is to identify the source of that particular 1092 entity. 1094 Section 6.1 of [Part2] describes how clients may process the Content- 1095 Location header field. 1097 A cache cannot assume that an entity with a Content-Location 1098 different from the URI used to retrieve it can be used to respond to 1099 later requests on that Content-Location URI. However, the Content- 1100 Location can be used to differentiate between multiple entities 1101 retrieved from a single requested resource, as described in Section 1102 2.6 of [Part6]. 1104 If the Content-Location is a relative URI, the relative URI is 1105 interpreted relative to the request-target. 1107 The meaning of the Content-Location header in requests is undefined; 1108 servers are free to ignore it in those cases. 1110 5.8. Content-MD5 1112 The "Content-MD5" entity-header field, as defined in [RFC1864], is an 1113 MD5 digest of the entity-body that provides an end-to-end message 1114 integrity check (MIC) of the entity-body. Note that a MIC is good 1115 for detecting accidental modification of the entity-body in transit, 1116 but is not proof against malicious attacks. 1118 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1119 Content-MD5-v = 1121 The Content-MD5 header field MAY be generated by an origin server or 1122 client to function as an integrity check of the entity-body. Only 1123 origin servers or clients MAY generate the Content-MD5 header field; 1124 proxies and gateways MUST NOT generate it, as this would defeat its 1125 value as an end-to-end integrity check. Any recipient of the entity- 1126 body, including gateways and proxies, MAY check that the digest value 1127 in this header field matches that of the entity-body as received. 1129 The MD5 digest is computed based on the content of the entity-body, 1130 including any content-coding that has been applied, but not including 1131 any transfer-encoding applied to the message-body. If the message is 1132 received with a transfer-encoding, that encoding MUST be removed 1133 prior to checking the Content-MD5 value against the received entity. 1135 This has the result that the digest is computed on the octets of the 1136 entity-body exactly as, and in the order that, they would be sent if 1137 no transfer-encoding were being applied. 1139 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1140 composite media-types (e.g., multipart/* and message/rfc822), but 1141 this does not change how the digest is computed as defined in the 1142 preceding paragraph. 1144 There are several consequences of this. The entity-body for 1145 composite types MAY contain many body-parts, each with its own MIME 1146 and HTTP headers (including Content-MD5, Content-Transfer-Encoding, 1147 and Content-Encoding headers). If a body-part has a Content- 1148 Transfer-Encoding or Content-Encoding header, it is assumed that the 1149 content of the body-part has had the encoding applied, and the body- 1150 part is included in the Content-MD5 digest as is -- i.e., after the 1151 application. The Transfer-Encoding header field is not allowed 1152 within body-parts. 1154 Conversion of all line breaks to CRLF MUST NOT be done before 1155 computing or checking the digest: the line break convention used in 1156 the text actually transmitted MUST be left unaltered when computing 1157 the digest. 1159 Note: While the definition of Content-MD5 is exactly the same for 1160 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1161 in which the application of Content-MD5 to HTTP entity-bodies 1162 differs from its application to MIME entity-bodies. One is that 1163 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1164 does use Transfer-Encoding and Content-Encoding. Another is that 1165 HTTP more frequently uses binary content types than MIME, so it is 1166 worth noting that, in such cases, the byte order used to compute 1167 the digest is the transmission byte order defined for the type. 1168 Lastly, HTTP allows transmission of text types with any of several 1169 line break conventions and not just the canonical form using CRLF. 1171 5.9. Content-Type 1173 The "Content-Type" entity-header field indicates the media type of 1174 the entity-body. In the case of responses to the HEAD method, the 1175 media type is that which would have been sent had the request been a 1176 GET. 1178 Content-Type = "Content-Type" ":" OWS Content-Type-v 1179 Content-Type-v = media-type 1181 Media types are defined in Section 2.3. An example of the field is 1183 Content-Type: text/html; charset=ISO-8859-4 1185 Further discussion of methods for identifying the media type of an 1186 entity is provided in Section 3.2.1. 1188 6. IANA Considerations 1190 6.1. Message Header Registration 1192 The Message Header Registry located at should be 1194 updated with the permanent registrations below (see [RFC3864]): 1196 +---------------------+----------+----------+--------------+ 1197 | Header Field Name | Protocol | Status | Reference | 1198 +---------------------+----------+----------+--------------+ 1199 | Accept | http | standard | Section 5.1 | 1200 | Accept-Charset | http | standard | Section 5.2 | 1201 | Accept-Encoding | http | standard | Section 5.3 | 1202 | Accept-Language | http | standard | Section 5.4 | 1203 | Content-Disposition | http | | Appendix B.1 | 1204 | Content-Encoding | http | standard | Section 5.5 | 1205 | Content-Language | http | standard | Section 5.6 | 1206 | Content-Location | http | standard | Section 5.7 | 1207 | Content-MD5 | http | standard | Section 5.8 | 1208 | Content-Type | http | standard | Section 5.9 | 1209 | MIME-Version | http | | Appendix A.1 | 1210 +---------------------+----------+----------+--------------+ 1212 The change controller is: "IETF (iesg@ietf.org) - Internet 1213 Engineering Task Force". 1215 6.2. Content Coding Registry 1217 The registration procedure for HTTP Content Codings is now defined by 1218 Section 2.2.1 of this document. 1220 The HTTP Content Codings Registry located at 1221 should be updated 1222 with the registration below: 1224 +----------+-----------------------------------+--------------------+ 1225 | Name | Description | Reference | 1226 +----------+-----------------------------------+--------------------+ 1227 | compress | UNIX "compress" program method | Section 6.2.2.1 of | 1228 | | | [Part1] | 1229 | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of | 1230 | | "deflate" compression | [Part1] | 1231 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 of | 1232 | | | [Part1] | 1233 | identity | No transformation | Section 2.2 | 1234 +----------+-----------------------------------+--------------------+ 1236 7. Security Considerations 1238 This section is meant to inform application developers, information 1239 providers, and users of the security limitations in HTTP/1.1 as 1240 described by this document. The discussion does not include 1241 definitive solutions to the problems revealed, though it does make 1242 some suggestions for reducing security risks. 1244 7.1. Privacy Issues Connected to Accept Headers 1246 Accept request-headers can reveal information about the user to all 1247 servers which are accessed. The Accept-Language header in particular 1248 can reveal information the user would consider to be of a private 1249 nature, because the understanding of particular languages is often 1250 strongly correlated to the membership of a particular ethnic group. 1251 User agents which offer the option to configure the contents of an 1252 Accept-Language header to be sent in every request are strongly 1253 encouraged to let the configuration process include a message which 1254 makes the user aware of the loss of privacy involved. 1256 An approach that limits the loss of privacy would be for a user agent 1257 to omit the sending of Accept-Language headers by default, and to ask 1258 the user whether or not to start sending Accept-Language headers to a 1259 server if it detects, by looking for any Vary response-header fields 1260 generated by the server, that such sending could improve the quality 1261 of service. 1263 Elaborate user-customized accept header fields sent in every request, 1264 in particular if these include quality values, can be used by servers 1265 as relatively reliable and long-lived user identifiers. Such user 1266 identifiers would allow content providers to do click-trail tracking, 1267 and would allow collaborating content providers to match cross-server 1268 click-trails or form submissions of individual users. Note that for 1269 many users not behind a proxy, the network address of the host 1270 running the user agent will also serve as a long-lived user 1271 identifier. In environments where proxies are used to enhance 1272 privacy, user agents ought to be conservative in offering accept 1273 header configuration options to end users. As an extreme privacy 1274 measure, proxies could filter the accept headers in relayed requests. 1275 General purpose user agents which provide a high degree of header 1276 configurability SHOULD warn users about the loss of privacy which can 1277 be involved. 1279 7.2. Content-Disposition Issues 1281 [RFC2183], from which the often implemented Content-Disposition (see 1282 Appendix B.1) header in HTTP is derived, has a number of very serious 1283 security considerations. Content-Disposition is not part of the HTTP 1284 standard, but since it is widely implemented, we are documenting its 1285 use and risks for implementors. See Section 5 of [RFC2183] for 1286 details. 1288 8. Acknowledgments 1290 9. References 1292 9.1. Normative References 1294 [ISO-8859-1] 1295 International Organization for Standardization, 1296 "Information technology -- 8-bit single-byte coded graphic 1297 character sets -- Part 1: Latin alphabet No. 1", ISO/ 1298 IEC 8859-1:1998, 1998. 1300 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1301 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1302 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1303 and Message Parsing", draft-ietf-httpbis-p1-messaging-09 1304 (work in progress), March 2010. 1306 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1307 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1308 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1309 Semantics", draft-ietf-httpbis-p2-semantics-09 (work in 1310 progress), March 2010. 1312 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1313 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1314 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1315 Requests", draft-ietf-httpbis-p4-conditional-09 (work in 1316 progress), March 2010. 1318 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1319 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1320 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1321 Partial Responses", draft-ietf-httpbis-p5-range-09 (work 1322 in progress), March 2010. 1324 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1325 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1326 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1327 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in 1328 progress), March 2010. 1330 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1331 RFC 1864, October 1995. 1333 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1334 Specification version 3.3", RFC 1950, May 1996. 1336 RFC 1950 is an Informational RFC, thus it may be less 1337 stable than this specification. On the other hand, this 1338 downward reference was present since the publication of 1339 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1340 cause problems in practice. See also [BCP97]. 1342 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1343 Randers-Pehrson, "GZIP file format specification version 1344 4.3", RFC 1952, May 1996. 1346 RFC 1952 is an Informational RFC, thus it may be less 1347 stable than this specification. On the other hand, this 1348 downward reference was present since the publication of 1349 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1350 cause problems in practice. See also [BCP97]. 1352 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1353 Extensions (MIME) Part One: Format of Internet Message 1354 Bodies", RFC 2045, November 1996. 1356 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1357 Extensions (MIME) Part Two: Media Types", RFC 2046, 1358 November 1996. 1360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1361 Requirement Levels", BCP 14, RFC 2119, March 1997. 1363 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1364 Tags", BCP 47, RFC 4647, September 2006. 1366 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1367 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1369 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1370 Languages", BCP 47, RFC 5646, September 2009. 1372 9.2. Informative References 1374 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 1375 to Standards-Track Documents", BCP 97, RFC 4897, 1376 June 2007. 1378 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1379 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1381 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1382 Extensions (MIME) Part Five: Conformance Criteria and 1383 Examples", RFC 2049, November 1996. 1385 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1386 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1387 RFC 2068, January 1997. 1389 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1390 February 1997. 1392 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1393 Presentation Information in Internet Messages: The 1394 Content-Disposition Header Field", RFC 2183, August 1997. 1396 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1397 Languages", BCP 18, RFC 2277, January 1998. 1399 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1400 in HTTP", RFC 2295, March 1998. 1402 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1403 form-data", RFC 2388, August 1998. 1405 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1406 "MIME Encapsulation of Aggregate Documents, such as HTML 1407 (MHTML)", RFC 2557, March 1999. 1409 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1410 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1411 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1413 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1414 10646", RFC 3629, STD 63, November 2003. 1416 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1417 Procedures for Message Header Fields", BCP 90, RFC 3864, 1418 September 2004. 1420 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1421 Registration Procedures", BCP 13, RFC 4288, December 2005. 1423 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1424 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1425 May 2008. 1427 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1428 October 2008. 1430 Appendix A. Differences Between HTTP Entities and RFC 2045 Entities 1432 HTTP/1.1 uses many of the constructs defined for Internet Mail 1433 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1434 [RFC2045]) to allow entities to be transmitted in an open variety of 1435 representations and with extensible mechanisms. However, RFC 2045 1436 discusses mail, and HTTP has a few features that are different from 1437 those described in RFC 2045. These differences were carefully chosen 1438 to optimize performance over binary connections, to allow greater 1439 freedom in the use of new media types, to make date comparisons 1440 easier, and to acknowledge the practice of some early HTTP servers 1441 and clients. 1443 This appendix describes specific areas where HTTP differs from RFC 1444 2045. Proxies and gateways to strict MIME environments SHOULD be 1445 aware of these differences and provide the appropriate conversions 1446 where necessary. Proxies and gateways from MIME environments to HTTP 1447 also need to be aware of the differences because some conversions 1448 might be required. 1450 A.1. MIME-Version 1452 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1453 MAY include a single MIME-Version general-header field to indicate 1454 what version of the MIME protocol was used to construct the message. 1455 Use of the MIME-Version header field indicates that the message is in 1456 full compliance with the MIME protocol (as defined in [RFC2045]). 1457 Proxies/gateways are responsible for ensuring full compliance (where 1458 possible) when exporting HTTP messages to strict MIME environments. 1460 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1461 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1463 MIME version "1.0" is the default for use in HTTP/1.1. However, 1464 HTTP/1.1 message parsing and semantics are defined by this document 1465 and not the MIME specification. 1467 A.2. Conversion to Canonical Form 1469 [RFC2045] requires that an Internet mail entity be converted to 1470 canonical form prior to being transferred, as described in Section 4 1471 of [RFC2049]. Section 2.3.1 of this document describes the forms 1472 allowed for subtypes of the "text" media type when transmitted over 1473 HTTP. [RFC2046] requires that content with a type of "text" 1474 represent line breaks as CRLF and forbids the use of CR or LF outside 1475 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1476 indicate a line break within text content when a message is 1477 transmitted over HTTP. 1479 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1480 environment SHOULD translate all line breaks within the text media 1481 types described in Section 2.3.1 of this document to the RFC 2049 1482 canonical form of CRLF. Note, however, that this might be 1483 complicated by the presence of a Content-Encoding and by the fact 1484 that HTTP allows the use of some character sets which do not use 1485 octets 13 and 10 to represent CR and LF, as is the case for some 1486 multi-byte character sets. 1488 Implementors should note that conversion will break any cryptographic 1489 checksums applied to the original content unless the original content 1490 is already in canonical form. Therefore, the canonical form is 1491 recommended for any content that uses such checksums in HTTP. 1493 A.3. Conversion of Date Formats 1495 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1496 [Part1]) to simplify the process of date comparison. Proxies and 1497 gateways from other protocols SHOULD ensure that any Date header 1498 field present in a message conforms to one of the HTTP/1.1 formats 1499 and rewrite the date if necessary. 1501 A.4. Introduction of Content-Encoding 1503 RFC 2045 does not include any concept equivalent to HTTP/1.1's 1504 Content-Encoding header field. Since this acts as a modifier on the 1505 media type, proxies and gateways from HTTP to MIME-compliant 1506 protocols MUST either change the value of the Content-Type header 1507 field or decode the entity-body before forwarding the message. (Some 1508 experimental applications of Content-Type for Internet mail have used 1509 a media-type parameter of ";conversions=" to perform 1510 a function equivalent to Content-Encoding. However, this parameter 1511 is not part of RFC 2045). 1513 A.5. No Content-Transfer-Encoding 1515 HTTP does not use the Content-Transfer-Encoding field of RFC 2045. 1516 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1517 remove any Content-Transfer-Encoding prior to delivering the response 1518 message to an HTTP client. 1520 Proxies and gateways from HTTP to MIME-compliant protocols are 1521 responsible for ensuring that the message is in the correct format 1522 and encoding for safe transport on that protocol, where "safe 1523 transport" is defined by the limitations of the protocol being used. 1524 Such a proxy or gateway SHOULD label the data with an appropriate 1525 Content-Transfer-Encoding if doing so will improve the likelihood of 1526 safe transport over the destination protocol. 1528 A.6. Introduction of Transfer-Encoding 1530 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1531 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1532 to forwarding a message via a MIME-compliant protocol. 1534 A.7. MHTML and Line Length Limitations 1536 HTTP implementations which share code with MHTML [RFC2557] 1537 implementations need to be aware of MIME line length limitations. 1538 Since HTTP does not have this limitation, HTTP does not fold long 1539 lines. MHTML messages being transported by HTTP follow all 1540 conventions of MHTML, including line length limitations and folding, 1541 canonicalization, etc., since HTTP transports all message-bodies as 1542 payload (see Section 2.3.2) and does not interpret the content or any 1543 MIME header lines that might be contained therein. 1545 Appendix B. Additional Features 1547 [RFC1945] and [RFC2068] document protocol elements used by some 1548 existing HTTP implementations, but not consistently and correctly 1549 across most HTTP/1.1 applications. Implementors are advised to be 1550 aware of these features, but cannot rely upon their presence in, or 1551 interoperability with, other HTTP/1.1 applications. Some of these 1552 describe proposed experimental features, and some describe features 1553 that experimental deployment found lacking that are now addressed in 1554 the base HTTP/1.1 specification. 1556 A number of other headers, such as Content-Disposition and Title, 1557 from SMTP and MIME are also often implemented (see [RFC2076]). 1559 B.1. Content-Disposition 1561 The "Content-Disposition" response-header field has been proposed as 1562 a means for the origin server to suggest a default filename if the 1563 user requests that the content is saved to a file. This usage is 1564 derived from the definition of Content-Disposition in [RFC2183]. 1566 content-disposition = "Content-Disposition" ":" OWS 1567 content-disposition-v 1568 content-disposition-v = disposition-type 1569 *( OWS ";" OWS disposition-parm ) 1570 disposition-type = "attachment" / disp-extension-token 1571 disposition-parm = filename-parm / disp-extension-parm 1572 filename-parm = "filename" "=" quoted-string 1573 disp-extension-token = token 1574 disp-extension-parm = token "=" ( token / quoted-string ) 1576 An example is 1578 Content-Disposition: attachment; filename="fname.ext" 1580 The receiving user agent SHOULD NOT respect any directory path 1581 information present in the filename-parm parameter, which is the only 1582 parameter believed to apply to HTTP implementations at this time. 1583 The filename SHOULD be treated as a terminal component only. 1585 If this header is used in a response with the application/ 1586 octet-stream content-type, the implied suggestion is that the user 1587 agent should not display the response, but directly enter a "save 1588 response as..." dialog. 1590 See Section 7.2 for Content-Disposition security issues. 1592 Appendix C. Compatibility with Previous Versions 1594 C.1. Changes from RFC 2068 1596 Transfer-coding and message lengths all interact in ways that 1597 required fixing exactly when chunked encoding is used (to allow for 1598 transfer encoding that may not be self delimiting); it was important 1599 to straighten out exactly how message lengths are computed. 1600 (Section 3.2.2, see also [Part1], [Part5] and [Part6]). 1602 Charset wildcarding is introduced to avoid explosion of character set 1603 names in accept headers. (Section 5.2) 1605 Content-Base was deleted from the specification: it was not 1606 implemented widely, and there is no simple, safe way to introduce it 1607 without a robust extension mechanism. In addition, it is used in a 1608 similar, but not identical fashion in MHTML [RFC2557]. 1610 A content-coding of "identity" was introduced, to solve problems 1611 discovered in caching. (Section 2.2) 1613 The Alternates, Content-Version, Derived-From, Link, URI, Public and 1614 Content-Base header fields were defined in previous versions of this 1615 specification, but not commonly implemented. See Section 19.6.2 of 1616 [RFC2068]. 1618 C.2. Changes from RFC 2616 1620 Clarify contexts that charset is used in. (Section 2.1) 1622 Remove base URI setting semantics for Content-Location due to poor 1623 implementation support, which was caused by too many broken servers 1624 emitting bogus Content-Location headers, and also the potentially 1625 undesirable effect of potentially breaking relative links in content- 1626 negotiated resources. (Section 5.7) 1628 Remove reference to non-existant identity transfer-coding value 1629 tokens. (Appendix A.5) 1631 Appendix D. Collected ABNF 1633 Accept = "Accept:" OWS Accept-v 1634 Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v 1635 Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1636 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1637 qvalue ] ] ) 1638 Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v 1639 Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) 1640 ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1641 Accept-Language = "Accept-Language:" OWS Accept-Language-v 1642 Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1643 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1644 ] ) 1645 Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1646 OWS media-range [ accept-params ] ] ) ] 1648 Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v 1649 Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS 1650 content-coding ] ) 1651 Content-Language = "Content-Language:" OWS Content-Language-v 1652 Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS 1653 language-tag ] ) 1654 Content-Length = 1655 Content-Location = "Content-Location:" OWS Content-Location-v 1656 Content-Location-v = absolute-URI / partial-URI 1657 Content-MD5 = "Content-MD5:" OWS Content-MD5-v 1658 Content-MD5-v = 1659 Content-Range = 1660 Content-Type = "Content-Type:" OWS Content-Type-v 1661 Content-Type-v = media-type 1663 Expires = 1665 Last-Modified = 1667 MIME-Version = "MIME-Version:" OWS MIME-Version-v 1668 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1670 OWS = 1672 absolute-URI = 1673 accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 1674 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1675 attribute = token 1677 charset = token 1678 codings = ( content-coding / "*" ) 1679 content-coding = token 1680 content-disposition = "Content-Disposition:" OWS 1681 content-disposition-v 1682 content-disposition-v = disposition-type *( OWS ";" OWS 1683 disposition-parm ) 1685 disp-extension-parm = token "=" ( token / quoted-string ) 1686 disp-extension-token = token 1687 disposition-parm = filename-parm / disp-extension-parm 1688 disposition-type = "attachment" / disp-extension-token 1690 entity-body = *OCTET 1691 entity-header = Content-Encoding / Content-Language / Content-Length 1692 / Content-Location / Content-MD5 / Content-Range / Content-Type / 1693 Expires / Last-Modified / extension-header 1694 extension-header = header-field 1696 filename-parm = "filename=" quoted-string 1698 header-field = 1700 language-range = 1701 language-tag = 1703 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1704 ";" OWS parameter ) 1705 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1707 parameter = attribute "=" value 1708 partial-URI = 1710 quoted-string = 1711 qvalue = 1713 subtype = token 1715 token = 1716 type = token 1718 value = token / quoted-string 1720 ABNF diagnostics: 1722 ; Accept defined but not used 1723 ; Accept-Charset defined but not used 1724 ; Accept-Encoding defined but not used 1725 ; Accept-Language defined but not used 1726 ; MIME-Version defined but not used 1727 ; content-disposition defined but not used 1728 ; entity-body defined but not used 1729 ; entity-header defined but not used 1731 Appendix E. Change Log (to be removed by RFC Editor before publication) 1733 E.1. Since RFC2616 1735 Extracted relevant partitions from [RFC2616]. 1737 E.2. Since draft-ietf-httpbis-p3-payload-00 1739 Closed issues: 1741 o : "Media Type 1742 Registrations" () 1744 o : "Clarification 1745 regarding quoting of charset values" 1746 () 1748 o : "Remove 1749 'identity' token references" 1750 () 1752 o : "Accept- 1753 Encoding BNF" 1755 o : "Normative and 1756 Informative references" 1758 o : "RFC1700 1759 references" 1761 o : "Updating to 1762 RFC4288" 1764 o : "Informative 1765 references" 1767 o : "ISO-8859-1 1768 Reference" 1770 o : "Encoding 1771 References Normative" 1773 o : "Normative up- 1774 to-date references" 1776 E.3. Since draft-ietf-httpbis-p3-payload-01 1778 Ongoing work on ABNF conversion 1779 (): 1781 o Add explicit references to BNF syntax and rules imported from 1782 other parts of the specification. 1784 E.4. Since draft-ietf-httpbis-p3-payload-02 1786 Closed issues: 1788 o : "Quoting 1789 Charsets" 1791 o : 1792 "Classification for Allow header" 1794 o : "missing 1795 default for qvalue in description of Accept-Encoding" 1797 Ongoing work on IANA Message Header Registration 1798 (): 1800 o Reference RFC 3984, and update header registrations for headers 1801 defined in this document. 1803 E.5. Since draft-ietf-httpbis-p3-payload-03 1805 Closed issues: 1807 o : "Quoting 1808 Charsets" 1810 o : "language tag 1811 matching (Accept-Language) vs RFC4647" 1813 o : "RFC 1806 has 1814 been replaced by RFC2183" 1816 Other changes: 1818 o : "Encoding 1819 References Normative" -- rephrase the annotation and reference 1820 [BCP97]. 1822 E.6. Since draft-ietf-httpbis-p3-payload-04 1824 Closed issues: 1826 o : "RFC 2822 is 1827 updated by RFC 5322" 1829 Ongoing work on ABNF conversion 1830 (): 1832 o Use "/" instead of "|" for alternatives. 1834 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1835 whitespace ("OWS") and required whitespace ("RWS"). 1837 o Rewrite ABNFs to spell out whitespace rules, factor out header 1838 value format definitions. 1840 E.7. Since draft-ietf-httpbis-p3-payload-05 1842 Closed issues: 1844 o : "Join 1845 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1847 Final work on ABNF conversion 1848 (): 1850 o Add appendix containing collected and expanded ABNF, reorganize 1851 ABNF introduction. 1853 Other changes: 1855 o Move definition of quality values into Part 1. 1857 E.8. Since draft-ietf-httpbis-p3-payload-06 1859 Closed issues: 1861 o : "Content- 1862 Location isn't special" 1864 o : "Content 1865 Sniffing" 1867 E.9. Since draft-ietf-httpbis-p3-payload-07 1869 Closed issues: 1871 o : "Updated 1872 reference for language tags" 1874 o : "Clarify rules 1875 for determining what entities a response carries" 1877 o : "Content- 1878 Location base-setting problems" 1880 o : "Content 1881 Sniffing" 1883 o : "pick IANA 1884 policy (RFC5226) for Transfer Coding / Content Coding" 1886 o : "move 1887 definitions of gzip/deflate/compress to part 1" 1889 Partly resolved issues: 1891 o : "update IANA 1892 requirements wrt Transfer-Coding values" (add the IANA 1893 Considerations subsection) 1895 o : "update IANA 1896 requirements wrt Content-Coding values" (add the IANA 1897 Considerations subsection) 1899 E.10. Since draft-ietf-httpbis-p3-payload-08 1901 Closed issues: 1903 o : "Content 1904 Negotiation for media types" 1906 o : "Accept- 1907 Language: which RFC4647 filtering?" 1909 Index 1911 A 1912 Accept header 16 1913 Accept-Charset header 19 1914 Accept-Encoding header 19 1915 Accept-Language header 21 1916 Alternates header 35 1918 C 1919 Coding Format 1920 compress 8 1921 deflate 8 1922 gzip 9 1923 identity 9 1924 compress (Coding Format) 8 1925 content negotiation 5 1926 Content-Base header 35 1927 Content-Disposition header 34 1928 Content-Encoding header 22 1929 Content-Language header 23 1930 Content-Location header 23 1931 Content-MD5 header 24 1932 Content-Type header 26 1933 Content-Version header 35 1935 D 1936 deflate (Coding Format) 8 1937 Derived-From header 35 1939 E 1940 entity 5 1942 G 1943 Grammar 1944 Accept 17 1945 Accept-Charset 19 1946 Accept-Charset-v 19 1947 Accept-Encoding 19 1948 Accept-Encoding-v 19 1949 accept-ext 17 1950 Accept-Language 21 1951 Accept-Language-v 21 1952 accept-params 17 1953 Accept-v 17 1954 attribute 10 1955 charset 7 1956 codings 19 1957 content-coding 8 1958 content-disposition 34 1959 content-disposition-v 34 1960 Content-Encoding 22 1961 Content-Encoding-v 22 1962 Content-Language 23 1963 Content-Language-v 23 1964 Content-Location 24 1965 Content-Location-v 24 1966 Content-MD5 24 1967 Content-MD5-v 24 1968 Content-Type 26 1969 Content-Type-v 26 1970 disp-extension-parm 34 1971 disp-extension-token 34 1972 disposition-parm 34 1973 disposition-type 34 1974 entity-body 13 1975 entity-header 12 1976 extension-header 12 1977 filename-parm 34 1978 language-range 21 1979 language-tag 12 1980 media-range 17 1981 media-type 9 1982 MIME-Version 32 1983 MIME-Version-v 32 1984 parameter 10 1985 subtype 9 1986 type 9 1987 value 10 1988 gzip (Coding Format) 9 1990 H 1991 Headers 1992 Accept 16 1993 Accept-Charset 19 1994 Accept-Encoding 19 1995 Accept-Language 21 1996 Alternate 35 1997 Content-Base 35 1998 Content-Disposition 34 1999 Content-Encoding 22 2000 Content-Language 23 2001 Content-Location 23 2002 Content-MD5 24 2003 Content-Type 26 2004 Content-Version 35 2005 Derived-From 35 2006 Link 35 2007 MIME-Version 32 2008 Public 35 2009 URI 35 2011 I 2012 identity (Coding Format) 9 2014 L 2015 Link header 35 2017 M 2018 MIME-Version header 32 2020 P 2021 Public header 35 2023 R 2024 representation 5 2026 U 2027 URI header 35 2029 V 2030 variant 5 2032 Authors' Addresses 2034 Roy T. Fielding (editor) 2035 Day Software 2036 23 Corporate Plaza DR, Suite 280 2037 Newport Beach, CA 92660 2038 USA 2040 Phone: +1-949-706-5300 2041 Fax: +1-949-706-5305 2042 Email: fielding@gbiv.com 2043 URI: http://roy.gbiv.com/ 2045 Jim Gettys 2046 One Laptop per Child 2047 21 Oak Knoll Road 2048 Carlisle, MA 01741 2049 USA 2051 Email: jg@laptop.org 2052 URI: http://www.laptop.org/ 2053 Jeffrey C. Mogul 2054 Hewlett-Packard Company 2055 HP Labs, Large Scale Systems Group 2056 1501 Page Mill Road, MS 1177 2057 Palo Alto, CA 94304 2058 USA 2060 Email: JeffMogul@acm.org 2062 Henrik Frystyk Nielsen 2063 Microsoft Corporation 2064 1 Microsoft Way 2065 Redmond, WA 98052 2066 USA 2068 Email: henrikn@microsoft.com 2070 Larry Masinter 2071 Adobe Systems, Incorporated 2072 345 Park Ave 2073 San Jose, CA 95110 2074 USA 2076 Email: LMM@acm.org 2077 URI: http://larry.masinter.net/ 2079 Paul J. Leach 2080 Microsoft Corporation 2081 1 Microsoft Way 2082 Redmond, WA 98052 2084 Email: paulle@microsoft.com 2086 Tim Berners-Lee 2087 World Wide Web Consortium 2088 MIT Computer Science and Artificial Intelligence Laboratory 2089 The Stata Center, Building 32 2090 32 Vassar Street 2091 Cambridge, MA 02139 2092 USA 2094 Email: timbl@w3.org 2095 URI: http://www.w3.org/People/Berners-Lee/ 2096 Yves Lafon (editor) 2097 World Wide Web Consortium 2098 W3C / ERCIM 2099 2004, rte des Lucioles 2100 Sophia-Antipolis, AM 06902 2101 France 2103 Email: ylafon@w3.org 2104 URI: http://www.raubacapeu.net/people/yves/ 2106 Julian F. Reschke (editor) 2107 greenbytes GmbH 2108 Hafenweg 16 2109 Muenster, NW 48155 2110 Germany 2112 Phone: +49 251 2807760 2113 Fax: +49 251 2807761 2114 Email: julian.reschke@greenbytes.de 2115 URI: http://greenbytes.de/tech/webdav/