idnits 2.17.1 draft-ietf-httpbis-p3-payload-13.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 (March 14, 2011) is 4790 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-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-13 ** 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 Adobe 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: September 15, 2011 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 March 14, 2011 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-13 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.14. 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 September 15, 2011. 62 Copyright Notice 64 Copyright (c) 2011 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 Encodings (charset) . . . . . . . . . . . . . . 6 101 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 102 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 103 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 104 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 105 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 106 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 107 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 108 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 109 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 110 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 111 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 112 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 16 118 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 119 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 120 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . 26 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 Header Fields . . . . . 28 132 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 133 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 134 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 135 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 136 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 137 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 138 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 139 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 140 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 141 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 142 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 143 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 144 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 145 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 146 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 147 Appendix E. Change Log (to be removed by RFC Editor before 148 publication) . . . . . . . . . . . . . . . . . . . . 37 149 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 150 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 151 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 152 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 153 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 154 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 155 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 156 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39 157 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 158 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 159 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 160 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 161 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 162 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42 163 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 165 1. Introduction 167 This document defines HTTP/1.1 message payloads (a.k.a., content), 168 the associated metadata header fields that define how the payload is 169 intended to be interpreted by a recipient, the request header fields 170 that might influence content selection, and the various selection 171 algorithms that are collectively referred to as HTTP content 172 negotiation. 174 This document is currently disorganized in order to minimize the 175 changes between drafts and enable reviewers to see the smaller errata 176 changes. A future draft will reorganize the sections to better 177 reflect the content. In particular, the sections on entities will be 178 renamed payload and moved to the first half of the document, while 179 the sections on content negotiation and associated request header 180 fields will be moved to the second half. The current mess reflects 181 how widely dispersed these topics and associated requirements had 182 become in [RFC2616]. 184 1.1. Terminology 186 This specification uses a number of terms to refer to the roles 187 played by participants in, and objects of, the HTTP communication. 189 content negotiation 191 The mechanism for selecting the appropriate representation when 192 servicing a request. The representation in any response can be 193 negotiated (including error responses). 195 1.2. Requirements 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 An implementation is not compliant if it fails to satisfy one or more 202 of the "MUST" or "REQUIRED" level requirements for the protocols it 203 implements. An implementation that satisfies all the "MUST" or 204 "REQUIRED" level and all the "SHOULD" level requirements for its 205 protocols is said to be "unconditionally compliant"; one that 206 satisfies all the "MUST" level requirements but not all the "SHOULD" 207 level requirements for its protocols is said to be "conditionally 208 compliant". 210 1.3. Syntax Notation 212 This specification uses the ABNF syntax defined in Section 1.2 of 213 [Part1] (which extends the syntax defined in [RFC5234] with a list 214 rule). Appendix D shows the collected ABNF, with the list rule 215 expanded. 217 The following core rules are included by reference, as defined in 218 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 219 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 220 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 221 sequence of data), SP (space), VCHAR (any visible USASCII character), 222 and WSP (whitespace). 224 1.3.1. Core Rules 226 The core rules below are defined in Section 1.2.2 of [Part1]: 228 token = 229 word = 230 OWS = 232 1.3.2. ABNF Rules defined in other Parts of the Specification 234 The ABNF rules below are defined in other parts: 236 absolute-URI = 237 partial-URI = 238 qvalue = 240 2. Protocol Parameters 242 2.1. Character Encodings (charset) 244 HTTP uses charset names to indicate the character encoding of a 245 textual representation. 247 A character encoding is identified by a case-insensitive token. The 248 complete set of tokens is defined by the IANA Character Set registry 249 (). 251 charset = token 253 Although HTTP allows an arbitrary token to be used as a charset 254 value, any token that has a predefined value within the IANA 255 Character Set registry MUST represent the character encoding defined 256 by that registry. Applications SHOULD limit their use of character 257 encodings to those defined within the IANA registry. 259 HTTP uses charset in two contexts: within an Accept-Charset request 260 header field (in which the charset value is an unquoted token) and as 261 the value of a parameter in a Content-Type header field (within a 262 request or response), in which case the parameter value of the 263 charset parameter can be quoted. 265 Implementors need to be aware of IETF character set requirements 266 [RFC3629] [RFC2277]. 268 2.1.1. Missing Charset 270 Some HTTP/1.0 software has interpreted a Content-Type header field 271 without charset parameter incorrectly to mean "recipient should 272 guess". Senders wishing to defeat this behavior MAY include a 273 charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) 274 and SHOULD do so when it is known that it will not confuse the 275 recipient. 277 Unfortunately, some older HTTP/1.0 clients did not deal properly with 278 an explicit charset parameter. HTTP/1.1 recipients MUST respect the 279 charset label provided by the sender; and those user agents that have 280 a provision to "guess" a charset MUST use the charset from the 281 content-type field if they support that charset, rather than the 282 recipient's preference, when initially displaying a document. See 283 Section 2.3.1. 285 2.2. Content Codings 287 Content coding values indicate an encoding transformation that has 288 been or can be applied to a representation. Content codings are 289 primarily used to allow a representation to be compressed or 290 otherwise usefully transformed without losing the identity of its 291 underlying media type and without loss of information. Frequently, 292 the representation is stored in coded form, transmitted directly, and 293 only decoded by the recipient. 295 content-coding = token 297 All content-coding values are case-insensitive. HTTP/1.1 uses 298 content-coding values in the Accept-Encoding (Section 6.3) and 299 Content-Encoding (Section 6.5) header fields. Although the value 300 describes the content-coding, what is more important is that it 301 indicates what decoding mechanism will be required to remove the 302 encoding. 304 compress 305 See Section 6.2.2.1 of [Part1]. 307 deflate 309 See Section 6.2.2.2 of [Part1]. 311 gzip 313 See Section 6.2.2.3 of [Part1]. 315 identity 317 The default (identity) encoding; the use of no transformation 318 whatsoever. This content-coding is used only in the Accept- 319 Encoding header field, and SHOULD NOT be used in the Content- 320 Encoding header field. 322 2.2.1. Content Coding Registry 324 The HTTP Content Coding Registry defines the name space for the 325 content coding names. 327 Registrations MUST include the following fields: 329 o Name 331 o Description 333 o Pointer to specification text 335 Names of content codings MUST NOT overlap with names of transfer 336 codings (Section 6.2 of [Part1]), unless the encoding transformation 337 is identical (as it is the case for the compression codings defined 338 in Section 6.2.2 of [Part1]). 340 Values to be added to this name space require a specification (see 341 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 342 conform to the purpose of content coding defined in this section. 344 The registry itself is maintained at 345 . 347 2.3. Media Types 349 HTTP uses Internet Media Types [RFC2046] in the Content-Type 350 (Section 6.9) and Accept (Section 6.1) header fields in order to 351 provide open and extensible data typing and type negotiation. 353 media-type = type "/" subtype *( OWS ";" OWS parameter ) 354 type = token 355 subtype = token 357 The type/subtype MAY be followed by parameters in the form of 358 attribute/value pairs. 360 parameter = attribute "=" value 361 attribute = token 362 value = word 364 The type, subtype, and parameter attribute names are case- 365 insensitive. Parameter values might or might not be case-sensitive, 366 depending on the semantics of the parameter name. The presence or 367 absence of a parameter might be significant to the processing of a 368 media-type, depending on its definition within the media type 369 registry. 371 A parameter value that matches the token production can be 372 transmitted as either a token or within a quoted-string. The quoted 373 and unquoted values are equivalent. 375 Note that some older HTTP applications do not recognize media type 376 parameters. When sending data to older HTTP applications, 377 implementations SHOULD only use media type parameters when they are 378 required by that type/subtype definition. 380 Media-type values are registered with the Internet Assigned Number 381 Authority (IANA). The media type registration process is outlined in 382 [RFC4288]. Use of non-registered media types is discouraged. 384 2.3.1. Canonicalization and Text Defaults 386 Internet media types are registered with a canonical form. A 387 representation transferred via HTTP messages MUST be in the 388 appropriate canonical form prior to its transmission except for 389 "text" types, as defined in the next paragraph. 391 When in canonical form, media subtypes of the "text" type use CRLF as 392 the text line break. HTTP relaxes this requirement and allows the 393 transport of text media with plain CR or LF alone representing a line 394 break when it is done consistently for an entire representation. 395 HTTP applications MUST accept CRLF, bare CR, and bare LF as 396 indicating a line break in text media received via HTTP. In 397 addition, if the text is in a character encoding that does not use 398 octets 13 and 10 for CR and LF respectively, as is the case for some 399 multi-byte character encodings, HTTP allows the use of whatever octet 400 sequences are defined by that character encoding to represent the 401 equivalent of CR and LF for line breaks. This flexibility regarding 402 line breaks applies only to text media in the payload body; a bare CR 403 or LF MUST NOT be substituted for CRLF within any of the HTTP control 404 structures (such as header fields and multipart boundaries). 406 If a representation is encoded with a content-coding, the underlying 407 data MUST be in a form defined above prior to being encoded. 409 The "charset" parameter is used with some media types to define the 410 character encoding (Section 2.1) of the data. When no explicit 411 charset parameter is provided by the sender, media subtypes of the 412 "text" type are defined to have a default charset value of 413 "ISO-8859-1" when received via HTTP. Data in character encodings 414 other than "ISO-8859-1" or its subsets MUST be labeled with an 415 appropriate charset value. See Section 2.1.1 for compatibility 416 problems. 418 2.3.2. Multipart Types 420 MIME provides for a number of "multipart" types -- encapsulations of 421 one or more representations within a single message-body. All 422 multipart types share a common syntax, as defined in Section 5.1.1 of 423 [RFC2046], and MUST include a boundary parameter as part of the media 424 type value. The message body is itself a protocol element and MUST 425 therefore use only CRLF to represent line breaks between body-parts. 427 In general, HTTP treats a multipart message-body no differently than 428 any other media type: strictly as payload. HTTP does not use the 429 multipart boundary as an indicator of message-body length. In all 430 other respects, an HTTP user agent SHOULD follow the same or similar 431 behavior as a MIME user agent would upon receipt of a multipart type. 432 The MIME header fields within each body-part of a multipart message- 433 body do not have any significance to HTTP beyond that defined by 434 their MIME semantics. 436 If an application receives an unrecognized multipart subtype, the 437 application MUST treat it as being equivalent to "multipart/mixed". 439 Note: The "multipart/form-data" type has been specifically defined 440 for carrying form data suitable for processing via the POST 441 request method, as described in [RFC2388]. 443 2.4. Language Tags 445 A language tag, as defined in [RFC5646], identifies a natural 446 language spoken, written, or otherwise conveyed by human beings for 447 communication of information to other human beings. Computer 448 languages are explicitly excluded. HTTP uses language tags within 449 the Accept-Language and Content-Language fields. 451 In summary, a language tag is composed of one or more parts: A 452 primary language subtag followed by a possibly empty series of 453 subtags: 455 language-tag = 457 White space is not allowed within the tag and all tags are case- 458 insensitive. The name space of language subtags is administered by 459 the IANA (see 460 ). 462 Example tags include: 464 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 466 See [RFC5646] for further information. 468 3. Payload 470 HTTP messages MAY transfer a payload if not otherwise restricted by 471 the request method or response status code. The payload consists of 472 metadata, in the form of header fields, and data, in the form of the 473 sequence of octets in the message-body after any transfer-coding has 474 been decoded. 476 A "payload" in HTTP is always a partial or complete representation of 477 some resource. We use separate terms for payload and representation 478 because some messages contain only the associated representation's 479 header fields (e.g., responses to HEAD) or only some part(s) of the 480 representation (e.g., the 206 status code). 482 3.1. Payload Header Fields 484 HTTP header fields that specifically define the payload, rather than 485 the associated representation, are referred to as "payload header 486 fields". The following payload header fields are defined by 487 HTTP/1.1: 489 +-------------------+------------------------+ 490 | Header Field Name | Defined in... | 491 +-------------------+------------------------+ 492 | Content-Length | Section 9.2 of [Part1] | 493 | Content-MD5 | Section 6.8 | 494 | Content-Range | Section 5.2 of [Part5] | 495 +-------------------+------------------------+ 497 3.2. Payload Body 499 A payload body is only present in a message when a message-body is 500 present, as described in Section 3.3 of [Part1]. The payload body is 501 obtained from the message-body by decoding any Transfer-Encoding that 502 might have been applied to ensure safe and proper transfer of the 503 message. 505 4. Representation 507 A "representation" is information in a format that can be readily 508 communicated from one party to another. A resource representation is 509 information that reflects the state of that resource, as observed at 510 some point in the past (e.g., in a response to GET) or to be desired 511 at some point in the future (e.g., in a PUT request). 513 Most, but not all, representations transferred via HTTP are intended 514 to be a representation of the target resource (the resource 515 identified by the effective request URI). The precise semantics of a 516 representation are determined by the type of message (request or 517 response), the request method, the response status code, and the 518 representation metadata. For example, the above semantic is true for 519 the representation in any 200 (OK) response to GET and for the 520 representation in any PUT request. A 200 response to PUT, in 521 contrast, contains either a representation that describes the 522 successful action or a representation of the target resource, with 523 the latter indicated by a Content-Location header field with the same 524 value as the effective request URI. Likewise, response messages with 525 an error status code usually contain a representation that describes 526 the error and what next steps are suggested for resolving it. 528 4.1. Representation Header Fields 530 Representation header fields define metadata about the representation 531 data enclosed in the message-body or, if no message-body is present, 532 about the representation that would have been transferred in a 200 533 response to a simultaneous GET request with the same effective 534 request URI. 536 The following header fields are defined as representation metadata: 538 +-------------------+------------------------+ 539 | Header Field Name | Defined in... | 540 +-------------------+------------------------+ 541 | Content-Encoding | Section 6.5 | 542 | Content-Language | Section 6.6 | 543 | Content-Location | Section 6.7 | 544 | Content-Type | Section 6.9 | 545 | Expires | Section 3.3 of [Part6] | 546 | Last-Modified | Section 6.6 of [Part4] | 547 +-------------------+------------------------+ 549 4.2. Representation Data 551 The representation body associated with an HTTP message is either 552 provided as the payload body of the message or referred to by the 553 message semantics and the effective request URI. The representation 554 data is in a format and encoding defined by the representation 555 metadata header fields. 557 The data type of the representation data is determined via the header 558 fields Content-Type and Content-Encoding. These define a two-layer, 559 ordered encoding model: 561 representation-data := Content-Encoding( Content-Type( bits ) ) 563 Content-Type specifies the media type of the underlying data, which 564 defines both the data format and how that data SHOULD be processed by 565 the recipient (within the scope of the request method semantics). 566 Any HTTP/1.1 message containing a payload body SHOULD include a 567 Content-Type header field defining the media type of the associated 568 representation unless that metadata is unknown to the sender. If the 569 Content-Type header field is not present, it indicates that the 570 sender does not know the media type of the representation; recipients 571 MAY either assume that the media type is "application/octet-stream" 572 ([RFC2046], Section 4.5.1) or examine the content to determine its 573 type. 575 In practice, resource owners do not always properly configure their 576 origin server to provide the correct Content-Type for a given 577 representation, with the result that some clients will examine a 578 response body's content and override the specified type. Clients 579 that do so risk drawing incorrect conclusions, which might expose 580 additional security risks (e.g., "privilege escalation"). 581 Furthermore, it is impossible to determine the sender's intent by 582 examining the data format: many data formats match multiple media 583 types that differ only in processing semantics. Implementers are 584 encouraged to provide a means of disabling such "content sniffing" 585 when it is used. 587 Content-Encoding is used to indicate any additional content codings 588 applied to the data, usually for the purpose of data compression, 589 that are a property of the representation. If Content-Encoding is 590 not present, then there is no additional encoding beyond that defined 591 by the Content-Type. 593 5. Content Negotiation 595 HTTP responses include a representation which contains information 596 for interpretation, whether by a human user or for further 597 processing. Often, the server has different ways of representing the 598 same information; for example, in different formats, languages, or 599 using different character encodings. 601 HTTP clients and their users might have different or variable 602 capabilities, characteristics or preferences which would influence 603 which representation, among those available from the server, would be 604 best for the server to deliver. For this reason, HTTP provides 605 mechanisms for "content negotiation" -- a process of allowing 606 selection of a representation of a given resource, when more than one 607 is available. 609 This specification defines two patterns of content negotiation; 610 "server-driven", where the server selects the representation based 611 upon the client's stated preferences, and "agent-driven" negotiation, 612 where the server provides a list of representations for the client to 613 choose from, based upon their metadata. In addition, there are other 614 patterns: some applications use an "active content" pattern, where 615 the server returns active content which runs on the client and, based 616 on client available parameters, selects additional resources to 617 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 618 proposed. 620 These patterns are all widely used, and have trade-offs in 621 applicability and practicality. In particular, when the number of 622 preferences or capabilities to be expressed by a client are large 623 (such as when many different formats are supported by a user-agent), 624 server-driven negotiation becomes unwieldy, and might not be 625 appropriate. Conversely, when the number of representations to 626 choose from is very large, agent-driven negotiation might not be 627 appropriate. 629 Note that in all cases, the supplier of representations has the 630 responsibility for determining which representations might be 631 considered to be the "same information". 633 5.1. Server-driven Negotiation 635 If the selection of the best representation for a response is made by 636 an algorithm located at the server, it is called server-driven 637 negotiation. Selection is based on the available representations of 638 the response (the dimensions over which it can vary; e.g., language, 639 content-coding, etc.) and the contents of particular header fields in 640 the request message or on other information pertaining to the request 641 (such as the network address of the client). 643 Server-driven negotiation is advantageous when the algorithm for 644 selecting from among the available representations is difficult to 645 describe to the user agent, or when the server desires to send its 646 "best guess" to the client along with the first response (hoping to 647 avoid the round-trip delay of a subsequent request if the "best 648 guess" is good enough for the user). In order to improve the 649 server's guess, the user agent MAY include request header fields 650 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 651 preferences for such a response. 653 Server-driven negotiation has disadvantages: 655 1. It is impossible for the server to accurately determine what 656 might be "best" for any given user, since that would require 657 complete knowledge of both the capabilities of the user agent and 658 the intended use for the response (e.g., does the user want to 659 view it on screen or print it on paper?). 661 2. Having the user agent describe its capabilities in every request 662 can be both very inefficient (given that only a small percentage 663 of responses have multiple representations) and a potential 664 violation of the user's privacy. 666 3. It complicates the implementation of an origin server and the 667 algorithms for generating responses to a request. 669 4. It might limit a public cache's ability to use the same response 670 for multiple user's requests. 672 HTTP/1.1 includes the following header fields for enabling server- 673 driven negotiation through description of user agent capabilities and 674 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 675 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 676 User-Agent (Section 9.9 of [Part2]). However, an origin server is 677 not limited to these dimensions and MAY vary the response based on 678 any aspect of the request, including aspects of the connection (e.g., 679 IP address) or information within extension header fields not defined 680 by this specification. 682 Note: In practice, User-Agent based negotiation is fragile, 683 because new clients might not be recognized. 685 The Vary header field (Section 3.5 of [Part6]) can be used to express 686 the parameters the server uses to select a representation that is 687 subject to server-driven negotiation. 689 5.2. Agent-driven Negotiation 691 With agent-driven negotiation, selection of the best representation 692 for a response is performed by the user agent after receiving an 693 initial response from the origin server. Selection is based on a 694 list of the available representations of the response included within 695 the header fields or body of the initial response, with each 696 representation identified by its own URI. Selection from among the 697 representations can be performed automatically (if the user agent is 698 capable of doing so) or manually by the user selecting from a 699 generated (possibly hypertext) menu. 701 Agent-driven negotiation is advantageous when the response would vary 702 over commonly-used dimensions (such as type, language, or encoding), 703 when the origin server is unable to determine a user agent's 704 capabilities from examining the request, and generally when public 705 caches are used to distribute server load and reduce network usage. 707 Agent-driven negotiation suffers from the disadvantage of needing a 708 second request to obtain the best alternate representation. This 709 second request is only efficient when caching is used. In addition, 710 this specification does not define any mechanism for supporting 711 automatic selection, though it also does not prevent any such 712 mechanism from being developed as an extension and used within 713 HTTP/1.1. 715 This specification defines the 300 (Multiple Choices) and 406 (Not 716 Acceptable) status codes for enabling agent-driven negotiation when 717 the server is unwilling or unable to provide a varying response using 718 server-driven negotiation. 720 6. Header Field Definitions 722 This section defines the syntax and semantics of HTTP/1.1 header 723 fields related to the payload of messages. 725 6.1. Accept 727 The "Accept" header field can be used by user agents to specify 728 response media types that are acceptable. Accept header fields can 729 be used to indicate that the request is specifically limited to a 730 small set of desired types, as in the case of a request for an in- 731 line image. 733 Accept = "Accept" ":" OWS Accept-v 734 Accept-v = #( media-range [ accept-params ] ) 736 media-range = ( "*/*" 737 / ( type "/" "*" ) 738 / ( type "/" subtype ) 739 ) *( OWS ";" OWS parameter ) 740 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 741 accept-ext = OWS ";" OWS token [ "=" word ] 743 The asterisk "*" character is used to group media types into ranges, 744 with "*/*" indicating all media types and "type/*" indicating all 745 subtypes of that type. The media-range MAY include media type 746 parameters that are applicable to that range. 748 Each media-range MAY be followed by one or more accept-params, 749 beginning with the "q" parameter for indicating a relative quality 750 factor. The first "q" parameter (if any) separates the media-range 751 parameter(s) from the accept-params. Quality factors allow the user 752 or user agent to indicate the relative degree of preference for that 753 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 754 [Part1]). The default value is q=1. 756 Note: Use of the "q" parameter name to separate media type 757 parameters from Accept extension parameters is due to historical 758 practice. Although this prevents any media type parameter named 759 "q" from being used with a media range, such an event is believed 760 to be unlikely given the lack of any "q" parameters in the IANA 761 media type registry and the rare usage of any media type 762 parameters in Accept. Future media types are discouraged from 763 registering any parameter named "q". 765 The example 767 Accept: audio/*; q=0.2, audio/basic 769 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 770 type if it is the best available after an 80% mark-down in quality". 772 If no Accept header field is present, then it is assumed that the 773 client accepts all media types. If an Accept header field is 774 present, and if the server cannot send a response which is acceptable 775 according to the combined Accept field value, then the server SHOULD 776 send a 406 (Not Acceptable) response. 778 A more elaborate example is 780 Accept: text/plain; q=0.5, text/html, 781 text/x-dvi; q=0.8, text/x-c 783 Verbally, this would be interpreted as "text/html and text/x-c are 784 the preferred media types, but if they do not exist, then send the 785 text/x-dvi representation, and if that does not exist, send the text/ 786 plain representation". 788 Media ranges can be overridden by more specific media ranges or 789 specific media types. If more than one media range applies to a 790 given type, the most specific reference has precedence. For example, 792 Accept: text/*, text/html, text/html;level=1, */* 794 have the following precedence: 796 1. text/html;level=1 798 2. text/html 800 3. text/* 802 4. */* 804 The media type quality factor associated with a given type is 805 determined by finding the media range with the highest precedence 806 which matches that type. For example, 808 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 809 text/html;level=2;q=0.4, */*;q=0.5 811 would cause the following values to be associated: 813 +-------------------+---------------+ 814 | Media Type | Quality Value | 815 +-------------------+---------------+ 816 | text/html;level=1 | 1 | 817 | text/html | 0.7 | 818 | text/plain | 0.3 | 819 | image/jpeg | 0.5 | 820 | text/html;level=2 | 0.4 | 821 | text/html;level=3 | 0.7 | 822 +-------------------+---------------+ 824 Note: A user agent might be provided with a default set of quality 825 values for certain media ranges. However, unless the user agent is a 826 closed system which cannot interact with other rendering agents, this 827 default set ought to be configurable by the user. 829 6.2. Accept-Charset 831 The "Accept-Charset" header field can be used by user agents to 832 indicate what character encodings are acceptable in a response 833 payload. This field allows clients capable of understanding more 834 comprehensive or special-purpose character encodings to signal that 835 capability to a server which is capable of representing documents in 836 those character encodings. 838 Accept-Charset = "Accept-Charset" ":" OWS 839 Accept-Charset-v 840 Accept-Charset-v = 1#( ( charset / "*" ) 841 [ OWS ";" OWS "q=" qvalue ] ) 843 Character encoding values (a.k.a., charsets) are described in 844 Section 2.1. Each charset MAY be given an associated quality value 845 which represents the user's preference for that charset. The default 846 value is q=1. An example is 848 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 850 The special value "*", if present in the Accept-Charset field, 851 matches every character encoding (including ISO-8859-1) which is not 852 mentioned elsewhere in the Accept-Charset field. If no "*" is 853 present in an Accept-Charset field, then all character encodings not 854 explicitly mentioned get a quality value of 0, except for ISO-8859-1, 855 which gets a quality value of 1 if not explicitly mentioned. 857 If no Accept-Charset header field is present, the default is that any 858 character encoding is acceptable. If an Accept-Charset header field 859 is present, and if the server cannot send a response which is 860 acceptable according to the Accept-Charset header field, then the 861 server SHOULD send an error response with the 406 (Not Acceptable) 862 status code, though the sending of an unacceptable response is also 863 allowed. 865 6.3. Accept-Encoding 867 The "Accept-Encoding" header field can be used by user agents to 868 indicate what response content-codings (Section 2.2) are acceptable 869 in the response. 871 Accept-Encoding = "Accept-Encoding" ":" OWS 872 Accept-Encoding-v 873 Accept-Encoding-v = 874 #( codings [ OWS ";" OWS "q=" qvalue ] ) 875 codings = ( content-coding / "*" ) 877 Each codings value MAY be given an associated quality value which 878 represents the preference for that encoding. The default value is 879 q=1. 881 Examples of its use are: 883 Accept-Encoding: compress, gzip 884 Accept-Encoding: 885 Accept-Encoding: * 886 Accept-Encoding: compress;q=0.5, gzip;q=1.0 887 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 889 A server tests whether a content-coding is acceptable, according to 890 an Accept-Encoding field, using these rules: 892 1. If the content-coding is one of the content-codings listed in the 893 Accept-Encoding field, then it is acceptable, unless it is 894 accompanied by a qvalue of 0. (As defined in Section 6.4 of 895 [Part1], a qvalue of 0 means "not acceptable".) 897 2. The special "*" symbol in an Accept-Encoding field matches any 898 available content-coding not explicitly listed in the header 899 field. 901 3. If multiple content-codings are acceptable, then the acceptable 902 content-coding with the highest non-zero qvalue is preferred. 904 4. The "identity" content-coding is always acceptable, unless 905 specifically refused because the Accept-Encoding field includes 906 "identity;q=0", or because the field includes "*;q=0" and does 907 not explicitly include the "identity" content-coding. If the 908 Accept-Encoding field-value is empty, then only the "identity" 909 encoding is acceptable. 911 If an Accept-Encoding field is present in a request, and if the 912 server cannot send a response which is acceptable according to the 913 Accept-Encoding header field, then the server SHOULD send an error 914 response with the 406 (Not Acceptable) status code. 916 If no Accept-Encoding field is present in a request, the server MAY 917 assume that the client will accept any content coding. In this case, 918 if "identity" is one of the available content-codings, then the 919 server SHOULD use the "identity" content-coding, unless it has 920 additional information that a different content-coding is meaningful 921 to the client. 923 Note: If the request does not include an Accept-Encoding field, 924 and if the "identity" content-coding is unavailable, then content- 925 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 926 "compress") are preferred; some older clients improperly display 927 messages sent with other content-codings. The server might also 928 make this decision based on information about the particular user- 929 agent or client. 931 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 932 associated with content-codings. This means that qvalues will not 933 work and are not permitted with x-gzip or x-compress. 935 6.4. Accept-Language 937 The "Accept-Language" header field can be used by user agents to 938 indicate the set of natural languages that are preferred in the 939 response. Language tags are defined in Section 2.4. 941 Accept-Language = "Accept-Language" ":" OWS 942 Accept-Language-v 943 Accept-Language-v = 944 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 945 language-range = 946 948 Each language-range can be given an associated quality value which 949 represents an estimate of the user's preference for the languages 950 specified by that range. The quality value defaults to "q=1". For 951 example, 953 Accept-Language: da, en-gb;q=0.8, en;q=0.7 955 would mean: "I prefer Danish, but will accept British English and 956 other types of English". (see also Section 2.3 of [RFC4647]) 958 For matching, Section 3 of [RFC4647] defines several matching 959 schemes. Implementations can offer the most appropriate matching 960 scheme for their requirements. 962 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 963 identical to the matching scheme that was previously defined in 964 Section 14.4 of [RFC2616]. 966 It might be contrary to the privacy expectations of the user to send 967 an Accept-Language header field with the complete linguistic 968 preferences of the user in every request. For a discussion of this 969 issue, see Section 8.1. 971 As intelligibility is highly dependent on the individual user, it is 972 recommended that client applications make the choice of linguistic 973 preference available to the user. If the choice is not made 974 available, then the Accept-Language header field MUST NOT be given in 975 the request. 977 Note: When making the choice of linguistic preference available to 978 the user, we remind implementors of the fact that users are not 979 familiar with the details of language matching as described above, 980 and ought to be provided appropriate guidance. As an example, 981 users might assume that on selecting "en-gb", they will be served 982 any kind of English document if British English is not available. 983 A user agent might suggest in such a case to add "en" to get the 984 best matching behavior. 986 6.5. Content-Encoding 988 The "Content-Encoding" header field indicates what content-codings 989 have been applied to the representation, and thus what decoding 990 mechanisms must be applied in order to obtain the media-type 991 referenced by the Content-Type header field. Content-Encoding is 992 primarily used to allow a representation to be compressed without 993 losing the identity of its underlying media type. 995 Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v 996 Content-Encoding-v = 1#content-coding 998 Content codings are defined in Section 2.2. An example of its use is 1000 Content-Encoding: gzip 1002 The content-coding is a characteristic of the representation. 1003 Typically, the representation body is stored with this encoding and 1004 is only decoded before rendering or analogous usage. However, a 1005 transforming proxy MAY modify the content-coding if the new coding is 1006 known to be acceptable to the recipient, unless the "no-transform" 1007 cache-control directive is present in the message. 1009 If the content-coding of a representation is not "identity", then the 1010 representation metadata MUST include a Content-Encoding header field 1011 (Section 6.5) that lists the non-identity content-coding(s) used. 1013 If the content-coding of a representation in a request message is not 1014 acceptable to the origin server, the server SHOULD respond with a 1015 status code of 415 (Unsupported Media Type). 1017 If multiple encodings have been applied to a representation, the 1018 content codings MUST be listed in the order in which they were 1019 applied. Additional information about the encoding parameters MAY be 1020 provided by other header fields not defined by this specification. 1022 6.6. Content-Language 1024 The "Content-Language" header field describes the natural language(s) 1025 of the intended audience for the representation. Note that this 1026 might not be equivalent to all the languages used within the 1027 representation. 1029 Content-Language = "Content-Language" ":" OWS Content-Language-v 1030 Content-Language-v = 1#language-tag 1032 Language tags are defined in Section 2.4. The primary purpose of 1033 Content-Language is to allow a user to identify and differentiate 1034 representations according to the user's own preferred language. 1035 Thus, if the body content is intended only for a Danish-literate 1036 audience, the appropriate field is 1038 Content-Language: da 1040 If no Content-Language is specified, the default is that the content 1041 is intended for all language audiences. This might mean that the 1042 sender does not consider it to be specific to any natural language, 1043 or that the sender does not know for which language it is intended. 1045 Multiple languages MAY be listed for content that is intended for 1046 multiple audiences. For example, a rendition of the "Treaty of 1047 Waitangi", presented simultaneously in the original Maori and English 1048 versions, would call for 1050 Content-Language: mi, en 1052 However, just because multiple languages are present within a 1053 representation does not mean that it is intended for multiple 1054 linguistic audiences. An example would be a beginner's language 1055 primer, such as "A First Lesson in Latin", which is clearly intended 1056 to be used by an English-literate audience. In this case, the 1057 Content-Language would properly only include "en". 1059 Content-Language MAY be applied to any media type -- it is not 1060 limited to textual documents. 1062 6.7. Content-Location 1064 The "Content-Location" header field supplies a URI that can be used 1065 as a specific identifier for the representation in this message. In 1066 other words, if one were to perform a GET on this URI at the time of 1067 this message's generation, then a 200 response would contain the same 1068 representation that is enclosed as payload in this message. 1070 Content-Location = "Content-Location" ":" OWS 1071 Content-Location-v 1072 Content-Location-v = 1073 absolute-URI / partial-URI 1075 The Content-Location value is not a replacement for the effective 1076 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1077 It has the same syntax and semantics as the header field of the same 1078 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1079 its appearance in an HTTP message has some special implications for 1080 HTTP recipients. 1082 If Content-Location is included in a response message and its value 1083 is the same as the effective request URI, then the response payload 1084 SHOULD be considered the current representation of that resource. 1085 For a GET or HEAD request, this is the same as the default semantics 1086 when no Content-Location is provided by the server. For a state- 1087 changing request like PUT or POST, it implies that the server's 1088 response contains the new representation of that resource, thereby 1089 distinguishing it from representations that might only report about 1090 the action (e.g., "It worked!"). This allows authoring applications 1091 to update their local copies without the need for a subsequent GET 1092 request. 1094 If Content-Location is included in a response message and its value 1095 differs from the effective request URI, then the origin server is 1096 informing recipients that this representation has its own, presumably 1097 more specific, identifier. For a GET or HEAD request, this is an 1098 indication that the effective request URI identifies a resource that 1099 is subject to content negotiation and the representation selected for 1100 this response can also be found at the identified URI. For other 1101 methods, such a Content-Location indicates that this representation 1102 contains a report on the action's status and the same report is 1103 available (for future access with GET) at the given URI. For 1104 example, a purchase transaction made via a POST request might include 1105 a receipt document as the payload of the 200 response; the Content- 1106 Location value provides an identifier for retrieving a copy of that 1107 same receipt in the future. 1109 If Content-Location is included in a request message, then it MAY be 1110 interpreted by the origin server as an indication of where the user 1111 agent originally obtained the content of the enclosed representation 1112 (prior to any subsequent modification of the content by that user 1113 agent). In other words, the user agent is providing the same 1114 representation metadata that it received with the original 1115 representation. However, such interpretation MUST NOT be used to 1116 alter the semantics of the method requested by the client. For 1117 example, if a client makes a PUT request on a negotiated resource and 1118 the origin server accepts that PUT (without redirection), then the 1119 new set of values for that resource is expected to be consistent with 1120 the one representation supplied in that PUT; the Content-Location 1121 cannot be used as a form of reverse content selection that identifies 1122 only one of the negotiated representations to be updated. If the 1123 user agent had wanted the latter semantics, it would have applied the 1124 PUT directly to the Content-Location URI. 1126 A Content-Location field received in a request message is transitory 1127 information that SHOULD NOT be saved with other representation 1128 metadata for use in later responses. The Content-Location's value 1129 might be saved for use in other contexts, such as within source links 1130 or other metadata. 1132 A cache cannot assume that a representation with a Content-Location 1133 different from the URI used to retrieve it can be used to respond to 1134 later requests on that Content-Location URI. 1136 If the Content-Location value is a partial URI, the partial URI is 1137 interpreted relative to the effective request URI. 1139 6.8. Content-MD5 1141 The "Content-MD5" header field, as defined in [RFC1864], is an MD5 1142 digest of the payload body that provides an end-to-end message 1143 integrity check (MIC) of the payload body (the message-body after any 1144 transfer-coding is decoded). Note that a MIC is good for detecting 1145 accidental modification of the payload body in transit, but is not 1146 proof against malicious attacks. 1148 Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v 1149 Content-MD5-v = 1151 The Content-MD5 header field MAY be generated by an origin server or 1152 client to function as an integrity check of the payload body. Only 1153 origin servers or user agents MAY generate the Content-MD5 header 1154 field; proxies MUST NOT generate it, as this would defeat its value 1155 as an end-to-end integrity check. Any recipient MAY check that the 1156 digest value in this header field matches a corresponding digest 1157 calculated on payload body as received. 1159 The MD5 digest is computed based on the content of the payload body, 1160 including any content-coding, but not including any transfer-coding 1161 applied to the message-body because such transfer-codings might be 1162 applied or removed anywhere along the request/response chain. If the 1163 message is received with a transfer-coding, that encoding MUST be 1164 decoded prior to checking the Content-MD5 value against the received 1165 payload. 1167 HTTP extends RFC 1864 to permit the digest to be computed for MIME 1168 composite media-types (e.g., multipart/* and message/rfc822), but 1169 this does not change how the digest is computed as defined in the 1170 preceding paragraph. 1172 There are several consequences of this. The payload for composite 1173 types MAY contain many body-parts, each with its own MIME and HTTP 1174 header fields (including Content-MD5, Content-Transfer-Encoding, and 1175 Content-Encoding header fields). If a body-part has a Content- 1176 Transfer-Encoding or Content-Encoding header field, it is assumed 1177 that the content of the body-part has had the encoding applied, and 1178 the body-part is included in the Content-MD5 digest as is -- i.e., 1179 after the application. The Transfer-Encoding header field is not 1180 allowed within body-parts. 1182 Conversion of all line breaks to CRLF MUST NOT be done before 1183 computing or checking the digest: the line break convention used in 1184 the text actually transmitted MUST be left unaltered when computing 1185 the digest. 1187 Note: While the definition of Content-MD5 is exactly the same for 1188 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1189 in which the application of Content-MD5 to HTTP entity-bodies 1190 differs from its application to MIME entity-bodies. One is that 1191 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1192 does use Transfer-Encoding and Content-Encoding. Another is that 1193 HTTP more frequently uses binary content types than MIME, so it is 1194 worth noting that, in such cases, the byte order used to compute 1195 the digest is the transmission byte order defined for the type. 1196 Lastly, HTTP allows transmission of text types with any of several 1197 line break conventions and not just the canonical form using CRLF. 1199 6.9. Content-Type 1201 The "Content-Type" header field indicates the media type of the 1202 representation. In the case of responses to the HEAD method, the 1203 media type is that which would have been sent had the request been a 1204 GET. 1206 Content-Type = "Content-Type" ":" OWS Content-Type-v 1207 Content-Type-v = media-type 1209 Media types are defined in Section 2.3. An example of the field is 1211 Content-Type: text/html; charset=ISO-8859-4 1213 Further discussion of Content-Type is provided in Section 4.2. 1215 7. IANA Considerations 1217 7.1. Header Field Registration 1219 The Message Header Field Registry located at shall be 1221 updated with the permanent registrations below (see [RFC3864]): 1223 +-------------------+----------+----------+--------------+ 1224 | Header Field Name | Protocol | Status | Reference | 1225 +-------------------+----------+----------+--------------+ 1226 | Accept | http | standard | Section 6.1 | 1227 | Accept-Charset | http | standard | Section 6.2 | 1228 | Accept-Encoding | http | standard | Section 6.3 | 1229 | Accept-Language | http | standard | Section 6.4 | 1230 | Content-Encoding | http | standard | Section 6.5 | 1231 | Content-Language | http | standard | Section 6.6 | 1232 | Content-Location | http | standard | Section 6.7 | 1233 | Content-MD5 | http | standard | Section 6.8 | 1234 | Content-Type | http | standard | Section 6.9 | 1235 | MIME-Version | http | standard | Appendix A.1 | 1236 +-------------------+----------+----------+--------------+ 1238 The change controller is: "IETF (iesg@ietf.org) - Internet 1239 Engineering Task Force". 1241 7.2. Content Coding Registry 1243 The registration procedure for HTTP Content Codings is now defined by 1244 Section 2.2.1 of this document. 1246 The HTTP Content Codings Registry located at 1247 shall be updated 1248 with the registration below: 1250 +----------+-----------------------------------------+--------------+ 1251 | Name | Description | Reference | 1252 +----------+-----------------------------------------+--------------+ 1253 | compress | UNIX "compress" program method | Section | 1254 | | | 6.2.2.1 of | 1255 | | | [Part1] | 1256 | deflate | "deflate" compression mechanism | Section | 1257 | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | 1258 | | format ([RFC1950]) | [Part1] | 1259 | gzip | Same as GNU zip [RFC1952] | Section | 1260 | | | 6.2.2.3 of | 1261 | | | [Part1] | 1262 | identity | No transformation | Section 2.2 | 1263 +----------+-----------------------------------------+--------------+ 1265 8. Security Considerations 1267 This section is meant to inform application developers, information 1268 providers, and users of the security limitations in HTTP/1.1 as 1269 described by this document. The discussion does not include 1270 definitive solutions to the problems revealed, though it does make 1271 some suggestions for reducing security risks. 1273 8.1. Privacy Issues Connected to Accept Header Fields 1275 Accept headers fields can reveal information about the user to all 1276 servers which are accessed. The Accept-Language header field in 1277 particular can reveal information the user would consider to be of a 1278 private nature, because the understanding of particular languages is 1279 often strongly correlated to the membership of a particular ethnic 1280 group. User agents which offer the option to configure the contents 1281 of an Accept-Language header field to be sent in every request are 1282 strongly encouraged to let the configuration process include a 1283 message which makes the user aware of the loss of privacy involved. 1285 An approach that limits the loss of privacy would be for a user agent 1286 to omit the sending of Accept-Language header fields by default, and 1287 to ask the user whether or not to start sending Accept-Language 1288 header fields to a server if it detects, by looking for any Vary 1289 header fields generated by the server, that such sending could 1290 improve the quality of service. 1292 Elaborate user-customized accept header fields sent in every request, 1293 in particular if these include quality values, can be used by servers 1294 as relatively reliable and long-lived user identifiers. Such user 1295 identifiers would allow content providers to do click-trail tracking, 1296 and would allow collaborating content providers to match cross-server 1297 click-trails or form submissions of individual users. Note that for 1298 many users not behind a proxy, the network address of the host 1299 running the user agent will also serve as a long-lived user 1300 identifier. In environments where proxies are used to enhance 1301 privacy, user agents ought to be conservative in offering accept 1302 header configuration options to end users. As an extreme privacy 1303 measure, proxies could filter the accept header fields in relayed 1304 requests. General purpose user agents which provide a high degree of 1305 header configurability SHOULD warn users about the loss of privacy 1306 which can be involved. 1308 9. Acknowledgments 1310 10. References 1312 10.1. Normative References 1314 [ISO-8859-1] International Organization for Standardization, 1315 "Information technology -- 8-bit single-byte coded 1316 graphic character sets -- Part 1: Latin alphabet No. 1317 1", ISO/IEC 8859-1:1998, 1998. 1319 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1320 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1321 Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, 1322 Connections, and Message Parsing", 1323 draft-ietf-httpbis-p1-messaging-13 (work in progress), 1324 March 2011. 1326 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1327 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1328 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1329 Semantics", draft-ietf-httpbis-p2-semantics-13 (work in 1330 progress), March 2011. 1332 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1333 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1334 Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: 1335 Conditional Requests", 1336 draft-ietf-httpbis-p4-conditional-13 (work in 1337 progress), March 2011. 1339 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1340 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1341 Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range 1342 Requests and Partial Responses", 1343 draft-ietf-httpbis-p5-range-13 (work in progress), 1344 March 2011. 1346 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1347 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 1348 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 1349 "HTTP/1.1, part 6: Caching", 1350 draft-ietf-httpbis-p6-cache-13 (work in progress), 1351 March 2011. 1353 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 1354 RFC 1864, October 1995. 1356 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 1357 Format Specification version 3.3", RFC 1950, May 1996. 1359 RFC 1950 is an Informational RFC, thus it might be less 1360 stable than this specification. On the other hand, 1361 this downward reference was present since the 1362 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1363 it is unlikely to cause problems in practice. See also 1364 [BCP97]. 1366 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 1367 Specification version 1.3", RFC 1951, May 1996. 1369 RFC 1951 is an Informational RFC, thus it might be less 1370 stable than this specification. On the other hand, 1371 this downward reference was present since the 1372 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1373 it is unlikely to cause problems in practice. See also 1374 [BCP97]. 1376 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 1377 G. Randers-Pehrson, "GZIP file format specification 1378 version 4.3", RFC 1952, May 1996. 1380 RFC 1952 is an Informational RFC, thus it might be less 1381 stable than this specification. On the other hand, 1382 this downward reference was present since the 1383 publication of RFC 2068 in 1997 ([RFC2068]), therefore 1384 it is unlikely to cause problems in practice. See also 1385 [BCP97]. 1387 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 1388 Mail Extensions (MIME) Part One: Format of Internet 1389 Message Bodies", RFC 2045, November 1996. 1391 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 1392 Mail Extensions (MIME) Part Two: Media Types", 1393 RFC 2046, November 1996. 1395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1396 Requirement Levels", BCP 14, RFC 2119, March 1997. 1398 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of 1399 Language Tags", BCP 47, RFC 4647, September 2006. 1401 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 1402 Syntax Specifications: ABNF", STD 68, RFC 5234, 1403 January 2008. 1405 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for 1406 Identifying Languages", BCP 47, RFC 5646, 1407 September 2009. 1409 10.2. Informative References 1411 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 1412 References to Standards-Track Documents", BCP 97, 1413 RFC 4897, June 2007. 1415 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 1416 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 1417 May 1996. 1419 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet 1420 Mail Extensions (MIME) Part Five: Conformance Criteria 1421 and Examples", RFC 2049, November 1996. 1423 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 1424 T. Berners-Lee, "Hypertext Transfer Protocol -- 1425 HTTP/1.1", RFC 2068, January 1997. 1427 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1428 February 1997. 1430 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1431 Languages", BCP 18, RFC 2277, January 1998. 1433 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content 1434 Negotiation in HTTP", RFC 2295, March 1998. 1436 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1437 form-data", RFC 2388, August 1998. 1439 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1440 "MIME Encapsulation of Aggregate Documents, such as 1441 HTML (MHTML)", RFC 2557, March 1999. 1443 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1444 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1445 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1447 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1448 10646", STD 63, RFC 3629, November 2003. 1450 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1451 Procedures for Message Header Fields", BCP 90, 1452 RFC 3864, September 2004. 1454 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 1455 and Registration Procedures", BCP 13, RFC 4288, 1456 December 2005. 1458 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 1459 an IANA Considerations Section in RFCs", BCP 26, 1460 RFC 5226, May 2008. 1462 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1463 October 2008. 1465 Appendix A. Differences between HTTP and MIME 1467 HTTP/1.1 uses many of the constructs defined for Internet Mail 1468 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1469 [RFC2045]) to allow a message-body to be transmitted in an open 1470 variety of representations and with extensible mechanisms. However, 1471 RFC 2045 discusses mail, and HTTP has a few features that are 1472 different from those described in MIME. These differences were 1473 carefully chosen to optimize performance over binary connections, to 1474 allow greater freedom in the use of new media types, to make date 1475 comparisons easier, and to acknowledge the practice of some early 1476 HTTP servers and clients. 1478 This appendix describes specific areas where HTTP differs from MIME. 1479 Proxies and gateways to strict MIME environments SHOULD be aware of 1480 these differences and provide the appropriate conversions where 1481 necessary. Proxies and gateways from MIME environments to HTTP also 1482 need to be aware of the differences because some conversions might be 1483 required. 1485 A.1. MIME-Version 1487 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1488 MAY include a single MIME-Version header field to indicate what 1489 version of the MIME protocol was used to construct the message. Use 1490 of the MIME-Version header field indicates that the message is in 1491 full compliance with the MIME protocol (as defined in [RFC2045]). 1492 Proxies/gateways are responsible for ensuring full compliance (where 1493 possible) when exporting HTTP messages to strict MIME environments. 1495 MIME-Version = "MIME-Version" ":" OWS MIME-Version-v 1496 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1498 MIME version "1.0" is the default for use in HTTP/1.1. However, 1499 HTTP/1.1 message parsing and semantics are defined by this document 1500 and not the MIME specification. 1502 A.2. Conversion to Canonical Form 1504 MIME requires that an Internet mail body-part be converted to 1505 canonical form prior to being transferred, as described in Section 4 1506 of [RFC2049]. Section 2.3.1 of this document describes the forms 1507 allowed for subtypes of the "text" media type when transmitted over 1508 HTTP. [RFC2046] requires that content with a type of "text" 1509 represent line breaks as CRLF and forbids the use of CR or LF outside 1510 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1511 indicate a line break within text content when a message is 1512 transmitted over HTTP. 1514 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1515 environment SHOULD translate all line breaks within the text media 1516 types described in Section 2.3.1 of this document to the RFC 2049 1517 canonical form of CRLF. Note, however, that this might be 1518 complicated by the presence of a Content-Encoding and by the fact 1519 that HTTP allows the use of some character encodings which do not use 1520 octets 13 and 10 to represent CR and LF, respectively, as is the case 1521 for some multi-byte character encodings. 1523 Conversion will break any cryptographic checksums applied to the 1524 original content unless the original content is already in canonical 1525 form. Therefore, the canonical form is recommended for any content 1526 that uses such checksums in HTTP. 1528 A.3. Conversion of Date Formats 1530 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1531 [Part1]) to simplify the process of date comparison. Proxies and 1532 gateways from other protocols SHOULD ensure that any Date header 1533 field present in a message conforms to one of the HTTP/1.1 formats 1534 and rewrite the date if necessary. 1536 A.4. Introduction of Content-Encoding 1538 MIME does not include any concept equivalent to HTTP/1.1's Content- 1539 Encoding header field. Since this acts as a modifier on the media 1540 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1541 either change the value of the Content-Type header field or decode 1542 the representation before forwarding the message. (Some experimental 1543 applications of Content-Type for Internet mail have used a media-type 1544 parameter of ";conversions=" to perform a function 1545 equivalent to Content-Encoding. However, this parameter is not part 1546 of the MIME standards). 1548 A.5. No Content-Transfer-Encoding 1550 HTTP does not use the Content-Transfer-Encoding field of MIME. 1551 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1552 remove any Content-Transfer-Encoding prior to delivering the response 1553 message to an HTTP client. 1555 Proxies and gateways from HTTP to MIME-compliant protocols are 1556 responsible for ensuring that the message is in the correct format 1557 and encoding for safe transport on that protocol, where "safe 1558 transport" is defined by the limitations of the protocol being used. 1559 Such a proxy or gateway SHOULD label the data with an appropriate 1560 Content-Transfer-Encoding if doing so will improve the likelihood of 1561 safe transport over the destination protocol. 1563 A.6. Introduction of Transfer-Encoding 1565 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1566 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1567 to forwarding a message via a MIME-compliant protocol. 1569 A.7. MHTML and Line Length Limitations 1571 HTTP implementations which share code with MHTML [RFC2557] 1572 implementations need to be aware of MIME line length limitations. 1573 Since HTTP does not have this limitation, HTTP does not fold long 1574 lines. MHTML messages being transported by HTTP follow all 1575 conventions of MHTML, including line length limitations and folding, 1576 canonicalization, etc., since HTTP transports all message-bodies as 1577 payload (see Section 2.3.2) and does not interpret the content or any 1578 MIME header lines that might be contained therein. 1580 Appendix B. Additional Features 1582 [RFC1945] and [RFC2068] document protocol elements used by some 1583 existing HTTP implementations, but not consistently and correctly 1584 across most HTTP/1.1 applications. Implementors are advised to be 1585 aware of these features, but cannot rely upon their presence in, or 1586 interoperability with, other HTTP/1.1 applications. Some of these 1587 describe proposed experimental features, and some describe features 1588 that experimental deployment found lacking that are now addressed in 1589 the base HTTP/1.1 specification. 1591 A number of other header fields, such as Content-Disposition and 1592 Title, from SMTP and MIME are also often implemented (see [RFC2076]). 1594 Appendix C. Changes from RFC 2616 1596 Clarify contexts that charset is used in. (Section 2.1) 1598 Remove base URI setting semantics for Content-Location due to poor 1599 implementation support, which was caused by too many broken servers 1600 emitting bogus Content-Location header fields, and also the 1601 potentially undesirable effect of potentially breaking relative links 1602 in content-negotiated resources. (Section 6.7) 1604 Remove reference to non-existant identity transfer-coding value 1605 tokens. (Appendix A.5) 1607 Appendix D. Collected ABNF 1609 Accept = "Accept:" OWS Accept-v 1610 Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v 1611 Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1612 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1613 qvalue ] ] ) 1614 Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v 1615 Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) 1616 ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1617 Accept-Language = "Accept-Language:" OWS Accept-Language-v 1618 Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1619 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1620 ] ) 1621 Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1622 OWS media-range [ accept-params ] ] ) ] 1624 Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v 1625 Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS 1626 content-coding ] ) 1627 Content-Language = "Content-Language:" OWS Content-Language-v 1628 Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS 1629 language-tag ] ) 1630 Content-Location = "Content-Location:" OWS Content-Location-v 1631 Content-Location-v = absolute-URI / partial-URI 1632 Content-MD5 = "Content-MD5:" OWS Content-MD5-v 1633 Content-MD5-v = 1634 Content-Type = "Content-Type:" OWS Content-Type-v 1635 Content-Type-v = media-type 1637 MIME-Version = "MIME-Version:" OWS MIME-Version-v 1638 MIME-Version-v = 1*DIGIT "." 1*DIGIT 1640 OWS = 1642 absolute-URI = 1643 accept-ext = OWS ";" OWS token [ "=" word ] 1644 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1645 attribute = token 1647 charset = token 1648 codings = ( content-coding / "*" ) 1649 content-coding = token 1651 language-range = 1652 language-tag = 1654 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1655 ";" OWS parameter ) 1656 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1658 parameter = attribute "=" value 1659 partial-URI = 1661 qvalue = 1663 subtype = token 1665 token = 1666 type = token 1668 value = word 1670 word = 1671 ABNF diagnostics: 1673 ; Accept defined but not used 1674 ; Accept-Charset defined but not used 1675 ; Accept-Encoding defined but not used 1676 ; Accept-Language defined but not used 1677 ; Content-Encoding defined but not used 1678 ; Content-Language defined but not used 1679 ; Content-Location defined but not used 1680 ; Content-MD5 defined but not used 1681 ; Content-Type defined but not used 1682 ; MIME-Version defined but not used 1684 Appendix E. Change Log (to be removed by RFC Editor before publication) 1686 E.1. Since RFC 2616 1688 Extracted relevant partitions from [RFC2616]. 1690 E.2. Since draft-ietf-httpbis-p3-payload-00 1692 Closed issues: 1694 o : "Media Type 1695 Registrations" () 1697 o : "Clarification 1698 regarding quoting of charset values" 1699 () 1701 o : "Remove 1702 'identity' token references" 1703 () 1705 o : "Accept- 1706 Encoding BNF" 1708 o : "Normative and 1709 Informative references" 1711 o : "RFC1700 1712 references" 1714 o : "Updating to 1715 RFC4288" 1717 o : "Informative 1718 references" 1720 o : "ISO-8859-1 1721 Reference" 1723 o : "Encoding 1724 References Normative" 1726 o : "Normative up- 1727 to-date references" 1729 E.3. Since draft-ietf-httpbis-p3-payload-01 1731 Ongoing work on ABNF conversion 1732 (): 1734 o Add explicit references to BNF syntax and rules imported from 1735 other parts of the specification. 1737 E.4. Since draft-ietf-httpbis-p3-payload-02 1739 Closed issues: 1741 o : "Quoting 1742 Charsets" 1744 o : 1745 "Classification for Allow header" 1747 o : "missing 1748 default for qvalue in description of Accept-Encoding" 1750 Ongoing work on IANA Message Header Field Registration 1751 (): 1753 o Reference RFC 3984, and update header field registrations for 1754 headers defined in this document. 1756 E.5. Since draft-ietf-httpbis-p3-payload-03 1758 Closed issues: 1760 o : "Quoting 1761 Charsets" 1763 o : "language tag 1764 matching (Accept-Language) vs RFC4647" 1766 o : "RFC 1806 has 1767 been replaced by RFC2183" 1769 Other changes: 1771 o : "Encoding 1772 References Normative" -- rephrase the annotation and reference 1773 [BCP97]. 1775 E.6. Since draft-ietf-httpbis-p3-payload-04 1777 Closed issues: 1779 o : "RFC 2822 is 1780 updated by RFC 5322" 1782 Ongoing work on ABNF conversion 1783 (): 1785 o Use "/" instead of "|" for alternatives. 1787 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1788 whitespace ("OWS") and required whitespace ("RWS"). 1790 o Rewrite ABNFs to spell out whitespace rules, factor out header 1791 field value format definitions. 1793 E.7. Since draft-ietf-httpbis-p3-payload-05 1795 Closed issues: 1797 o : "Join 1798 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1800 Final work on ABNF conversion 1801 (): 1803 o Add appendix containing collected and expanded ABNF, reorganize 1804 ABNF introduction. 1806 Other changes: 1808 o Move definition of quality values into Part 1. 1810 E.8. Since draft-ietf-httpbis-p3-payload-06 1812 Closed issues: 1814 o : "Content- 1815 Location isn't special" 1817 o : "Content 1818 Sniffing" 1820 E.9. Since draft-ietf-httpbis-p3-payload-07 1822 Closed issues: 1824 o : "Updated 1825 reference for language tags" 1827 o : "Clarify rules 1828 for determining what entities a response carries" 1830 o : "Content- 1831 Location base-setting problems" 1833 o : "Content 1834 Sniffing" 1836 o : "pick IANA 1837 policy (RFC5226) for Transfer Coding / Content Coding" 1839 o : "move 1840 definitions of gzip/deflate/compress to part 1" 1842 Partly resolved issues: 1844 o : "update IANA 1845 requirements wrt Transfer-Coding values" (add the IANA 1846 Considerations subsection) 1848 o : "update IANA 1849 requirements wrt Content-Coding values" (add the IANA 1850 Considerations subsection) 1852 E.10. Since draft-ietf-httpbis-p3-payload-08 1854 Closed issues: 1856 o : "Content 1857 Negotiation for media types" 1859 o : "Accept- 1860 Language: which RFC4647 filtering?" 1862 E.11. Since draft-ietf-httpbis-p3-payload-09 1864 Closed issues: 1866 o : "MIME-Version 1867 not listed in P1, general header fields" 1869 o : "IANA registry 1870 for content/transfer encodings" 1872 o : "Content 1873 Sniffing" 1875 o : "use of term 1876 "word" when talking about header structure" 1878 Partly resolved issues: 1880 o : "Term for the 1881 requested resource's URI" 1883 E.12. Since draft-ietf-httpbis-p3-payload-10 1885 Closed issues: 1887 o : "Clarify 1888 'Requested Variant'" 1890 o : "Content- 1891 Location isn't special" 1893 o : "Delimiting 1894 messages with multipart/byteranges" 1896 o : "Clarify 1897 entity / representation / variant terminology" 1899 o : "confusing 1900 req. language for Content-Location" 1902 o : "Content- 1903 Location on 304 responses" 1905 o : "'requested 1906 resource' in content-encoding definition" 1908 o : "consider 1909 removing the 'changes from 2068' sections" 1911 Partly resolved issues: 1913 o : "Content-MD5 1914 and partial responses" 1916 E.13. Since draft-ietf-httpbis-p3-payload-11 1918 Closed issues: 1920 o : "Factor out 1921 Content-Disposition" 1923 E.14. Since draft-ietf-httpbis-p3-payload-12 1925 Closed issues: 1927 o : "Header 1928 Classification" 1930 o : "untangle 1931 ABNFs for header fields" 1933 o : "potentially 1934 misleading MAY in media-type def" 1936 Index 1938 A 1939 Accept header field 16 1940 Accept-Charset header field 19 1941 Accept-Encoding header field 19 1942 Accept-Language header field 21 1944 C 1945 Coding Format 1946 compress 7 1947 deflate 8 1948 gzip 8 1949 identity 8 1950 compress (Coding Format) 7 1951 content negotiation 5 1952 Content-Encoding header field 22 1953 Content-Language header field 23 1954 Content-Location header field 24 1955 Content-MD5 header field 25 1956 Content-Type header field 26 1958 D 1959 deflate (Coding Format) 8 1961 G 1962 Grammar 1963 Accept 17 1964 Accept-Charset 19 1965 Accept-Charset-v 19 1966 Accept-Encoding 20 1967 Accept-Encoding-v 20 1968 accept-ext 17 1969 Accept-Language 21 1970 Accept-Language-v 21 1971 accept-params 17 1972 Accept-v 17 1973 attribute 9 1974 charset 6 1975 codings 20 1976 content-coding 7 1977 Content-Encoding 22 1978 Content-Encoding-v 22 1979 Content-Language 23 1980 Content-Language-v 23 1981 Content-Location 24 1982 Content-Location-v 24 1983 Content-MD5 25 1984 Content-MD5-v 25 1985 Content-Type 26 1986 Content-Type-v 26 1987 language-range 21 1988 language-tag 11 1989 media-range 17 1990 media-type 9 1991 MIME-Version 33 1992 MIME-Version-v 33 1993 parameter 9 1994 subtype 9 1995 type 9 1996 value 9 1997 gzip (Coding Format) 8 1999 H 2000 Header Fields 2001 Accept 16 2002 Accept-Charset 19 2003 Accept-Encoding 19 2004 Accept-Language 21 2005 Content-Encoding 22 2006 Content-Language 23 2007 Content-Location 24 2008 Content-MD5 25 2009 Content-Type 26 2010 MIME-Version 32 2012 I 2013 identity (Coding Format) 8 2015 M 2016 MIME-Version header field 32 2018 P 2019 payload 11 2021 R 2022 representation 12 2024 Authors' Addresses 2026 Roy T. Fielding (editor) 2027 Adobe Systems Incorporated 2028 345 Park Ave 2029 San Jose, CA 95110 2030 USA 2032 EMail: fielding@gbiv.com 2033 URI: http://roy.gbiv.com/ 2035 Jim Gettys 2036 Alcatel-Lucent Bell Labs 2037 21 Oak Knoll Road 2038 Carlisle, MA 01741 2039 USA 2041 EMail: jg@freedesktop.org 2042 URI: http://gettys.wordpress.com/ 2044 Jeffrey C. Mogul 2045 Hewlett-Packard Company 2046 HP Labs, Large Scale Systems Group 2047 1501 Page Mill Road, MS 1177 2048 Palo Alto, CA 94304 2049 USA 2051 EMail: JeffMogul@acm.org 2052 Henrik Frystyk Nielsen 2053 Microsoft Corporation 2054 1 Microsoft Way 2055 Redmond, WA 98052 2056 USA 2058 EMail: henrikn@microsoft.com 2060 Larry Masinter 2061 Adobe Systems Incorporated 2062 345 Park Ave 2063 San Jose, CA 95110 2064 USA 2066 EMail: LMM@acm.org 2067 URI: http://larry.masinter.net/ 2069 Paul J. Leach 2070 Microsoft Corporation 2071 1 Microsoft Way 2072 Redmond, WA 98052 2074 EMail: paulle@microsoft.com 2076 Tim Berners-Lee 2077 World Wide Web Consortium 2078 MIT Computer Science and Artificial Intelligence Laboratory 2079 The Stata Center, Building 32 2080 32 Vassar Street 2081 Cambridge, MA 02139 2082 USA 2084 EMail: timbl@w3.org 2085 URI: http://www.w3.org/People/Berners-Lee/ 2086 Yves Lafon (editor) 2087 World Wide Web Consortium 2088 W3C / ERCIM 2089 2004, rte des Lucioles 2090 Sophia-Antipolis, AM 06902 2091 France 2093 EMail: ylafon@w3.org 2094 URI: http://www.raubacapeu.net/people/yves/ 2096 Julian F. Reschke (editor) 2097 greenbytes GmbH 2098 Hafenweg 16 2099 Muenster, NW 48155 2100 Germany 2102 Phone: +49 251 2807760 2103 Fax: +49 251 2807761 2104 EMail: julian.reschke@greenbytes.de 2105 URI: http://greenbytes.de/tech/webdav/