idnits 2.17.1 draft-ietf-httpbis-p3-payload-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (July 12, 2010) is 5037 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-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-10 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 7 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 Alcatel-Lucent 6 Expires: January 13, 2011 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 July 12, 2010 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-10 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.11. 45 Status of This Memo 47 This Internet-Draft is submitted 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). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 13, 2011. 62 Copyright Notice 64 Copyright (c) 2010 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 92 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 93 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 95 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 96 1.3.2. ABNF Rules defined in other Parts of the 97 Specification . . . . . . . . . . . . . . . . . . . . 6 99 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 100 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 101 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 102 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 103 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 104 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 105 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 106 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 107 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 12 108 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 109 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 110 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 111 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 112 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14 113 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 114 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 115 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 116 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 117 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 118 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 119 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 120 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 121 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 122 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 123 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 124 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 125 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 126 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 127 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 128 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 129 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 130 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 131 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 132 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 133 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 134 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 135 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 136 Appendix A. Differences Between HTTP Entities and RFC 2045 137 Entities . . . . . . . . . . . . . . . . . . . . . . 32 138 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 139 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 140 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 141 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 142 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 143 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 144 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 145 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 146 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 148 Appendix C. Compatibility with Previous Versions . . . . . . . . 35 149 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 150 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36 151 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 152 Appendix E. Change Log (to be removed by RFC Editor before 153 publication) . . . . . . . . . . . . . . . . . . . . 38 154 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 155 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 156 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 157 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 158 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40 159 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 160 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 41 161 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41 162 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 163 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 164 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 165 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 167 1. Introduction 169 This document defines HTTP/1.1 message payloads (a.k.a., content), 170 the associated metadata header fields that define how the payload is 171 intended to be interpreted by a recipient, the request header fields 172 that may influence content selection, and the various selection 173 algorithms that are collectively referred to as HTTP content 174 negotiation. 176 This document is currently disorganized in order to minimize the 177 changes between drafts and enable reviewers to see the smaller errata 178 changes. The next draft will reorganize the sections to better 179 reflect the content. In particular, the sections on entities will be 180 renamed payload and moved to the first half of the document, while 181 the sections on content negotiation and associated request header 182 fields will be moved to the second half. The current mess reflects 183 how widely dispersed these topics and associated requirements had 184 become in [RFC2616]. 186 1.1. Terminology 188 This specification uses a number of terms to refer to the roles 189 played by participants in, and objects of, the HTTP communication. 191 content negotiation 193 The mechanism for selecting the appropriate representation when 194 servicing a request. The representation of entities in any 195 response can be negotiated (including error responses). 197 entity 199 The information transferred as the payload of a request or 200 response. An entity consists of metadata in the form of entity- 201 header fields and content in the form of an entity-body. 203 representation 205 An entity included with a response that is subject to content 206 negotiation. There may exist multiple representations associated 207 with a particular response status. 209 variant 211 A resource may have one, or more than one, representation(s) 212 associated with it at any given instant. Each of these 213 representations is termed a "variant". Use of the term "variant" 214 does not necessarily imply that the resource is subject to content 215 negotiation. 217 1.2. Requirements 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 An implementation is not compliant if it fails to satisfy one or more 224 of the "MUST" or "REQUIRED" level requirements for the protocols it 225 implements. An implementation that satisfies all the "MUST" or 226 "REQUIRED" level and all the "SHOULD" level requirements for its 227 protocols is said to be "unconditionally compliant"; one that 228 satisfies all the "MUST" level requirements but not all the "SHOULD" 229 level requirements for its protocols is said to be "conditionally 230 compliant". 232 1.3. Syntax Notation 234 This specification uses the ABNF syntax defined in Section 1.2 of 235 [Part1] (which extends the syntax defined in [RFC5234] with a list 236 rule). Appendix D shows the collected ABNF, with the list rule 237 expanded. 239 The following core rules are included by reference, as defined in 240 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 241 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 242 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 243 sequence of data), SP (space), VCHAR (any visible USASCII character), 244 and WSP (whitespace). 246 1.3.1. Core Rules 248 The core rules below are defined in Section 1.2.2 of [Part1]: 250 quoted-string = 251 token = 252 word = 253 OWS = 255 1.3.2. ABNF Rules defined in other Parts of the Specification 257 The ABNF rules below are defined in other parts: 259 absolute-URI = 260 Content-Length = 261 header-field = 262 partial-URI = 263 qvalue = 265 Last-Modified = 267 Content-Range = 269 Expires = 271 2. Protocol Parameters 273 2.1. Character Sets 275 HTTP uses the same definition of the term "character set" as that 276 described for MIME: 278 The term "character set" is used in this document to refer to a 279 method used with one or more tables to convert a sequence of octets 280 into a sequence of characters. Note that unconditional conversion in 281 the other direction is not required, in that not all characters may 282 be available in a given character set and a character set may provide 283 more than one sequence of octets to represent a particular character. 284 This definition is intended to allow various kinds of character 285 encoding, from simple single-table mappings such as US-ASCII to 286 complex table switching methods such as those that use ISO-2022's 287 techniques. However, the definition associated with a MIME character 288 set name MUST fully specify the mapping to be performed from octets 289 to characters. In particular, use of external profiling information 290 to determine the exact mapping is not permitted. 292 Note: This use of the term "character set" is more commonly 293 referred to as a "character encoding." However, since HTTP and 294 MIME share the same registry, it is important that the terminology 295 also be shared. 297 HTTP character sets are identified by case-insensitive tokens. The 298 complete set of tokens is defined by the IANA Character Set registry 299 (). 301 charset = token 303 Although HTTP allows an arbitrary token to be used as a charset 304 value, any token that has a predefined value within the IANA 305 Character Set registry MUST represent the character set defined by 306 that registry. Applications SHOULD limit their use of character sets 307 to those defined by the IANA registry. 309 HTTP uses charset in two contexts: within an Accept-Charset request 310 header (in which the charset value is an unquoted token) and as the 311 value of a parameter in a Content-Type header (within a request or 312 response), in which case the parameter value of the charset parameter 313 may be quoted. 315 Implementors should be aware of IETF character set requirements 316 [RFC3629] [RFC2277]. 318 2.1.1. Missing Charset 320 Some HTTP/1.0 software has interpreted a Content-Type header without 321 charset parameter incorrectly to mean "recipient should guess." 322 Senders wishing to defeat this behavior MAY include a charset 323 parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and 324 SHOULD do so when it is known that it will not confuse the recipient. 326 Unfortunately, some older HTTP/1.0 clients did not deal properly with 327 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 328 charset label provided by the sender; and those user agents that have 329 a provision to "guess" a charset MUST use the charset from the 330 content-type field if they support that charset, rather than the 331 recipient's preference, when initially displaying a document. See 332 Section 2.3.1. 334 2.2. Content Codings 336 Content coding values indicate an encoding transformation that has 337 been or can be applied to an entity. Content codings are primarily 338 used to allow a document to be compressed or otherwise usefully 339 transformed without losing the identity of its underlying media type 340 and without loss of information. Frequently, the entity is stored in 341 coded form, transmitted directly, and only decoded by the recipient. 343 content-coding = token 345 All content-coding values are case-insensitive. HTTP/1.1 uses 346 content-coding values in the Accept-Encoding (Section 5.3) and 347 Content-Encoding (Section 5.5) header fields. Although the value 348 describes the content-coding, what is more important is that it 349 indicates what decoding mechanism will be required to remove the 350 encoding. 352 compress 354 See Section 6.2.2.1 of [Part1]. 356 deflate 357 See Section 6.2.2.2 of [Part1]. 359 gzip 361 See Section 6.2.2.3 of [Part1]. 363 identity 365 The default (identity) encoding; the use of no transformation 366 whatsoever. This content-coding is used only in the Accept- 367 Encoding header, and SHOULD NOT be used in the Content-Encoding 368 header. 370 2.2.1. Content Coding Registry 372 The HTTP Content Coding Registry defines the name space for the 373 content coding names. 375 Registrations MUST include the following fields: 377 o Name 379 o Description 381 o Pointer to specification text 383 Names of content codings MUST NOT overlap with names of transfer 384 codings (Section 6.2 of [Part1]), unless the encoding transformation 385 is identical (as it is the case for the compression codings defined 386 in Section 6.2.2 of [Part1]). 388 Values to be added to this name space require expert review and a 389 specification (see "Expert Review" and "Specification Required" in 390 Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 391 coding defined in this section. 393 The registry itself is maintained at 394 . 396 2.3. Media Types 398 HTTP uses Internet Media Types [RFC2046] in the Content-Type 399 (Section 5.9) and Accept (Section 5.1) header fields in order to 400 provide open and extensible data typing and type negotiation. 402 media-type = type "/" subtype *( OWS ";" OWS parameter ) 403 type = token 404 subtype = token 406 Parameters MAY follow the type/subtype in the form of attribute/value 407 pairs. 409 parameter = attribute "=" value 410 attribute = token 411 value = word 413 The type, subtype, and parameter attribute names are case- 414 insensitive. Parameter values might or might not be case-sensitive, 415 depending on the semantics of the parameter name. The presence or 416 absence of a parameter might be significant to the processing of a 417 media-type, depending on its definition within the media type 418 registry. 420 A parameter value that matches the token production may be 421 transmitted as either a token or within a quoted-string. The quoted 422 and unquoted values are equivalent. 424 Note that some older HTTP applications do not recognize media type 425 parameters. When sending data to older HTTP applications, 426 implementations SHOULD only use media type parameters when they are 427 required by that type/subtype definition. 429 Media-type values are registered with the Internet Assigned Number 430 Authority (IANA). The media type registration process is outlined in 431 [RFC4288]. Use of non-registered media types is discouraged. 433 2.3.1. Canonicalization and Text Defaults 435 Internet media types are registered with a canonical form. An 436 entity-body transferred via HTTP messages MUST be represented in the 437 appropriate canonical form prior to its transmission except for 438 "text" types, as defined in the next paragraph. 440 When in canonical form, media subtypes of the "text" type use CRLF as 441 the text line break. HTTP relaxes this requirement and allows the 442 transport of text media with plain CR or LF alone representing a line 443 break when it is done consistently for an entire entity-body. HTTP 444 applications MUST accept CRLF, bare CR, and bare LF as being 445 representative of a line break in text media received via HTTP. In 446 addition, if the text is represented in a character set that does not 447 use octets 13 and 10 for CR and LF respectively, as is the case for 448 some multi-byte character sets, HTTP allows the use of whatever octet 449 sequences are defined by that character set to represent the 450 equivalent of CR and LF for line breaks. This flexibility regarding 451 line breaks applies only to text media in the entity-body; a bare CR 452 or LF MUST NOT be substituted for CRLF within any of the HTTP control 453 structures (such as header fields and multipart boundaries). 455 If an entity-body is encoded with a content-coding, the underlying 456 data MUST be in a form defined above prior to being encoded. 458 The "charset" parameter is used with some media types to define the 459 character set (Section 2.1) of the data. When no explicit charset 460 parameter is provided by the sender, media subtypes of the "text" 461 type are defined to have a default charset value of "ISO-8859-1" when 462 received via HTTP. Data in character sets other than "ISO-8859-1" or 463 its subsets MUST be labeled with an appropriate charset value. See 464 Section 2.1.1 for compatibility problems. 466 2.3.2. Multipart Types 468 MIME provides for a number of "multipart" types -- encapsulations of 469 one or more entities within a single message-body. All multipart 470 types share a common syntax, as defined in Section 5.1.1 of 471 [RFC2046], and MUST include a boundary parameter as part of the media 472 type value. The message body is itself a protocol element and MUST 473 therefore use only CRLF to represent line breaks between body-parts. 474 Unlike in RFC 2046, the epilogue of any multipart message MUST be 475 empty; HTTP applications MUST NOT transmit the epilogue (even if the 476 original multipart contains an epilogue). These restrictions exist 477 in order to preserve the self-delimiting nature of a multipart 478 message-body, wherein the "end" of the message-body is indicated by 479 the ending multipart boundary. 481 In general, HTTP treats a multipart message-body no differently than 482 any other media type: strictly as payload. The one exception is the 483 "multipart/byteranges" type (Appendix A of [Part5]) when it appears 484 in a 206 (Partial Content) response. In all other cases, an HTTP 485 user agent SHOULD follow the same or similar behavior as a MIME user 486 agent would upon receipt of a multipart type. The MIME header fields 487 within each body-part of a multipart message-body do not have any 488 significance to HTTP beyond that defined by their MIME semantics. 490 In general, an HTTP user agent SHOULD follow the same or similar 491 behavior as a MIME user agent would upon receipt of a multipart type. 492 If an application receives an unrecognized multipart subtype, the 493 application MUST treat it as being equivalent to "multipart/mixed". 495 Note: The "multipart/form-data" type has been specifically defined 496 for carrying form data suitable for processing via the POST 497 request method, as described in [RFC2388]. 499 2.4. Language Tags 501 A language tag, as defined in [RFC5646], identifies a natural 502 language spoken, written, or otherwise conveyed by human beings for 503 communication of information to other human beings. Computer 504 languages are explicitly excluded. HTTP uses language tags within 505 the Accept-Language and Content-Language fields. 507 In summary, a language tag is composed of one or more parts: A 508 primary language subtag followed by a possibly empty series of 509 subtags: 511 language-tag = 513 White space is not allowed within the tag and all tags are case- 514 insensitive. The name space of language subtags is administered by 515 the IANA (see 516 ). 518 Example tags include: 520 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 522 See [RFC5646] for further information. 524 3. Entity 526 Request and Response messages MAY transfer an entity if not otherwise 527 restricted by the request method or response status code. An entity 528 consists of entity-header fields and an entity-body, although some 529 responses will only include the entity-headers. 531 In this section, both sender and recipient refer to either the client 532 or the server, depending on who sends and who receives the entity. 534 3.1. Entity Header Fields 536 Entity-header fields define metainformation about the entity-body or, 537 if no body is present, about the resource identified by the request. 539 entity-header = Content-Encoding ; Section 5.5 540 / Content-Language ; Section 5.6 541 / Content-Length ; [Part1], Section 9.2 542 / Content-Location ; Section 5.7 543 / Content-MD5 ; Section 5.8 544 / Content-Range ; [Part5], Section 5.2 545 / Content-Type ; Section 5.9 546 / Expires ; [Part6], Section 3.3 547 / Last-Modified ; [Part4], Section 6.6 548 / extension-header 550 extension-header = header-field 552 The extension-header mechanism allows additional entity-header fields 553 to be defined without changing the protocol, but these fields cannot 554 be assumed to be recognizable by the recipient. Unrecognized header 555 fields SHOULD be ignored by the recipient and MUST be forwarded by 556 transparent proxies. 558 3.2. Entity Body 560 The entity-body (if any) sent with an HTTP request or response is in 561 a format and encoding defined by the entity-header fields. 563 entity-body = *OCTET 565 An entity-body is only present in a message when a message-body is 566 present, as described in Section 3.3 of [Part1]. The entity-body is 567 obtained from the message-body by decoding any Transfer-Encoding that 568 might have been applied to ensure safe and proper transfer of the 569 message. 571 3.2.1. Type 573 When an entity-body is included with a message, the data type of that 574 body is determined via the header fields Content-Type and Content- 575 Encoding. These define a two-layer, ordered encoding model: 577 entity-body := Content-Encoding( Content-Type( data ) ) 579 Content-Type specifies the media type of the underlying data. Any 580 HTTP/1.1 message containing an entity-body SHOULD include a Content- 581 Type header field defining the media type of that body, unless that 582 information is unknown. 584 If the Content-Type header field is not present, it indicates that 585 the sender does not know the media type of the data; recipients MAY 586 either assume that it is "application/octet-stream" ([RFC2046], 587 Section 4.5.1) or examine the content to determine its type. 589 In practice, currently-deployed servers sometimes provide a Content- 590 Type header which does not correctly convey the intended 591 interpretation of the content sent, with the result that some clients 592 will examine the response body's content and override the specified 593 type. 595 Client that do so risk drawing incorrect conclusions, which may 596 expose additional security risks (e.g., "privilege escalation"). 597 Implementers are encouraged to provide a means of disabling such 598 "content sniffing" when it is used. 600 Content-Encoding may be used to indicate any additional content 601 codings applied to the data, usually for the purpose of data 602 compression, that are a property of the requested resource. There is 603 no default encoding. 605 3.2.2. Entity Length 607 The entity-length of a message is the length of the message-body 608 before any transfer-codings have been applied. Section 3.4 of 609 [Part1] defines how the transfer-length of a message-body is 610 determined. 612 4. Content Negotiation 614 HTTP responses include a representation which contains information 615 for interpretation, whether by a human user or for further 616 processing. Often, the server has different ways of representing the 617 same information; for example, in different formats, languages, or 618 using different character encodings. 620 HTTP clients and their users might have different or variable 621 capabilities, characteristics or preferences which would influence 622 which representation, among those available from the server, would be 623 best for the server to deliver. For this reason, HTTP provides 624 mechanisms for "content negotiation" -- a process of allowing 625 selection of a representation of a given resource, when more than one 626 is available. 628 This specification defines two patterns of content negotiation; 629 "server-driven", where the server selects the representation based 630 upon the client's stated preferences, and "agent-driven" negotiation, 631 where the server provides a list of representations for the client to 632 choose from, based upon their metadata. In addition, there are other 633 patterns: some applications use an "active content" pattern, where 634 the server returns active content which runs on the client and, based 635 on client available parameters, selects additional resources to 636 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 637 proposed. 639 These patterns are all widely used, and have trade-offs in 640 applicability and practicality. In particular, when the number of 641 preferences or capabilities to be expressed by a client are large 642 (such as when many different formats are supported by a user-agent), 643 server-driven negotiation becomes unwieldy, and may not be 644 appropriate. Conversely, when the number of representations to 645 choose from is very large, agent-driven negotiation may not be 646 appropriate. 648 Note that in all cases, the supplier of representations has the 649 responsibility for determining which representations might be 650 considered to be the "same information". 652 4.1. Server-driven Negotiation 654 If the selection of the best representation for a response is made by 655 an algorithm located at the server, it is called server-driven 656 negotiation. Selection is based on the available representations of 657 the response (the dimensions over which it can vary; e.g., language, 658 content-coding, etc.) and the contents of particular header fields in 659 the request message or on other information pertaining to the request 660 (such as the network address of the client). 662 Server-driven negotiation is advantageous when the algorithm for 663 selecting from among the available representations is difficult to 664 describe to the user agent, or when the server desires to send its 665 "best guess" to the client along with the first response (hoping to 666 avoid the round-trip delay of a subsequent request if the "best 667 guess" is good enough for the user). In order to improve the 668 server's guess, the user agent MAY include request header fields 669 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 670 preferences for such a response. 672 Server-driven negotiation has disadvantages: 674 1. It is impossible for the server to accurately determine what 675 might be "best" for any given user, since that would require 676 complete knowledge of both the capabilities of the user agent and 677 the intended use for the response (e.g., does the user want to 678 view it on screen or print it on paper?). 680 2. Having the user agent describe its capabilities in every request 681 can be both very inefficient (given that only a small percentage 682 of responses have multiple representations) and a potential 683 violation of the user's privacy. 685 3. It complicates the implementation of an origin server and the 686 algorithms for generating responses to a request. 688 4. It may limit a public cache's ability to use the same response 689 for multiple user's requests. 691 HTTP/1.1 includes the following request-header fields for enabling 692 server-driven negotiation through description of user agent 693 capabilities and user preferences: Accept (Section 5.1), Accept- 694 Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language 695 (Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an 696 origin server is not limited to these dimensions and MAY vary the 697 response based on any aspect of the request, including information 698 outside the request-header fields or within extension header fields 699 not defined by this specification. 701 Note: In practice, User-Agent based negotiation is fragile, 702 because new clients might not be recognized. 704 The Vary header field (Section 3.5 of [Part6]) can be used to express 705 the parameters the server uses to select a representation that is 706 subject to server-driven negotiation. 708 4.2. Agent-driven Negotiation 710 With agent-driven negotiation, selection of the best representation 711 for a response is performed by the user agent after receiving an 712 initial response from the origin server. Selection is based on a 713 list of the available representations of the response included within 714 the header fields or entity-body of the initial response, with each 715 representation identified by its own URI. Selection from among the 716 representations may be performed automatically (if the user agent is 717 capable of doing so) or manually by the user selecting from a 718 generated (possibly hypertext) menu. 720 Agent-driven negotiation is advantageous when the response would vary 721 over commonly-used dimensions (such as type, language, or encoding), 722 when the origin server is unable to determine a user agent's 723 capabilities from examining the request, and generally when public 724 caches are used to distribute server load and reduce network usage. 726 Agent-driven negotiation suffers from the disadvantage of needing a 727 second request to obtain the best alternate representation. This 728 second request is only efficient when caching is used. In addition, 729 this specification does not define any mechanism for supporting 730 automatic selection, though it also does not prevent any such 731 mechanism from being developed as an extension and used within 732 HTTP/1.1. 734 This specification defines the 300 (Multiple Choices) and 406 (Not 735 Acceptable) status codes for enabling agent-driven negotiation when 736 the server is unwilling or unable to provide a varying response using 737 server-driven negotiation. 739 5. Header Field Definitions 741 This section defines the syntax and semantics of HTTP/1.1 header 742 fields related to the payload of messages. 744 For entity-header fields, both sender and recipient refer to either 745 the client or the server, depending on who sends and who receives the 746 entity. 748 5.1. Accept 750 The "Accept" request-header field can be used by user agents to 751 specify response media types that are acceptable. Accept headers can 752 be used to indicate that the request is specifically limited to a 753 small set of desired types, as in the case of a request for an in- 754 line image. 756 Accept = "Accept" ":" OWS Accept-v 757 Accept-v = #( media-range [ accept-params ] ) 759 media-range = ( "*/*" 760 / ( type "/" "*" ) 761 / ( type "/" subtype ) 762 ) *( OWS ";" OWS parameter ) 763 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 764 accept-ext = OWS ";" OWS token 765 [ "=" word ] 767 The asterisk "*" character is used to group media types into ranges, 768 with "*/*" indicating all media types and "type/*" indicating all 769 subtypes of that type. The media-range MAY include media type 770 parameters that are applicable to that range. 772 Each media-range MAY be followed by one or more accept-params, 773 beginning with the "q" parameter for indicating a relative quality 774 factor. The first "q" parameter (if any) separates the media-range 775 parameter(s) from the accept-params. Quality factors allow the user 776 or user agent to indicate the relative degree of preference for that 777 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 778 [Part1]). The default value is q=1. 780 Note: Use of the "q" parameter name to separate media type 781 parameters from Accept extension parameters is due to historical 782 practice. Although this prevents any media type parameter named 783 "q" from being used with a media range, such an event is believed 784 to be unlikely given the lack of any "q" parameters in the IANA 785 media type registry and the rare usage of any media type 786 parameters in Accept. Future media types are discouraged from 787 registering any parameter named "q". 789 The example 791 Accept: audio/*; q=0.2, audio/basic 793 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 794 type if it is the best available after an 80% mark-down in quality." 796 If no Accept header field is present, then it is assumed that the 797 client accepts all media types. If an Accept header field is 798 present, and if the server cannot send a response which is acceptable 799 according to the combined Accept field value, then the server SHOULD 800 send a 406 (Not Acceptable) response. 802 A more elaborate example is 804 Accept: text/plain; q=0.5, text/html, 805 text/x-dvi; q=0.8, text/x-c 807 Verbally, this would be interpreted as "text/html and text/x-c are 808 the preferred media types, but if they do not exist, then send the 809 text/x-dvi entity, and if that does not exist, send the text/plain 810 entity." 812 Media ranges can be overridden by more specific media ranges or 813 specific media types. If more than one media range applies to a 814 given type, the most specific reference has precedence. For example, 816 Accept: text/*, text/html, text/html;level=1, */* 818 have the following precedence: 820 1. text/html;level=1 822 2. text/html 824 3. text/* 826 4. */* 827 The media type quality factor associated with a given type is 828 determined by finding the media range with the highest precedence 829 which matches that type. For example, 831 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 832 text/html;level=2;q=0.4, */*;q=0.5 834 would cause the following values to be associated: 836 +-------------------+---------------+ 837 | Media Type | Quality Value | 838 +-------------------+---------------+ 839 | text/html;level=1 | 1 | 840 | text/html | 0.7 | 841 | text/plain | 0.3 | 842 | image/jpeg | 0.5 | 843 | text/html;level=2 | 0.4 | 844 | text/html;level=3 | 0.7 | 845 +-------------------+---------------+ 847 Note: A user agent might be provided with a default set of quality 848 values for certain media ranges. However, unless the user agent is a 849 closed system which cannot interact with other rendering agents, this 850 default set ought to be configurable by the user. 852 5.2. Accept-Charset 854 The "Accept-Charset" request-header field can be used by user agents 855 to indicate what response character sets are acceptable. This field 856 allows clients capable of understanding more comprehensive or 857 special-purpose character sets to signal that capability to a server 858 which is capable of representing documents in those character sets. 860 Accept-Charset = "Accept-Charset" ":" OWS 861 Accept-Charset-v 862 Accept-Charset-v = 1#( ( charset / "*" ) 863 [ OWS ";" OWS "q=" qvalue ] ) 865 Character set values are described in Section 2.1. Each charset MAY 866 be given an associated quality value which represents the user's 867 preference for that charset. The default value is q=1. An example 868 is 870 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 872 The special value "*", if present in the Accept-Charset field, 873 matches every character set (including ISO-8859-1) which is not 874 mentioned elsewhere in the Accept-Charset field. If no "*" is 875 present in an Accept-Charset field, then all character sets not 876 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 877 which gets a quality value of 1 if not explicitly mentioned. 879 If no Accept-Charset header is present, the default is that any 880 character set is acceptable. If an Accept-Charset header is present, 881 and if the server cannot send a response which is acceptable 882 according to the Accept-Charset header, then the server SHOULD send 883 an error response with the 406 (Not Acceptable) status code, though 884 the sending of an unacceptable response is also allowed. 886 5.3. Accept-Encoding 888 The "Accept-Encoding" request-header field can be used by user agents 889 to indicate what response content-codings (Section 2.2) are 890 acceptable in the response. 892 Accept-Encoding = "Accept-Encoding" ":" OWS 893 Accept-Encoding-v 894 Accept-Encoding-v = 895 #( codings [ OWS ";" OWS "q=" qvalue ] ) 896 codings = ( content-coding / "*" ) 898 Each codings value MAY be given an associated quality value which 899 represents the preference for that encoding. The default value is 900 q=1. 902 Examples of its use are: 904 Accept-Encoding: compress, gzip 905 Accept-Encoding: 906 Accept-Encoding: * 907 Accept-Encoding: compress;q=0.5, gzip;q=1.0 908 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 910 A server tests whether a content-coding is acceptable, according to 911 an Accept-Encoding field, using these rules: 913 1. If the content-coding is one of the content-codings listed in the 914 Accept-Encoding field, then it is acceptable, unless it is 915 accompanied by a qvalue of 0. (As defined in Section 6.4 of 916 [Part1], a qvalue of 0 means "not acceptable.") 918 2. The special "*" symbol in an Accept-Encoding field matches any 919 available content-coding not explicitly listed in the header 920 field. 922 3. If multiple content-codings are acceptable, then the acceptable 923 content-coding with the highest non-zero qvalue is preferred. 925 4. The "identity" content-coding is always acceptable, unless 926 specifically refused because the Accept-Encoding field includes 927 "identity;q=0", or because the field includes "*;q=0" and does 928 not explicitly include the "identity" content-coding. If the 929 Accept-Encoding field-value is empty, then only the "identity" 930 encoding is acceptable. 932 If an Accept-Encoding field is present in a request, and if the 933 server cannot send a response which is acceptable according to the 934 Accept-Encoding header, then the server SHOULD send an error response 935 with the 406 (Not Acceptable) status code. 937 If no Accept-Encoding field is present in a request, the server MAY 938 assume that the client will accept any content coding. In this case, 939 if "identity" is one of the available content-codings, then the 940 server SHOULD use the "identity" content-coding, unless it has 941 additional information that a different content-coding is meaningful 942 to the client. 944 Note: If the request does not include an Accept-Encoding field, 945 and if the "identity" content-coding is unavailable, then content- 946 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 947 "compress") are preferred; some older clients improperly display 948 messages sent with other content-codings. The server might also 949 make this decision based on information about the particular user- 950 agent or client. 952 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 953 associated with content-codings. This means that qvalues will not 954 work and are not permitted with x-gzip or x-compress. 956 5.4. Accept-Language 958 The "Accept-Language" request-header field can be used by user agents 959 to indicate the set of natural languages that are preferred in the 960 response. Language tags are defined in Section 2.4. 962 Accept-Language = "Accept-Language" ":" OWS 963 Accept-Language-v 964 Accept-Language-v = 965 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 966 language-range = 967 969 Each language-range can be given an associated quality value which 970 represents an estimate of the user's preference for the languages 971 specified by that range. The quality value defaults to "q=1". For 972 example, 974 Accept-Language: da, en-gb;q=0.8, en;q=0.7 976 would mean: "I prefer Danish, but will accept British English and 977 other types of English." (see also Section 2.3 of [RFC4647]) 979 For matching, Section 3 of [RFC4647] defines several matching 980 schemes. Implementations can offer the most appropriate matching 981 scheme for their requirements. 983 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 984 identical to the matching scheme that was previously defined in 985 Section 14.4 of [RFC2616]. 987 It might be contrary to the privacy expectations of the user to send 988 an Accept-Language header with the complete linguistic preferences of 989 the user in every request. For a discussion of this issue, see 990 Section 7.1. 992 As intelligibility is highly dependent on the individual user, it is 993 recommended that client applications make the choice of linguistic 994 preference available to the user. If the choice is not made 995 available, then the Accept-Language header field MUST NOT be given in 996 the request. 998 Note: When making the choice of linguistic preference available to 999 the user, we remind implementors of the fact that users are not 1000 familiar with the details of language matching as described above, 1001 and should provide appropriate guidance. As an example, users 1002 might assume that on selecting "en-gb", they will be served any 1003 kind of English document if British English is not available. A 1004 user agent might suggest in such a case to add "en" to get the 1005 best matching behavior. 1007 5.5. Content-Encoding 1009 The "Content-Encoding" entity-header field indicates what content- 1010 codings have been applied to the entity-body, and thus what decoding 1011 mechanisms must be applied in order to obtain the media-type 1012 referenced by the Content-Type header field. Content-Encoding is 1013 primarily used to allow a document to be compressed without losing 1014 the identity of its underlying media type. 1016 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 1017 Content-Encoding-v = 1#content-coding 1019 Content codings are defined in Section 2.2. An example of its use is 1021 Content-Encoding: gzip 1023 The content-coding is a characteristic of the entity identified by 1024 the Effective Request URI (Section 4.3 of [Part1]). Typically, the 1025 entity-body is stored with this encoding and is only decoded before 1026 rendering or analogous usage. However, a non-transparent proxy MAY 1027 modify the content-coding if the new coding is known to be acceptable 1028 to the recipient, unless the "no-transform" cache-control directive 1029 is present in the message. 1031 If the content-coding of an entity is not "identity", then the 1032 response MUST include a Content-Encoding entity-header (Section 5.5) 1033 that lists the non-identity content-coding(s) used. 1035 If the content-coding of an entity in a request message is not 1036 acceptable to the origin server, the server SHOULD respond with a 1037 status code of 415 (Unsupported Media Type). 1039 If multiple encodings have been applied to an entity, the content 1040 codings MUST be listed in the order in which they were applied. 1041 Additional information about the encoding parameters MAY be provided 1042 by other entity-header fields not defined by this specification. 1044 5.6. Content-Language 1046 The "Content-Language" entity-header field describes the natural 1047 language(s) of the intended audience for the entity. Note that this 1048 might not be equivalent to all the languages used within the entity- 1049 body. 1051 Content-Language = "Content-Language" ":" OWS Content-Language-v 1052 Content-Language-v = 1#language-tag 1054 Language tags are defined in Section 2.4. The primary purpose of 1055 Content-Language is to allow a user to identify and differentiate 1056 entities according to the user's own preferred language. Thus, if 1057 the body content is intended only for a Danish-literate audience, the 1058 appropriate field is 1060 Content-Language: da 1062 If no Content-Language is specified, the default is that the content 1063 is intended for all language audiences. This might mean that the 1064 sender does not consider it to be specific to any natural language, 1065 or that the sender does not know for which language it is intended. 1067 Multiple languages MAY be listed for content that is intended for 1068 multiple audiences. For example, a rendition of the "Treaty of 1069 Waitangi," presented simultaneously in the original Maori and English 1070 versions, would call for 1072 Content-Language: mi, en 1074 However, just because multiple languages are present within an entity 1075 does not mean that it is intended for multiple linguistic audiences. 1076 An example would be a beginner's language primer, such as "A First 1077 Lesson in Latin," which is clearly intended to be used by an English- 1078 literate audience. In this case, the Content-Language would properly 1079 only include "en". 1081 Content-Language MAY be applied to any media type -- it is not 1082 limited to textual documents. 1084 5.7. Content-Location 1086 The "Content-Location" entity-header field is used to supply a URI 1087 for the entity in the message when it is accessible from a location 1088 separate from the requested resource's URI. 1090 A server SHOULD provide a Content-Location for the variant 1091 corresponding to the response entity, especially in the case where a 1092 resource has multiple entities associated with it, and those entities 1093 actually have separate locations by which they might be individually 1094 accessed, the server SHOULD provide a Content-Location for the 1095 particular variant which is returned. 1097 Content-Location = "Content-Location" ":" OWS 1098 Content-Location-v 1099 Content-Location-v = 1100 absolute-URI / partial-URI 1102 The Content-Location value is not a replacement for the Effective 1103 Request URI (Section 4.3 of [Part1]); it is only a statement of the 1104 location of the resource corresponding to this particular entity at 1105 the time of the request. Future requests MAY may be addressed to the 1106 Content-Location URI if the desire is to identify the source of that 1107 particular entity. 1109 Section 6.1 of [Part2] describes how clients may process the Content- 1110 Location header field. 1112 A cache cannot assume that an entity with a Content-Location 1113 different from the URI used to retrieve it can be used to respond to 1114 later requests on that Content-Location URI. However, the Content- 1115 Location can be used to differentiate between multiple entities 1116 retrieved from a single requested resource, as described in Section 1117 2.7 of [Part6]. 1119 If the Content-Location is a relative URI, the relative URI is 1120 interpreted relative to the Effective Request URI. 1122 The meaning of the Content-Location header in requests is undefined; 1123 servers are free to ignore it in those cases. 1125 5.8. Content-MD5 1127 The "Content-MD5" entity-header field, as defined in [RFC1864], is an 1128 MD5 digest of the entity-body that provides an end-to-end message 1129 integrity check (MIC) of the entity-body. Note that a MIC is good 1130 for detecting accidental modification of the entity-body in transit, 1131 but is not proof against malicious attacks. 1133 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1134 Content-MD5-v = 1136 The Content-MD5 header field MAY be generated by an origin server or 1137 client to function as an integrity check of the entity-body. Only 1138 origin servers or clients MAY generate the Content-MD5 header field; 1139 proxies and gateways MUST NOT generate it, as this would defeat its 1140 value as an end-to-end integrity check. Any recipient of the entity- 1141 body, including gateways and proxies, MAY check that the digest value 1142 in this header field matches that of the entity-body as received. 1144 The MD5 digest is computed based on the content of the entity-body, 1145 including any content-coding that has been applied, but not including 1146 any transfer-encoding applied to the message-body. If the message is 1147 received with a transfer-encoding, that encoding MUST be removed 1148 prior to checking the Content-MD5 value against the received entity. 1150 This has the result that the digest is computed on the octets of the 1151 entity-body exactly as, and in the order that, they would be sent if 1152 no transfer-encoding were being applied. 1154 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1155 composite media-types (e.g., multipart/* and message/rfc822), but 1156 this does not change how the digest is computed as defined in the 1157 preceding paragraph. 1159 There are several consequences of this. The entity-body for 1160 composite types MAY contain many body-parts, each with its own MIME 1161 and HTTP headers (including Content-MD5, Content-Transfer-Encoding, 1162 and Content-Encoding headers). If a body-part has a Content- 1163 Transfer-Encoding or Content-Encoding header, it is assumed that the 1164 content of the body-part has had the encoding applied, and the body- 1165 part is included in the Content-MD5 digest as is -- i.e., after the 1166 application. The Transfer-Encoding header field is not allowed 1167 within body-parts. 1169 Conversion of all line breaks to CRLF MUST NOT be done before 1170 computing or checking the digest: the line break convention used in 1171 the text actually transmitted MUST be left unaltered when computing 1172 the digest. 1174 Note: While the definition of Content-MD5 is exactly the same for 1175 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1176 in which the application of Content-MD5 to HTTP entity-bodies 1177 differs from its application to MIME entity-bodies. One is that 1178 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1179 does use Transfer-Encoding and Content-Encoding. Another is that 1180 HTTP more frequently uses binary content types than MIME, so it is 1181 worth noting that, in such cases, the byte order used to compute 1182 the digest is the transmission byte order defined for the type. 1183 Lastly, HTTP allows transmission of text types with any of several 1184 line break conventions and not just the canonical form using CRLF. 1186 5.9. Content-Type 1188 The "Content-Type" entity-header field indicates the media type of 1189 the entity-body. In the case of responses to the HEAD method, the 1190 media type is that which would have been sent had the request been a 1191 GET. 1193 Content-Type = "Content-Type" ":" OWS Content-Type-v 1194 Content-Type-v = media-type 1196 Media types are defined in Section 2.3. An example of the field is 1198 Content-Type: text/html; charset=ISO-8859-4 1200 Further discussion of methods for identifying the media type of an 1201 entity is provided in Section 3.2.1. 1203 6. IANA Considerations 1205 6.1. Message Header Registration 1207 The Message Header Registry located at should be 1209 updated with the permanent registrations below (see [RFC3864]): 1211 +---------------------+----------+----------+--------------+ 1212 | Header Field Name | Protocol | Status | Reference | 1213 +---------------------+----------+----------+--------------+ 1214 | Accept | http | standard | Section 5.1 | 1215 | Accept-Charset | http | standard | Section 5.2 | 1216 | Accept-Encoding | http | standard | Section 5.3 | 1217 | Accept-Language | http | standard | Section 5.4 | 1218 | Content-Disposition | http | | Appendix B.1 | 1219 | Content-Encoding | http | standard | Section 5.5 | 1220 | Content-Language | http | standard | Section 5.6 | 1221 | Content-Location | http | standard | Section 5.7 | 1222 | Content-MD5 | http | standard | Section 5.8 | 1223 | Content-Type | http | standard | Section 5.9 | 1224 | MIME-Version | http | | Appendix A.1 | 1225 +---------------------+----------+----------+--------------+ 1227 The change controller is: "IETF (iesg@ietf.org) - Internet 1228 Engineering Task Force". 1230 6.2. Content Coding Registry 1232 The registration procedure for HTTP Content Codings is now defined by 1233 Section 2.2.1 of this document. 1235 The HTTP Content Codings Registry located at 1236 should be updated 1237 with the registration below: 1239 +----------+-----------------------------------------+--------------+ 1240 | Name | Description | Reference | 1241 +----------+-----------------------------------------+--------------+ 1242 | compress | UNIX "compress" program method | Section | 1243 | | | 6.2.2.1 of | 1244 | | | [Part1] | 1245 | deflate | "deflate" compression mechanism | Section | 1246 | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | 1247 | | format ([RFC1950]) | [Part1] | 1248 | gzip | Same as GNU zip [RFC1952] | Section | 1249 | | | 6.2.2.3 of | 1250 | | | [Part1] | 1251 | identity | No transformation | Section 2.2 | 1252 +----------+-----------------------------------------+--------------+ 1254 7. Security Considerations 1256 This section is meant to inform application developers, information 1257 providers, and users of the security limitations in HTTP/1.1 as 1258 described by this document. The discussion does not include 1259 definitive solutions to the problems revealed, though it does make 1260 some suggestions for reducing security risks. 1262 7.1. Privacy Issues Connected to Accept Headers 1264 Accept request-headers can reveal information about the user to all 1265 servers which are accessed. The Accept-Language header in particular 1266 can reveal information the user would consider to be of a private 1267 nature, because the understanding of particular languages is often 1268 strongly correlated to the membership of a particular ethnic group. 1269 User agents which offer the option to configure the contents of an 1270 Accept-Language header to be sent in every request are strongly 1271 encouraged to let the configuration process include a message which 1272 makes the user aware of the loss of privacy involved. 1274 An approach that limits the loss of privacy would be for a user agent 1275 to omit the sending of Accept-Language headers by default, and to ask 1276 the user whether or not to start sending Accept-Language headers to a 1277 server if it detects, by looking for any Vary response-header fields 1278 generated by the server, that such sending could improve the quality 1279 of service. 1281 Elaborate user-customized accept header fields sent in every request, 1282 in particular if these include quality values, can be used by servers 1283 as relatively reliable and long-lived user identifiers. Such user 1284 identifiers would allow content providers to do click-trail tracking, 1285 and would allow collaborating content providers to match cross-server 1286 click-trails or form submissions of individual users. Note that for 1287 many users not behind a proxy, the network address of the host 1288 running the user agent will also serve as a long-lived user 1289 identifier. In environments where proxies are used to enhance 1290 privacy, user agents ought to be conservative in offering accept 1291 header configuration options to end users. As an extreme privacy 1292 measure, proxies could filter the accept headers in relayed requests. 1293 General purpose user agents which provide a high degree of header 1294 configurability SHOULD warn users about the loss of privacy which can 1295 be involved. 1297 7.2. Content-Disposition Issues 1299 [RFC2183], from which the often implemented Content-Disposition (see 1300 Appendix B.1) header in HTTP is derived, has a number of very serious 1301 security considerations. Content-Disposition is not part of the HTTP 1302 standard, but since it is widely implemented, we are documenting its 1303 use and risks for implementors. See Section 5 of [RFC2183] for 1304 details. 1306 8. Acknowledgments 1308 9. References 1310 9.1. Normative References 1312 [ISO-8859-1] International Organization for Standardization, 1313 "Information technology -- 8-bit single-byte coded 1314 graphic character sets -- Part 1: Latin alphabet No. 1315 1", ISO/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., 1319 Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, 1320 Connections, and Message Parsing", 1321 draft-ietf-httpbis-p1-messaging-10 (work in progress), 1322 July 2010. 1324 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1325 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1326 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1327 Semantics", draft-ietf-httpbis-p2-semantics-10 (work in 1328 progress), July 2010. 1330 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1331 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1332 Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: 1333 Conditional Requests", 1334 draft-ietf-httpbis-p4-conditional-10 (work in 1335 progress), July 2010. 1337 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1338 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1339 Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range 1340 Requests and Partial Responses", 1341 draft-ietf-httpbis-p5-range-10 (work in progress), 1342 July 2010. 1344 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1345 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1346 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 1347 "HTTP/1.1, part 6: Caching", 1348 draft-ietf-httpbis-p6-cache-10 (work in progress), 1349 July 2010. 1351 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1352 RFC 1864, October 1995. 1354 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 1355 Format Specification version 3.3", RFC 1950, May 1996. 1357 RFC 1950 is an Informational RFC, thus it may be less 1358 stable than this specification. On the other hand, 1359 this downward reference was present since the 1360 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1361 it is unlikely to cause problems in practice. See also 1362 [BCP97]. 1364 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 1365 Specification version 1.3", RFC 1951, May 1996. 1367 RFC 1951 is an Informational RFC, thus it may be less 1368 stable than this specification. On the other hand, 1369 this downward reference was present since the 1370 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1371 it is unlikely to cause problems in practice. See also 1372 [BCP97]. 1374 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 1375 G. Randers-Pehrson, "GZIP file format specification 1376 version 4.3", RFC 1952, May 1996. 1378 RFC 1952 is an Informational RFC, thus it may be less 1379 stable than this specification. On the other hand, 1380 this downward reference was present since the 1381 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1382 it is unlikely to cause problems in practice. See also 1383 [BCP97]. 1385 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 1386 Mail Extensions (MIME) Part One: Format of Internet 1387 Message Bodies", RFC 2045, November 1996. 1389 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 1390 Mail Extensions (MIME) Part Two: Media Types", 1391 RFC 2046, November 1996. 1393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1394 Requirement Levels", BCP 14, RFC 2119, March 1997. 1396 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of 1397 Language Tags", BCP 47, RFC 4647, September 2006. 1399 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1400 Syntax Specifications: ABNF", STD 68, RFC 5234, 1401 January 2008. 1403 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 1404 Identifying Languages", BCP 47, RFC 5646, 1405 September 2009. 1407 9.2. Informative References 1409 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 1410 References to Standards-Track Documents", BCP 97, 1411 RFC 4897, June 2007. 1413 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 1414 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 1415 May 1996. 1417 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet 1418 Mail Extensions (MIME) Part Five: Conformance Criteria 1419 and Examples", RFC 2049, November 1996. 1421 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 1422 T. Berners-Lee, "Hypertext Transfer Protocol -- 1423 HTTP/1.1", RFC 2068, January 1997. 1425 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1426 February 1997. 1428 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1429 Presentation Information in Internet Messages: The 1430 Content-Disposition Header Field", RFC 2183, 1431 August 1997. 1433 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1434 Languages", BCP 18, RFC 2277, January 1998. 1436 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content 1437 Negotiation in HTTP", RFC 2295, March 1998. 1439 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1440 form-data", RFC 2388, August 1998. 1442 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1443 "MIME Encapsulation of Aggregate Documents, such as 1444 HTML (MHTML)", RFC 2557, March 1999. 1446 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1447 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1448 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1450 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1451 10646", RFC 3629, STD 63, November 2003. 1453 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1454 Procedures for Message Header Fields", BCP 90, 1455 RFC 3864, September 2004. 1457 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 1458 and Registration Procedures", BCP 13, RFC 4288, 1459 December 2005. 1461 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 1462 an IANA Considerations Section in RFCs", BCP 26, 1463 RFC 5226, May 2008. 1465 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1466 October 2008. 1468 Appendix A. Differences Between HTTP Entities and RFC 2045 Entities 1470 HTTP/1.1 uses many of the constructs defined for Internet Mail 1471 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1472 [RFC2045]) to allow entities to be transmitted in an open variety of 1473 representations and with extensible mechanisms. However, RFC 2045 1474 discusses mail, and HTTP has a few features that are different from 1475 those described in RFC 2045. These differences were carefully chosen 1476 to optimize performance over binary connections, to allow greater 1477 freedom in the use of new media types, to make date comparisons 1478 easier, and to acknowledge the practice of some early HTTP servers 1479 and clients. 1481 This appendix describes specific areas where HTTP differs from RFC 1482 2045. Proxies and gateways to strict MIME environments SHOULD be 1483 aware of these differences and provide the appropriate conversions 1484 where necessary. Proxies and gateways from MIME environments to HTTP 1485 also need to be aware of the differences because some conversions 1486 might be required. 1488 A.1. MIME-Version 1490 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1491 MAY include a single MIME-Version general-header field to indicate 1492 what version of the MIME protocol was used to construct the message. 1493 Use of the MIME-Version header field indicates that the message is in 1494 full compliance with the MIME protocol (as defined in [RFC2045]). 1495 Proxies/gateways are responsible for ensuring full compliance (where 1496 possible) when exporting HTTP messages to strict MIME environments. 1498 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1499 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1501 MIME version "1.0" is the default for use in HTTP/1.1. However, 1502 HTTP/1.1 message parsing and semantics are defined by this document 1503 and not the MIME specification. 1505 A.2. Conversion to Canonical Form 1507 [RFC2045] requires that an Internet mail entity be converted to 1508 canonical form prior to being transferred, as described in Section 4 1509 of [RFC2049]. Section 2.3.1 of this document describes the forms 1510 allowed for subtypes of the "text" media type when transmitted over 1511 HTTP. [RFC2046] requires that content with a type of "text" 1512 represent line breaks as CRLF and forbids the use of CR or LF outside 1513 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1514 indicate a line break within text content when a message is 1515 transmitted over HTTP. 1517 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1518 environment SHOULD translate all line breaks within the text media 1519 types described in Section 2.3.1 of this document to the RFC 2049 1520 canonical form of CRLF. Note, however, that this might be 1521 complicated by the presence of a Content-Encoding and by the fact 1522 that HTTP allows the use of some character sets which do not use 1523 octets 13 and 10 to represent CR and LF, as is the case for some 1524 multi-byte character sets. 1526 Implementors should note that conversion will break any cryptographic 1527 checksums applied to the original content unless the original content 1528 is already in canonical form. Therefore, the canonical form is 1529 recommended for any content that uses such checksums in HTTP. 1531 A.3. Conversion of Date Formats 1533 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1534 [Part1]) to simplify the process of date comparison. Proxies and 1535 gateways from other protocols SHOULD ensure that any Date header 1536 field present in a message conforms to one of the HTTP/1.1 formats 1537 and rewrite the date if necessary. 1539 A.4. Introduction of Content-Encoding 1541 RFC 2045 does not include any concept equivalent to HTTP/1.1's 1542 Content-Encoding header field. Since this acts as a modifier on the 1543 media type, proxies and gateways from HTTP to MIME-compliant 1544 protocols MUST either change the value of the Content-Type header 1545 field or decode the entity-body before forwarding the message. (Some 1546 experimental applications of Content-Type for Internet mail have used 1547 a media-type parameter of ";conversions=" to perform 1548 a function equivalent to Content-Encoding. However, this parameter 1549 is not part of RFC 2045). 1551 A.5. No Content-Transfer-Encoding 1553 HTTP does not use the Content-Transfer-Encoding field of RFC 2045. 1554 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1555 remove any Content-Transfer-Encoding prior to delivering the response 1556 message to an HTTP client. 1558 Proxies and gateways from HTTP to MIME-compliant protocols are 1559 responsible for ensuring that the message is in the correct format 1560 and encoding for safe transport on that protocol, where "safe 1561 transport" is defined by the limitations of the protocol being used. 1562 Such a proxy or gateway SHOULD label the data with an appropriate 1563 Content-Transfer-Encoding if doing so will improve the likelihood of 1564 safe transport over the destination protocol. 1566 A.6. Introduction of Transfer-Encoding 1568 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1569 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1570 to forwarding a message via a MIME-compliant protocol. 1572 A.7. MHTML and Line Length Limitations 1574 HTTP implementations which share code with MHTML [RFC2557] 1575 implementations need to be aware of MIME line length limitations. 1576 Since HTTP does not have this limitation, HTTP does not fold long 1577 lines. MHTML messages being transported by HTTP follow all 1578 conventions of MHTML, including line length limitations and folding, 1579 canonicalization, etc., since HTTP transports all message-bodies as 1580 payload (see Section 2.3.2) and does not interpret the content or any 1581 MIME header lines that might be contained therein. 1583 Appendix B. Additional Features 1585 [RFC1945] and [RFC2068] document protocol elements used by some 1586 existing HTTP implementations, but not consistently and correctly 1587 across most HTTP/1.1 applications. Implementors are advised to be 1588 aware of these features, but cannot rely upon their presence in, or 1589 interoperability with, other HTTP/1.1 applications. Some of these 1590 describe proposed experimental features, and some describe features 1591 that experimental deployment found lacking that are now addressed in 1592 the base HTTP/1.1 specification. 1594 A number of other headers, such as Content-Disposition and Title, 1595 from SMTP and MIME are also often implemented (see [RFC2076]). 1597 B.1. Content-Disposition 1599 The "Content-Disposition" response-header field has been proposed as 1600 a means for the origin server to suggest a default filename if the 1601 user requests that the content is saved to a file. This usage is 1602 derived from the definition of Content-Disposition in [RFC2183]. 1604 content-disposition = "Content-Disposition" ":" OWS 1605 content-disposition-v 1606 content-disposition-v = disposition-type 1607 *( OWS ";" OWS disposition-parm ) 1608 disposition-type = "attachment" / disp-extension-token 1609 disposition-parm = filename-parm / disp-extension-parm 1610 filename-parm = "filename" "=" quoted-string 1611 disp-extension-token = token 1612 disp-extension-parm = token "=" word 1614 An example is 1616 Content-Disposition: attachment; filename="fname.ext" 1618 The receiving user agent SHOULD NOT respect any directory path 1619 information present in the filename-parm parameter, which is the only 1620 parameter believed to apply to HTTP implementations at this time. 1621 The filename SHOULD be treated as a terminal component only. 1623 If this header is used in a response with the application/ 1624 octet-stream content-type, the implied suggestion is that the user 1625 agent should not display the response, but directly enter a "save 1626 response as..." dialog. 1628 See Section 7.2 for Content-Disposition security issues. 1630 Appendix C. Compatibility with Previous Versions 1632 C.1. Changes from RFC 2068 1634 Transfer-coding and message lengths all interact in ways that 1635 required fixing exactly when chunked encoding is used (to allow for 1636 transfer encoding that may not be self delimiting); it was important 1637 to straighten out exactly how message lengths are computed. 1638 (Section 3.2.2, see also [Part1], [Part5] and [Part6]). 1640 Charset wildcarding is introduced to avoid explosion of character set 1641 names in accept headers. (Section 5.2) 1642 Content-Base was deleted from the specification: it was not 1643 implemented widely, and there is no simple, safe way to introduce it 1644 without a robust extension mechanism. In addition, it is used in a 1645 similar, but not identical fashion in MHTML [RFC2557]. 1647 A content-coding of "identity" was introduced, to solve problems 1648 discovered in caching. (Section 2.2) 1650 The Alternates, Content-Version, Derived-From, Link, URI, Public and 1651 Content-Base header fields were defined in previous versions of this 1652 specification, but not commonly implemented. See Section 19.6.2 of 1653 [RFC2068]. 1655 C.2. Changes from RFC 2616 1657 Clarify contexts that charset is used in. (Section 2.1) 1659 Remove base URI setting semantics for Content-Location due to poor 1660 implementation support, which was caused by too many broken servers 1661 emitting bogus Content-Location headers, and also the potentially 1662 undesirable effect of potentially breaking relative links in content- 1663 negotiated resources. (Section 5.7) 1665 Remove reference to non-existant identity transfer-coding value 1666 tokens. (Appendix A.5) 1668 Appendix D. Collected ABNF 1670 Accept = "Accept:" OWS Accept-v 1671 Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v 1672 Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1673 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1674 qvalue ] ] ) 1675 Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v 1676 Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) 1677 ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1678 Accept-Language = "Accept-Language:" OWS Accept-Language-v 1679 Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1680 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1681 ] ) 1682 Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1683 OWS media-range [ accept-params ] ] ) ] 1685 Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v 1686 Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS 1687 content-coding ] ) 1688 Content-Language = "Content-Language:" OWS Content-Language-v 1689 Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS 1690 language-tag ] ) 1691 Content-Length = 1692 Content-Location = "Content-Location:" OWS Content-Location-v 1693 Content-Location-v = absolute-URI / partial-URI 1694 Content-MD5 = "Content-MD5:" OWS Content-MD5-v 1695 Content-MD5-v = 1696 Content-Range = 1697 Content-Type = "Content-Type:" OWS Content-Type-v 1698 Content-Type-v = media-type 1700 Expires = 1702 Last-Modified = 1704 MIME-Version = "MIME-Version:" OWS MIME-Version-v 1705 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1707 OWS = 1709 absolute-URI = 1710 accept-ext = OWS ";" OWS token [ "=" word ] 1711 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1712 attribute = token 1714 charset = token 1715 codings = ( content-coding / "*" ) 1716 content-coding = token 1717 content-disposition = "Content-Disposition:" OWS 1718 content-disposition-v 1719 content-disposition-v = disposition-type *( OWS ";" OWS 1720 disposition-parm ) 1722 disp-extension-parm = token "=" word 1723 disp-extension-token = token 1724 disposition-parm = filename-parm / disp-extension-parm 1725 disposition-type = "attachment" / disp-extension-token 1727 entity-body = *OCTET 1728 entity-header = Content-Encoding / Content-Language / Content-Length 1729 / Content-Location / Content-MD5 / Content-Range / Content-Type / 1730 Expires / Last-Modified / extension-header 1731 extension-header = header-field 1733 filename-parm = "filename=" quoted-string 1735 header-field = 1736 language-range = 1737 language-tag = 1739 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1740 ";" OWS parameter ) 1741 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1743 parameter = attribute "=" value 1744 partial-URI = 1746 quoted-string = 1747 qvalue = 1749 subtype = token 1751 token = 1752 type = token 1754 value = word 1756 word = 1758 ABNF diagnostics: 1760 ; Accept defined but not used 1761 ; Accept-Charset defined but not used 1762 ; Accept-Encoding defined but not used 1763 ; Accept-Language defined but not used 1764 ; MIME-Version defined but not used 1765 ; content-disposition defined but not used 1766 ; entity-body defined but not used 1767 ; entity-header defined but not used 1769 Appendix E. Change Log (to be removed by RFC Editor before publication) 1771 E.1. Since RFC2616 1773 Extracted relevant partitions from [RFC2616]. 1775 E.2. Since draft-ietf-httpbis-p3-payload-00 1777 Closed issues: 1779 o : "Media Type 1780 Registrations" () 1782 o : "Clarification 1783 regarding quoting of charset values" 1784 () 1786 o : "Remove 1787 'identity' token references" 1788 () 1790 o : "Accept- 1791 Encoding BNF" 1793 o : "Normative and 1794 Informative references" 1796 o : "RFC1700 1797 references" 1799 o : "Updating to 1800 RFC4288" 1802 o : "Informative 1803 references" 1805 o : "ISO-8859-1 1806 Reference" 1808 o : "Encoding 1809 References Normative" 1811 o : "Normative up- 1812 to-date references" 1814 E.3. Since draft-ietf-httpbis-p3-payload-01 1816 Ongoing work on ABNF conversion 1817 (): 1819 o Add explicit references to BNF syntax and rules imported from 1820 other parts of the specification. 1822 E.4. Since draft-ietf-httpbis-p3-payload-02 1824 Closed issues: 1826 o : "Quoting 1827 Charsets" 1829 o : 1830 "Classification for Allow header" 1832 o : "missing 1833 default for qvalue in description of Accept-Encoding" 1835 Ongoing work on IANA Message Header Registration 1836 (): 1838 o Reference RFC 3984, and update header registrations for headers 1839 defined in this document. 1841 E.5. Since draft-ietf-httpbis-p3-payload-03 1843 Closed issues: 1845 o : "Quoting 1846 Charsets" 1848 o : "language tag 1849 matching (Accept-Language) vs RFC4647" 1851 o : "RFC 1806 has 1852 been replaced by RFC2183" 1854 Other changes: 1856 o : "Encoding 1857 References Normative" -- rephrase the annotation and reference 1858 [BCP97]. 1860 E.6. Since draft-ietf-httpbis-p3-payload-04 1862 Closed issues: 1864 o : "RFC 2822 is 1865 updated by RFC 5322" 1867 Ongoing work on ABNF conversion 1868 (): 1870 o Use "/" instead of "|" for alternatives. 1872 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1873 whitespace ("OWS") and required whitespace ("RWS"). 1875 o Rewrite ABNFs to spell out whitespace rules, factor out header 1876 value format definitions. 1878 E.7. Since draft-ietf-httpbis-p3-payload-05 1880 Closed issues: 1882 o : "Join 1883 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1885 Final work on ABNF conversion 1886 (): 1888 o Add appendix containing collected and expanded ABNF, reorganize 1889 ABNF introduction. 1891 Other changes: 1893 o Move definition of quality values into Part 1. 1895 E.8. Since draft-ietf-httpbis-p3-payload-06 1897 Closed issues: 1899 o : "Content- 1900 Location isn't special" 1902 o : "Content 1903 Sniffing" 1905 E.9. Since draft-ietf-httpbis-p3-payload-07 1907 Closed issues: 1909 o : "Updated 1910 reference for language tags" 1912 o : "Clarify rules 1913 for determining what entities a response carries" 1915 o : "Content- 1916 Location base-setting problems" 1918 o : "Content 1919 Sniffing" 1921 o : "pick IANA 1922 policy (RFC5226) for Transfer Coding / Content Coding" 1924 o : "move 1925 definitions of gzip/deflate/compress to part 1" 1927 Partly resolved issues: 1929 o : "update IANA 1930 requirements wrt Transfer-Coding values" (add the IANA 1931 Considerations subsection) 1933 o : "update IANA 1934 requirements wrt Content-Coding values" (add the IANA 1935 Considerations subsection) 1937 E.10. Since draft-ietf-httpbis-p3-payload-08 1939 Closed issues: 1941 o : "Content 1942 Negotiation for media types" 1944 o : "Accept- 1945 Language: which RFC4647 filtering?" 1947 E.11. Since draft-ietf-httpbis-p3-payload-09 1949 Closed issues: 1951 o : "IANA registry 1952 for content/transfer encodings" 1954 o : "Content 1955 Sniffing" 1957 o : "use of term 1958 "word" when talking about header structure" 1960 Partly resolved issues: 1962 o : "Term for the 1963 requested resource's URI" 1965 Index 1967 A 1968 Accept header 17 1969 Accept-Charset header 19 1970 Accept-Encoding header 20 1971 Accept-Language header 21 1972 Alternates header 36 1974 C 1975 Coding Format 1976 compress 8 1977 deflate 8 1978 gzip 9 1979 identity 9 1980 compress (Coding Format) 8 1981 content negotiation 5 1982 Content-Base header 36 1983 Content-Disposition header 35 1984 Content-Encoding header 22 1985 Content-Language header 23 1986 Content-Location header 24 1987 Content-MD5 header 25 1988 Content-Type header 26 1989 Content-Version header 36 1991 D 1992 deflate (Coding Format) 8 1993 Derived-From header 36 1995 E 1996 entity 5 1998 G 1999 Grammar 2000 Accept 17 2001 Accept-Charset 19 2002 Accept-Charset-v 19 2003 Accept-Encoding 20 2004 Accept-Encoding-v 20 2005 accept-ext 17 2006 Accept-Language 21 2007 Accept-Language-v 21 2008 accept-params 17 2009 Accept-v 17 2010 attribute 10 2011 charset 7 2012 codings 20 2013 content-coding 8 2014 content-disposition 35 2015 content-disposition-v 35 2016 Content-Encoding 22 2017 Content-Encoding-v 22 2018 Content-Language 23 2019 Content-Language-v 23 2020 Content-Location 24 2021 Content-Location-v 24 2022 Content-MD5 25 2023 Content-MD5-v 25 2024 Content-Type 26 2025 Content-Type-v 26 2026 disp-extension-parm 35 2027 disp-extension-token 35 2028 disposition-parm 35 2029 disposition-type 35 2030 entity-body 13 2031 entity-header 13 2032 extension-header 13 2033 filename-parm 35 2034 language-range 21 2035 language-tag 12 2036 media-range 17 2037 media-type 9 2038 MIME-Version 32 2039 MIME-Version-v 32 2040 parameter 10 2041 subtype 9 2042 type 9 2043 value 10 2044 gzip (Coding Format) 9 2046 H 2047 Headers 2048 Accept 17 2049 Accept-Charset 19 2050 Accept-Encoding 20 2051 Accept-Language 21 2052 Alternate 36 2053 Content-Base 36 2054 Content-Disposition 35 2055 Content-Encoding 22 2056 Content-Language 23 2057 Content-Location 24 2058 Content-MD5 25 2059 Content-Type 26 2060 Content-Version 36 2061 Derived-From 36 2062 Link 36 2063 MIME-Version 32 2064 Public 36 2065 URI 36 2067 I 2068 identity (Coding Format) 9 2070 L 2071 Link header 36 2073 M 2074 MIME-Version header 32 2076 P 2077 Public header 36 2079 R 2080 representation 5 2082 U 2083 URI header 36 2085 V 2086 variant 5 2088 Authors' Addresses 2090 Roy T. Fielding (editor) 2091 Day Software 2092 23 Corporate Plaza DR, Suite 280 2093 Newport Beach, CA 92660 2094 USA 2096 Phone: +1-949-706-5300 2097 Fax: +1-949-706-5305 2098 EMail: fielding@gbiv.com 2099 URI: http://roy.gbiv.com/ 2101 Jim Gettys 2102 Alcatel-Lucent Bell Labs 2103 21 Oak Knoll Road 2104 Carlisle, MA 01741 2105 USA 2107 EMail: jg@freedesktop.org 2108 URI: http://gettys.wordpress.com/ 2109 Jeffrey C. Mogul 2110 Hewlett-Packard Company 2111 HP Labs, Large Scale Systems Group 2112 1501 Page Mill Road, MS 1177 2113 Palo Alto, CA 94304 2114 USA 2116 EMail: JeffMogul@acm.org 2118 Henrik Frystyk Nielsen 2119 Microsoft Corporation 2120 1 Microsoft Way 2121 Redmond, WA 98052 2122 USA 2124 EMail: henrikn@microsoft.com 2126 Larry Masinter 2127 Adobe Systems, Incorporated 2128 345 Park Ave 2129 San Jose, CA 95110 2130 USA 2132 EMail: LMM@acm.org 2133 URI: http://larry.masinter.net/ 2135 Paul J. Leach 2136 Microsoft Corporation 2137 1 Microsoft Way 2138 Redmond, WA 98052 2140 EMail: paulle@microsoft.com 2142 Tim Berners-Lee 2143 World Wide Web Consortium 2144 MIT Computer Science and Artificial Intelligence Laboratory 2145 The Stata Center, Building 32 2146 32 Vassar Street 2147 Cambridge, MA 02139 2148 USA 2150 EMail: timbl@w3.org 2151 URI: http://www.w3.org/People/Berners-Lee/ 2152 Yves Lafon (editor) 2153 World Wide Web Consortium 2154 W3C / ERCIM 2155 2004, rte des Lucioles 2156 Sophia-Antipolis, AM 06902 2157 France 2159 EMail: ylafon@w3.org 2160 URI: http://www.raubacapeu.net/people/yves/ 2162 Julian F. Reschke (editor) 2163 greenbytes GmbH 2164 Hafenweg 16 2165 Muenster, NW 48155 2166 Germany 2168 Phone: +49 251 2807760 2169 Fax: +49 251 2807761 2170 EMail: julian.reschke@greenbytes.de 2171 URI: http://greenbytes.de/tech/webdav/