idnits 2.17.1 draft-ietf-httpbis-p3-payload-11.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 (August 4, 2010) is 5015 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-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-11 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-11 ** 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: February 5, 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 August 4, 2010 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-11 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.12. 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 February 5, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 6 100 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 101 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 11 108 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 109 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 12 110 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 111 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 112 4.1. Representation Header Fields . . . . . . . . . . . . . . . 13 113 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 114 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 115 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 116 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 117 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 118 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 119 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 120 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 121 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 122 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 123 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 124 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 125 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 126 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 127 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 128 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 129 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 130 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 131 8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 132 8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29 133 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 134 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 135 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 136 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 137 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 138 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33 139 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 140 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 34 141 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 142 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 143 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 144 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 35 145 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35 146 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 148 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 149 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 150 Appendix E. Change Log (to be removed by RFC Editor before 151 publication) . . . . . . . . . . . . . . . . . . . . 38 152 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 153 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 154 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 155 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 156 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40 157 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 158 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 159 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41 160 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 161 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 162 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 163 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 42 164 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 166 1. Introduction 168 This document defines HTTP/1.1 message payloads (a.k.a., content), 169 the associated metadata header fields that define how the payload is 170 intended to be interpreted by a recipient, the request header fields 171 that might influence content selection, and the various selection 172 algorithms that are collectively referred to as HTTP content 173 negotiation. 175 This document is currently disorganized in order to minimize the 176 changes between drafts and enable reviewers to see the smaller errata 177 changes. The next draft will reorganize the sections to better 178 reflect the content. In particular, the sections on entities will be 179 renamed payload and moved to the first half of the document, while 180 the sections on content negotiation and associated request header 181 fields will be moved to the second half. The current mess reflects 182 how widely dispersed these topics and associated requirements had 183 become in [RFC2616]. 185 1.1. Terminology 187 This specification uses a number of terms to refer to the roles 188 played by participants in, and objects of, the HTTP communication. 190 content negotiation 192 The mechanism for selecting the appropriate representation when 193 servicing a request. The representation in any response can be 194 negotiated (including error responses). 196 1.2. Requirements 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 An implementation is not compliant if it fails to satisfy one or more 203 of the "MUST" or "REQUIRED" level requirements for the protocols it 204 implements. An implementation that satisfies all the "MUST" or 205 "REQUIRED" level and all the "SHOULD" level requirements for its 206 protocols is said to be "unconditionally compliant"; one that 207 satisfies all the "MUST" level requirements but not all the "SHOULD" 208 level requirements for its protocols is said to be "conditionally 209 compliant". 211 1.3. Syntax Notation 213 This specification uses the ABNF syntax defined in Section 1.2 of 214 [Part1] (which extends the syntax defined in [RFC5234] with a list 215 rule). Appendix D shows the collected ABNF, with the list rule 216 expanded. 218 The following core rules are included by reference, as defined in 219 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 220 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 221 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 222 sequence of data), SP (space), VCHAR (any visible USASCII character), 223 and WSP (whitespace). 225 1.3.1. Core Rules 227 The core rules below are defined in Section 1.2.2 of [Part1]: 229 quoted-string = 230 token = 231 word = 232 OWS = 234 1.3.2. ABNF Rules defined in other Parts of the Specification 236 The ABNF rules below are defined in other parts: 238 absolute-URI = 239 Content-Length = 240 header-field = 241 partial-URI = 242 qvalue = 244 Last-Modified = 246 Content-Range = 248 Expires = 250 2. Protocol Parameters 252 2.1. Character Sets 254 HTTP uses the same definition of the term "character set" as that 255 described for MIME: 257 The term "character set" is used in this document to refer to a 258 method used with one or more tables to convert a sequence of octets 259 into a sequence of characters. Note that unconditional conversion in 260 the other direction is not required, in that not all characters might 261 be available in a given character set and a character set might 262 provide more than one sequence of octets to represent a particular 263 character. This definition is intended to allow various kinds of 264 character encoding, from simple single-table mappings such as US- 265 ASCII to complex table switching methods such as those that use ISO- 266 2022's techniques. However, the definition associated with a MIME 267 character set name MUST fully specify the mapping to be performed 268 from octets to characters. In particular, use of external profiling 269 information to determine the exact mapping is not permitted. 271 Note: This use of the term "character set" is more commonly 272 referred to as a "character encoding". However, since HTTP and 273 MIME share the same registry, it is important that the terminology 274 also be shared. 276 HTTP character sets are identified by case-insensitive tokens. The 277 complete set of tokens is defined by the IANA Character Set registry 278 (). 280 charset = token 282 Although HTTP allows an arbitrary token to be used as a charset 283 value, any token that has a predefined value within the IANA 284 Character Set registry MUST represent the character set defined by 285 that registry. Applications SHOULD limit their use of character sets 286 to those defined by the IANA registry. 288 HTTP uses charset in two contexts: within an Accept-Charset request 289 header (in which the charset value is an unquoted token) and as the 290 value of a parameter in a Content-Type header (within a request or 291 response), in which case the parameter value of the charset parameter 292 can be quoted. 294 Implementors need to be aware of IETF character set requirements 295 [RFC3629] [RFC2277]. 297 2.1.1. Missing Charset 299 Some HTTP/1.0 software has interpreted a Content-Type header without 300 charset parameter incorrectly to mean "recipient should guess". 301 Senders wishing to defeat this behavior MAY include a charset 302 parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and 303 SHOULD do so when it is known that it will not confuse the recipient. 305 Unfortunately, some older HTTP/1.0 clients did not deal properly with 306 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 307 charset label provided by the sender; and those user agents that have 308 a provision to "guess" a charset MUST use the charset from the 309 content-type field if they support that charset, rather than the 310 recipient's preference, when initially displaying a document. See 311 Section 2.3.1. 313 2.2. Content Codings 315 Content coding values indicate an encoding transformation that has 316 been or can be applied to a representation. Content codings are 317 primarily used to allow a representation to be compressed or 318 otherwise usefully transformed without losing the identity of its 319 underlying media type and without loss of information. Frequently, 320 the representation is stored in coded form, transmitted directly, and 321 only decoded by the recipient. 323 content-coding = token 325 All content-coding values are case-insensitive. HTTP/1.1 uses 326 content-coding values in the Accept-Encoding (Section 6.3) and 327 Content-Encoding (Section 6.5) header fields. Although the value 328 describes the content-coding, what is more important is that it 329 indicates what decoding mechanism will be required to remove the 330 encoding. 332 compress 334 See Section 6.2.2.1 of [Part1]. 336 deflate 338 See Section 6.2.2.2 of [Part1]. 340 gzip 342 See Section 6.2.2.3 of [Part1]. 344 identity 346 The default (identity) encoding; the use of no transformation 347 whatsoever. This content-coding is used only in the Accept- 348 Encoding header, and SHOULD NOT be used in the Content-Encoding 349 header. 351 2.2.1. Content Coding Registry 353 The HTTP Content Coding Registry defines the name space for the 354 content coding names. 356 Registrations MUST include the following fields: 358 o Name 360 o Description 362 o Pointer to specification text 364 Names of content codings MUST NOT overlap with names of transfer 365 codings (Section 6.2 of [Part1]), unless the encoding transformation 366 is identical (as it is the case for the compression codings defined 367 in Section 6.2.2 of [Part1]). 369 Values to be added to this name space require a specification (see 370 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 371 conform to the purpose of content coding defined in this section. 373 The registry itself is maintained at 374 . 376 2.3. Media Types 378 HTTP uses Internet Media Types [RFC2046] in the Content-Type 379 (Section 6.9) and Accept (Section 6.1) header fields in order to 380 provide open and extensible data typing and type negotiation. 382 media-type = type "/" subtype *( OWS ";" OWS parameter ) 383 type = token 384 subtype = token 386 Parameters MAY follow the type/subtype in the form of attribute/value 387 pairs. 389 parameter = attribute "=" value 390 attribute = token 391 value = word 393 The type, subtype, and parameter attribute names are case- 394 insensitive. Parameter values might or might not be case-sensitive, 395 depending on the semantics of the parameter name. The presence or 396 absence of a parameter might be significant to the processing of a 397 media-type, depending on its definition within the media type 398 registry. 400 A parameter value that matches the token production can be 401 transmitted as either a token or within a quoted-string. The quoted 402 and unquoted values are equivalent. 404 Note that some older HTTP applications do not recognize media type 405 parameters. When sending data to older HTTP applications, 406 implementations SHOULD only use media type parameters when they are 407 required by that type/subtype definition. 409 Media-type values are registered with the Internet Assigned Number 410 Authority (IANA). The media type registration process is outlined in 411 [RFC4288]. Use of non-registered media types is discouraged. 413 2.3.1. Canonicalization and Text Defaults 415 Internet media types are registered with a canonical form. A 416 representation transferred via HTTP messages MUST be in the 417 appropriate canonical form prior to its transmission except for 418 "text" types, as defined in the next paragraph. 420 When in canonical form, media subtypes of the "text" type use CRLF as 421 the text line break. HTTP relaxes this requirement and allows the 422 transport of text media with plain CR or LF alone representing a line 423 break when it is done consistently for an entire representation. 424 HTTP applications MUST accept CRLF, bare CR, and bare LF as 425 indicating a line break in text media received via HTTP. In 426 addition, if the text is in a character encoding that does not use 427 octets 13 and 10 for CR and LF respectively, as is the case for some 428 multi-byte character encodings, HTTP allows the use of whatever octet 429 sequences are defined by that character encoding to represent the 430 equivalent of CR and LF for line breaks. This flexibility regarding 431 line breaks applies only to text media in the payload body; a bare CR 432 or LF MUST NOT be substituted for CRLF within any of the HTTP control 433 structures (such as header fields and multipart boundaries). 435 If a representation is encoded with a content-coding, the underlying 436 data MUST be in a form defined above prior to being encoded. 438 The "charset" parameter is used with some media types to define the 439 character encoding (Section 2.1) of the data. When no explicit 440 charset parameter is provided by the sender, media subtypes of the 441 "text" type are defined to have a default charset value of 442 "ISO-8859-1" when received via HTTP. Data in character encodings 443 other than "ISO-8859-1" or its subsets MUST be labeled with an 444 appropriate charset value. See Section 2.1.1 for compatibility 445 problems. 447 2.3.2. Multipart Types 449 MIME provides for a number of "multipart" types -- encapsulations of 450 one or more representations within a single message-body. All 451 multipart types share a common syntax, as defined in Section 5.1.1 of 452 [RFC2046], and MUST include a boundary parameter as part of the media 453 type value. The message body is itself a protocol element and MUST 454 therefore use only CRLF to represent line breaks between body-parts. 456 In general, HTTP treats a multipart message-body no differently than 457 any other media type: strictly as payload. HTTP does not use the 458 multipart boundary as an indicator of message-body length. In all 459 other respects, an HTTP user agent SHOULD follow the same or similar 460 behavior as a MIME user agent would upon receipt of a multipart type. 461 The MIME header fields within each body-part of a multipart message- 462 body do not have any significance to HTTP beyond that defined by 463 their MIME semantics. 465 If an application receives an unrecognized multipart subtype, the 466 application MUST treat it as being equivalent to "multipart/mixed". 468 Note: The "multipart/form-data" type has been specifically defined 469 for carrying form data suitable for processing via the POST 470 request method, as described in [RFC2388]. 472 2.4. Language Tags 474 A language tag, as defined in [RFC5646], identifies a natural 475 language spoken, written, or otherwise conveyed by human beings for 476 communication of information to other human beings. Computer 477 languages are explicitly excluded. HTTP uses language tags within 478 the Accept-Language and Content-Language fields. 480 In summary, a language tag is composed of one or more parts: A 481 primary language subtag followed by a possibly empty series of 482 subtags: 484 language-tag = 486 White space is not allowed within the tag and all tags are case- 487 insensitive. The name space of language subtags is administered by 488 the IANA (see 489 ). 491 Example tags include: 493 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 495 See [RFC5646] for further information. 497 3. Payload 499 HTTP messages MAY transfer a payload if not otherwise restricted by 500 the request method or response status code. The payload consists of 501 metadata, in the form of header fields, and data, in the form of the 502 sequence of octets in the message-body after any transfer-coding has 503 been decoded. 505 A "payload" in HTTP is always a partial or complete representation of 506 some resource. We use separate terms for payload and representation 507 because some messages contain only the associated representation's 508 header fields (e.g., responses to HEAD) or only some part(s) of the 509 representation (e.g., the 206 status code). 511 3.1. Payload Header Fields 513 HTTP header fields that specifically define the payload, rather than 514 the associated representation, are referred to as "payload header 515 fields". The following payload header fields are defined by 516 HTTP/1.1: 518 Content-Length ; [Part1], Section 9.2 519 Content-MD5 ; Section 6.8 520 Content-Range ; [Part5], Section 5.2 522 3.2. Payload Body 524 A payload body is only present in a message when a message-body is 525 present, as described in Section 3.3 of [Part1]. The payload body is 526 obtained from the message-body by decoding any Transfer-Encoding that 527 might have been applied to ensure safe and proper transfer of the 528 message. 530 4. Representation 532 A "representation" is information in a format that can be readily 533 communicated from one party to another. A resource representation is 534 information that reflects the state of that resource, as observed at 535 some point in the past (e.g., in a response to GET) or to be desired 536 at some point in the future (e.g., in a PUT request). 538 Most, but not all, representations transferred via HTTP are intended 539 to be a representation of the target resource (the resource 540 identified by the effective request URI). The precise semantics of a 541 representation are determined by the type of message (request or 542 response), the request method, the response status code, and the 543 representation metadata. For example, the above semantic is true for 544 the representation in any 200 (OK) response to GET and for the 545 representation in any PUT request. A 200 response to PUT, in 546 contrast, contains either a representation that describes the 547 successful action or a representation of the target resource, with 548 the latter indicated by a Content-Location header field with the same 549 value as the effective request URI. Likewise, response messages with 550 an error status code usually contain a representation that describes 551 the error and what next steps are suggested for resolving it. 553 4.1. Representation Header Fields 555 Representation header fields define metadata about the representation 556 data enclosed in the message-body or, if no message-body is present, 557 about the representation that would have been transferred in a 200 558 response to a simultaneous GET request with the same effective 559 request URI. 561 The following header fields are defined as representation metadata: 563 Content-Encoding ; Section 6.5 564 Content-Language ; Section 6.6 565 Content-Location ; Section 6.7 566 Content-Type ; Section 6.9 567 Expires ; [Part6], Section 3.3 568 Last-Modified ; [Part4], Section 6.6 570 4.2. Representation Data 572 The representation body associated with an HTTP message is either 573 provided as the payload body of the message or referred to by the 574 message semantics and the effective request URI. The representation 575 data is in a format and encoding defined by the representation 576 metadata header fields. 578 The data type of the representation data is determined via the header 579 fields Content-Type and Content-Encoding. These define a two-layer, 580 ordered encoding model: 582 representation-data := Content-Encoding( Content-Type( bits ) ) 584 Content-Type specifies the media type of the underlying data, which 585 defines both the data format and how that data SHOULD be processed by 586 the recipient (within the scope of the request method semantics). 587 Any HTTP/1.1 message containing a payload body SHOULD include a 588 Content-Type header field defining the media type of the associated 589 representation unless that metadata is unknown to the sender. If the 590 Content-Type header field is not present, it indicates that the 591 sender does not know the media type of the representation; recipients 592 MAY either assume that the media type is "application/octet-stream" 593 ([RFC2046], Section 4.5.1) or examine the content to determine its 594 type. 596 In practice, resource owners do not always properly configure their 597 origin server to provide the correct Content-Type for a given 598 representation, with the result that some clients will examine a 599 response body's content and override the specified type. Clients 600 that do so risk drawing incorrect conclusions, which might expose 601 additional security risks (e.g., "privilege escalation"). 602 Furthermore, it is impossible to determine the sender's intent by 603 examining the data format: many data formats match multiple media 604 types that differ only in processing semantics. Implementers are 605 encouraged to provide a means of disabling such "content sniffing" 606 when it is used. 608 Content-Encoding is used to indicate any additional content codings 609 applied to the data, usually for the purpose of data compression, 610 that are a property of the representation. If Content-Encoding is 611 not present, then there is no additional encoding beyond that defined 612 by the Content-Type. 614 5. Content Negotiation 616 HTTP responses include a representation which contains information 617 for interpretation, whether by a human user or for further 618 processing. Often, the server has different ways of representing the 619 same information; for example, in different formats, languages, or 620 using different character encodings. 622 HTTP clients and their users might have different or variable 623 capabilities, characteristics or preferences which would influence 624 which representation, among those available from the server, would be 625 best for the server to deliver. For this reason, HTTP provides 626 mechanisms for "content negotiation" -- a process of allowing 627 selection of a representation of a given resource, when more than one 628 is available. 630 This specification defines two patterns of content negotiation; 631 "server-driven", where the server selects the representation based 632 upon the client's stated preferences, and "agent-driven" negotiation, 633 where the server provides a list of representations for the client to 634 choose from, based upon their metadata. In addition, there are other 635 patterns: some applications use an "active content" pattern, where 636 the server returns active content which runs on the client and, based 637 on client available parameters, selects additional resources to 638 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 639 proposed. 641 These patterns are all widely used, and have trade-offs in 642 applicability and practicality. In particular, when the number of 643 preferences or capabilities to be expressed by a client are large 644 (such as when many different formats are supported by a user-agent), 645 server-driven negotiation becomes unwieldy, and might not be 646 appropriate. Conversely, when the number of representations to 647 choose from is very large, agent-driven negotiation might not be 648 appropriate. 650 Note that in all cases, the supplier of representations has the 651 responsibility for determining which representations might be 652 considered to be the "same information". 654 5.1. Server-driven Negotiation 656 If the selection of the best representation for a response is made by 657 an algorithm located at the server, it is called server-driven 658 negotiation. Selection is based on the available representations of 659 the response (the dimensions over which it can vary; e.g., language, 660 content-coding, etc.) and the contents of particular header fields in 661 the request message or on other information pertaining to the request 662 (such as the network address of the client). 664 Server-driven negotiation is advantageous when the algorithm for 665 selecting from among the available representations is difficult to 666 describe to the user agent, or when the server desires to send its 667 "best guess" to the client along with the first response (hoping to 668 avoid the round-trip delay of a subsequent request if the "best 669 guess" is good enough for the user). In order to improve the 670 server's guess, the user agent MAY include request header fields 671 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 672 preferences for such a response. 674 Server-driven negotiation has disadvantages: 676 1. It is impossible for the server to accurately determine what 677 might be "best" for any given user, since that would require 678 complete knowledge of both the capabilities of the user agent and 679 the intended use for the response (e.g., does the user want to 680 view it on screen or print it on paper?). 682 2. Having the user agent describe its capabilities in every request 683 can be both very inefficient (given that only a small percentage 684 of responses have multiple representations) and a potential 685 violation of the user's privacy. 687 3. It complicates the implementation of an origin server and the 688 algorithms for generating responses to a request. 690 4. It might limit a public cache's ability to use the same response 691 for multiple user's requests. 693 HTTP/1.1 includes the following request-header fields for enabling 694 server-driven negotiation through description of user agent 695 capabilities and user preferences: Accept (Section 6.1), Accept- 696 Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language 697 (Section 6.4), and User-Agent (Section 9.9 of [Part2]). However, an 698 origin server is not limited to these dimensions and MAY vary the 699 response based on any aspect of the request, including information 700 outside the request-header fields or within extension header fields 701 not defined by this specification. 703 Note: In practice, User-Agent based negotiation is fragile, 704 because new clients might not be recognized. 706 The Vary header field (Section 3.5 of [Part6]) can be used to express 707 the parameters the server uses to select a representation that is 708 subject to server-driven negotiation. 710 5.2. Agent-driven Negotiation 712 With agent-driven negotiation, selection of the best representation 713 for a response is performed by the user agent after receiving an 714 initial response from the origin server. Selection is based on a 715 list of the available representations of the response included within 716 the header fields or body of the initial response, with each 717 representation identified by its own URI. Selection from among the 718 representations can be performed automatically (if the user agent is 719 capable of doing so) or manually by the user selecting from a 720 generated (possibly hypertext) menu. 722 Agent-driven negotiation is advantageous when the response would vary 723 over commonly-used dimensions (such as type, language, or encoding), 724 when the origin server is unable to determine a user agent's 725 capabilities from examining the request, and generally when public 726 caches are used to distribute server load and reduce network usage. 728 Agent-driven negotiation suffers from the disadvantage of needing a 729 second request to obtain the best alternate representation. This 730 second request is only efficient when caching is used. In addition, 731 this specification does not define any mechanism for supporting 732 automatic selection, though it also does not prevent any such 733 mechanism from being developed as an extension and used within 734 HTTP/1.1. 736 This specification defines the 300 (Multiple Choices) and 406 (Not 737 Acceptable) status codes for enabling agent-driven negotiation when 738 the server is unwilling or unable to provide a varying response using 739 server-driven negotiation. 741 6. Header Field Definitions 743 This section defines the syntax and semantics of HTTP/1.1 header 744 fields related to the payload of messages. 746 6.1. Accept 748 The "Accept" request-header field can be used by user agents to 749 specify response media types that are acceptable. Accept headers can 750 be used to indicate that the request is specifically limited to a 751 small set of desired types, as in the case of a request for an in- 752 line image. 754 Accept = "Accept" ":" OWS Accept-v 755 Accept-v = #( media-range [ accept-params ] ) 757 media-range = ( "*/*" 758 / ( type "/" "*" ) 759 / ( type "/" subtype ) 760 ) *( OWS ";" OWS parameter ) 761 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 762 accept-ext = OWS ";" OWS token 763 [ "=" word ] 765 The asterisk "*" character is used to group media types into ranges, 766 with "*/*" indicating all media types and "type/*" indicating all 767 subtypes of that type. The media-range MAY include media type 768 parameters that are applicable to that range. 770 Each media-range MAY be followed by one or more accept-params, 771 beginning with the "q" parameter for indicating a relative quality 772 factor. The first "q" parameter (if any) separates the media-range 773 parameter(s) from the accept-params. Quality factors allow the user 774 or user agent to indicate the relative degree of preference for that 775 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 776 [Part1]). The default value is q=1. 778 Note: Use of the "q" parameter name to separate media type 779 parameters from Accept extension parameters is due to historical 780 practice. Although this prevents any media type parameter named 781 "q" from being used with a media range, such an event is believed 782 to be unlikely given the lack of any "q" parameters in the IANA 783 media type registry and the rare usage of any media type 784 parameters in Accept. Future media types are discouraged from 785 registering any parameter named "q". 787 The example 789 Accept: audio/*; q=0.2, audio/basic 791 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 792 type if it is the best available after an 80% mark-down in quality". 794 If no Accept header field is present, then it is assumed that the 795 client accepts all media types. If an Accept header field is 796 present, and if the server cannot send a response which is acceptable 797 according to the combined Accept field value, then the server SHOULD 798 send a 406 (Not Acceptable) response. 800 A more elaborate example is 802 Accept: text/plain; q=0.5, text/html, 803 text/x-dvi; q=0.8, text/x-c 805 Verbally, this would be interpreted as "text/html and text/x-c are 806 the preferred media types, but if they do not exist, then send the 807 text/x-dvi representation, and if that does not exist, send the text/ 808 plain representation". 810 Media ranges can be overridden by more specific media ranges or 811 specific media types. If more than one media range applies to a 812 given type, the most specific reference has precedence. For example, 814 Accept: text/*, text/html, text/html;level=1, */* 816 have the following precedence: 818 1. text/html;level=1 820 2. text/html 822 3. text/* 824 4. */* 826 The media type quality factor associated with a given type is 827 determined by finding the media range with the highest precedence 828 which matches that type. For example, 830 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 831 text/html;level=2;q=0.4, */*;q=0.5 833 would cause the following values to be associated: 835 +-------------------+---------------+ 836 | Media Type | Quality Value | 837 +-------------------+---------------+ 838 | text/html;level=1 | 1 | 839 | text/html | 0.7 | 840 | text/plain | 0.3 | 841 | image/jpeg | 0.5 | 842 | text/html;level=2 | 0.4 | 843 | text/html;level=3 | 0.7 | 844 +-------------------+---------------+ 846 Note: A user agent might be provided with a default set of quality 847 values for certain media ranges. However, unless the user agent is a 848 closed system which cannot interact with other rendering agents, this 849 default set ought to be configurable by the user. 851 6.2. Accept-Charset 853 The "Accept-Charset" request-header field can be used by user agents 854 to indicate what response character sets are acceptable. This field 855 allows clients capable of understanding more comprehensive or 856 special-purpose character sets to signal that capability to a server 857 which is capable of representing documents in those character sets. 859 Accept-Charset = "Accept-Charset" ":" OWS 860 Accept-Charset-v 861 Accept-Charset-v = 1#( ( charset / "*" ) 862 [ OWS ";" OWS "q=" qvalue ] ) 864 Character set values are described in Section 2.1. Each charset MAY 865 be given an associated quality value which represents the user's 866 preference for that charset. The default value is q=1. An example 867 is 869 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 871 The special value "*", if present in the Accept-Charset field, 872 matches every character set (including ISO-8859-1) which is not 873 mentioned elsewhere in the Accept-Charset field. If no "*" is 874 present in an Accept-Charset field, then all character sets not 875 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 876 which gets a quality value of 1 if not explicitly mentioned. 878 If no Accept-Charset header is present, the default is that any 879 character set is acceptable. If an Accept-Charset header is present, 880 and if the server cannot send a response which is acceptable 881 according to the Accept-Charset header, then the server SHOULD send 882 an error response with the 406 (Not Acceptable) status code, though 883 the sending of an unacceptable response is also allowed. 885 6.3. Accept-Encoding 887 The "Accept-Encoding" request-header field can be used by user agents 888 to indicate what response content-codings (Section 2.2) are 889 acceptable in the response. 891 Accept-Encoding = "Accept-Encoding" ":" OWS 892 Accept-Encoding-v 893 Accept-Encoding-v = 894 #( codings [ OWS ";" OWS "q=" qvalue ] ) 895 codings = ( content-coding / "*" ) 897 Each codings value MAY be given an associated quality value which 898 represents the preference for that encoding. The default value is 899 q=1. 901 Examples of its use are: 903 Accept-Encoding: compress, gzip 904 Accept-Encoding: 905 Accept-Encoding: * 906 Accept-Encoding: compress;q=0.5, gzip;q=1.0 907 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 909 A server tests whether a content-coding is acceptable, according to 910 an Accept-Encoding field, using these rules: 912 1. If the content-coding is one of the content-codings listed in the 913 Accept-Encoding field, then it is acceptable, unless it is 914 accompanied by a qvalue of 0. (As defined in Section 6.4 of 915 [Part1], a qvalue of 0 means "not acceptable".) 917 2. The special "*" symbol in an Accept-Encoding field matches any 918 available content-coding not explicitly listed in the header 919 field. 921 3. If multiple content-codings are acceptable, then the acceptable 922 content-coding with the highest non-zero qvalue is preferred. 924 4. The "identity" content-coding is always acceptable, unless 925 specifically refused because the Accept-Encoding field includes 926 "identity;q=0", or because the field includes "*;q=0" and does 927 not explicitly include the "identity" content-coding. If the 928 Accept-Encoding field-value is empty, then only the "identity" 929 encoding is acceptable. 931 If an Accept-Encoding field is present in a request, and if the 932 server cannot send a response which is acceptable according to the 933 Accept-Encoding header, then the server SHOULD send an error response 934 with the 406 (Not Acceptable) status code. 936 If no Accept-Encoding field is present in a request, the server MAY 937 assume that the client will accept any content coding. In this case, 938 if "identity" is one of the available content-codings, then the 939 server SHOULD use the "identity" content-coding, unless it has 940 additional information that a different content-coding is meaningful 941 to the client. 943 Note: If the request does not include an Accept-Encoding field, 944 and if the "identity" content-coding is unavailable, then content- 945 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 946 "compress") are preferred; some older clients improperly display 947 messages sent with other content-codings. The server might also 948 make this decision based on information about the particular user- 949 agent or client. 951 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 952 associated with content-codings. This means that qvalues will not 953 work and are not permitted with x-gzip or x-compress. 955 6.4. Accept-Language 957 The "Accept-Language" request-header field can be used by user agents 958 to indicate the set of natural languages that are preferred in the 959 response. Language tags are defined in Section 2.4. 961 Accept-Language = "Accept-Language" ":" OWS 962 Accept-Language-v 963 Accept-Language-v = 964 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 965 language-range = 966 968 Each language-range can be given an associated quality value which 969 represents an estimate of the user's preference for the languages 970 specified by that range. The quality value defaults to "q=1". For 971 example, 973 Accept-Language: da, en-gb;q=0.8, en;q=0.7 975 would mean: "I prefer Danish, but will accept British English and 976 other types of English". (see also Section 2.3 of [RFC4647]) 977 For matching, Section 3 of [RFC4647] defines several matching 978 schemes. Implementations can offer the most appropriate matching 979 scheme for their requirements. 981 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 982 identical to the matching scheme that was previously defined in 983 Section 14.4 of [RFC2616]. 985 It might be contrary to the privacy expectations of the user to send 986 an Accept-Language header with the complete linguistic preferences of 987 the user in every request. For a discussion of this issue, see 988 Section 8.1. 990 As intelligibility is highly dependent on the individual user, it is 991 recommended that client applications make the choice of linguistic 992 preference available to the user. If the choice is not made 993 available, then the Accept-Language header field MUST NOT be given in 994 the request. 996 Note: When making the choice of linguistic preference available to 997 the user, we remind implementors of the fact that users are not 998 familiar with the details of language matching as described above, 999 and ought to be provided appropriate guidance. As an example, 1000 users might assume that on selecting "en-gb", they will be served 1001 any kind of English document if British English is not available. 1002 A user agent might suggest in such a case to add "en" to get the 1003 best matching behavior. 1005 6.5. Content-Encoding 1007 The "Content-Encoding" header field indicates what content-codings 1008 have been applied to the representation, and thus what decoding 1009 mechanisms must be applied in order to obtain the media-type 1010 referenced by the Content-Type header field. Content-Encoding is 1011 primarily used to allow a representation to be compressed without 1012 losing the identity of its underlying media type. 1014 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 1015 Content-Encoding-v = 1#content-coding 1017 Content codings are defined in Section 2.2. An example of its use is 1019 Content-Encoding: gzip 1021 The content-coding is a characteristic of the representation. 1022 Typically, the representation body is stored with this encoding and 1023 is only decoded before rendering or analogous usage. However, a non- 1024 transparent proxy MAY modify the content-coding if the new coding is 1025 known to be acceptable to the recipient, unless the "no-transform" 1026 cache-control directive is present in the message. 1028 If the content-coding of a representation is not "identity", then the 1029 representation metadata MUST include a Content-Encoding header field 1030 (Section 6.5) that lists the non-identity content-coding(s) used. 1032 If the content-coding of a representation in a request message is not 1033 acceptable to the origin server, the server SHOULD respond with a 1034 status code of 415 (Unsupported Media Type). 1036 If multiple encodings have been applied to a representation, the 1037 content codings MUST be listed in the order in which they were 1038 applied. Additional information about the encoding parameters MAY be 1039 provided by other header fields not defined by this specification. 1041 6.6. Content-Language 1043 The "Content-Language" header field describes the natural language(s) 1044 of the intended audience for the representation. Note that this 1045 might not be equivalent to all the languages used within the 1046 representation. 1048 Content-Language = "Content-Language" ":" OWS Content-Language-v 1049 Content-Language-v = 1#language-tag 1051 Language tags are defined in Section 2.4. The primary purpose of 1052 Content-Language is to allow a user to identify and differentiate 1053 representations according to the user's own preferred language. 1054 Thus, if the body content is intended only for a Danish-literate 1055 audience, the appropriate field is 1057 Content-Language: da 1059 If no Content-Language is specified, the default is that the content 1060 is intended for all language audiences. This might mean that the 1061 sender does not consider it to be specific to any natural language, 1062 or that the sender does not know for which language it is intended. 1064 Multiple languages MAY be listed for content that is intended for 1065 multiple audiences. For example, a rendition of the "Treaty of 1066 Waitangi", presented simultaneously in the original Maori and English 1067 versions, would call for 1069 Content-Language: mi, en 1071 However, just because multiple languages are present within a 1072 representation does not mean that it is intended for multiple 1073 linguistic audiences. An example would be a beginner's language 1074 primer, such as "A First Lesson in Latin", which is clearly intended 1075 to be used by an English-literate audience. In this case, the 1076 Content-Language would properly only include "en". 1078 Content-Language MAY be applied to any media type -- it is not 1079 limited to textual documents. 1081 6.7. Content-Location 1083 The "Content-Location" header field supplies a URI that can be used 1084 as a specific identifier for the representation in this message. In 1085 other words, if one were to perform a GET on this URI at the time of 1086 this message's generation, then a 200 response would contain the same 1087 representation that is enclosed as payload in this message. 1089 Content-Location = "Content-Location" ":" OWS 1090 Content-Location-v 1091 Content-Location-v = 1092 absolute-URI / partial-URI 1094 The Content-Location value is not a replacement for the effective 1095 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1096 It has the same syntax and semantics as the header field of the same 1097 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1098 its appearance in an HTTP message has some special implications for 1099 HTTP recipients. 1101 If Content-Location is included in a response message and its value 1102 is the same as the effective request URI, then the response payload 1103 SHOULD be considered the current representation of that resource. 1104 For a GET or HEAD request, this is the same as the default semantics 1105 when no Content-Location is provided by the server. For a state- 1106 changing method like PUT or POST, it implies that the server's 1107 response contains the new representation of that resource, thereby 1108 distinguishing it from representations that might only report about 1109 the action (e.g., "It worked!"). This allows authoring applications 1110 to update their local copies without the need for a subsequent GET 1111 request. 1113 If Content-Location is included in a response message and its value 1114 differs from the effective request URI, then the origin server is 1115 informing recipients that this representation has its own, presumably 1116 more specific, identifier. For a GET or HEAD request, this is an 1117 indication that the effective request URI identifies a resource that 1118 is subject to content negotiation and the representation selected for 1119 this response can also be found at the identified URI. For other 1120 methods, such a Content-Location indicates that this representation 1121 contains a report on the action's status and the same report is 1122 available (for future access with GET) at the given URI. For 1123 example, a purchase transaction made via the POST method might 1124 include a receipt document as the payload of the 200 response; the 1125 Content-Location value provides an identifier for retrieving a copy 1126 of that same receipt in the future. 1128 If Content-Location is included in a request message, then it MAY be 1129 interpreted by the origin server as an indication of where the user 1130 agent originally obtained the content of the enclosed representation 1131 (prior to any subsequent modification of the content by that user 1132 agent). In other words, the user agent is providing the same 1133 representation metadata that it received with the original 1134 representation. However, such interpretation MUST NOT be used to 1135 alter the semantics of the method requested by the client. For 1136 example, if a client makes a PUT request on a negotiated resource and 1137 the origin server accepts that PUT (without redirection), then the 1138 new set of values for that resource is expected to be consistent with 1139 the one representation supplied in that PUT; the Content-Location 1140 cannot be used as a form of reverse content selection that identifies 1141 only one of the negotiated representations to be updated. If the 1142 user agent had wanted the latter semantics, it would have applied the 1143 PUT directly to the Content-Location URI. 1145 A Content-Location field received in a request message is transitory 1146 information that SHOULD NOT be saved with other representation 1147 metadata for use in later responses. The Content-Location's value 1148 might be saved for use in other contexts, such as within source links 1149 or other metadata. 1151 A cache cannot assume that a representation with a Content-Location 1152 different from the URI used to retrieve it can be used to respond to 1153 later requests on that Content-Location URI. 1155 If the Content-Location value is a partial URI, the partial URI is 1156 interpreted relative to the effective request URI. 1158 6.8. Content-MD5 1160 The "Content-MD5" header field, as defined in [RFC1864], is an MD5 1161 digest of the payload body that provides an end-to-end message 1162 integrity check (MIC) of the payload body (the message-body after any 1163 transfer-coding is decoded). Note that a MIC is good for detecting 1164 accidental modification of the payload body in transit, but is not 1165 proof against malicious attacks. 1167 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1168 Content-MD5-v = 1170 The Content-MD5 header field MAY be generated by an origin server or 1171 client to function as an integrity check of the payload body. Only 1172 origin servers or user agents MAY generate the Content-MD5 header 1173 field; proxies and gateways MUST NOT generate it, as this would 1174 defeat its value as an end-to-end integrity check. Any recipient MAY 1175 check that the digest value in this header field matches a 1176 corresponding digest calculated on payload body as received. 1178 The MD5 digest is computed based on the content of the payload body, 1179 including any content-coding, but not including any transfer-coding 1180 applied to the message-body because such transfer-codings might be 1181 applied or removed anywhere along the request/response chain. If the 1182 message is received with a transfer-coding, that encoding MUST be 1183 decoded prior to checking the Content-MD5 value against the received 1184 payload. 1186 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1187 composite media-types (e.g., multipart/* and message/rfc822), but 1188 this does not change how the digest is computed as defined in the 1189 preceding paragraph. 1191 There are several consequences of this. The payload for composite 1192 types MAY contain many body-parts, each with its own MIME and HTTP 1193 headers (including Content-MD5, Content-Transfer-Encoding, and 1194 Content-Encoding headers). If a body-part has a Content-Transfer- 1195 Encoding or Content-Encoding header, it is assumed that the content 1196 of the body-part has had the encoding applied, and the body-part is 1197 included in the Content-MD5 digest as is -- i.e., after the 1198 application. The Transfer-Encoding header field is not allowed 1199 within body-parts. 1201 Conversion of all line breaks to CRLF MUST NOT be done before 1202 computing or checking the digest: the line break convention used in 1203 the text actually transmitted MUST be left unaltered when computing 1204 the digest. 1206 Note: While the definition of Content-MD5 is exactly the same for 1207 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1208 in which the application of Content-MD5 to HTTP entity-bodies 1209 differs from its application to MIME entity-bodies. One is that 1210 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1211 does use Transfer-Encoding and Content-Encoding. Another is that 1212 HTTP more frequently uses binary content types than MIME, so it is 1213 worth noting that, in such cases, the byte order used to compute 1214 the digest is the transmission byte order defined for the type. 1215 Lastly, HTTP allows transmission of text types with any of several 1216 line break conventions and not just the canonical form using CRLF. 1218 6.9. Content-Type 1220 The "Content-Type" header field indicates the media type of the 1221 representation. In the case of responses to the HEAD method, the 1222 media type is that which would have been sent had the request been a 1223 GET. 1225 Content-Type = "Content-Type" ":" OWS Content-Type-v 1226 Content-Type-v = media-type 1228 Media types are defined in Section 2.3. An example of the field is 1230 Content-Type: text/html; charset=ISO-8859-4 1232 Further discussion of Content-Type is provided in Section 4.2. 1234 7. IANA Considerations 1236 7.1. Header Field Registration 1238 The Message Header Field Registry located at shall be 1240 updated with the permanent registrations below (see [RFC3864]): 1242 +---------------------+----------+----------+--------------+ 1243 | Header Field Name | Protocol | Status | Reference | 1244 +---------------------+----------+----------+--------------+ 1245 | Accept | http | standard | Section 6.1 | 1246 | Accept-Charset | http | standard | Section 6.2 | 1247 | Accept-Encoding | http | standard | Section 6.3 | 1248 | Accept-Language | http | standard | Section 6.4 | 1249 | Content-Disposition | http | standard | Appendix B.1 | 1250 | Content-Encoding | http | standard | Section 6.5 | 1251 | Content-Language | http | standard | Section 6.6 | 1252 | Content-Location | http | standard | Section 6.7 | 1253 | Content-MD5 | http | standard | Section 6.8 | 1254 | Content-Type | http | standard | Section 6.9 | 1255 | MIME-Version | http | standard | Appendix A.1 | 1256 +---------------------+----------+----------+--------------+ 1258 The change controller is: "IETF (iesg@ietf.org) - Internet 1259 Engineering Task Force". 1261 7.2. Content Coding Registry 1263 The registration procedure for HTTP Content Codings is now defined by 1264 Section 2.2.1 of this document. 1266 The HTTP Content Codings Registry located at 1267 shall be updated 1268 with the registration below: 1270 +----------+-----------------------------------------+--------------+ 1271 | Name | Description | Reference | 1272 +----------+-----------------------------------------+--------------+ 1273 | compress | UNIX "compress" program method | Section | 1274 | | | 6.2.2.1 of | 1275 | | | [Part1] | 1276 | deflate | "deflate" compression mechanism | Section | 1277 | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | 1278 | | format ([RFC1950]) | [Part1] | 1279 | gzip | Same as GNU zip [RFC1952] | Section | 1280 | | | 6.2.2.3 of | 1281 | | | [Part1] | 1282 | identity | No transformation | Section 2.2 | 1283 +----------+-----------------------------------------+--------------+ 1285 8. Security Considerations 1287 This section is meant to inform application developers, information 1288 providers, and users of the security limitations in HTTP/1.1 as 1289 described by this document. The discussion does not include 1290 definitive solutions to the problems revealed, though it does make 1291 some suggestions for reducing security risks. 1293 8.1. Privacy Issues Connected to Accept Headers 1295 Accept request-headers can reveal information about the user to all 1296 servers which are accessed. The Accept-Language header in particular 1297 can reveal information the user would consider to be of a private 1298 nature, because the understanding of particular languages is often 1299 strongly correlated to the membership of a particular ethnic group. 1300 User agents which offer the option to configure the contents of an 1301 Accept-Language header to be sent in every request are strongly 1302 encouraged to let the configuration process include a message which 1303 makes the user aware of the loss of privacy involved. 1305 An approach that limits the loss of privacy would be for a user agent 1306 to omit the sending of Accept-Language headers by default, and to ask 1307 the user whether or not to start sending Accept-Language headers to a 1308 server if it detects, by looking for any Vary response-header fields 1309 generated by the server, that such sending could improve the quality 1310 of service. 1312 Elaborate user-customized accept header fields sent in every request, 1313 in particular if these include quality values, can be used by servers 1314 as relatively reliable and long-lived user identifiers. Such user 1315 identifiers would allow content providers to do click-trail tracking, 1316 and would allow collaborating content providers to match cross-server 1317 click-trails or form submissions of individual users. Note that for 1318 many users not behind a proxy, the network address of the host 1319 running the user agent will also serve as a long-lived user 1320 identifier. In environments where proxies are used to enhance 1321 privacy, user agents ought to be conservative in offering accept 1322 header configuration options to end users. As an extreme privacy 1323 measure, proxies could filter the accept headers in relayed requests. 1324 General purpose user agents which provide a high degree of header 1325 configurability SHOULD warn users about the loss of privacy which can 1326 be involved. 1328 8.2. Content-Disposition Issues 1330 [RFC2183], from which the often implemented Content-Disposition (see 1331 Appendix B.1) header in HTTP is derived, has a number of very serious 1332 security considerations. Content-Disposition is not part of the HTTP 1333 standard, but since it is widely implemented, we are documenting its 1334 use and risks for implementors. See Section 5 of [RFC2183] for 1335 details. 1337 9. Acknowledgments 1339 10. References 1341 10.1. Normative References 1343 [ISO-8859-1] International Organization for Standardization, 1344 "Information technology -- 8-bit single-byte coded 1345 graphic character sets -- Part 1: Latin alphabet No. 1346 1", ISO/IEC 8859-1:1998, 1998. 1348 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1349 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1350 Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, 1351 Connections, and Message Parsing", 1352 draft-ietf-httpbis-p1-messaging-11 (work in progress), 1353 August 2010. 1355 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1356 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1357 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1358 Semantics", draft-ietf-httpbis-p2-semantics-11 (work in 1359 progress), August 2010. 1361 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1362 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1363 Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: 1364 Conditional Requests", 1365 draft-ietf-httpbis-p4-conditional-11 (work in 1366 progress), August 2010. 1368 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1369 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1370 Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range 1371 Requests and Partial Responses", 1372 draft-ietf-httpbis-p5-range-11 (work in progress), 1373 August 2010. 1375 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1376 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1377 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 1378 "HTTP/1.1, part 6: Caching", 1379 draft-ietf-httpbis-p6-cache-11 (work in progress), 1380 August 2010. 1382 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1383 RFC 1864, October 1995. 1385 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 1386 Format Specification version 3.3", RFC 1950, May 1996. 1388 RFC 1950 is an Informational RFC, thus it might be less 1389 stable than this specification. On the other hand, 1390 this downward reference was present since the 1391 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1392 it is unlikely to cause problems in practice. See also 1393 [BCP97]. 1395 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 1396 Specification version 1.3", RFC 1951, May 1996. 1398 RFC 1951 is an Informational RFC, thus it might be less 1399 stable than this specification. On the other hand, 1400 this downward reference was present since the 1401 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1402 it is unlikely to cause problems in practice. See also 1403 [BCP97]. 1405 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 1406 G. Randers-Pehrson, "GZIP file format specification 1407 version 4.3", RFC 1952, May 1996. 1409 RFC 1952 is an Informational RFC, thus it might be less 1410 stable than this specification. On the other hand, 1411 this downward reference was present since the 1412 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1413 it is unlikely to cause problems in practice. See also 1414 [BCP97]. 1416 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 1417 Mail Extensions (MIME) Part One: Format of Internet 1418 Message Bodies", RFC 2045, November 1996. 1420 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 1421 Mail Extensions (MIME) Part Two: Media Types", 1422 RFC 2046, November 1996. 1424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1425 Requirement Levels", BCP 14, RFC 2119, March 1997. 1427 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of 1428 Language Tags", BCP 47, RFC 4647, September 2006. 1430 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1431 Syntax Specifications: ABNF", STD 68, RFC 5234, 1432 January 2008. 1434 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 1435 Identifying Languages", BCP 47, RFC 5646, 1436 September 2009. 1438 10.2. Informative References 1440 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 1441 References to Standards-Track Documents", BCP 97, 1442 RFC 4897, June 2007. 1444 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 1445 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 1446 May 1996. 1448 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet 1449 Mail Extensions (MIME) Part Five: Conformance Criteria 1450 and Examples", RFC 2049, November 1996. 1452 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 1453 T. Berners-Lee, "Hypertext Transfer Protocol -- 1454 HTTP/1.1", RFC 2068, January 1997. 1456 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1457 February 1997. 1459 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1460 Presentation Information in Internet Messages: The 1461 Content-Disposition Header Field", RFC 2183, 1462 August 1997. 1464 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1465 Languages", BCP 18, RFC 2277, January 1998. 1467 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content 1468 Negotiation in HTTP", RFC 2295, March 1998. 1470 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1471 form-data", RFC 2388, August 1998. 1473 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1474 "MIME Encapsulation of Aggregate Documents, such as 1475 HTML (MHTML)", RFC 2557, March 1999. 1477 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1478 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1479 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1481 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1482 10646", RFC 3629, STD 63, November 2003. 1484 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1485 Procedures for Message Header Fields", BCP 90, 1486 RFC 3864, September 2004. 1488 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 1489 and Registration Procedures", BCP 13, RFC 4288, 1490 December 2005. 1492 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 1493 an IANA Considerations Section in RFCs", BCP 26, 1494 RFC 5226, May 2008. 1496 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1497 October 2008. 1499 Appendix A. Differences between HTTP and MIME 1501 HTTP/1.1 uses many of the constructs defined for Internet Mail 1502 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1503 [RFC2045]) to allow a message-body to be transmitted in an open 1504 variety of representations and with extensible mechanisms. However, 1505 RFC 2045 discusses mail, and HTTP has a few features that are 1506 different from those described in MIME. These differences were 1507 carefully chosen to optimize performance over binary connections, to 1508 allow greater freedom in the use of new media types, to make date 1509 comparisons easier, and to acknowledge the practice of some early 1510 HTTP servers and clients. 1512 This appendix describes specific areas where HTTP differs from MIME. 1513 Proxies and gateways to strict MIME environments SHOULD be aware of 1514 these differences and provide the appropriate conversions where 1515 necessary. Proxies and gateways from MIME environments to HTTP also 1516 need to be aware of the differences because some conversions might be 1517 required. 1519 A.1. MIME-Version 1521 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1522 MAY include a single MIME-Version general-header field to indicate 1523 what version of the MIME protocol was used to construct the message. 1524 Use of the MIME-Version header field indicates that the message is in 1525 full compliance with the MIME protocol (as defined in [RFC2045]). 1526 Proxies/gateways are responsible for ensuring full compliance (where 1527 possible) when exporting HTTP messages to strict MIME environments. 1529 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1530 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1532 MIME version "1.0" is the default for use in HTTP/1.1. However, 1533 HTTP/1.1 message parsing and semantics are defined by this document 1534 and not the MIME specification. 1536 A.2. Conversion to Canonical Form 1538 MIME requires that an Internet mail body-part be converted to 1539 canonical form prior to being transferred, as described in Section 4 1540 of [RFC2049]. Section 2.3.1 of this document describes the forms 1541 allowed for subtypes of the "text" media type when transmitted over 1542 HTTP. [RFC2046] requires that content with a type of "text" 1543 represent line breaks as CRLF and forbids the use of CR or LF outside 1544 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1545 indicate a line break within text content when a message is 1546 transmitted over HTTP. 1548 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1549 environment SHOULD translate all line breaks within the text media 1550 types described in Section 2.3.1 of this document to the RFC 2049 1551 canonical form of CRLF. Note, however, that this might be 1552 complicated by the presence of a Content-Encoding and by the fact 1553 that HTTP allows the use of some character sets which do not use 1554 octets 13 and 10 to represent CR and LF, as is the case for some 1555 multi-byte character sets. 1557 Conversion will break any cryptographic checksums applied to the 1558 original content unless the original content is already in canonical 1559 form. Therefore, the canonical form is recommended for any content 1560 that uses such checksums in HTTP. 1562 A.3. Conversion of Date Formats 1564 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1565 [Part1]) to simplify the process of date comparison. Proxies and 1566 gateways from other protocols SHOULD ensure that any Date header 1567 field present in a message conforms to one of the HTTP/1.1 formats 1568 and rewrite the date if necessary. 1570 A.4. Introduction of Content-Encoding 1572 MIME does not include any concept equivalent to HTTP/1.1's Content- 1573 Encoding header field. Since this acts as a modifier on the media 1574 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1575 either change the value of the Content-Type header field or decode 1576 the representation before forwarding the message. (Some experimental 1577 applications of Content-Type for Internet mail have used a media-type 1578 parameter of ";conversions=" to perform a function 1579 equivalent to Content-Encoding. However, this parameter is not part 1580 of the MIME standards). 1582 A.5. No Content-Transfer-Encoding 1584 HTTP does not use the Content-Transfer-Encoding field of MIME. 1585 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1586 remove any Content-Transfer-Encoding prior to delivering the response 1587 message to an HTTP client. 1589 Proxies and gateways from HTTP to MIME-compliant protocols are 1590 responsible for ensuring that the message is in the correct format 1591 and encoding for safe transport on that protocol, where "safe 1592 transport" is defined by the limitations of the protocol being used. 1593 Such a proxy or gateway SHOULD label the data with an appropriate 1594 Content-Transfer-Encoding if doing so will improve the likelihood of 1595 safe transport over the destination protocol. 1597 A.6. Introduction of Transfer-Encoding 1599 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1600 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1601 to forwarding a message via a MIME-compliant protocol. 1603 A.7. MHTML and Line Length Limitations 1605 HTTP implementations which share code with MHTML [RFC2557] 1606 implementations need to be aware of MIME line length limitations. 1607 Since HTTP does not have this limitation, HTTP does not fold long 1608 lines. MHTML messages being transported by HTTP follow all 1609 conventions of MHTML, including line length limitations and folding, 1610 canonicalization, etc., since HTTP transports all message-bodies as 1611 payload (see Section 2.3.2) and does not interpret the content or any 1612 MIME header lines that might be contained therein. 1614 Appendix B. Additional Features 1616 [RFC1945] and [RFC2068] document protocol elements used by some 1617 existing HTTP implementations, but not consistently and correctly 1618 across most HTTP/1.1 applications. Implementors are advised to be 1619 aware of these features, but cannot rely upon their presence in, or 1620 interoperability with, other HTTP/1.1 applications. Some of these 1621 describe proposed experimental features, and some describe features 1622 that experimental deployment found lacking that are now addressed in 1623 the base HTTP/1.1 specification. 1625 A number of other headers, such as Content-Disposition and Title, 1626 from SMTP and MIME are also often implemented (see [RFC2076]). 1628 B.1. Content-Disposition 1630 The "Content-Disposition" response-header field has been proposed as 1631 a means for the origin server to suggest a default filename if the 1632 user requests that the content is saved to a file. This usage is 1633 derived from the definition of Content-Disposition in [RFC2183]. 1635 content-disposition = "Content-Disposition" ":" OWS 1636 content-disposition-v 1637 content-disposition-v = disposition-type 1638 *( OWS ";" OWS disposition-parm ) 1639 disposition-type = "attachment" / disp-extension-token 1640 disposition-parm = filename-parm / disp-extension-parm 1641 filename-parm = "filename" "=" quoted-string 1642 disp-extension-token = token 1643 disp-extension-parm = token "=" word 1645 An example is 1647 Content-Disposition: attachment; filename="fname.ext" 1649 The receiving user agent SHOULD NOT respect any directory path 1650 information present in the filename-parm parameter, which is the only 1651 parameter believed to apply to HTTP implementations at this time. 1652 The filename SHOULD be treated as a terminal component only. 1654 If this header is used in a response with the application/ 1655 octet-stream content-type, the implied suggestion is that the user 1656 agent should not display the response, but directly enter a "save 1657 response as..." dialog. 1659 See Section 8.2 for Content-Disposition security issues. 1661 Appendix C. Changes from RFC 2616 1663 Clarify contexts that charset is used in. (Section 2.1) 1665 Remove base URI setting semantics for Content-Location due to poor 1666 implementation support, which was caused by too many broken servers 1667 emitting bogus Content-Location headers, and also the potentially 1668 undesirable effect of potentially breaking relative links in content- 1669 negotiated resources. (Section 6.7) 1671 Remove reference to non-existant identity transfer-coding value 1672 tokens. (Appendix A.5) 1674 Appendix D. Collected ABNF 1676 Accept = "Accept:" OWS Accept-v 1677 Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v 1678 Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1679 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1680 qvalue ] ] ) 1681 Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v 1682 Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) 1683 ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1684 Accept-Language = "Accept-Language:" OWS Accept-Language-v 1685 Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1686 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1687 ] ) 1688 Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1689 OWS media-range [ accept-params ] ] ) ] 1691 Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v 1692 Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS 1693 content-coding ] ) 1694 Content-Language = "Content-Language:" OWS Content-Language-v 1695 Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS 1696 language-tag ] ) 1697 Content-Length = 1698 Content-Location = "Content-Location:" OWS Content-Location-v 1699 Content-Location-v = absolute-URI / partial-URI 1700 Content-MD5 = "Content-MD5:" OWS Content-MD5-v 1701 Content-MD5-v = 1702 Content-Range = 1703 Content-Type = "Content-Type:" OWS Content-Type-v 1704 Content-Type-v = media-type 1706 Expires = 1708 Last-Modified = 1710 MIME-Version = "MIME-Version:" OWS MIME-Version-v 1711 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1713 OWS = 1715 absolute-URI = 1716 accept-ext = OWS ";" OWS token [ "=" word ] 1717 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1718 attribute = token 1720 charset = token 1721 codings = ( content-coding / "*" ) 1722 content-coding = token 1723 content-disposition = "Content-Disposition:" OWS 1724 content-disposition-v 1725 content-disposition-v = disposition-type *( OWS ";" OWS 1726 disposition-parm ) 1728 disp-extension-parm = token "=" word 1729 disp-extension-token = token 1730 disposition-parm = filename-parm / disp-extension-parm 1731 disposition-type = "attachment" / disp-extension-token 1733 filename-parm = "filename=" quoted-string 1735 header-field = 1737 language-range = 1738 language-tag = 1740 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1741 ";" OWS parameter ) 1742 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1744 parameter = attribute "=" value 1745 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 ; Content-Encoding defined but not used 1765 ; Content-Language defined but not used 1766 ; Content-Length defined but not used 1767 ; Content-Location defined but not used 1768 ; Content-MD5 defined but not used 1769 ; Content-Range defined but not used 1770 ; Content-Type defined but not used 1771 ; Expires defined but not used 1772 ; Last-Modified defined but not used 1773 ; MIME-Version defined but not used 1774 ; content-disposition defined but not used 1775 ; header-field defined but not used 1777 Appendix E. Change Log (to be removed by RFC Editor before publication) 1779 E.1. Since RFC2616 1781 Extracted relevant partitions from [RFC2616]. 1783 E.2. Since draft-ietf-httpbis-p3-payload-00 1785 Closed issues: 1787 o : "Media Type 1788 Registrations" () 1790 o : "Clarification 1791 regarding quoting of charset values" 1792 () 1794 o : "Remove 1795 'identity' token references" 1796 () 1798 o : "Accept- 1799 Encoding BNF" 1801 o : "Normative and 1802 Informative references" 1804 o : "RFC1700 1805 references" 1807 o : "Updating to 1808 RFC4288" 1810 o : "Informative 1811 references" 1813 o : "ISO-8859-1 1814 Reference" 1816 o : "Encoding 1817 References Normative" 1819 o : "Normative up- 1820 to-date references" 1822 E.3. Since draft-ietf-httpbis-p3-payload-01 1824 Ongoing work on ABNF conversion 1825 (): 1827 o Add explicit references to BNF syntax and rules imported from 1828 other parts of the specification. 1830 E.4. Since draft-ietf-httpbis-p3-payload-02 1832 Closed issues: 1834 o : "Quoting 1835 Charsets" 1837 o : 1838 "Classification for Allow header" 1840 o : "missing 1841 default for qvalue in description of Accept-Encoding" 1843 Ongoing work on IANA Message Header Registration 1844 (): 1846 o Reference RFC 3984, and update header registrations for headers 1847 defined in this document. 1849 E.5. Since draft-ietf-httpbis-p3-payload-03 1851 Closed issues: 1853 o : "Quoting 1854 Charsets" 1856 o : "language tag 1857 matching (Accept-Language) vs RFC4647" 1859 o : "RFC 1806 has 1860 been replaced by RFC2183" 1862 Other changes: 1864 o : "Encoding 1865 References Normative" -- rephrase the annotation and reference 1866 [BCP97]. 1868 E.6. Since draft-ietf-httpbis-p3-payload-04 1870 Closed issues: 1872 o : "RFC 2822 is 1873 updated by RFC 5322" 1875 Ongoing work on ABNF conversion 1876 (): 1878 o Use "/" instead of "|" for alternatives. 1880 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1881 whitespace ("OWS") and required whitespace ("RWS"). 1883 o Rewrite ABNFs to spell out whitespace rules, factor out header 1884 value format definitions. 1886 E.7. Since draft-ietf-httpbis-p3-payload-05 1888 Closed issues: 1890 o : "Join 1891 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1893 Final work on ABNF conversion 1894 (): 1896 o Add appendix containing collected and expanded ABNF, reorganize 1897 ABNF introduction. 1899 Other changes: 1901 o Move definition of quality values into Part 1. 1903 E.8. Since draft-ietf-httpbis-p3-payload-06 1905 Closed issues: 1907 o : "Content- 1908 Location isn't special" 1910 o : "Content 1911 Sniffing" 1913 E.9. Since draft-ietf-httpbis-p3-payload-07 1915 Closed issues: 1917 o : "Updated 1918 reference for language tags" 1920 o : "Clarify rules 1921 for determining what entities a response carries" 1923 o : "Content- 1924 Location base-setting problems" 1926 o : "Content 1927 Sniffing" 1929 o : "pick IANA 1930 policy (RFC5226) for Transfer Coding / Content Coding" 1932 o : "move 1933 definitions of gzip/deflate/compress to part 1" 1935 Partly resolved issues: 1937 o : "update IANA 1938 requirements wrt Transfer-Coding values" (add the IANA 1939 Considerations subsection) 1941 o : "update IANA 1942 requirements wrt Content-Coding values" (add the IANA 1943 Considerations subsection) 1945 E.10. Since draft-ietf-httpbis-p3-payload-08 1947 Closed issues: 1949 o : "Content 1950 Negotiation for media types" 1952 o : "Accept- 1953 Language: which RFC4647 filtering?" 1955 E.11. Since draft-ietf-httpbis-p3-payload-09 1957 Closed issues: 1959 o : "MIME-Version 1960 not listed in P1, general header fields" 1962 o : "IANA registry 1963 for content/transfer encodings" 1965 o : "Content 1966 Sniffing" 1968 o : "use of term 1969 "word" when talking about header structure" 1971 Partly resolved issues: 1973 o : "Term for the 1974 requested resource's URI" 1976 E.12. Since draft-ietf-httpbis-p3-payload-10 1978 Closed issues: 1980 o : "Clarify 1981 'Requested Variant'" 1983 o : "Content- 1984 Location isn't special" 1986 o : "Delimiting 1987 messages with multipart/byteranges" 1989 o : "Clarify 1990 entity / representation / variant terminology" 1992 o : "confusing 1993 req. language for Content-Location" 1995 o : "Content- 1996 Location on 304 responses" 1998 o : "'requested 1999 resource' in content-encoding definition" 2001 o : "consider 2002 removing the 'changes from 2068' sections" 2004 Partly resolved issues: 2006 o : "Content-MD5 2007 and partial responses" 2009 Index 2011 A 2012 Accept header 17 2013 Accept-Charset header 19 2014 Accept-Encoding header 20 2015 Accept-Language header 21 2017 C 2018 Coding Format 2019 compress 8 2020 deflate 8 2021 gzip 8 2022 identity 8 2023 compress (Coding Format) 8 2024 content negotiation 5 2025 Content-Disposition header 35 2026 Content-Encoding header 22 2027 Content-Language header 23 2028 Content-Location header 24 2029 Content-MD5 header 25 2030 Content-Type header 27 2032 D 2033 deflate (Coding Format) 8 2035 G 2036 Grammar 2037 Accept 17 2038 Accept-Charset 19 2039 Accept-Charset-v 19 2040 Accept-Encoding 20 2041 Accept-Encoding-v 20 2042 accept-ext 17 2043 Accept-Language 21 2044 Accept-Language-v 21 2045 accept-params 17 2046 Accept-v 17 2047 attribute 9 2048 charset 7 2049 codings 20 2050 content-coding 8 2051 content-disposition 35 2052 content-disposition-v 35 2053 Content-Encoding 22 2054 Content-Encoding-v 22 2055 Content-Language 23 2056 Content-Language-v 23 2057 Content-Location 24 2058 Content-Location-v 24 2059 Content-MD5 25 2060 Content-MD5-v 25 2061 Content-Type 27 2062 Content-Type-v 27 2063 disp-extension-parm 35 2064 disp-extension-token 35 2065 disposition-parm 35 2066 disposition-type 35 2067 filename-parm 35 2068 language-range 21 2069 language-tag 11 2070 media-range 17 2071 media-type 9 2072 MIME-Version 33 2073 MIME-Version-v 33 2074 parameter 9 2075 subtype 9 2076 type 9 2077 value 9 2078 gzip (Coding Format) 8 2080 H 2081 Headers 2082 Accept 17 2083 Accept-Charset 19 2084 Accept-Encoding 20 2085 Accept-Language 21 2086 Content-Disposition 35 2087 Content-Encoding 22 2088 Content-Language 23 2089 Content-Location 24 2090 Content-MD5 25 2091 Content-Type 27 2092 MIME-Version 33 2094 I 2095 identity (Coding Format) 8 2097 M 2098 MIME-Version header 33 2100 P 2101 payload 12 2103 R 2104 representation 12 2106 Authors' Addresses 2108 Roy T. Fielding (editor) 2109 Day Software 2110 23 Corporate Plaza DR, Suite 280 2111 Newport Beach, CA 92660 2112 USA 2114 Phone: +1-949-706-5300 2115 Fax: +1-949-706-5305 2116 EMail: fielding@gbiv.com 2117 URI: http://roy.gbiv.com/ 2119 Jim Gettys 2120 Alcatel-Lucent Bell Labs 2121 21 Oak Knoll Road 2122 Carlisle, MA 01741 2123 USA 2125 EMail: jg@freedesktop.org 2126 URI: http://gettys.wordpress.com/ 2127 Jeffrey C. Mogul 2128 Hewlett-Packard Company 2129 HP Labs, Large Scale Systems Group 2130 1501 Page Mill Road, MS 1177 2131 Palo Alto, CA 94304 2132 USA 2134 EMail: JeffMogul@acm.org 2136 Henrik Frystyk Nielsen 2137 Microsoft Corporation 2138 1 Microsoft Way 2139 Redmond, WA 98052 2140 USA 2142 EMail: henrikn@microsoft.com 2144 Larry Masinter 2145 Adobe Systems, Incorporated 2146 345 Park Ave 2147 San Jose, CA 95110 2148 USA 2150 EMail: LMM@acm.org 2151 URI: http://larry.masinter.net/ 2153 Paul J. Leach 2154 Microsoft Corporation 2155 1 Microsoft Way 2156 Redmond, WA 98052 2158 EMail: paulle@microsoft.com 2160 Tim Berners-Lee 2161 World Wide Web Consortium 2162 MIT Computer Science and Artificial Intelligence Laboratory 2163 The Stata Center, Building 32 2164 32 Vassar Street 2165 Cambridge, MA 02139 2166 USA 2168 EMail: timbl@w3.org 2169 URI: http://www.w3.org/People/Berners-Lee/ 2170 Yves Lafon (editor) 2171 World Wide Web Consortium 2172 W3C / ERCIM 2173 2004, rte des Lucioles 2174 Sophia-Antipolis, AM 06902 2175 France 2177 EMail: ylafon@w3.org 2178 URI: http://www.raubacapeu.net/people/yves/ 2180 Julian F. Reschke (editor) 2181 greenbytes GmbH 2182 Hafenweg 16 2183 Muenster, NW 48155 2184 Germany 2186 Phone: +49 251 2807760 2187 Fax: +49 251 2807761 2188 EMail: julian.reschke@greenbytes.de 2189 URI: http://greenbytes.de/tech/webdav/