idnits 2.17.1 draft-ietf-httpbis-p3-payload-14.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 (April 18, 2011) is 4756 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-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-14 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-14 ** 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: October 20, 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 April 18, 2011 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-14 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), which is archived at 39 . 41 The current issues list is at 42 and related 43 documents (including fancy diffs) can be found at 44 . 46 The changes in this draft are summarized in Appendix E.15. 48 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on October 20, 2011. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 95 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 96 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 97 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 98 1.3.2. ABNF Rules defined in other Parts of the 99 Specification . . . . . . . . . . . . . . . . . . . . 6 100 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 101 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 9 107 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 108 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 109 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 110 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 111 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 112 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 113 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 114 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 115 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 116 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 117 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 118 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 119 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 120 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 121 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 122 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 123 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 124 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 125 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 126 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 127 7.1. Header Field Registration . . . . . . . . . . . . . . . . 24 128 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 129 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 130 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 131 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 132 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 133 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 134 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 135 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 31 136 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 137 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 138 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 139 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32 140 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33 141 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 142 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 143 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 144 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34 145 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 34 146 Appendix E. Change Log (to be removed by RFC Editor before 147 publication) . . . . . . . . . . . . . . . . . . . . 36 148 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 149 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 36 150 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 37 151 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 37 152 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 37 153 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 38 154 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 38 155 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 38 156 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 39 157 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 39 158 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39 159 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 40 160 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 41 161 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 41 162 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 41 163 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 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.2. Content Codings 270 Content coding values indicate an encoding transformation that has 271 been or can be applied to a representation. Content codings are 272 primarily used to allow a representation to be compressed or 273 otherwise usefully transformed without losing the identity of its 274 underlying media type and without loss of information. Frequently, 275 the representation is stored in coded form, transmitted directly, and 276 only decoded by the recipient. 278 content-coding = token 280 All content-coding values are case-insensitive. HTTP/1.1 uses 281 content-coding values in the Accept-Encoding (Section 6.3) and 282 Content-Encoding (Section 6.5) header fields. Although the value 283 describes the content-coding, what is more important is that it 284 indicates what decoding mechanism will be required to remove the 285 encoding. 287 compress 289 See Section 6.2.2.1 of [Part1]. 291 deflate 293 See Section 6.2.2.2 of [Part1]. 295 gzip 297 See Section 6.2.2.3 of [Part1]. 299 identity 301 The default (identity) encoding; the use of no transformation 302 whatsoever. This content-coding is used only in the Accept- 303 Encoding header field, and SHOULD NOT be used in the Content- 304 Encoding header field. 306 2.2.1. Content Coding Registry 308 The HTTP Content Coding Registry defines the name space for the 309 content coding names. 311 Registrations MUST include the following fields: 313 o Name 315 o Description 317 o Pointer to specification text 319 Names of content codings MUST NOT overlap with names of transfer 320 codings (Section 6.2 of [Part1]), unless the encoding transformation 321 is identical (as it is the case for the compression codings defined 322 in Section 6.2.2 of [Part1]). 324 Values to be added to this name space require a specification (see 325 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 326 conform to the purpose of content coding defined in this section. 328 The registry itself is maintained at 329 . 331 2.3. Media Types 333 HTTP uses Internet Media Types [RFC2046] in the Content-Type 334 (Section 6.8) and Accept (Section 6.1) header fields in order to 335 provide open and extensible data typing and type negotiation. 337 media-type = type "/" subtype *( OWS ";" OWS parameter ) 338 type = token 339 subtype = token 341 The type/subtype MAY be followed by parameters in the form of 342 attribute/value pairs. 344 parameter = attribute "=" value 345 attribute = token 346 value = word 348 The type, subtype, and parameter attribute names are case- 349 insensitive. Parameter values might or might not be case-sensitive, 350 depending on the semantics of the parameter name. The presence or 351 absence of a parameter might be significant to the processing of a 352 media-type, depending on its definition within the media type 353 registry. 355 A parameter value that matches the token production can be 356 transmitted as either a token or within a quoted-string. The quoted 357 and unquoted values are equivalent. 359 Note that some older HTTP applications do not recognize media type 360 parameters. When sending data to older HTTP applications, 361 implementations SHOULD only use media type parameters when they are 362 required by that type/subtype definition. 364 Media-type values are registered with the Internet Assigned Number 365 Authority (IANA). The media type registration process is outlined in 366 [RFC4288]. Use of non-registered media types is discouraged. 368 2.3.1. Canonicalization and Text Defaults 370 Internet media types are registered with a canonical form. A 371 representation transferred via HTTP messages MUST be in the 372 appropriate canonical form prior to its transmission except for 373 "text" types, as defined in the next paragraph. 375 When in canonical form, media subtypes of the "text" type use CRLF as 376 the text line break. HTTP relaxes this requirement and allows the 377 transport of text media with plain CR or LF alone representing a line 378 break when it is done consistently for an entire representation. 379 HTTP applications MUST accept CRLF, bare CR, and bare LF as 380 indicating a line break in text media received via HTTP. In 381 addition, if the text is in a character encoding that does not use 382 octets 13 and 10 for CR and LF respectively, as is the case for some 383 multi-byte character encodings, HTTP allows the use of whatever octet 384 sequences are defined by that character encoding to represent the 385 equivalent of CR and LF for line breaks. This flexibility regarding 386 line breaks applies only to text media in the payload body; a bare CR 387 or LF MUST NOT be substituted for CRLF within any of the HTTP control 388 structures (such as header fields and multipart boundaries). 390 If a representation is encoded with a content-coding, the underlying 391 data MUST be in a form defined above prior to being encoded. 393 2.3.2. Multipart Types 395 MIME provides for a number of "multipart" types -- encapsulations of 396 one or more representations within a single message-body. All 397 multipart types share a common syntax, as defined in Section 5.1.1 of 398 [RFC2046], and MUST include a boundary parameter as part of the media 399 type value. The message body is itself a protocol element and MUST 400 therefore use only CRLF to represent line breaks between body-parts. 402 In general, HTTP treats a multipart message-body no differently than 403 any other media type: strictly as payload. HTTP does not use the 404 multipart boundary as an indicator of message-body length. In all 405 other respects, an HTTP user agent SHOULD follow the same or similar 406 behavior as a MIME user agent would upon receipt of a multipart type. 407 The MIME header fields within each body-part of a multipart message- 408 body do not have any significance to HTTP beyond that defined by 409 their MIME semantics. 411 If an application receives an unrecognized multipart subtype, the 412 application MUST treat it as being equivalent to "multipart/mixed". 414 Note: The "multipart/form-data" type has been specifically defined 415 for carrying form data suitable for processing via the POST 416 request method, as described in [RFC2388]. 418 2.4. Language Tags 420 A language tag, as defined in [RFC5646], identifies a natural 421 language spoken, written, or otherwise conveyed by human beings for 422 communication of information to other human beings. Computer 423 languages are explicitly excluded. HTTP uses language tags within 424 the Accept-Language and Content-Language fields. 426 In summary, a language tag is composed of one or more parts: A 427 primary language subtag followed by a possibly empty series of 428 subtags: 430 language-tag = 432 White space is not allowed within the tag and all tags are case- 433 insensitive. The name space of language subtags is administered by 434 the IANA (see 435 ). 437 Example tags include: 439 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 441 See [RFC5646] for further information. 443 3. Payload 445 HTTP messages MAY transfer a payload if not otherwise restricted by 446 the request method or response status code. The payload consists of 447 metadata, in the form of header fields, and data, in the form of the 448 sequence of octets in the message-body after any transfer-coding has 449 been decoded. 451 A "payload" in HTTP is always a partial or complete representation of 452 some resource. We use separate terms for payload and representation 453 because some messages contain only the associated representation's 454 header fields (e.g., responses to HEAD) or only some part(s) of the 455 representation (e.g., the 206 status code). 457 3.1. Payload Header Fields 459 HTTP header fields that specifically define the payload, rather than 460 the associated representation, are referred to as "payload header 461 fields". The following payload header fields are defined by 462 HTTP/1.1: 464 +-------------------+------------------------+ 465 | Header Field Name | Defined in... | 466 +-------------------+------------------------+ 467 | Content-Length | Section 9.2 of [Part1] | 468 | Content-Range | Section 5.2 of [Part5] | 469 +-------------------+------------------------+ 471 3.2. Payload Body 473 A payload body is only present in a message when a message-body is 474 present, as described in Section 3.3 of [Part1]. The payload body is 475 obtained from the message-body by decoding any Transfer-Encoding that 476 might have been applied to ensure safe and proper transfer of the 477 message. 479 4. Representation 481 A "representation" is information in a format that can be readily 482 communicated from one party to another. A resource representation is 483 information that reflects the state of that resource, as observed at 484 some point in the past (e.g., in a response to GET) or to be desired 485 at some point in the future (e.g., in a PUT request). 487 Most, but not all, representations transferred via HTTP are intended 488 to be a representation of the target resource (the resource 489 identified by the effective request URI). The precise semantics of a 490 representation are determined by the type of message (request or 491 response), the request method, the response status code, and the 492 representation metadata. For example, the above semantic is true for 493 the representation in any 200 (OK) response to GET and for the 494 representation in any PUT request. A 200 response to PUT, in 495 contrast, contains either a representation that describes the 496 successful action or a representation of the target resource, with 497 the latter indicated by a Content-Location header field with the same 498 value as the effective request URI. Likewise, response messages with 499 an error status code usually contain a representation that describes 500 the error and what next steps are suggested for resolving it. 502 4.1. Representation Header Fields 504 Representation header fields define metadata about the representation 505 data enclosed in the message-body or, if no message-body is present, 506 about the representation that would have been transferred in a 200 507 response to a simultaneous GET request with the same effective 508 request URI. 510 The following header fields are defined as representation metadata: 512 +-------------------+------------------------+ 513 | Header Field Name | Defined in... | 514 +-------------------+------------------------+ 515 | Content-Encoding | Section 6.5 | 516 | Content-Language | Section 6.6 | 517 | Content-Location | Section 6.7 | 518 | Content-Type | Section 6.8 | 519 | Expires | Section 3.3 of [Part6] | 520 | Last-Modified | Section 2.1 of [Part4] | 521 +-------------------+------------------------+ 523 4.2. Representation Data 525 The representation body associated with an HTTP message is either 526 provided as the payload body of the message or referred to by the 527 message semantics and the effective request URI. The representation 528 data is in a format and encoding defined by the representation 529 metadata header fields. 531 The data type of the representation data is determined via the header 532 fields Content-Type and Content-Encoding. These define a two-layer, 533 ordered encoding model: 535 representation-data := Content-Encoding( Content-Type( bits ) ) 537 Content-Type specifies the media type of the underlying data, which 538 defines both the data format and how that data SHOULD be processed by 539 the recipient (within the scope of the request method semantics). 540 Any HTTP/1.1 message containing a payload body SHOULD include a 541 Content-Type header field defining the media type of the associated 542 representation unless that metadata is unknown to the sender. If the 543 Content-Type header field is not present, it indicates that the 544 sender does not know the media type of the representation; recipients 545 MAY either assume that the media type is "application/octet-stream" 546 ([RFC2046], Section 4.5.1) or examine the content to determine its 547 type. 549 In practice, resource owners do not always properly configure their 550 origin server to provide the correct Content-Type for a given 551 representation, with the result that some clients will examine a 552 response body's content and override the specified type. Clients 553 that do so risk drawing incorrect conclusions, which might expose 554 additional security risks (e.g., "privilege escalation"). 555 Furthermore, it is impossible to determine the sender's intent by 556 examining the data format: many data formats match multiple media 557 types that differ only in processing semantics. Implementers are 558 encouraged to provide a means of disabling such "content sniffing" 559 when it is used. 561 Content-Encoding is used to indicate any additional content codings 562 applied to the data, usually for the purpose of data compression, 563 that are a property of the representation. If Content-Encoding is 564 not present, then there is no additional encoding beyond that defined 565 by the Content-Type. 567 5. Content Negotiation 569 HTTP responses include a representation which contains information 570 for interpretation, whether by a human user or for further 571 processing. Often, the server has different ways of representing the 572 same information; for example, in different formats, languages, or 573 using different character encodings. 575 HTTP clients and their users might have different or variable 576 capabilities, characteristics or preferences which would influence 577 which representation, among those available from the server, would be 578 best for the server to deliver. For this reason, HTTP provides 579 mechanisms for "content negotiation" -- a process of allowing 580 selection of a representation of a given resource, when more than one 581 is available. 583 This specification defines two patterns of content negotiation; 584 "server-driven", where the server selects the representation based 585 upon the client's stated preferences, and "agent-driven" negotiation, 586 where the server provides a list of representations for the client to 587 choose from, based upon their metadata. In addition, there are other 588 patterns: some applications use an "active content" pattern, where 589 the server returns active content which runs on the client and, based 590 on client available parameters, selects additional resources to 591 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 592 proposed. 594 These patterns are all widely used, and have trade-offs in 595 applicability and practicality. In particular, when the number of 596 preferences or capabilities to be expressed by a client are large 597 (such as when many different formats are supported by a user-agent), 598 server-driven negotiation becomes unwieldy, and might not be 599 appropriate. Conversely, when the number of representations to 600 choose from is very large, agent-driven negotiation might not be 601 appropriate. 603 Note that in all cases, the supplier of representations has the 604 responsibility for determining which representations might be 605 considered to be the "same information". 607 5.1. Server-driven Negotiation 609 If the selection of the best representation for a response is made by 610 an algorithm located at the server, it is called server-driven 611 negotiation. Selection is based on the available representations of 612 the response (the dimensions over which it can vary; e.g., language, 613 content-coding, etc.) and the contents of particular header fields in 614 the request message or on other information pertaining to the request 615 (such as the network address of the client). 617 Server-driven negotiation is advantageous when the algorithm for 618 selecting from among the available representations is difficult to 619 describe to the user agent, or when the server desires to send its 620 "best guess" to the client along with the first response (hoping to 621 avoid the round-trip delay of a subsequent request if the "best 622 guess" is good enough for the user). In order to improve the 623 server's guess, the user agent MAY include request header fields 624 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 625 preferences for such a response. 627 Server-driven negotiation has disadvantages: 629 1. It is impossible for the server to accurately determine what 630 might be "best" for any given user, since that would require 631 complete knowledge of both the capabilities of the user agent and 632 the intended use for the response (e.g., does the user want to 633 view it on screen or print it on paper?). 635 2. Having the user agent describe its capabilities in every request 636 can be both very inefficient (given that only a small percentage 637 of responses have multiple representations) and a potential 638 violation of the user's privacy. 640 3. It complicates the implementation of an origin server and the 641 algorithms for generating responses to a request. 643 4. It might limit a public cache's ability to use the same response 644 for multiple user's requests. 646 HTTP/1.1 includes the following header fields for enabling server- 647 driven negotiation through description of user agent capabilities and 648 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 649 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 650 User-Agent (Section 9.9 of [Part2]). However, an origin server is 651 not limited to these dimensions and MAY vary the response based on 652 any aspect of the request, including aspects of the connection (e.g., 653 IP address) or information within extension header fields not defined 654 by this specification. 656 Note: In practice, User-Agent based negotiation is fragile, 657 because new clients might not be recognized. 659 The Vary header field (Section 3.5 of [Part6]) can be used to express 660 the parameters the server uses to select a representation that is 661 subject to server-driven negotiation. 663 5.2. Agent-driven Negotiation 665 With agent-driven negotiation, selection of the best representation 666 for a response is performed by the user agent after receiving an 667 initial response from the origin server. Selection is based on a 668 list of the available representations of the response included within 669 the header fields or body of the initial response, with each 670 representation identified by its own URI. Selection from among the 671 representations can be performed automatically (if the user agent is 672 capable of doing so) or manually by the user selecting from a 673 generated (possibly hypertext) menu. 675 Agent-driven negotiation is advantageous when the response would vary 676 over commonly-used dimensions (such as type, language, or encoding), 677 when the origin server is unable to determine a user agent's 678 capabilities from examining the request, and generally when public 679 caches are used to distribute server load and reduce network usage. 681 Agent-driven negotiation suffers from the disadvantage of needing a 682 second request to obtain the best alternate representation. This 683 second request is only efficient when caching is used. In addition, 684 this specification does not define any mechanism for supporting 685 automatic selection, though it also does not prevent any such 686 mechanism from being developed as an extension and used within 687 HTTP/1.1. 689 This specification defines the 300 (Multiple Choices) and 406 (Not 690 Acceptable) status codes for enabling agent-driven negotiation when 691 the server is unwilling or unable to provide a varying response using 692 server-driven negotiation. 694 6. Header Field Definitions 696 This section defines the syntax and semantics of HTTP/1.1 header 697 fields related to the payload of messages. 699 6.1. Accept 701 The "Accept" header field can be used by user agents to specify 702 response media types that are acceptable. Accept header fields can 703 be used to indicate that the request is specifically limited to a 704 small set of desired types, as in the case of a request for an in- 705 line image. 707 Accept = #( media-range [ accept-params ] ) 709 media-range = ( "*/*" 710 / ( type "/" "*" ) 711 / ( type "/" subtype ) 712 ) *( OWS ";" OWS parameter ) 713 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 714 accept-ext = OWS ";" OWS token [ "=" word ] 716 The asterisk "*" character is used to group media types into ranges, 717 with "*/*" indicating all media types and "type/*" indicating all 718 subtypes of that type. The media-range MAY include media type 719 parameters that are applicable to that range. 721 Each media-range MAY be followed by one or more accept-params, 722 beginning with the "q" parameter for indicating a relative quality 723 factor. The first "q" parameter (if any) separates the media-range 724 parameter(s) from the accept-params. Quality factors allow the user 725 or user agent to indicate the relative degree of preference for that 726 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 727 [Part1]). The default value is q=1. 729 Note: Use of the "q" parameter name to separate media type 730 parameters from Accept extension parameters is due to historical 731 practice. Although this prevents any media type parameter named 732 "q" from being used with a media range, such an event is believed 733 to be unlikely given the lack of any "q" parameters in the IANA 734 media type registry and the rare usage of any media type 735 parameters in Accept. Future media types are discouraged from 736 registering any parameter named "q". 738 The example 739 Accept: audio/*; q=0.2, audio/basic 741 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 742 type if it is the best available after an 80% mark-down in quality". 744 If no Accept header field is present, then it is assumed that the 745 client accepts all media types. If an Accept header field is 746 present, and if the server cannot send a response which is acceptable 747 according to the combined Accept field value, then the server SHOULD 748 send a 406 (Not Acceptable) response. 750 A more elaborate example is 752 Accept: text/plain; q=0.5, text/html, 753 text/x-dvi; q=0.8, text/x-c 755 Verbally, this would be interpreted as "text/html and text/x-c are 756 the preferred media types, but if they do not exist, then send the 757 text/x-dvi representation, and if that does not exist, send the text/ 758 plain representation". 760 Media ranges can be overridden by more specific media ranges or 761 specific media types. If more than one media range applies to a 762 given type, the most specific reference has precedence. For example, 764 Accept: text/*, text/plain, text/plain;format=flowed, */* 766 have the following precedence: 768 1. text/plain;format=flowed 770 2. text/plain 772 3. text/* 774 4. */* 776 The media type quality factor associated with a given type is 777 determined by finding the media range with the highest precedence 778 which matches that type. For example, 780 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 781 text/html;level=2;q=0.4, */*;q=0.5 783 would cause the following values to be associated: 785 +-------------------+---------------+ 786 | Media Type | Quality Value | 787 +-------------------+---------------+ 788 | text/html;level=1 | 1 | 789 | text/html | 0.7 | 790 | text/plain | 0.3 | 791 | image/jpeg | 0.5 | 792 | text/html;level=2 | 0.4 | 793 | text/html;level=3 | 0.7 | 794 +-------------------+---------------+ 796 Note: A user agent might be provided with a default set of quality 797 values for certain media ranges. However, unless the user agent is a 798 closed system which cannot interact with other rendering agents, this 799 default set ought to be configurable by the user. 801 6.2. Accept-Charset 803 The "Accept-Charset" header field can be used by user agents to 804 indicate what character encodings are acceptable in a response 805 payload. This field allows clients capable of understanding more 806 comprehensive or special-purpose character encodings to signal that 807 capability to a server which is capable of representing documents in 808 those character encodings. 810 Accept-Charset = 1#( ( charset / "*" ) 811 [ OWS ";" OWS "q=" qvalue ] ) 813 Character encoding values (a.k.a., charsets) are described in 814 Section 2.1. Each charset MAY be given an associated quality value 815 which represents the user's preference for that charset. The default 816 value is q=1. An example is 818 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 820 The special value "*", if present in the Accept-Charset field, 821 matches every character encoding which is not mentioned elsewhere in 822 the Accept-Charset field. If no "*" is present in an Accept-Charset 823 field, then all character encodings not explicitly mentioned get a 824 quality value of 0. 826 If no Accept-Charset header field is present, the default is that any 827 character encoding is acceptable. If an Accept-Charset header field 828 is present, and if the server cannot send a response which is 829 acceptable according to the Accept-Charset header field, then the 830 server SHOULD send an error response with the 406 (Not Acceptable) 831 status code, though the sending of an unacceptable response is also 832 allowed. 834 6.3. Accept-Encoding 836 The "Accept-Encoding" header field can be used by user agents to 837 indicate what response content-codings (Section 2.2) are acceptable 838 in the response. 840 Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) 841 codings = ( content-coding / "*" ) 843 Each codings value MAY be given an associated quality value which 844 represents the preference for that encoding. The default value is 845 q=1. 847 Examples of its use are: 849 Accept-Encoding: compress, gzip 850 Accept-Encoding: 851 Accept-Encoding: * 852 Accept-Encoding: compress;q=0.5, gzip;q=1.0 853 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 855 A server tests whether a content-coding is acceptable, according to 856 an Accept-Encoding field, using these rules: 858 1. If the content-coding is one of the content-codings listed in the 859 Accept-Encoding field, then it is acceptable, unless it is 860 accompanied by a qvalue of 0. (As defined in Section 6.4 of 861 [Part1], a qvalue of 0 means "not acceptable".) 863 2. The special "*" symbol in an Accept-Encoding field matches any 864 available content-coding not explicitly listed in the header 865 field. 867 3. If multiple content-codings are acceptable, then the acceptable 868 content-coding with the highest non-zero qvalue is preferred. 870 4. The "identity" content-coding is always acceptable, unless 871 specifically refused because the Accept-Encoding field includes 872 "identity;q=0", or because the field includes "*;q=0" and does 873 not explicitly include the "identity" content-coding. If the 874 Accept-Encoding field-value is empty, then only the "identity" 875 encoding is acceptable. 877 If an Accept-Encoding field is present in a request, and if the 878 server cannot send a response which is acceptable according to the 879 Accept-Encoding header field, then the server SHOULD send an error 880 response with the 406 (Not Acceptable) status code. 882 If no Accept-Encoding field is present in a request, the server MAY 883 assume that the client will accept any content coding. In this case, 884 if "identity" is one of the available content-codings, then the 885 server SHOULD use the "identity" content-coding, unless it has 886 additional information that a different content-coding is meaningful 887 to the client. 889 Note: If the request does not include an Accept-Encoding field, 890 and if the "identity" content-coding is unavailable, then content- 891 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 892 "compress") are preferred; some older clients improperly display 893 messages sent with other content-codings. The server might also 894 make this decision based on information about the particular user- 895 agent or client. 897 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 898 associated with content-codings. This means that qvalues will not 899 work and are not permitted with x-gzip or x-compress. 901 6.4. Accept-Language 903 The "Accept-Language" header field can be used by user agents to 904 indicate the set of natural languages that are preferred in the 905 response. Language tags are defined in Section 2.4. 907 Accept-Language = 908 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 909 language-range = 910 912 Each language-range can be given an associated quality value which 913 represents an estimate of the user's preference for the languages 914 specified by that range. The quality value defaults to "q=1". For 915 example, 917 Accept-Language: da, en-gb;q=0.8, en;q=0.7 919 would mean: "I prefer Danish, but will accept British English and 920 other types of English". (see also Section 2.3 of [RFC4647]) 922 For matching, Section 3 of [RFC4647] defines several matching 923 schemes. Implementations can offer the most appropriate matching 924 scheme for their requirements. 926 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 927 identical to the matching scheme that was previously defined in 928 Section 14.4 of [RFC2616]. 930 It might be contrary to the privacy expectations of the user to send 931 an Accept-Language header field with the complete linguistic 932 preferences of the user in every request. For a discussion of this 933 issue, see Section 8.1. 935 As intelligibility is highly dependent on the individual user, it is 936 recommended that client applications make the choice of linguistic 937 preference available to the user. If the choice is not made 938 available, then the Accept-Language header field MUST NOT be given in 939 the request. 941 Note: When making the choice of linguistic preference available to 942 the user, we remind implementors of the fact that users are not 943 familiar with the details of language matching as described above, 944 and ought to be provided appropriate guidance. As an example, 945 users might assume that on selecting "en-gb", they will be served 946 any kind of English document if British English is not available. 947 A user agent might suggest in such a case to add "en" to get the 948 best matching behavior. 950 6.5. Content-Encoding 952 The "Content-Encoding" header field indicates what content-codings 953 have been applied to the representation, and thus what decoding 954 mechanisms must be applied in order to obtain the media-type 955 referenced by the Content-Type header field. Content-Encoding is 956 primarily used to allow a representation to be compressed without 957 losing the identity of its underlying media type. 959 Content-Encoding = 1#content-coding 961 Content codings are defined in Section 2.2. An example of its use is 963 Content-Encoding: gzip 965 The content-coding is a characteristic of the representation. 966 Typically, the representation body is stored with this encoding and 967 is only decoded before rendering or analogous usage. However, a 968 transforming proxy MAY modify the content-coding if the new coding is 969 known to be acceptable to the recipient, unless the "no-transform" 970 cache-control directive is present in the message. 972 If the content-coding of a representation is not "identity", then the 973 representation metadata MUST include a Content-Encoding header field 974 (Section 6.5) that lists the non-identity content-coding(s) used. 976 If the content-coding of a representation in a request message is not 977 acceptable to the origin server, the server SHOULD respond with a 978 status code of 415 (Unsupported Media Type). 980 If multiple encodings have been applied to a representation, the 981 content codings MUST be listed in the order in which they were 982 applied. Additional information about the encoding parameters MAY be 983 provided by other header fields not defined by this specification. 985 6.6. Content-Language 987 The "Content-Language" header field describes the natural language(s) 988 of the intended audience for the representation. Note that this 989 might not be equivalent to all the languages used within the 990 representation. 992 Content-Language = 1#language-tag 994 Language tags are defined in Section 2.4. The primary purpose of 995 Content-Language is to allow a user to identify and differentiate 996 representations according to the user's own preferred language. 997 Thus, if the body content is intended only for a Danish-literate 998 audience, the appropriate field is 1000 Content-Language: da 1002 If no Content-Language is specified, the default is that the content 1003 is intended for all language audiences. This might mean that the 1004 sender does not consider it to be specific to any natural language, 1005 or that the sender does not know for which language it is intended. 1007 Multiple languages MAY be listed for content that is intended for 1008 multiple audiences. For example, a rendition of the "Treaty of 1009 Waitangi", presented simultaneously in the original Maori and English 1010 versions, would call for 1012 Content-Language: mi, en 1014 However, just because multiple languages are present within a 1015 representation does not mean that it is intended for multiple 1016 linguistic audiences. An example would be a beginner's language 1017 primer, such as "A First Lesson in Latin", which is clearly intended 1018 to be used by an English-literate audience. In this case, the 1019 Content-Language would properly only include "en". 1021 Content-Language MAY be applied to any media type -- it is not 1022 limited to textual documents. 1024 6.7. Content-Location 1026 The "Content-Location" header field supplies a URI that can be used 1027 as a specific identifier for the representation in this message. In 1028 other words, if one were to perform a GET on this URI at the time of 1029 this message's generation, then a 200 response would contain the same 1030 representation that is enclosed as payload in this message. 1032 Content-Location = absolute-URI / partial-URI 1034 The Content-Location value is not a replacement for the effective 1035 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1036 It has the same syntax and semantics as the header field of the same 1037 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1038 its appearance in an HTTP message has some special implications for 1039 HTTP recipients. 1041 If Content-Location is included in a response message and its value 1042 is the same as the effective request URI, then the response payload 1043 SHOULD be considered the current representation of that resource. 1044 For a GET or HEAD request, this is the same as the default semantics 1045 when no Content-Location is provided by the server. For a state- 1046 changing request like PUT or POST, it implies that the server's 1047 response contains the new representation of that resource, thereby 1048 distinguishing it from representations that might only report about 1049 the action (e.g., "It worked!"). This allows authoring applications 1050 to update their local copies without the need for a subsequent GET 1051 request. 1053 If Content-Location is included in a response message and its value 1054 differs from the effective request URI, then the origin server is 1055 informing recipients that this representation has its own, presumably 1056 more specific, identifier. For a GET or HEAD request, this is an 1057 indication that the effective request URI identifies a resource that 1058 is subject to content negotiation and the representation selected for 1059 this response can also be found at the identified URI. For other 1060 methods, such a Content-Location indicates that this representation 1061 contains a report on the action's status and the same report is 1062 available (for future access with GET) at the given URI. For 1063 example, a purchase transaction made via a POST request might include 1064 a receipt document as the payload of the 200 response; the Content- 1065 Location value provides an identifier for retrieving a copy of that 1066 same receipt in the future. 1068 If Content-Location is included in a request message, then it MAY be 1069 interpreted by the origin server as an indication of where the user 1070 agent originally obtained the content of the enclosed representation 1071 (prior to any subsequent modification of the content by that user 1072 agent). In other words, the user agent is providing the same 1073 representation metadata that it received with the original 1074 representation. However, such interpretation MUST NOT be used to 1075 alter the semantics of the method requested by the client. For 1076 example, if a client makes a PUT request on a negotiated resource and 1077 the origin server accepts that PUT (without redirection), then the 1078 new set of values for that resource is expected to be consistent with 1079 the one representation supplied in that PUT; the Content-Location 1080 cannot be used as a form of reverse content selection that identifies 1081 only one of the negotiated representations to be updated. If the 1082 user agent had wanted the latter semantics, it would have applied the 1083 PUT directly to the Content-Location URI. 1085 A Content-Location field received in a request message is transitory 1086 information that SHOULD NOT be saved with other representation 1087 metadata for use in later responses. The Content-Location's value 1088 might be saved for use in other contexts, such as within source links 1089 or other metadata. 1091 A cache cannot assume that a representation with a Content-Location 1092 different from the URI used to retrieve it can be used to respond to 1093 later requests on that Content-Location URI. 1095 If the Content-Location value is a partial URI, the partial URI is 1096 interpreted relative to the effective request URI. 1098 6.8. Content-Type 1100 The "Content-Type" header field indicates the media type of the 1101 representation. In the case of responses to the HEAD method, the 1102 media type is that which would have been sent had the request been a 1103 GET. 1105 Content-Type = media-type 1107 Media types are defined in Section 2.3. An example of the field is 1109 Content-Type: text/html; charset=ISO-8859-4 1111 Further discussion of Content-Type is provided in Section 4.2. 1113 7. IANA Considerations 1115 7.1. Header Field Registration 1117 The Message Header Field Registry located at shall be 1119 updated with the permanent registrations below (see [RFC3864]): 1121 +-------------------+----------+----------+--------------+ 1122 | Header Field Name | Protocol | Status | Reference | 1123 +-------------------+----------+----------+--------------+ 1124 | Accept | http | standard | Section 6.1 | 1125 | Accept-Charset | http | standard | Section 6.2 | 1126 | Accept-Encoding | http | standard | Section 6.3 | 1127 | Accept-Language | http | standard | Section 6.4 | 1128 | Content-Encoding | http | standard | Section 6.5 | 1129 | Content-Language | http | standard | Section 6.6 | 1130 | Content-Location | http | standard | Section 6.7 | 1131 | Content-Type | http | standard | Section 6.8 | 1132 | MIME-Version | http | standard | Appendix A.1 | 1133 +-------------------+----------+----------+--------------+ 1135 The change controller is: "IETF (iesg@ietf.org) - Internet 1136 Engineering Task Force". 1138 7.2. Content Coding Registry 1140 The registration procedure for HTTP Content Codings is now defined by 1141 Section 2.2.1 of this document. 1143 The HTTP Content Codings Registry located at 1144 shall be updated 1145 with the registration below: 1147 +----------+-----------------------------------------+--------------+ 1148 | Name | Description | Reference | 1149 +----------+-----------------------------------------+--------------+ 1150 | compress | UNIX "compress" program method | Section | 1151 | | | 6.2.2.1 of | 1152 | | | [Part1] | 1153 | deflate | "deflate" compression mechanism | Section | 1154 | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | 1155 | | format ([RFC1950]) | [Part1] | 1156 | gzip | Same as GNU zip [RFC1952] | Section | 1157 | | | 6.2.2.3 of | 1158 | | | [Part1] | 1159 | identity | No transformation | Section 2.2 | 1160 +----------+-----------------------------------------+--------------+ 1162 8. Security Considerations 1164 This section is meant to inform application developers, information 1165 providers, and users of the security limitations in HTTP/1.1 as 1166 described by this document. The discussion does not include 1167 definitive solutions to the problems revealed, though it does make 1168 some suggestions for reducing security risks. 1170 8.1. Privacy Issues Connected to Accept Header Fields 1172 Accept headers fields can reveal information about the user to all 1173 servers which are accessed. The Accept-Language header field in 1174 particular can reveal information the user would consider to be of a 1175 private nature, because the understanding of particular languages is 1176 often strongly correlated to the membership of a particular ethnic 1177 group. User agents which offer the option to configure the contents 1178 of an Accept-Language header field to be sent in every request are 1179 strongly encouraged to let the configuration process include a 1180 message which makes the user aware of the loss of privacy involved. 1182 An approach that limits the loss of privacy would be for a user agent 1183 to omit the sending of Accept-Language header fields by default, and 1184 to ask the user whether or not to start sending Accept-Language 1185 header fields to a server if it detects, by looking for any Vary 1186 header fields generated by the server, that such sending could 1187 improve the quality of service. 1189 Elaborate user-customized accept header fields sent in every request, 1190 in particular if these include quality values, can be used by servers 1191 as relatively reliable and long-lived user identifiers. Such user 1192 identifiers would allow content providers to do click-trail tracking, 1193 and would allow collaborating content providers to match cross-server 1194 click-trails or form submissions of individual users. Note that for 1195 many users not behind a proxy, the network address of the host 1196 running the user agent will also serve as a long-lived user 1197 identifier. In environments where proxies are used to enhance 1198 privacy, user agents ought to be conservative in offering accept 1199 header configuration options to end users. As an extreme privacy 1200 measure, proxies could filter the accept header fields in relayed 1201 requests. General purpose user agents which provide a high degree of 1202 header configurability SHOULD warn users about the loss of privacy 1203 which can be involved. 1205 9. Acknowledgments 1207 10. References 1209 10.1. Normative References 1211 [Part1] Fielding, R., Ed., Gettys, J., 1212 Mogul, J., Frystyk, H., Masinter, 1213 L., Leach, P., Berners-Lee, T., 1214 Lafon, Y., Ed., and J. Reschke, 1215 Ed., "HTTP/1.1, part 1: URIs, 1216 Connections, and Message Parsing", 1217 draft-ietf-httpbis-p1-messaging-14 1218 (work in progress), April 2011. 1220 [Part2] Fielding, R., Ed., Gettys, J., 1221 Mogul, J., Frystyk, H., Masinter, 1222 L., Leach, P., Berners-Lee, T., 1223 Lafon, Y., Ed., and J. Reschke, 1224 Ed., "HTTP/1.1, part 2: Message 1225 Semantics", 1226 draft-ietf-httpbis-p2-semantics-14 1227 (work in progress), April 2011. 1229 [Part4] Fielding, R., Ed., Gettys, J., 1230 Mogul, J., Frystyk, H., Masinter, 1231 L., Leach, P., Berners-Lee, T., 1232 Lafon, Y., Ed., and J. Reschke, 1233 Ed., "HTTP/1.1, part 4: 1234 Conditional Requests", draft-ietf- 1235 httpbis-p4-conditional-14 (work in 1236 progress), April 2011. 1238 [Part5] Fielding, R., Ed., Gettys, J., 1239 Mogul, J., Frystyk, H., Masinter, 1240 L., Leach, P., Berners-Lee, T., 1241 Lafon, Y., Ed., and J. Reschke, 1242 Ed., "HTTP/1.1, part 5: Range 1243 Requests and Partial Responses", 1244 draft-ietf-httpbis-p5-range-14 1245 (work in progress), April 2011. 1247 [Part6] Fielding, R., Ed., Gettys, J., 1248 Mogul, J., Frystyk, H., Masinter, 1249 L., Leach, P., Berners-Lee, T., 1250 Lafon, Y., Ed., Nottingham, M., 1251 Ed., and J. Reschke, Ed., 1252 "HTTP/1.1, part 6: Caching", 1253 draft-ietf-httpbis-p6-cache-14 1254 (work in progress), April 2011. 1256 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB 1257 Compressed Data Format 1258 Specification version 3.3", 1259 RFC 1950, May 1996. 1261 RFC 1950 is an Informational RFC, 1262 thus it might be less stable than 1263 this specification. On the other 1264 hand, this downward reference was 1265 present since the publication of 1266 RFC 2068 in 1997 ([RFC2068]), 1267 therefore it is unlikely to cause 1268 problems in practice. See also 1269 [BCP97]. 1271 [RFC1951] Deutsch, P., "DEFLATE Compressed 1272 Data Format Specification version 1273 1.3", RFC 1951, May 1996. 1275 RFC 1951 is an Informational RFC, 1276 thus it might be less stable than 1277 this specification. On the other 1278 hand, this downward reference was 1279 present since the publication of 1280 RFC 2068 in 1997 ([RFC2068]), 1281 therefore it is unlikely to cause 1282 problems in practice. See also 1283 [BCP97]. 1285 [RFC1952] Deutsch, P., Gailly, J-L., Adler, 1286 M., Deutsch, L., and G. Randers- 1287 Pehrson, "GZIP file format 1288 specification version 4.3", 1289 RFC 1952, May 1996. 1291 RFC 1952 is an Informational RFC, 1292 thus it might be less stable than 1293 this specification. On the other 1294 hand, this downward reference was 1295 present since the publication of 1296 RFC 2068 in 1997 ([RFC2068]), 1297 therefore it is unlikely to cause 1298 problems in practice. See also 1299 [BCP97]. 1301 [RFC2045] Freed, N. and N. Borenstein, 1302 "Multipurpose Internet Mail 1303 Extensions (MIME) Part One: Format 1304 of Internet Message Bodies", 1305 RFC 2045, November 1996. 1307 [RFC2046] Freed, N. and N. Borenstein, 1308 "Multipurpose Internet Mail 1309 Extensions (MIME) Part Two: Media 1310 Types", RFC 2046, November 1996. 1312 [RFC2119] Bradner, S., "Key words for use in 1313 RFCs to Indicate Requirement 1314 Levels", BCP 14, RFC 2119, 1315 March 1997. 1317 [RFC4647] Phillips, A., Ed. and M. Davis, 1318 Ed., "Matching of Language Tags", 1319 BCP 47, RFC 4647, September 2006. 1321 [RFC5234] Crocker, D., Ed. and P. Overell, 1322 "Augmented BNF for Syntax 1323 Specifications: ABNF", STD 68, 1324 RFC 5234, January 2008. 1326 [RFC5646] Phillips, A., Ed. and M. Davis, 1327 Ed., "Tags for Identifying 1328 Languages", BCP 47, RFC 5646, 1329 September 2009. 1331 10.2. Informative References 1333 [BCP97] Klensin, J. and S. Hartman, 1334 "Handling Normative References to 1335 Standards-Track Documents", 1336 BCP 97, RFC 4897, June 2007. 1338 [RFC1945] Berners-Lee, T., Fielding, R., and 1339 H. Nielsen, "Hypertext Transfer 1340 Protocol -- HTTP/1.0", RFC 1945, 1341 May 1996. 1343 [RFC2049] Freed, N. and N. Borenstein, 1344 "Multipurpose Internet Mail 1345 Extensions (MIME) Part Five: 1346 Conformance Criteria and 1347 Examples", RFC 2049, 1348 November 1996. 1350 [RFC2068] Fielding, R., Gettys, J., Mogul, 1351 J., Nielsen, H., and T. Berners- 1352 Lee, "Hypertext Transfer Protocol 1353 -- HTTP/1.1", RFC 2068, 1354 January 1997. 1356 [RFC2076] Palme, J., "Common Internet 1357 Message Headers", RFC 2076, 1358 February 1997. 1360 [RFC2277] Alvestrand, H., "IETF Policy on 1361 Character Sets and Languages", 1362 BCP 18, RFC 2277, January 1998. 1364 [RFC2295] Holtman, K. and A. Mutz, 1365 "Transparent Content Negotiation 1366 in HTTP", RFC 2295, March 1998. 1368 [RFC2388] Masinter, L., "Returning Values 1369 from Forms: multipart/form-data", 1370 RFC 2388, August 1998. 1372 [RFC2557] Palme, F., Hopmann, A., Shelness, 1373 N., and E. Stefferud, "MIME 1374 Encapsulation of Aggregate 1375 Documents, such as HTML (MHTML)", 1376 RFC 2557, March 1999. 1378 [RFC2616] Fielding, R., Gettys, J., Mogul, 1379 J., Frystyk, H., Masinter, L., 1380 Leach, P., and T. Berners-Lee, 1381 "Hypertext Transfer Protocol -- 1382 HTTP/1.1", RFC 2616, June 1999. 1384 [RFC3629] Yergeau, F., "UTF-8, a 1385 transformation format of ISO 1386 10646", STD 63, RFC 3629, 1387 November 2003. 1389 [RFC3864] Klyne, G., Nottingham, M., and J. 1390 Mogul, "Registration Procedures 1391 for Message Header Fields", 1392 BCP 90, RFC 3864, September 2004. 1394 [RFC4288] Freed, N. and J. Klensin, "Media 1395 Type Specifications and 1396 Registration Procedures", BCP 13, 1397 RFC 4288, December 2005. 1399 [RFC5226] Narten, T. and H. Alvestrand, 1400 "Guidelines for Writing an IANA 1401 Considerations Section in RFCs", 1402 BCP 26, RFC 5226, May 2008. 1404 [RFC5322] Resnick, P., "Internet Message 1405 Format", RFC 5322, October 2008. 1407 [RFC6151] Turner, S. and L. Chen, "Updated 1408 Security Considerations for the 1409 MD5 Message-Digest and the HMAC- 1410 MD5 Algorithms", RFC 6151, 1411 March 2011. 1413 [draft-ietf-httpbis-content-disp] Reschke, J., "Use of the Content- 1414 Disposition Header Field in the 1415 Hypertext Transfer Protocol 1416 (HTTP)", 1417 draft-ietf-httpbis-content-disp-09 1418 (work in progress), March 2011. 1420 Appendix A. Differences between HTTP and MIME 1422 HTTP/1.1 uses many of the constructs defined for Internet Mail 1423 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1424 [RFC2045]) to allow a message-body to be transmitted in an open 1425 variety of representations and with extensible mechanisms. However, 1426 RFC 2045 discusses mail, and HTTP has a few features that are 1427 different from those described in MIME. These differences were 1428 carefully chosen to optimize performance over binary connections, to 1429 allow greater freedom in the use of new media types, to make date 1430 comparisons easier, and to acknowledge the practice of some early 1431 HTTP servers and clients. 1433 This appendix describes specific areas where HTTP differs from MIME. 1434 Proxies and gateways to strict MIME environments SHOULD be aware of 1435 these differences and provide the appropriate conversions where 1436 necessary. Proxies and gateways from MIME environments to HTTP also 1437 need to be aware of the differences because some conversions might be 1438 required. 1440 A.1. MIME-Version 1442 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1443 MAY include a single MIME-Version header field to indicate what 1444 version of the MIME protocol was used to construct the message. Use 1445 of the MIME-Version header field indicates that the message is in 1446 full compliance with the MIME protocol (as defined in [RFC2045]). 1447 Proxies/gateways are responsible for ensuring full compliance (where 1448 possible) when exporting HTTP messages to strict MIME environments. 1450 MIME-Version = 1*DIGIT "." 1*DIGIT 1452 MIME version "1.0" is the default for use in HTTP/1.1. However, 1453 HTTP/1.1 message parsing and semantics are defined by this document 1454 and not the MIME specification. 1456 A.2. Conversion to Canonical Form 1458 MIME requires that an Internet mail body-part be converted to 1459 canonical form prior to being transferred, as described in Section 4 1460 of [RFC2049]. Section 2.3.1 of this document describes the forms 1461 allowed for subtypes of the "text" media type when transmitted over 1462 HTTP. [RFC2046] requires that content with a type of "text" 1463 represent line breaks as CRLF and forbids the use of CR or LF outside 1464 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1465 indicate a line break within text content when a message is 1466 transmitted over HTTP. 1468 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1469 environment SHOULD translate all line breaks within the text media 1470 types described in Section 2.3.1 of this document to the RFC 2049 1471 canonical form of CRLF. Note, however, that this might be 1472 complicated by the presence of a Content-Encoding and by the fact 1473 that HTTP allows the use of some character encodings which do not use 1474 octets 13 and 10 to represent CR and LF, respectively, as is the case 1475 for some multi-byte character encodings. 1477 Conversion will break any cryptographic checksums applied to the 1478 original content unless the original content is already in canonical 1479 form. Therefore, the canonical form is recommended for any content 1480 that uses such checksums in HTTP. 1482 A.3. Conversion of Date Formats 1484 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1485 [Part1]) to simplify the process of date comparison. Proxies and 1486 gateways from other protocols SHOULD ensure that any Date header 1487 field present in a message conforms to one of the HTTP/1.1 formats 1488 and rewrite the date if necessary. 1490 A.4. Introduction of Content-Encoding 1492 MIME does not include any concept equivalent to HTTP/1.1's Content- 1493 Encoding header field. Since this acts as a modifier on the media 1494 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1495 either change the value of the Content-Type header field or decode 1496 the representation before forwarding the message. (Some experimental 1497 applications of Content-Type for Internet mail have used a media-type 1498 parameter of ";conversions=" to perform a function 1499 equivalent to Content-Encoding. However, this parameter is not part 1500 of the MIME standards). 1502 A.5. No Content-Transfer-Encoding 1504 HTTP does not use the Content-Transfer-Encoding field of MIME. 1505 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1506 remove any Content-Transfer-Encoding prior to delivering the response 1507 message to an HTTP client. 1509 Proxies and gateways from HTTP to MIME-compliant protocols are 1510 responsible for ensuring that the message is in the correct format 1511 and encoding for safe transport on that protocol, where "safe 1512 transport" is defined by the limitations of the protocol being used. 1513 Such a proxy or gateway SHOULD label the data with an appropriate 1514 Content-Transfer-Encoding if doing so will improve the likelihood of 1515 safe transport over the destination protocol. 1517 A.6. Introduction of Transfer-Encoding 1519 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1520 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1521 to forwarding a message via a MIME-compliant protocol. 1523 A.7. MHTML and Line Length Limitations 1525 HTTP implementations which share code with MHTML [RFC2557] 1526 implementations need to be aware of MIME line length limitations. 1527 Since HTTP does not have this limitation, HTTP does not fold long 1528 lines. MHTML messages being transported by HTTP follow all 1529 conventions of MHTML, including line length limitations and folding, 1530 canonicalization, etc., since HTTP transports all message-bodies as 1531 payload (see Section 2.3.2) and does not interpret the content or any 1532 MIME header lines that might be contained therein. 1534 Appendix B. Additional Features 1536 [RFC1945] and [RFC2068] document protocol elements used by some 1537 existing HTTP implementations, but not consistently and correctly 1538 across most HTTP/1.1 applications. Implementors are advised to be 1539 aware of these features, but cannot rely upon their presence in, or 1540 interoperability with, other HTTP/1.1 applications. Some of these 1541 describe proposed experimental features, and some describe features 1542 that experimental deployment found lacking that are now addressed in 1543 the base HTTP/1.1 specification. 1545 A number of other header fields, such as Content-Disposition and 1546 Title, from SMTP and MIME are also often implemented (see 1547 [draft-ietf-httpbis-content-disp] and [RFC2076]). 1549 Appendix C. Changes from RFC 2616 1551 Clarify contexts that charset is used in. (Section 2.1) 1553 Remove the default character encoding for text media types; the 1554 default now is whatever the media type definition says. 1555 (Section 2.3.1) 1557 Change ABNF productions for header fields to only define the field 1558 value. (Section 6) 1560 Remove definition of Content-MD5 header field because it was 1561 inconsistently implemented with respect to partial responses, and 1562 also because of known deficiencies in the hash algorithm itself (see 1563 [RFC6151] for details). (Section 6) 1565 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) 1567 Remove base URI setting semantics for Content-Location due to poor 1568 implementation support, which was caused by too many broken servers 1569 emitting bogus Content-Location header fields, and also the 1570 potentially undesirable effect of potentially breaking relative links 1571 in content-negotiated resources. (Section 6.7) 1573 Remove discussion of Content-Disposition header field, it is now 1574 defined by [draft-ietf-httpbis-content-disp]. (Appendix B) 1576 Remove reference to non-existant identity transfer-coding value 1577 tokens. (Appendix A.5) 1579 Appendix D. Collected ABNF 1581 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1582 OWS media-range [ accept-params ] ] ) ] 1583 Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1584 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1585 qvalue ] ] ) 1586 Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) 1587 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1588 Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1589 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1590 ] ) 1592 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 1593 content-coding ] ) 1594 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 1595 language-tag ] ) 1596 Content-Location = absolute-URI / partial-URI 1597 Content-Type = media-type 1599 MIME-Version = 1*DIGIT "." 1*DIGIT 1601 OWS = 1603 absolute-URI = 1604 accept-ext = OWS ";" OWS token [ "=" word ] 1605 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1606 attribute = token 1608 charset = token 1609 codings = ( content-coding / "*" ) 1610 content-coding = token 1612 language-range = 1613 language-tag = 1615 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1616 ";" OWS parameter ) 1617 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1619 parameter = attribute "=" value 1620 partial-URI = 1622 qvalue = 1624 subtype = token 1626 token = 1627 type = token 1629 value = word 1631 word = 1633 ABNF diagnostics: 1635 ; Accept defined but not used 1636 ; Accept-Charset defined but not used 1637 ; Accept-Encoding defined but not used 1638 ; Accept-Language defined but not used 1639 ; Content-Encoding defined but not used 1640 ; Content-Language defined but not used 1641 ; Content-Location defined but not used 1642 ; Content-Type defined but not used 1643 ; MIME-Version defined but not used 1645 Appendix E. Change Log (to be removed by RFC Editor before publication) 1647 E.1. Since RFC 2616 1649 Extracted relevant partitions from [RFC2616]. 1651 E.2. Since draft-ietf-httpbis-p3-payload-00 1653 Closed issues: 1655 o : "Media Type 1656 Registrations" () 1658 o : "Clarification 1659 regarding quoting of charset values" 1660 () 1662 o : "Remove 1663 'identity' token references" 1664 () 1666 o : "Accept- 1667 Encoding BNF" 1669 o : "Normative and 1670 Informative references" 1672 o : "RFC1700 1673 references" 1675 o : "Updating to 1676 RFC4288" 1678 o : "Informative 1679 references" 1681 o : "ISO-8859-1 1682 Reference" 1684 o : "Encoding 1685 References Normative" 1687 o : "Normative up- 1688 to-date references" 1690 E.3. Since draft-ietf-httpbis-p3-payload-01 1692 Ongoing work on ABNF conversion 1693 (): 1695 o Add explicit references to BNF syntax and rules imported from 1696 other parts of the specification. 1698 E.4. Since draft-ietf-httpbis-p3-payload-02 1700 Closed issues: 1702 o : "Quoting 1703 Charsets" 1705 o : 1706 "Classification for Allow header" 1708 o : "missing 1709 default for qvalue in description of Accept-Encoding" 1711 Ongoing work on IANA Message Header Field Registration 1712 (): 1714 o Reference RFC 3984, and update header field registrations for 1715 headers defined in this document. 1717 E.5. Since draft-ietf-httpbis-p3-payload-03 1719 Closed issues: 1721 o : "Quoting 1722 Charsets" 1724 o : "language tag 1725 matching (Accept-Language) vs RFC4647" 1727 o : "RFC 1806 has 1728 been replaced by RFC2183" 1730 Other changes: 1732 o : "Encoding 1733 References Normative" -- rephrase the annotation and reference 1734 [BCP97]. 1736 E.6. Since draft-ietf-httpbis-p3-payload-04 1738 Closed issues: 1740 o : "RFC 2822 is 1741 updated by RFC 5322" 1743 Ongoing work on ABNF conversion 1744 (): 1746 o Use "/" instead of "|" for alternatives. 1748 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1749 whitespace ("OWS") and required whitespace ("RWS"). 1751 o Rewrite ABNFs to spell out whitespace rules, factor out header 1752 field value format definitions. 1754 E.7. Since draft-ietf-httpbis-p3-payload-05 1756 Closed issues: 1758 o : "Join 1759 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1761 Final work on ABNF conversion 1762 (): 1764 o Add appendix containing collected and expanded ABNF, reorganize 1765 ABNF introduction. 1767 Other changes: 1769 o Move definition of quality values into Part 1. 1771 E.8. Since draft-ietf-httpbis-p3-payload-06 1773 Closed issues: 1775 o : "Content- 1776 Location isn't special" 1778 o : "Content 1779 Sniffing" 1781 E.9. Since draft-ietf-httpbis-p3-payload-07 1783 Closed issues: 1785 o : "Updated 1786 reference for language tags" 1788 o : "Clarify rules 1789 for determining what entities a response carries" 1791 o : "Content- 1792 Location base-setting problems" 1794 o : "Content 1795 Sniffing" 1797 o : "pick IANA 1798 policy (RFC5226) for Transfer Coding / Content Coding" 1800 o : "move 1801 definitions of gzip/deflate/compress to part 1" 1803 Partly resolved issues: 1805 o : "update IANA 1806 requirements wrt Transfer-Coding values" (add the IANA 1807 Considerations subsection) 1809 o : "update IANA 1810 requirements wrt Content-Coding values" (add the IANA 1811 Considerations subsection) 1813 E.10. Since draft-ietf-httpbis-p3-payload-08 1815 Closed issues: 1817 o : "Content 1818 Negotiation for media types" 1820 o : "Accept- 1821 Language: which RFC4647 filtering?" 1823 E.11. Since draft-ietf-httpbis-p3-payload-09 1825 Closed issues: 1827 o : "MIME-Version 1828 not listed in P1, general header fields" 1830 o : "IANA registry 1831 for content/transfer encodings" 1833 o : "Content 1834 Sniffing" 1836 o : "use of term 1837 "word" when talking about header structure" 1839 Partly resolved issues: 1841 o : "Term for the 1842 requested resource's URI" 1844 E.12. Since draft-ietf-httpbis-p3-payload-10 1846 Closed issues: 1848 o : "Clarify 1849 'Requested Variant'" 1851 o : "Content- 1852 Location isn't special" 1854 o : "Delimiting 1855 messages with multipart/byteranges" 1857 o : "Clarify 1858 entity / representation / variant terminology" 1860 o : "confusing 1861 req. language for Content-Location" 1863 o : "Content- 1864 Location on 304 responses" 1866 o : "'requested 1867 resource' in content-encoding definition" 1869 o : "consider 1870 removing the 'changes from 2068' sections" 1872 Partly resolved issues: 1874 o : "Content-MD5 1875 and partial responses" 1877 E.13. Since draft-ietf-httpbis-p3-payload-11 1879 Closed issues: 1881 o : "Factor out 1882 Content-Disposition" 1884 E.14. Since draft-ietf-httpbis-p3-payload-12 1886 Closed issues: 1888 o : "Header 1889 Classification" 1891 o : "untangle 1892 ABNFs for header fields" 1894 o : "potentially 1895 misleading MAY in media-type def" 1897 E.15. Since draft-ietf-httpbis-p3-payload-13 1899 Closed issues: 1901 o : "Default 1902 charsets for text media types" 1904 o : "Content-MD5 1905 and partial responses" 1907 o : "untangle 1908 ABNFs for header fields" 1910 o : "confusing 1911 undefined parameter in media range example" 1913 Index 1915 A 1916 Accept header field 16 1917 Accept-Charset header field 18 1918 Accept-Encoding header field 19 1919 Accept-Language header field 20 1921 C 1922 Coding Format 1923 compress 7 1924 deflate 7 1925 gzip 7 1926 identity 7 1927 compress (Coding Format) 7 1928 content negotiation 5 1929 Content-Encoding header field 21 1930 Content-Language header field 22 1931 Content-Location header field 23 1932 Content-Type header field 24 1934 D 1935 deflate (Coding Format) 7 1937 G 1938 Grammar 1939 Accept 16 1940 Accept-Charset 18 1941 Accept-Encoding 19 1942 accept-ext 16 1943 Accept-Language 20 1944 accept-params 16 1945 attribute 8 1946 charset 6 1947 codings 19 1948 content-coding 7 1949 Content-Encoding 21 1950 Content-Language 22 1951 Content-Location 23 1952 Content-Type 24 1953 language-range 20 1954 language-tag 10 1955 media-range 16 1956 media-type 8 1957 MIME-Version 31 1958 parameter 8 1959 subtype 8 1960 type 8 1961 value 8 1962 gzip (Coding Format) 7 1964 H 1965 Header Fields 1966 Accept 16 1967 Accept-Charset 18 1968 Accept-Encoding 19 1969 Accept-Language 20 1970 Content-Encoding 21 1971 Content-Language 22 1972 Content-Location 23 1973 Content-Type 24 1974 MIME-Version 31 1976 I 1977 identity (Coding Format) 7 1979 M 1980 MIME-Version header field 31 1982 P 1983 payload 10 1985 R 1986 representation 11 1988 Authors' Addresses 1990 Roy T. Fielding (editor) 1991 Adobe Systems Incorporated 1992 345 Park Ave 1993 San Jose, CA 95110 1994 USA 1996 EMail: fielding@gbiv.com 1997 URI: http://roy.gbiv.com/ 1999 Jim Gettys 2000 Alcatel-Lucent Bell Labs 2001 21 Oak Knoll Road 2002 Carlisle, MA 01741 2003 USA 2005 EMail: jg@freedesktop.org 2006 URI: http://gettys.wordpress.com/ 2008 Jeffrey C. Mogul 2009 Hewlett-Packard Company 2010 HP Labs, Large Scale Systems Group 2011 1501 Page Mill Road, MS 1177 2012 Palo Alto, CA 94304 2013 USA 2015 EMail: JeffMogul@acm.org 2016 Henrik Frystyk Nielsen 2017 Microsoft Corporation 2018 1 Microsoft Way 2019 Redmond, WA 98052 2020 USA 2022 EMail: henrikn@microsoft.com 2024 Larry Masinter 2025 Adobe Systems Incorporated 2026 345 Park Ave 2027 San Jose, CA 95110 2028 USA 2030 EMail: LMM@acm.org 2031 URI: http://larry.masinter.net/ 2033 Paul J. Leach 2034 Microsoft Corporation 2035 1 Microsoft Way 2036 Redmond, WA 98052 2038 EMail: paulle@microsoft.com 2040 Tim Berners-Lee 2041 World Wide Web Consortium 2042 MIT Computer Science and Artificial Intelligence Laboratory 2043 The Stata Center, Building 32 2044 32 Vassar Street 2045 Cambridge, MA 02139 2046 USA 2048 EMail: timbl@w3.org 2049 URI: http://www.w3.org/People/Berners-Lee/ 2050 Yves Lafon (editor) 2051 World Wide Web Consortium 2052 W3C / ERCIM 2053 2004, rte des Lucioles 2054 Sophia-Antipolis, AM 06902 2055 France 2057 EMail: ylafon@w3.org 2058 URI: http://www.raubacapeu.net/people/yves/ 2060 Julian F. Reschke (editor) 2061 greenbytes GmbH 2062 Hafenweg 16 2063 Muenster, NW 48155 2064 Germany 2066 Phone: +49 251 2807760 2067 Fax: +49 251 2807761 2068 EMail: julian.reschke@greenbytes.de 2069 URI: http://greenbytes.de/tech/webdav/