idnits 2.17.1 draft-ietf-httpbis-p3-payload-17.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 (October 31, 2011) is 4554 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-17 ** 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 (==), 8 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: May 3, 2012 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 October 31, 2011 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-17 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext 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. 34 Part 3 defines HTTP message content, metadata, and content 35 negotiation. 37 Editorial Note (To be removed by RFC Editor) 39 Discussion of this draft should take place on the HTTPBIS working 40 group mailing list (ietf-http-wg@w3.org), which is archived at 41 . 43 The current issues list is at 44 and related 45 documents (including fancy diffs) can be found at 46 . 48 The changes in this draft are summarized in Appendix E.18. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on May 3, 2012. 67 Copyright Notice 69 Copyright (c) 2011 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 This document may contain material from IETF Documents or IETF 83 Contributions published or made publicly available before November 84 10, 2008. The person(s) controlling the copyright in some of this 85 material may not have granted the IETF Trust the right to allow 86 modifications of such material outside the IETF Standards Process. 87 Without obtaining an adequate license from the person(s) controlling 88 the copyright in such materials, this document may not be modified 89 outside the IETF Standards Process, and derivative works of it may 90 not be created outside the IETF Standards Process, except to format 91 it for publication as an RFC or to translate it into languages other 92 than English. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 97 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 98 1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5 99 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 100 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 101 1.3.2. ABNF Rules defined in other Parts of the 102 Specification . . . . . . . . . . . . . . . . . . . . 6 103 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 104 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 105 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 106 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 107 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 108 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 109 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 110 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 111 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 112 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 113 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 114 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 115 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 116 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 117 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 118 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 119 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 120 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 121 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 122 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 123 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 124 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 125 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 126 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 127 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 128 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 130 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 131 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 133 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 134 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 136 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 137 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 138 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 139 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 140 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 141 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 142 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 143 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 144 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 145 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 147 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 148 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 33 149 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 150 Appendix E. Change Log (to be removed by RFC Editor before 151 publication) . . . . . . . . . . . . . . . . . . . . 35 152 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 35 153 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 154 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 155 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 156 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 157 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 158 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 37 159 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 160 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 38 161 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 162 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38 163 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 39 164 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 40 165 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 40 166 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 40 167 E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 168 E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40 169 E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 41 170 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 172 1. Introduction 174 This document defines HTTP/1.1 message payloads (a.k.a., content), 175 the associated metadata header fields that define how the payload is 176 intended to be interpreted by a recipient, the request header fields 177 that might influence content selection, and the various selection 178 algorithms that are collectively referred to as HTTP content 179 negotiation. 181 This document is currently disorganized in order to minimize the 182 changes between drafts and enable reviewers to see the smaller errata 183 changes. A future draft will reorganize the sections to better 184 reflect the content. In particular, the sections on entities will be 185 renamed payload and moved to the first half of the document, while 186 the sections on content negotiation and associated request header 187 fields will be moved to the second half. The current mess reflects 188 how widely dispersed these topics and associated requirements had 189 become in [RFC2616]. 191 1.1. Terminology 193 This specification uses a number of terms to refer to the roles 194 played by participants in, and objects of, the HTTP communication. 196 content negotiation 198 The mechanism for selecting the appropriate representation when 199 servicing a request. The representation in any response can be 200 negotiated (including error responses). 202 1.2. Conformance and Error Handling 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 This document defines conformance criteria for several roles in HTTP 209 communication, including Senders, Recipients, Clients, Servers, User- 210 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 211 Section 2 of [Part1] for definitions of these terms. 213 An implementation is considered conformant if it complies with all of 214 the requirements associated with its role(s). Note that SHOULD-level 215 requirements are relevant here, unless one of the documented 216 exceptions is applicable. 218 This document also uses ABNF to define valid protocol elements 219 (Section 1.3). In addition to the prose requirements placed upon 220 them, Senders MUST NOT generate protocol elements that are invalid. 222 Unless noted otherwise, Recipients MAY take steps to recover a usable 223 protocol element from an invalid construct. However, HTTP does not 224 define specific error handling mechanisms, except in cases where it 225 has direct impact on security. This is because different uses of the 226 protocol require different error handling strategies; for example, a 227 Web browser may wish to transparently recover from a response where 228 the Location header field doesn't parse according to the ABNF, 229 whereby in a systems control protocol using HTTP, this type of error 230 recovery could lead to dangerous consequences. 232 1.3. Syntax Notation 234 This specification uses the ABNF syntax defined in Section 1.2 of 235 [Part1] (which extends the syntax defined in [RFC5234] with a list 236 rule). Appendix D shows the collected ABNF, with the list rule 237 expanded. 239 The following core rules are included by reference, as defined in 240 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 241 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 242 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 243 sequence of data), SP (space), and VCHAR (any visible US-ASCII 244 character). 246 1.3.1. Core Rules 248 The core rules below are defined in [Part1]: 250 OWS = 251 token = 252 word = 254 1.3.2. ABNF Rules defined in other Parts of the Specification 256 The ABNF rules below are defined in other parts: 258 absolute-URI = 259 partial-URI = 260 qvalue = 262 2. Protocol Parameters 264 2.1. Character Encodings (charset) 266 HTTP uses charset names to indicate the character encoding of a 267 textual representation. 269 A character encoding is identified by a case-insensitive token. The 270 complete set of tokens is defined by the IANA Character Set registry 271 (). 273 charset = token 275 Although HTTP allows an arbitrary token to be used as a charset 276 value, any token that has a predefined value within the IANA 277 Character Set registry MUST represent the character encoding defined 278 by that registry. Applications SHOULD limit their use of character 279 encodings to those defined within the IANA registry. 281 HTTP uses charset in two contexts: within an Accept-Charset request 282 header field (in which the charset value is an unquoted token) and as 283 the value of a parameter in a Content-Type header field (within a 284 request or response), in which case the parameter value of the 285 charset parameter can be quoted. 287 Implementors need to be aware of IETF character set requirements 288 [RFC3629] [RFC2277]. 290 2.2. Content Codings 292 Content coding values indicate an encoding transformation that has 293 been or can be applied to a representation. Content codings are 294 primarily used to allow a representation to be compressed or 295 otherwise usefully transformed without losing the identity of its 296 underlying media type and without loss of information. Frequently, 297 the representation is stored in coded form, transmitted directly, and 298 only decoded by the recipient. 300 content-coding = token 302 All content-coding values are case-insensitive. HTTP/1.1 uses 303 content-coding values in the Accept-Encoding (Section 6.3) and 304 Content-Encoding (Section 6.5) header fields. Although the value 305 describes the content-coding, what is more important is that it 306 indicates what decoding mechanism will be required to remove the 307 encoding. 309 compress 311 See Section 5.1.2.1 of [Part1]. 313 deflate 315 See Section 5.1.2.2 of [Part1]. 317 gzip 319 See Section 5.1.2.3 of [Part1]. 321 2.2.1. Content Coding Registry 323 The HTTP Content Coding Registry defines the name space for the 324 content coding names. 326 Registrations MUST include the following fields: 328 o Name 330 o Description 332 o Pointer to specification text 334 Names of content codings MUST NOT overlap with names of transfer 335 codings (Section 5.1 of [Part1]), unless the encoding transformation 336 is identical (as it is the case for the compression codings defined 337 in Section 5.1.2 of [Part1]). 339 Values to be added to this name space require a specification (see 340 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 341 conform to the purpose of content coding defined in this section. 343 The registry itself is maintained at 344 . 346 2.3. Media Types 348 HTTP uses Internet Media Types [RFC2046] in the Content-Type 349 (Section 6.8) and Accept (Section 6.1) header fields in order to 350 provide open and extensible data typing and type negotiation. 352 media-type = type "/" subtype *( OWS ";" OWS parameter ) 353 type = token 354 subtype = token 356 The type/subtype MAY be followed by parameters in the form of 357 attribute/value pairs. 359 parameter = attribute "=" value 360 attribute = token 361 value = word 363 The type, subtype, and parameter attribute names are case- 364 insensitive. Parameter values might or might not be case-sensitive, 365 depending on the semantics of the parameter name. The presence or 366 absence of a parameter might be significant to the processing of a 367 media-type, depending on its definition within the media type 368 registry. 370 A parameter value that matches the token production can be 371 transmitted as either a token or within a quoted-string. The quoted 372 and unquoted values are equivalent. 374 Note that some older HTTP applications do not recognize media type 375 parameters. When sending data to older HTTP applications, 376 implementations SHOULD only use media type parameters when they are 377 required by that type/subtype definition. 379 Media-type values are registered with the Internet Assigned Number 380 Authority (IANA). The media type registration process is outlined in 381 [RFC4288]. Use of non-registered media types is discouraged. 383 2.3.1. Canonicalization and Text Defaults 385 Internet media types are registered with a canonical form. A 386 representation transferred via HTTP messages MUST be in the 387 appropriate canonical form prior to its transmission except for 388 "text" types, as defined in the next paragraph. 390 When in canonical form, media subtypes of the "text" type use CRLF as 391 the text line break. HTTP relaxes this requirement and allows the 392 transport of text media with plain CR or LF alone representing a line 393 break when it is done consistently for an entire representation. 394 HTTP applications MUST accept CRLF, bare CR, and bare LF as 395 indicating a line break in text media received via HTTP. In 396 addition, if the text is in a character encoding that does not use 397 octets 13 and 10 for CR and LF respectively, as is the case for some 398 multi-byte character encodings, HTTP allows the use of whatever octet 399 sequences are defined by that character encoding to represent the 400 equivalent of CR and LF for line breaks. This flexibility regarding 401 line breaks applies only to text media in the payload body; a bare CR 402 or LF MUST NOT be substituted for CRLF within any of the HTTP control 403 structures (such as header fields and multipart boundaries). 405 If a representation is encoded with a content-coding, the underlying 406 data MUST be in a form defined above prior to being encoded. 408 2.3.2. Multipart Types 410 MIME provides for a number of "multipart" types -- encapsulations of 411 one or more representations within a single message-body. All 412 multipart types share a common syntax, as defined in Section 5.1.1 of 414 [RFC2046], and MUST include a boundary parameter as part of the media 415 type value. The message body is itself a protocol element and MUST 416 therefore use only CRLF to represent line breaks between body-parts. 418 In general, HTTP treats a multipart message-body no differently than 419 any other media type: strictly as payload. HTTP does not use the 420 multipart boundary as an indicator of message-body length. In all 421 other respects, an HTTP user agent SHOULD follow the same or similar 422 behavior as a MIME user agent would upon receipt of a multipart type. 423 The MIME header fields within each body-part of a multipart message- 424 body do not have any significance to HTTP beyond that defined by 425 their MIME semantics. 427 If an application receives an unrecognized multipart subtype, the 428 application MUST treat it as being equivalent to "multipart/mixed". 430 Note: The "multipart/form-data" type has been specifically defined 431 for carrying form data suitable for processing via the POST 432 request method, as described in [RFC2388]. 434 2.4. Language Tags 436 A language tag, as defined in [RFC5646], identifies a natural 437 language spoken, written, or otherwise conveyed by human beings for 438 communication of information to other human beings. Computer 439 languages are explicitly excluded. HTTP uses language tags within 440 the Accept-Language and Content-Language fields. 442 In summary, a language tag is composed of one or more parts: A 443 primary language subtag followed by a possibly empty series of 444 subtags: 446 language-tag = 448 White space is not allowed within the tag and all tags are case- 449 insensitive. The name space of language subtags is administered by 450 the IANA (see 451 ). 453 Example tags include: 455 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 457 See [RFC5646] for further information. 459 3. Payload 461 HTTP messages MAY transfer a payload if not otherwise restricted by 462 the request method or response status code. The payload consists of 463 metadata, in the form of header fields, and data, in the form of the 464 sequence of octets in the message-body after any transfer-coding has 465 been decoded. 467 A "payload" in HTTP is always a partial or complete representation of 468 some resource. We use separate terms for payload and representation 469 because some messages contain only the associated representation's 470 header fields (e.g., responses to HEAD) or only some part(s) of the 471 representation (e.g., the 206 status code). 473 3.1. Payload Header Fields 475 HTTP header fields that specifically define the payload, rather than 476 the associated representation, are referred to as "payload header 477 fields". The following payload header fields are defined by 478 HTTP/1.1: 480 +-------------------+------------------------+ 481 | Header Field Name | Defined in... | 482 +-------------------+------------------------+ 483 | Content-Length | Section 8.2 of [Part1] | 484 | Content-Range | Section 5.2 of [Part5] | 485 +-------------------+------------------------+ 487 3.2. Payload Body 489 A payload body is only present in a message when a message-body is 490 present, as described in Section 3.3 of [Part1]. The payload body is 491 obtained from the message-body by decoding any Transfer-Encoding that 492 might have been applied to ensure safe and proper transfer of the 493 message. 495 4. Representation 497 A "representation" is information in a format that can be readily 498 communicated from one party to another. A resource representation is 499 information that reflects the state of that resource, as observed at 500 some point in the past (e.g., in a response to GET) or to be desired 501 at some point in the future (e.g., in a PUT request). 503 Most, but not all, representations transferred via HTTP are intended 504 to be a representation of the target resource (the resource 505 identified by the effective request URI). The precise semantics of a 506 representation are determined by the type of message (request or 507 response), the request method, the response status code, and the 508 representation metadata. For example, the above semantic is true for 509 the representation in any 200 (OK) response to GET and for the 510 representation in any PUT request. A 200 response to PUT, in 511 contrast, contains either a representation that describes the 512 successful action or a representation of the target resource, with 513 the latter indicated by a Content-Location header field with the same 514 value as the effective request URI. Likewise, response messages with 515 an error status code usually contain a representation that describes 516 the error and what next steps are suggested for resolving it. 518 4.1. Representation Header Fields 520 Representation header fields define metadata about the representation 521 data enclosed in the message-body or, if no message-body is present, 522 about the representation that would have been transferred in a 200 523 response to a simultaneous GET request with the same effective 524 request URI. 526 The following header fields are defined as representation metadata: 528 +-------------------+------------------------+ 529 | Header Field Name | Defined in... | 530 +-------------------+------------------------+ 531 | Content-Encoding | Section 6.5 | 532 | Content-Language | Section 6.6 | 533 | Content-Location | Section 6.7 | 534 | Content-Type | Section 6.8 | 535 | Expires | Section 3.3 of [Part6] | 536 | Last-Modified | Section 2.2 of [Part4] | 537 +-------------------+------------------------+ 539 4.2. Representation Data 541 The representation body associated with an HTTP message is either 542 provided as the payload body of the message or referred to by the 543 message semantics and the effective request URI. The representation 544 data is in a format and encoding defined by the representation 545 metadata header fields. 547 The data type of the representation data is determined via the header 548 fields Content-Type and Content-Encoding. These define a two-layer, 549 ordered encoding model: 551 representation-data := Content-Encoding( Content-Type( bits ) ) 553 Content-Type specifies the media type of the underlying data, which 554 defines both the data format and how that data SHOULD be processed by 555 the recipient (within the scope of the request method semantics). 556 Any HTTP/1.1 message containing a payload body SHOULD include a 557 Content-Type header field defining the media type of the associated 558 representation unless that metadata is unknown to the sender. If the 559 Content-Type header field is not present, it indicates that the 560 sender does not know the media type of the representation; recipients 561 MAY either assume that the media type is "application/octet-stream" 562 ([RFC2046], Section 4.5.1) or examine the content to determine its 563 type. 565 In practice, resource owners do not always properly configure their 566 origin server to provide the correct Content-Type for a given 567 representation, with the result that some clients will examine a 568 response body's content and override the specified type. Clients 569 that do so risk drawing incorrect conclusions, which might expose 570 additional security risks (e.g., "privilege escalation"). 571 Furthermore, it is impossible to determine the sender's intent by 572 examining the data format: many data formats match multiple media 573 types that differ only in processing semantics. Implementers are 574 encouraged to provide a means of disabling such "content sniffing" 575 when it is used. 577 Content-Encoding is used to indicate any additional content codings 578 applied to the data, usually for the purpose of data compression, 579 that are a property of the representation. If Content-Encoding is 580 not present, then there is no additional encoding beyond that defined 581 by the Content-Type. 583 5. Content Negotiation 585 HTTP responses include a representation which contains information 586 for interpretation, whether by a human user or for further 587 processing. Often, the server has different ways of representing the 588 same information; for example, in different formats, languages, or 589 using different character encodings. 591 HTTP clients and their users might have different or variable 592 capabilities, characteristics or preferences which would influence 593 which representation, among those available from the server, would be 594 best for the server to deliver. For this reason, HTTP provides 595 mechanisms for "content negotiation" -- a process of allowing 596 selection of a representation of a given resource, when more than one 597 is available. 599 This specification defines two patterns of content negotiation; 600 "server-driven", where the server selects the representation based 601 upon the client's stated preferences, and "agent-driven" negotiation, 602 where the server provides a list of representations for the client to 603 choose from, based upon their metadata. In addition, there are other 604 patterns: some applications use an "active content" pattern, where 605 the server returns active content which runs on the client and, based 606 on client available parameters, selects additional resources to 607 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 608 proposed. 610 These patterns are all widely used, and have trade-offs in 611 applicability and practicality. In particular, when the number of 612 preferences or capabilities to be expressed by a client are large 613 (such as when many different formats are supported by a user-agent), 614 server-driven negotiation becomes unwieldy, and might not be 615 appropriate. Conversely, when the number of representations to 616 choose from is very large, agent-driven negotiation might not be 617 appropriate. 619 Note that in all cases, the supplier of representations has the 620 responsibility for determining which representations might be 621 considered to be the "same information". 623 5.1. Server-driven Negotiation 625 If the selection of the best representation for a response is made by 626 an algorithm located at the server, it is called server-driven 627 negotiation. Selection is based on the available representations of 628 the response (the dimensions over which it can vary; e.g., language, 629 content-coding, etc.) and the contents of particular header fields in 630 the request message or on other information pertaining to the request 631 (such as the network address of the client). 633 Server-driven negotiation is advantageous when the algorithm for 634 selecting from among the available representations is difficult to 635 describe to the user agent, or when the server desires to send its 636 "best guess" to the client along with the first response (hoping to 637 avoid the round-trip delay of a subsequent request if the "best 638 guess" is good enough for the user). In order to improve the 639 server's guess, the user agent MAY include request header fields 640 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 641 preferences for such a response. 643 Server-driven negotiation has disadvantages: 645 1. It is impossible for the server to accurately determine what 646 might be "best" for any given user, since that would require 647 complete knowledge of both the capabilities of the user agent and 648 the intended use for the response (e.g., does the user want to 649 view it on screen or print it on paper?). 651 2. Having the user agent describe its capabilities in every request 652 can be both very inefficient (given that only a small percentage 653 of responses have multiple representations) and a potential 654 violation of the user's privacy. 656 3. It complicates the implementation of an origin server and the 657 algorithms for generating responses to a request. 659 4. It might limit a public cache's ability to use the same response 660 for multiple user's requests. 662 Server-driven negotiation allows the user agent to specify its 663 preferences, but it cannot expect responses to always honour them. 664 For example, the origin server might not implement server-driven 665 negotiation, or it might decide that sending a response that doesn't 666 conform to them is better than sending a 406 (Not Acceptable) 667 response. 669 Many of the mechanisms for expressing preferences use quality values 670 to declare relative preference. See Section 5.3 of [Part1] for more 671 information. 673 HTTP/1.1 includes the following header fields for enabling server- 674 driven negotiation through description of user agent capabilities and 675 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 676 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 677 User-Agent (Section 9.10 of [Part2]). However, an origin server is 678 not limited to these dimensions and MAY vary the response based on 679 any aspect of the request, including aspects of the connection (e.g., 680 IP address) or information within extension header fields not defined 681 by this specification. 683 Note: In practice, User-Agent based negotiation is fragile, 684 because new clients might not be recognized. 686 The Vary header field (Section 3.5 of [Part6]) can be used to express 687 the parameters the server uses to select a representation that is 688 subject to server-driven negotiation. 690 5.2. Agent-driven Negotiation 692 With agent-driven negotiation, selection of the best representation 693 for a response is performed by the user agent after receiving an 694 initial response from the origin server. Selection is based on a 695 list of the available representations of the response included within 696 the header fields or body of the initial response, with each 697 representation identified by its own URI. Selection from among the 698 representations can be performed automatically (if the user agent is 699 capable of doing so) or manually by the user selecting from a 700 generated (possibly hypertext) menu. 702 Agent-driven negotiation is advantageous when the response would vary 703 over commonly-used dimensions (such as type, language, or encoding), 704 when the origin server is unable to determine a user agent's 705 capabilities from examining the request, and generally when public 706 caches are used to distribute server load and reduce network usage. 708 Agent-driven negotiation suffers from the disadvantage of needing a 709 second request to obtain the best alternate representation. This 710 second request is only efficient when caching is used. In addition, 711 this specification does not define any mechanism for supporting 712 automatic selection, though it also does not prevent any such 713 mechanism from being developed as an extension and used within 714 HTTP/1.1. 716 This specification defines the 300 (Multiple Choices) and 406 (Not 717 Acceptable) status codes for enabling agent-driven negotiation when 718 the server is unwilling or unable to provide a varying response using 719 server-driven negotiation. 721 6. Header Field Definitions 723 This section defines the syntax and semantics of HTTP/1.1 header 724 fields related to the payload of messages. 726 6.1. Accept 728 The "Accept" header field can be used by user agents to specify 729 response media types that are acceptable. Accept header fields can 730 be used to indicate that the request is specifically limited to a 731 small set of desired types, as in the case of a request for an in- 732 line image. 734 Accept = #( 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 5.3 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 A request without any Accept header field implies that the user agent 773 will accept any media type in response. If an Accept header field is 774 present in a request and none of the available representations for 775 the response have a media type that is listed as acceptable, the 776 origin server MAY either honor the Accept header field by sending a 777 406 (Not Acceptable) response or disregard the Accept header field by 778 treating the response as if it is not subject to content negotiation. 780 A more elaborate example is 782 Accept: text/plain; q=0.5, text/html, 783 text/x-dvi; q=0.8, text/x-c 785 Verbally, this would be interpreted as "text/html and text/x-c are 786 the preferred media types, but if they do not exist, then send the 787 text/x-dvi representation, and if that does not exist, send the text/ 788 plain representation". 790 Media ranges can be overridden by more specific media ranges or 791 specific media types. If more than one media range applies to a 792 given type, the most specific reference has precedence. For example, 794 Accept: text/*, text/plain, text/plain;format=flowed, */* 796 have the following precedence: 798 1. text/plain;format=flowed 800 2. text/plain 802 3. text/* 804 4. */* 806 The media type quality factor associated with a given type is 807 determined by finding the media range with the highest precedence 808 which matches that type. For example, 810 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 811 text/html;level=2;q=0.4, */*;q=0.5 813 would cause the following values to be associated: 815 +-------------------+---------------+ 816 | Media Type | Quality Value | 817 +-------------------+---------------+ 818 | text/html;level=1 | 1 | 819 | text/html | 0.7 | 820 | text/plain | 0.3 | 821 | image/jpeg | 0.5 | 822 | text/html;level=2 | 0.4 | 823 | text/html;level=3 | 0.7 | 824 +-------------------+---------------+ 826 Note: A user agent might be provided with a default set of quality 827 values for certain media ranges. However, unless the user agent is a 828 closed system which cannot interact with other rendering agents, this 829 default set ought to be configurable by the user. 831 6.2. Accept-Charset 833 The "Accept-Charset" header field can be used by user agents to 834 indicate what character encodings are acceptable in a response 835 payload. This field allows clients capable of understanding more 836 comprehensive or special-purpose character encodings to signal that 837 capability to a server which is capable of representing documents in 838 those character encodings. 840 Accept-Charset = 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 which is not mentioned elsewhere in 852 the Accept-Charset field. If no "*" is present in an Accept-Charset 853 field, then all character encodings not explicitly mentioned get a 854 quality value of 0. 856 A request without any Accept-Charset header field implies that the 857 user agent will accept any character encoding in response. If an 858 Accept-Charset header field is present in a request and none of the 859 available representations for the response have a character encoding 860 that is listed as acceptable, the origin server MAY either honor the 861 Accept-Charset header field by sending a 406 (Not Acceptable) 862 response or disregard the Accept-Charset header field by treating the 863 response as if it is not subject to content negotiation. 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. An "identity" token is used as a synonym for "no 870 encoding" in order to communicate when no encoding is preferred. 872 Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) 873 codings = content-coding / "identity" / "*" 875 Each codings value MAY be given an associated quality value which 876 represents the preference for that encoding. The default value is 877 q=1. 879 For example, 881 Accept-Encoding: compress, gzip 882 Accept-Encoding: 883 Accept-Encoding: * 884 Accept-Encoding: compress;q=0.5, gzip;q=1.0 885 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 887 A server tests whether a content-coding for a given representation is 888 acceptable, according to an Accept-Encoding field, using these rules: 890 1. The special "*" symbol in an Accept-Encoding field matches any 891 available content-coding not explicitly listed in the header 892 field. 894 2. If the representation has no content-coding, then it is 895 acceptable by default unless specifically excluded by the Accept- 896 Encoding field stating either "identity;q=0" or "*;q=0" without a 897 more specific entry for "identity". 899 3. If the representation's content-coding is one of the content- 900 codings listed in the Accept-Encoding field, then it is 901 acceptable unless it is accompanied by a qvalue of 0. (As 902 defined in Section 5.3 of [Part1], a qvalue of 0 means "not 903 acceptable".) 905 4. If multiple content-codings are acceptable, then the acceptable 906 content-coding with the highest non-zero qvalue is preferred. 908 An Accept-Encoding header field with a combined field-value that is 909 empty implies that the user agent does not want any content-coding in 910 response. If an Accept-Encoding header field is present in a request 911 and none of the available representations for the response have a 912 content-coding that is listed as acceptable, the origin server SHOULD 913 send a response without any content-coding. 915 A request without an Accept-Encoding header field implies that the 916 user agent will accept any content-coding in response, but a 917 representation without content-coding is preferred for compatibility 918 with the widest variety of user agents. 920 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 921 associated with content-codings. This means that qvalues will not 922 work and are not permitted with x-gzip or x-compress. 924 6.4. Accept-Language 926 The "Accept-Language" header field can be used by user agents to 927 indicate the set of natural languages that are preferred in the 928 response. Language tags are defined in Section 2.4. 930 Accept-Language = 931 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 932 language-range = 933 935 Each language-range can be given an associated quality value which 936 represents an estimate of the user's preference for the languages 937 specified by that range. The quality value defaults to "q=1". For 938 example, 939 Accept-Language: da, en-gb;q=0.8, en;q=0.7 941 would mean: "I prefer Danish, but will accept British English and 942 other types of English". (see also Section 2.3 of [RFC4647]) 944 For matching, Section 3 of [RFC4647] defines several matching 945 schemes. Implementations can offer the most appropriate matching 946 scheme for their requirements. 948 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 949 identical to the matching scheme that was previously defined in 950 Section 14.4 of [RFC2616]. 952 It might be contrary to the privacy expectations of the user to send 953 an Accept-Language header field with the complete linguistic 954 preferences of the user in every request. For a discussion of this 955 issue, see Section 8.1. 957 As intelligibility is highly dependent on the individual user, it is 958 recommended that client applications make the choice of linguistic 959 preference available to the user. If the choice is not made 960 available, then the Accept-Language header field MUST NOT be given in 961 the request. 963 Note: When making the choice of linguistic preference available to 964 the user, we remind implementors of the fact that users are not 965 familiar with the details of language matching as described above, 966 and ought to be provided appropriate guidance. As an example, 967 users might assume that on selecting "en-gb", they will be served 968 any kind of English document if British English is not available. 969 A user agent might suggest in such a case to add "en" to get the 970 best matching behavior. 972 6.5. Content-Encoding 974 The "Content-Encoding" header field indicates what content-codings 975 have been applied to the representation beyond those inherent in the 976 media type, and thus what decoding mechanisms must be applied in 977 order to obtain the media-type referenced by the Content-Type header 978 field. Content-Encoding is primarily used to allow a representation 979 to be compressed without losing the identity of its underlying media 980 type. 982 Content-Encoding = 1#content-coding 984 Content codings are defined in Section 2.2. An example of its use is 986 Content-Encoding: gzip 988 The content-coding is a characteristic of the representation. 989 Typically, the representation body is stored with this encoding and 990 is only decoded before rendering or analogous usage. However, a 991 transforming proxy MAY modify the content-coding if the new coding is 992 known to be acceptable to the recipient, unless the "no-transform" 993 cache-control directive is present in the message. 995 If the media type includes an inherent encoding, such as a data 996 format that is always compressed, then that encoding would not be 997 restated as a Content-Encoding even if it happens to be the same 998 algorithm as one of the content-codings. Such a content-coding would 999 only be listed if, for some bizarre reason, it is applied a second 1000 time to form the representation. Likewise, an origin server might 1001 choose to publish the same payload data as multiple representations 1002 that differ only in whether the coding is defined as part of Content- 1003 Type or Content-Encoding, since some user agents will behave 1004 differently in their handling of each response (e.g., open a "Save as 1005 ..." dialog instead of automatic decompression and rendering of 1006 content). 1008 A representation that has a content-coding applied to it MUST include 1009 a Content-Encoding header field (Section 6.5) that lists the content- 1010 coding(s) applied. 1012 If multiple encodings have been applied to a representation, the 1013 content codings MUST be listed in the order in which they were 1014 applied. Additional information about the encoding parameters MAY be 1015 provided by other header fields not defined by this specification. 1017 If the content-coding of a representation in a request message is not 1018 acceptable to the origin server, the server SHOULD respond with a 1019 status code of 415 (Unsupported Media Type). 1021 6.6. Content-Language 1023 The "Content-Language" header field describes the natural language(s) 1024 of the intended audience for the representation. Note that this 1025 might not be equivalent to all the languages used within the 1026 representation. 1028 Content-Language = 1#language-tag 1030 Language tags are defined in Section 2.4. The primary purpose of 1031 Content-Language is to allow a user to identify and differentiate 1032 representations according to the user's own preferred language. 1033 Thus, if the body content is intended only for a Danish-literate 1034 audience, the appropriate field is 1035 Content-Language: da 1037 If no Content-Language is specified, the default is that the content 1038 is intended for all language audiences. This might mean that the 1039 sender does not consider it to be specific to any natural language, 1040 or that the sender does not know for which language it is intended. 1042 Multiple languages MAY be listed for content that is intended for 1043 multiple audiences. For example, a rendition of the "Treaty of 1044 Waitangi", presented simultaneously in the original Maori and English 1045 versions, would call for 1047 Content-Language: mi, en 1049 However, just because multiple languages are present within a 1050 representation does not mean that it is intended for multiple 1051 linguistic audiences. An example would be a beginner's language 1052 primer, such as "A First Lesson in Latin", which is clearly intended 1053 to be used by an English-literate audience. In this case, the 1054 Content-Language would properly only include "en". 1056 Content-Language MAY be applied to any media type -- it is not 1057 limited to textual documents. 1059 6.7. Content-Location 1061 The "Content-Location" header field supplies a URI that can be used 1062 as a specific identifier for the representation in this message. In 1063 other words, if one were to perform a GET on this URI at the time of 1064 this message's generation, then a 200 response would contain the same 1065 representation that is enclosed as payload in this message. 1067 Content-Location = absolute-URI / partial-URI 1069 The Content-Location value is not a replacement for the effective 1070 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1071 It has the same syntax and semantics as the header field of the same 1072 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1073 its appearance in an HTTP message has some special implications for 1074 HTTP recipients. 1076 If Content-Location is included in a response message and its value 1077 is the same as the effective request URI, then the response payload 1078 SHOULD be considered the current representation of that resource. 1079 For a GET or HEAD request, this is the same as the default semantics 1080 when no Content-Location is provided by the server. For a state- 1081 changing request like PUT or POST, it implies that the server's 1082 response contains the new representation of that resource, thereby 1083 distinguishing it from representations that might only report about 1084 the action (e.g., "It worked!"). This allows authoring applications 1085 to update their local copies without the need for a subsequent GET 1086 request. 1088 If Content-Location is included in a response message and its value 1089 differs from the effective request URI, then the origin server is 1090 informing recipients that this representation has its own, presumably 1091 more specific, identifier. For a GET or HEAD request, this is an 1092 indication that the effective request URI identifies a resource that 1093 is subject to content negotiation and the representation selected for 1094 this response can also be found at the identified URI. For other 1095 methods, such a Content-Location indicates that this representation 1096 contains a report on the action's status and the same report is 1097 available (for future access with GET) at the given URI. For 1098 example, a purchase transaction made via a POST request might include 1099 a receipt document as the payload of the 200 response; the Content- 1100 Location value provides an identifier for retrieving a copy of that 1101 same receipt in the future. 1103 If Content-Location is included in a request message, then it MAY be 1104 interpreted by the origin server as an indication of where the user 1105 agent originally obtained the content of the enclosed representation 1106 (prior to any subsequent modification of the content by that user 1107 agent). In other words, the user agent is providing the same 1108 representation metadata that it received with the original 1109 representation. However, such interpretation MUST NOT be used to 1110 alter the semantics of the method requested by the client. For 1111 example, if a client makes a PUT request on a negotiated resource and 1112 the origin server accepts that PUT (without redirection), then the 1113 new set of values for that resource is expected to be consistent with 1114 the one representation supplied in that PUT; the Content-Location 1115 cannot be used as a form of reverse content selection that identifies 1116 only one of the negotiated representations to be updated. If the 1117 user agent had wanted the latter semantics, it would have applied the 1118 PUT directly to the Content-Location URI. 1120 A Content-Location field received in a request message is transitory 1121 information that SHOULD NOT be saved with other representation 1122 metadata for use in later responses. The Content-Location's value 1123 might be saved for use in other contexts, such as within source links 1124 or other metadata. 1126 A cache cannot assume that a representation with a Content-Location 1127 different from the URI used to retrieve it can be used to respond to 1128 later requests on that Content-Location URI. 1130 If the Content-Location value is a partial URI, the partial URI is 1131 interpreted relative to the effective request URI. 1133 6.8. Content-Type 1135 The "Content-Type" header field indicates the media type of the 1136 representation. In the case of responses to the HEAD method, the 1137 media type is that which would have been sent had the request been a 1138 GET. 1140 Content-Type = media-type 1142 Media types are defined in Section 2.3. An example of the field is 1144 Content-Type: text/html; charset=ISO-8859-4 1146 Further discussion of Content-Type is provided in Section 4.2. 1148 7. IANA Considerations 1150 7.1. Header Field Registration 1152 The Message Header Field Registry located at shall be 1154 updated with the permanent registrations below (see [RFC3864]): 1156 +-------------------+----------+----------+--------------+ 1157 | Header Field Name | Protocol | Status | Reference | 1158 +-------------------+----------+----------+--------------+ 1159 | Accept | http | standard | Section 6.1 | 1160 | Accept-Charset | http | standard | Section 6.2 | 1161 | Accept-Encoding | http | standard | Section 6.3 | 1162 | Accept-Language | http | standard | Section 6.4 | 1163 | Content-Encoding | http | standard | Section 6.5 | 1164 | Content-Language | http | standard | Section 6.6 | 1165 | Content-Location | http | standard | Section 6.7 | 1166 | Content-Type | http | standard | Section 6.8 | 1167 | MIME-Version | http | standard | Appendix A.1 | 1168 +-------------------+----------+----------+--------------+ 1170 The change controller is: "IETF (iesg@ietf.org) - Internet 1171 Engineering Task Force". 1173 7.2. Content Coding Registry 1175 The registration procedure for HTTP Content Codings is now defined by 1176 Section 2.2.1 of this document. 1178 The HTTP Content Codings Registry located at 1179 shall be updated 1180 with the registration below: 1182 +----------+-----------------------------------------+--------------+ 1183 | Name | Description | Reference | 1184 +----------+-----------------------------------------+--------------+ 1185 | compress | UNIX "compress" program method | Section | 1186 | | | 5.1.2.1 of | 1187 | | | [Part1] | 1188 | deflate | "deflate" compression mechanism | Section | 1189 | | ([RFC1951]) used inside the "zlib" data | 5.1.2.2 of | 1190 | | format ([RFC1950]) | [Part1] | 1191 | gzip | Same as GNU zip [RFC1952] | Section | 1192 | | | 5.1.2.3 of | 1193 | | | [Part1] | 1194 | identity | reserved (synonym for "no encoding" in | Section 6.3 | 1195 | | Accept-Encoding header field) | | 1196 +----------+-----------------------------------------+--------------+ 1198 8. Security Considerations 1200 This section is meant to inform application developers, information 1201 providers, and users of the security limitations in HTTP/1.1 as 1202 described by this document. The discussion does not include 1203 definitive solutions to the problems revealed, though it does make 1204 some suggestions for reducing security risks. 1206 8.1. Privacy Issues Connected to Accept Header Fields 1208 Accept headers fields can reveal information about the user to all 1209 servers which are accessed. The Accept-Language header field in 1210 particular can reveal information the user would consider to be of a 1211 private nature, because the understanding of particular languages is 1212 often strongly correlated to the membership of a particular ethnic 1213 group. User agents which offer the option to configure the contents 1214 of an Accept-Language header field to be sent in every request are 1215 strongly encouraged to let the configuration process include a 1216 message which makes the user aware of the loss of privacy involved. 1218 An approach that limits the loss of privacy would be for a user agent 1219 to omit the sending of Accept-Language header fields by default, and 1220 to ask the user whether or not to start sending Accept-Language 1221 header fields to a server if it detects, by looking for any Vary 1222 header fields generated by the server, that such sending could 1223 improve the quality of service. 1225 Elaborate user-customized accept header fields sent in every request, 1226 in particular if these include quality values, can be used by servers 1227 as relatively reliable and long-lived user identifiers. Such user 1228 identifiers would allow content providers to do click-trail tracking, 1229 and would allow collaborating content providers to match cross-server 1230 click-trails or form submissions of individual users. Note that for 1231 many users not behind a proxy, the network address of the host 1232 running the user agent will also serve as a long-lived user 1233 identifier. In environments where proxies are used to enhance 1234 privacy, user agents ought to be conservative in offering accept 1235 header configuration options to end users. As an extreme privacy 1236 measure, proxies could filter the accept header fields in relayed 1237 requests. General purpose user agents which provide a high degree of 1238 header configurability SHOULD warn users about the loss of privacy 1239 which can be involved. 1241 9. Acknowledgments 1243 See Section 11 of [Part1]. 1245 10. References 1247 10.1. Normative References 1249 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1250 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1251 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1252 and Message Parsing", draft-ietf-httpbis-p1-messaging-17 1253 (work in progress), October 2011. 1255 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1256 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1257 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1258 Semantics", draft-ietf-httpbis-p2-semantics-17 (work in 1259 progress), October 2011. 1261 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1262 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1263 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1264 Requests", draft-ietf-httpbis-p4-conditional-17 (work in 1265 progress), October 2011. 1267 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1268 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1269 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1270 Partial Responses", draft-ietf-httpbis-p5-range-17 (work 1271 in progress), October 2011. 1273 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1274 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1275 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1276 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in 1277 progress), October 2011. 1279 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1280 Specification version 3.3", RFC 1950, May 1996. 1282 RFC 1950 is an Informational RFC, thus it might be less 1283 stable than this specification. On the other hand, this 1284 downward reference was present since the publication of 1285 RFC 2068 in 1997, therefore it is unlikely to cause 1286 problems in practice. See also [BCP97]. 1288 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1289 version 1.3", RFC 1951, May 1996. 1291 RFC 1951 is an Informational RFC, thus it might be less 1292 stable than this specification. On the other hand, this 1293 downward reference was present since the publication of 1294 RFC 2068 in 1997, therefore it is unlikely to cause 1295 problems in practice. See also [BCP97]. 1297 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1298 Randers-Pehrson, "GZIP file format specification version 1299 4.3", RFC 1952, May 1996. 1301 RFC 1952 is an Informational RFC, thus it might be less 1302 stable than this specification. On the other hand, this 1303 downward reference was present since the publication of 1304 RFC 2068 in 1997, therefore it is unlikely to cause 1305 problems in practice. See also [BCP97]. 1307 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1308 Extensions (MIME) Part One: Format of Internet Message 1309 Bodies", RFC 2045, November 1996. 1311 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1312 Extensions (MIME) Part Two: Media Types", RFC 2046, 1313 November 1996. 1315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1316 Requirement Levels", BCP 14, RFC 2119, March 1997. 1318 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1319 Tags", BCP 47, RFC 4647, September 2006. 1321 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1322 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1324 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1325 Languages", BCP 47, RFC 5646, September 2009. 1327 10.2. Informative References 1329 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 1330 to Standards-Track Documents", BCP 97, RFC 4897, 1331 June 2007. 1333 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1334 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1336 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1337 Extensions (MIME) Part Five: Conformance Criteria and 1338 Examples", RFC 2049, November 1996. 1340 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1341 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1342 RFC 2068, January 1997. 1344 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1345 February 1997. 1347 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1348 Languages", BCP 18, RFC 2277, January 1998. 1350 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1351 in HTTP", RFC 2295, March 1998. 1353 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1354 form-data", RFC 2388, August 1998. 1356 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1357 "MIME Encapsulation of Aggregate Documents, such as HTML 1358 (MHTML)", RFC 2557, March 1999. 1360 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1361 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1362 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1364 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1365 10646", STD 63, RFC 3629, November 2003. 1367 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1368 Procedures for Message Header Fields", BCP 90, RFC 3864, 1369 September 2004. 1371 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1372 Registration Procedures", BCP 13, RFC 4288, December 2005. 1374 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1375 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1376 May 2008. 1378 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1379 October 2008. 1381 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1382 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1383 RFC 6151, March 2011. 1385 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1386 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1387 June 2011. 1389 Appendix A. Differences between HTTP and MIME 1391 HTTP/1.1 uses many of the constructs defined for Internet Mail 1392 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1393 [RFC2045]) to allow a message-body to be transmitted in an open 1394 variety of representations and with extensible mechanisms. However, 1395 RFC 2045 discusses mail, and HTTP has a few features that are 1396 different from those described in MIME. These differences were 1397 carefully chosen to optimize performance over binary connections, to 1398 allow greater freedom in the use of new media types, to make date 1399 comparisons easier, and to acknowledge the practice of some early 1400 HTTP servers and clients. 1402 This appendix describes specific areas where HTTP differs from MIME. 1403 Proxies and gateways to strict MIME environments SHOULD be aware of 1404 these differences and provide the appropriate conversions where 1405 necessary. Proxies and gateways from MIME environments to HTTP also 1406 need to be aware of the differences because some conversions might be 1407 required. 1409 A.1. MIME-Version 1411 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1412 MAY include a single MIME-Version header field to indicate what 1413 version of the MIME protocol was used to construct the message. Use 1414 of the MIME-Version header field indicates that the message is in 1415 full compliance with the MIME protocol (as defined in [RFC2045]). 1416 Proxies/gateways are responsible for ensuring full compliance (where 1417 possible) when exporting HTTP messages to strict MIME environments. 1419 MIME-Version = 1*DIGIT "." 1*DIGIT 1421 MIME version "1.0" is the default for use in HTTP/1.1. However, 1422 HTTP/1.1 message parsing and semantics are defined by this document 1423 and not the MIME specification. 1425 A.2. Conversion to Canonical Form 1427 MIME requires that an Internet mail body-part be converted to 1428 canonical form prior to being transferred, as described in Section 4 1429 of [RFC2049]. Section 2.3.1 of this document describes the forms 1430 allowed for subtypes of the "text" media type when transmitted over 1431 HTTP. [RFC2046] requires that content with a type of "text" 1432 represent line breaks as CRLF and forbids the use of CR or LF outside 1433 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1434 indicate a line break within text content when a message is 1435 transmitted over HTTP. 1437 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1438 environment SHOULD translate all line breaks within the text media 1439 types described in Section 2.3.1 of this document to the RFC 2049 1440 canonical form of CRLF. Note, however, that this might be 1441 complicated by the presence of a Content-Encoding and by the fact 1442 that HTTP allows the use of some character encodings which do not use 1443 octets 13 and 10 to represent CR and LF, respectively, as is the case 1444 for some multi-byte character encodings. 1446 Conversion will break any cryptographic checksums applied to the 1447 original content unless the original content is already in canonical 1448 form. Therefore, the canonical form is recommended for any content 1449 that uses such checksums in HTTP. 1451 A.3. Conversion of Date Formats 1453 HTTP/1.1 uses a restricted set of date formats (Section 8 of [Part2]) 1454 to simplify the process of date comparison. Proxies and gateways 1455 from other protocols SHOULD ensure that any Date header field present 1456 in a message conforms to one of the HTTP/1.1 formats and rewrite the 1457 date if necessary. 1459 A.4. Introduction of Content-Encoding 1461 MIME does not include any concept equivalent to HTTP/1.1's Content- 1462 Encoding header field. Since this acts as a modifier on the media 1463 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1464 either change the value of the Content-Type header field or decode 1465 the representation before forwarding the message. (Some experimental 1466 applications of Content-Type for Internet mail have used a media-type 1467 parameter of ";conversions=" to perform a function 1468 equivalent to Content-Encoding. However, this parameter is not part 1469 of the MIME standards). 1471 A.5. No Content-Transfer-Encoding 1473 HTTP does not use the Content-Transfer-Encoding field of MIME. 1474 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1475 remove any Content-Transfer-Encoding prior to delivering the response 1476 message to an HTTP client. 1478 Proxies and gateways from HTTP to MIME-compliant protocols are 1479 responsible for ensuring that the message is in the correct format 1480 and encoding for safe transport on that protocol, where "safe 1481 transport" is defined by the limitations of the protocol being used. 1482 Such a proxy or gateway SHOULD label the data with an appropriate 1483 Content-Transfer-Encoding if doing so will improve the likelihood of 1484 safe transport over the destination protocol. 1486 A.6. Introduction of Transfer-Encoding 1488 HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.6 1489 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1490 to forwarding a message via a MIME-compliant protocol. 1492 A.7. MHTML and Line Length Limitations 1494 HTTP implementations which share code with MHTML [RFC2557] 1495 implementations need to be aware of MIME line length limitations. 1496 Since HTTP does not have this limitation, HTTP does not fold long 1497 lines. MHTML messages being transported by HTTP follow all 1498 conventions of MHTML, including line length limitations and folding, 1499 canonicalization, etc., since HTTP transports all message-bodies as 1500 payload (see Section 2.3.2) and does not interpret the content or any 1501 MIME header lines that might be contained therein. 1503 Appendix B. Additional Features 1505 [RFC1945] and [RFC2068] document protocol elements used by some 1506 existing HTTP implementations, but not consistently and correctly 1507 across most HTTP/1.1 applications. Implementors are advised to be 1508 aware of these features, but cannot rely upon their presence in, or 1509 interoperability with, other HTTP/1.1 applications. Some of these 1510 describe proposed experimental features, and some describe features 1511 that experimental deployment found lacking that are now addressed in 1512 the base HTTP/1.1 specification. 1514 A number of other header fields, such as Content-Disposition and 1515 Title, from SMTP and MIME are also often implemented (see [RFC6266] 1516 and [RFC2076]). 1518 Appendix C. Changes from RFC 2616 1520 Clarify contexts that charset is used in. (Section 2.1) 1522 Remove the default character encoding for text media types; the 1523 default now is whatever the media type definition says. 1524 (Section 2.3.1) 1526 Change ABNF productions for header fields to only define the field 1527 value. (Section 6) 1529 Remove definition of Content-MD5 header field because it was 1530 inconsistently implemented with respect to partial responses, and 1531 also because of known deficiencies in the hash algorithm itself (see 1532 [RFC6151] for details). (Section 6) 1534 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) 1536 Remove base URI setting semantics for Content-Location due to poor 1537 implementation support, which was caused by too many broken servers 1538 emitting bogus Content-Location header fields, and also the 1539 potentially undesirable effect of potentially breaking relative links 1540 in content-negotiated resources. (Section 6.7) 1542 Remove discussion of Content-Disposition header field, it is now 1543 defined by [RFC6266]. (Appendix B) 1545 Remove reference to non-existant identity transfer-coding value 1546 tokens. (Appendix A.5) 1548 Appendix D. Collected ABNF 1550 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1551 OWS media-range [ accept-params ] ] ) ] 1552 Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1553 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1554 qvalue ] ] ) 1555 Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) 1556 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1557 Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1558 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1559 ] ) 1561 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 1562 content-coding ] ) 1563 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 1564 language-tag ] ) 1565 Content-Location = absolute-URI / partial-URI 1566 Content-Type = media-type 1568 MIME-Version = 1*DIGIT "." 1*DIGIT 1570 OWS = 1572 absolute-URI = 1573 accept-ext = OWS ";" OWS token [ "=" word ] 1574 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1575 attribute = token 1577 charset = token 1578 codings = content-coding / "identity" / "*" 1579 content-coding = token 1581 language-range = 1582 language-tag = 1584 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1585 ";" OWS parameter ) 1586 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1588 parameter = attribute "=" value 1589 partial-URI = 1591 qvalue = 1593 subtype = token 1595 token = 1596 type = token 1598 value = word 1600 word = 1602 ABNF diagnostics: 1604 ; Accept defined but not used 1605 ; Accept-Charset defined but not used 1606 ; Accept-Encoding defined but not used 1607 ; Accept-Language defined but not used 1608 ; Content-Encoding defined but not used 1609 ; Content-Language defined but not used 1610 ; Content-Location defined but not used 1611 ; Content-Type defined but not used 1612 ; MIME-Version defined but not used 1614 Appendix E. Change Log (to be removed by RFC Editor before publication) 1616 E.1. Since RFC 2616 1618 Extracted relevant partitions from [RFC2616]. 1620 E.2. Since draft-ietf-httpbis-p3-payload-00 1622 Closed issues: 1624 o : "Media Type 1625 Registrations" () 1627 o : "Clarification 1628 regarding quoting of charset values" 1629 () 1631 o : "Remove 1632 'identity' token references" 1633 () 1635 o : "Accept- 1636 Encoding BNF" 1638 o : "Normative and 1639 Informative references" 1641 o : "RFC1700 1642 references" 1644 o : "Updating to 1645 RFC4288" 1647 o : "Informative 1648 references" 1650 o : "ISO-8859-1 1651 Reference" 1653 o : "Encoding 1654 References Normative" 1656 o : "Normative up- 1657 to-date references" 1659 E.3. Since draft-ietf-httpbis-p3-payload-01 1661 Ongoing work on ABNF conversion 1662 (): 1664 o Add explicit references to BNF syntax and rules imported from 1665 other parts of the specification. 1667 E.4. Since draft-ietf-httpbis-p3-payload-02 1669 Closed issues: 1671 o : "Quoting 1672 Charsets" 1674 o : 1675 "Classification for Allow header" 1677 o : "missing 1678 default for qvalue in description of Accept-Encoding" 1680 Ongoing work on IANA Message Header Field Registration 1681 (): 1683 o Reference RFC 3984, and update header field registrations for 1684 headers defined in this document. 1686 E.5. Since draft-ietf-httpbis-p3-payload-03 1688 Closed issues: 1690 o : "Quoting 1691 Charsets" 1693 o : "language tag 1694 matching (Accept-Language) vs RFC4647" 1696 o : "RFC 1806 has 1697 been replaced by RFC2183" 1699 Other changes: 1701 o : "Encoding 1702 References Normative" -- rephrase the annotation and reference 1703 [BCP97]. 1705 E.6. Since draft-ietf-httpbis-p3-payload-04 1707 Closed issues: 1709 o : "RFC 2822 is 1710 updated by RFC 5322" 1712 Ongoing work on ABNF conversion 1713 (): 1715 o Use "/" instead of "|" for alternatives. 1717 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1718 whitespace ("OWS") and required whitespace ("RWS"). 1720 o Rewrite ABNFs to spell out whitespace rules, factor out header 1721 field value format definitions. 1723 E.7. Since draft-ietf-httpbis-p3-payload-05 1725 Closed issues: 1727 o : "Join 1728 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1730 Final work on ABNF conversion 1731 (): 1733 o Add appendix containing collected and expanded ABNF, reorganize 1734 ABNF introduction. 1736 Other changes: 1738 o Move definition of quality values into Part 1. 1740 E.8. Since draft-ietf-httpbis-p3-payload-06 1742 Closed issues: 1744 o : "Content- 1745 Location isn't special" 1747 o : "Content 1748 Sniffing" 1750 E.9. Since draft-ietf-httpbis-p3-payload-07 1752 Closed issues: 1754 o : "Updated 1755 reference for language tags" 1757 o : "Clarify rules 1758 for determining what entities a response carries" 1760 o : "Content- 1761 Location base-setting problems" 1763 o : "Content 1764 Sniffing" 1766 o : "pick IANA 1767 policy (RFC5226) for Transfer Coding / Content Coding" 1769 o : "move 1770 definitions of gzip/deflate/compress to part 1" 1772 Partly resolved issues: 1774 o : "update IANA 1775 requirements wrt Transfer-Coding values" (add the IANA 1776 Considerations subsection) 1778 o : "update IANA 1779 requirements wrt Content-Coding values" (add the IANA 1780 Considerations subsection) 1782 E.10. Since draft-ietf-httpbis-p3-payload-08 1784 Closed issues: 1786 o : "Content 1787 Negotiation for media types" 1789 o : "Accept- 1790 Language: which RFC4647 filtering?" 1792 E.11. Since draft-ietf-httpbis-p3-payload-09 1794 Closed issues: 1796 o : "MIME-Version 1797 not listed in P1, general header fields" 1799 o : "IANA registry 1800 for content/transfer encodings" 1802 o : "Content 1803 Sniffing" 1805 o : "use of term 1806 "word" when talking about header structure" 1808 Partly resolved issues: 1810 o : "Term for the 1811 requested resource's URI" 1813 E.12. Since draft-ietf-httpbis-p3-payload-10 1815 Closed issues: 1817 o : "Clarify 1818 'Requested Variant'" 1820 o : "Content- 1821 Location isn't special" 1823 o : "Delimiting 1824 messages with multipart/byteranges" 1826 o : "Clarify 1827 entity / representation / variant terminology" 1829 o : "confusing 1830 req. language for Content-Location" 1832 o : "Content- 1833 Location on 304 responses" 1835 o : "'requested 1836 resource' in content-encoding definition" 1838 o : "consider 1839 removing the 'changes from 2068' sections" 1841 Partly resolved issues: 1843 o : "Content-MD5 1844 and partial responses" 1846 E.13. Since draft-ietf-httpbis-p3-payload-11 1848 Closed issues: 1850 o : "Factor out 1851 Content-Disposition" 1853 E.14. Since draft-ietf-httpbis-p3-payload-12 1855 Closed issues: 1857 o : "Header 1858 Classification" 1860 o : "untangle 1861 ABNFs for header fields" 1863 o : "potentially 1864 misleading MAY in media-type def" 1866 E.15. Since draft-ietf-httpbis-p3-payload-13 1868 Closed issues: 1870 o : "Default 1871 charsets for text media types" 1873 o : "Content-MD5 1874 and partial responses" 1876 o : "untangle 1877 ABNFs for header fields" 1879 o : "confusing 1880 undefined parameter in media range example" 1882 E.16. Since draft-ietf-httpbis-p3-payload-14 1884 None. 1886 E.17. Since draft-ietf-httpbis-p3-payload-15 1888 Closed issues: 1890 o : "Strength of 1891 requirements on Accept re: 406" 1893 E.18. Since draft-ietf-httpbis-p3-payload-16 1895 Closed issues: 1897 o : "Document 1898 HTTP's error-handling philosophy" 1900 Index 1902 A 1903 Accept header field 16 1904 Accept-Charset header field 18 1905 Accept-Encoding header field 19 1906 Accept-Language header field 20 1908 C 1909 Coding Format 1910 compress 7 1911 deflate 7 1912 gzip 8 1913 compress (Coding Format) 7 1914 content negotiation 5 1915 Content-Encoding header field 21 1916 Content-Language header field 22 1917 Content-Location header field 23 1918 Content-Type header field 25 1920 D 1921 deflate (Coding Format) 7 1923 G 1924 Grammar 1925 Accept 16 1926 Accept-Charset 18 1927 Accept-Encoding 19 1928 accept-ext 16 1929 Accept-Language 20 1930 accept-params 16 1931 attribute 8 1932 charset 7 1933 codings 19 1934 content-coding 7 1935 Content-Encoding 21 1936 Content-Language 22 1937 Content-Location 23 1938 Content-Type 25 1939 language-range 20 1940 language-tag 10 1941 media-range 16 1942 media-type 8 1943 MIME-Version 30 1944 parameter 8 1945 subtype 8 1946 type 8 1947 value 8 1948 gzip (Coding Format) 8 1950 H 1951 Header Fields 1952 Accept 16 1953 Accept-Charset 18 1954 Accept-Encoding 19 1955 Accept-Language 20 1956 Content-Encoding 21 1957 Content-Language 22 1958 Content-Location 23 1959 Content-Type 25 1960 MIME-Version 30 1962 M 1963 MIME-Version header field 30 1965 P 1966 payload 11 1968 R 1969 representation 11 1971 Authors' Addresses 1973 Roy T. Fielding (editor) 1974 Adobe Systems Incorporated 1975 345 Park Ave 1976 San Jose, CA 95110 1977 USA 1979 EMail: fielding@gbiv.com 1980 URI: http://roy.gbiv.com/ 1981 Jim Gettys 1982 Alcatel-Lucent Bell Labs 1983 21 Oak Knoll Road 1984 Carlisle, MA 01741 1985 USA 1987 EMail: jg@freedesktop.org 1988 URI: http://gettys.wordpress.com/ 1990 Jeffrey C. Mogul 1991 Hewlett-Packard Company 1992 HP Labs, Large Scale Systems Group 1993 1501 Page Mill Road, MS 1177 1994 Palo Alto, CA 94304 1995 USA 1997 EMail: JeffMogul@acm.org 1999 Henrik Frystyk Nielsen 2000 Microsoft Corporation 2001 1 Microsoft Way 2002 Redmond, WA 98052 2003 USA 2005 EMail: henrikn@microsoft.com 2007 Larry Masinter 2008 Adobe Systems Incorporated 2009 345 Park Ave 2010 San Jose, CA 95110 2011 USA 2013 EMail: LMM@acm.org 2014 URI: http://larry.masinter.net/ 2016 Paul J. Leach 2017 Microsoft Corporation 2018 1 Microsoft Way 2019 Redmond, WA 98052 2021 EMail: paulle@microsoft.com 2022 Tim Berners-Lee 2023 World Wide Web Consortium 2024 MIT Computer Science and Artificial Intelligence Laboratory 2025 The Stata Center, Building 32 2026 32 Vassar Street 2027 Cambridge, MA 02139 2028 USA 2030 EMail: timbl@w3.org 2031 URI: http://www.w3.org/People/Berners-Lee/ 2033 Yves Lafon (editor) 2034 World Wide Web Consortium 2035 W3C / ERCIM 2036 2004, rte des Lucioles 2037 Sophia-Antipolis, AM 06902 2038 France 2040 EMail: ylafon@w3.org 2041 URI: http://www.raubacapeu.net/people/yves/ 2043 Julian F. Reschke (editor) 2044 greenbytes GmbH 2045 Hafenweg 16 2046 Muenster, NW 48155 2047 Germany 2049 Phone: +49 251 2807760 2050 Fax: +49 251 2807761 2051 EMail: julian.reschke@greenbytes.de 2052 URI: http://greenbytes.de/tech/webdav/