idnits 2.17.1 draft-ietf-httpbis-p3-payload-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2011) is 4628 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-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-16 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-16 ** 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: February 25, 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 August 24, 2011 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-16 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.17. 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 February 25, 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 24 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . 26 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 136 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 137 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 138 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 139 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 140 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 141 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 142 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 143 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . 32 149 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 150 Appendix E. Change Log (to be removed by RFC Editor before 151 publication) . . . . . . . . . . . . . . . . . . . . 34 152 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 153 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 154 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 155 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 156 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 157 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36 158 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36 159 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 160 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37 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 . . . . . . . . . . 38 164 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39 165 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39 166 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39 167 E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 168 E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40 169 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 171 1. Introduction 173 This document defines HTTP/1.1 message payloads (a.k.a., content), 174 the associated metadata header fields that define how the payload is 175 intended to be interpreted by a recipient, the request header fields 176 that might influence content selection, and the various selection 177 algorithms that are collectively referred to as HTTP content 178 negotiation. 180 This document is currently disorganized in order to minimize the 181 changes between drafts and enable reviewers to see the smaller errata 182 changes. A future draft will reorganize the sections to better 183 reflect the content. In particular, the sections on entities will be 184 renamed payload and moved to the first half of the document, while 185 the sections on content negotiation and associated request header 186 fields will be moved to the second half. The current mess reflects 187 how widely dispersed these topics and associated requirements had 188 become in [RFC2616]. 190 1.1. Terminology 192 This specification uses a number of terms to refer to the roles 193 played by participants in, and objects of, the HTTP communication. 195 content negotiation 197 The mechanism for selecting the appropriate representation when 198 servicing a request. The representation in any response can be 199 negotiated (including error responses). 201 1.2. Requirements 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 An implementation is not compliant if it fails to satisfy one or more 208 of the "MUST" or "REQUIRED" level requirements for the protocols it 209 implements. An implementation that satisfies all the "MUST" or 210 "REQUIRED" level and all the "SHOULD" level requirements for its 211 protocols is said to be "unconditionally compliant"; one that 212 satisfies all the "MUST" level requirements but not all the "SHOULD" 213 level requirements for its protocols is said to be "conditionally 214 compliant". 216 1.3. Syntax Notation 218 This specification uses the ABNF syntax defined in Section 1.2 of 219 [Part1] (which extends the syntax defined in [RFC5234] with a list 220 rule). Appendix D shows the collected ABNF, with the list rule 221 expanded. 223 The following core rules are included by reference, as defined in 224 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 225 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 226 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 227 sequence of data), SP (space), VCHAR (any visible USASCII character), 228 and WSP (whitespace). 230 1.3.1. Core Rules 232 The core rules below are defined in [Part1]: 234 OWS = 235 token = 236 word = 238 1.3.2. ABNF Rules defined in other Parts of the Specification 240 The ABNF rules below are defined in other parts: 242 absolute-URI = 243 partial-URI = 244 qvalue = 246 2. Protocol Parameters 248 2.1. Character Encodings (charset) 250 HTTP uses charset names to indicate the character encoding of a 251 textual representation. 253 A character encoding is identified by a case-insensitive token. The 254 complete set of tokens is defined by the IANA Character Set registry 255 (). 257 charset = token 259 Although HTTP allows an arbitrary token to be used as a charset 260 value, any token that has a predefined value within the IANA 261 Character Set registry MUST represent the character encoding defined 262 by that registry. Applications SHOULD limit their use of character 263 encodings to those defined within the IANA registry. 265 HTTP uses charset in two contexts: within an Accept-Charset request 266 header field (in which the charset value is an unquoted token) and as 267 the value of a parameter in a Content-Type header field (within a 268 request or response), in which case the parameter value of the 269 charset parameter can be quoted. 271 Implementors need to be aware of IETF character set requirements 272 [RFC3629] [RFC2277]. 274 2.2. Content Codings 276 Content coding values indicate an encoding transformation that has 277 been or can be applied to a representation. Content codings are 278 primarily used to allow a representation to be compressed or 279 otherwise usefully transformed without losing the identity of its 280 underlying media type and without loss of information. Frequently, 281 the representation is stored in coded form, transmitted directly, and 282 only decoded by the recipient. 284 content-coding = token 286 All content-coding values are case-insensitive. HTTP/1.1 uses 287 content-coding values in the Accept-Encoding (Section 6.3) and 288 Content-Encoding (Section 6.5) header fields. Although the value 289 describes the content-coding, what is more important is that it 290 indicates what decoding mechanism will be required to remove the 291 encoding. 293 compress 295 See Section 6.2.2.1 of [Part1]. 297 deflate 299 See Section 6.2.2.2 of [Part1]. 301 gzip 303 See Section 6.2.2.3 of [Part1]. 305 identity 307 The default (identity) encoding; the use of no transformation 308 whatsoever. This content-coding is used only in the Accept- 309 Encoding header field, and SHOULD NOT be used in the Content- 310 Encoding header field. 312 2.2.1. Content Coding Registry 314 The HTTP Content Coding Registry defines the name space for the 315 content coding names. 317 Registrations MUST include the following fields: 319 o Name 321 o Description 323 o Pointer to specification text 325 Names of content codings MUST NOT overlap with names of transfer 326 codings (Section 6.2 of [Part1]), unless the encoding transformation 327 is identical (as it is the case for the compression codings defined 328 in Section 6.2.2 of [Part1]). 330 Values to be added to this name space require a specification (see 331 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 332 conform to the purpose of content coding defined in this section. 334 The registry itself is maintained at 335 . 337 2.3. Media Types 339 HTTP uses Internet Media Types [RFC2046] in the Content-Type 340 (Section 6.8) and Accept (Section 6.1) header fields in order to 341 provide open and extensible data typing and type negotiation. 343 media-type = type "/" subtype *( OWS ";" OWS parameter ) 344 type = token 345 subtype = token 347 The type/subtype MAY be followed by parameters in the form of 348 attribute/value pairs. 350 parameter = attribute "=" value 351 attribute = token 352 value = word 354 The type, subtype, and parameter attribute names are case- 355 insensitive. Parameter values might or might not be case-sensitive, 356 depending on the semantics of the parameter name. The presence or 357 absence of a parameter might be significant to the processing of a 358 media-type, depending on its definition within the media type 359 registry. 361 A parameter value that matches the token production can be 362 transmitted as either a token or within a quoted-string. The quoted 363 and unquoted values are equivalent. 365 Note that some older HTTP applications do not recognize media type 366 parameters. When sending data to older HTTP applications, 367 implementations SHOULD only use media type parameters when they are 368 required by that type/subtype definition. 370 Media-type values are registered with the Internet Assigned Number 371 Authority (IANA). The media type registration process is outlined in 372 [RFC4288]. Use of non-registered media types is discouraged. 374 2.3.1. Canonicalization and Text Defaults 376 Internet media types are registered with a canonical form. A 377 representation transferred via HTTP messages MUST be in the 378 appropriate canonical form prior to its transmission except for 379 "text" types, as defined in the next paragraph. 381 When in canonical form, media subtypes of the "text" type use CRLF as 382 the text line break. HTTP relaxes this requirement and allows the 383 transport of text media with plain CR or LF alone representing a line 384 break when it is done consistently for an entire representation. 385 HTTP applications MUST accept CRLF, bare CR, and bare LF as 386 indicating a line break in text media received via HTTP. In 387 addition, if the text is in a character encoding that does not use 388 octets 13 and 10 for CR and LF respectively, as is the case for some 389 multi-byte character encodings, HTTP allows the use of whatever octet 390 sequences are defined by that character encoding to represent the 391 equivalent of CR and LF for line breaks. This flexibility regarding 392 line breaks applies only to text media in the payload body; a bare CR 393 or LF MUST NOT be substituted for CRLF within any of the HTTP control 394 structures (such as header fields and multipart boundaries). 396 If a representation is encoded with a content-coding, the underlying 397 data MUST be in a form defined above prior to being encoded. 399 2.3.2. Multipart Types 401 MIME provides for a number of "multipart" types -- encapsulations of 402 one or more representations within a single message-body. All 403 multipart types share a common syntax, as defined in Section 5.1.1 of 404 [RFC2046], and MUST include a boundary parameter as part of the media 405 type value. The message body is itself a protocol element and MUST 406 therefore use only CRLF to represent line breaks between body-parts. 408 In general, HTTP treats a multipart message-body no differently than 409 any other media type: strictly as payload. HTTP does not use the 410 multipart boundary as an indicator of message-body length. In all 411 other respects, an HTTP user agent SHOULD follow the same or similar 412 behavior as a MIME user agent would upon receipt of a multipart type. 413 The MIME header fields within each body-part of a multipart message- 414 body do not have any significance to HTTP beyond that defined by 415 their MIME semantics. 417 If an application receives an unrecognized multipart subtype, the 418 application MUST treat it as being equivalent to "multipart/mixed". 420 Note: The "multipart/form-data" type has been specifically defined 421 for carrying form data suitable for processing via the POST 422 request method, as described in [RFC2388]. 424 2.4. Language Tags 426 A language tag, as defined in [RFC5646], identifies a natural 427 language spoken, written, or otherwise conveyed by human beings for 428 communication of information to other human beings. Computer 429 languages are explicitly excluded. HTTP uses language tags within 430 the Accept-Language and Content-Language fields. 432 In summary, a language tag is composed of one or more parts: A 433 primary language subtag followed by a possibly empty series of 434 subtags: 436 language-tag = 438 White space is not allowed within the tag and all tags are case- 439 insensitive. The name space of language subtags is administered by 440 the IANA (see 441 ). 443 Example tags include: 445 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 447 See [RFC5646] for further information. 449 3. Payload 451 HTTP messages MAY transfer a payload if not otherwise restricted by 452 the request method or response status code. The payload consists of 453 metadata, in the form of header fields, and data, in the form of the 454 sequence of octets in the message-body after any transfer-coding has 455 been decoded. 457 A "payload" in HTTP is always a partial or complete representation of 458 some resource. We use separate terms for payload and representation 459 because some messages contain only the associated representation's 460 header fields (e.g., responses to HEAD) or only some part(s) of the 461 representation (e.g., the 206 status code). 463 3.1. Payload Header Fields 465 HTTP header fields that specifically define the payload, rather than 466 the associated representation, are referred to as "payload header 467 fields". The following payload header fields are defined by 468 HTTP/1.1: 470 +-------------------+------------------------+ 471 | Header Field Name | Defined in... | 472 +-------------------+------------------------+ 473 | Content-Length | Section 9.2 of [Part1] | 474 | Content-Range | Section 5.2 of [Part5] | 475 +-------------------+------------------------+ 477 3.2. Payload Body 479 A payload body is only present in a message when a message-body is 480 present, as described in Section 3.3 of [Part1]. The payload body is 481 obtained from the message-body by decoding any Transfer-Encoding that 482 might have been applied to ensure safe and proper transfer of the 483 message. 485 4. Representation 487 A "representation" is information in a format that can be readily 488 communicated from one party to another. A resource representation is 489 information that reflects the state of that resource, as observed at 490 some point in the past (e.g., in a response to GET) or to be desired 491 at some point in the future (e.g., in a PUT request). 493 Most, but not all, representations transferred via HTTP are intended 494 to be a representation of the target resource (the resource 495 identified by the effective request URI). The precise semantics of a 496 representation are determined by the type of message (request or 497 response), the request method, the response status code, and the 498 representation metadata. For example, the above semantic is true for 499 the representation in any 200 (OK) response to GET and for the 500 representation in any PUT request. A 200 response to PUT, in 501 contrast, contains either a representation that describes the 502 successful action or a representation of the target resource, with 503 the latter indicated by a Content-Location header field with the same 504 value as the effective request URI. Likewise, response messages with 505 an error status code usually contain a representation that describes 506 the error and what next steps are suggested for resolving it. 508 4.1. Representation Header Fields 510 Representation header fields define metadata about the representation 511 data enclosed in the message-body or, if no message-body is present, 512 about the representation that would have been transferred in a 200 513 response to a simultaneous GET request with the same effective 514 request URI. 516 The following header fields are defined as representation metadata: 518 +-------------------+------------------------+ 519 | Header Field Name | Defined in... | 520 +-------------------+------------------------+ 521 | Content-Encoding | Section 6.5 | 522 | Content-Language | Section 6.6 | 523 | Content-Location | Section 6.7 | 524 | Content-Type | Section 6.8 | 525 | Expires | Section 3.3 of [Part6] | 526 | Last-Modified | Section 2.2 of [Part4] | 527 +-------------------+------------------------+ 529 4.2. Representation Data 531 The representation body associated with an HTTP message is either 532 provided as the payload body of the message or referred to by the 533 message semantics and the effective request URI. The representation 534 data is in a format and encoding defined by the representation 535 metadata header fields. 537 The data type of the representation data is determined via the header 538 fields Content-Type and Content-Encoding. These define a two-layer, 539 ordered encoding model: 541 representation-data := Content-Encoding( Content-Type( bits ) ) 543 Content-Type specifies the media type of the underlying data, which 544 defines both the data format and how that data SHOULD be processed by 545 the recipient (within the scope of the request method semantics). 546 Any HTTP/1.1 message containing a payload body SHOULD include a 547 Content-Type header field defining the media type of the associated 548 representation unless that metadata is unknown to the sender. If the 549 Content-Type header field is not present, it indicates that the 550 sender does not know the media type of the representation; recipients 551 MAY either assume that the media type is "application/octet-stream" 552 ([RFC2046], Section 4.5.1) or examine the content to determine its 553 type. 555 In practice, resource owners do not always properly configure their 556 origin server to provide the correct Content-Type for a given 557 representation, with the result that some clients will examine a 558 response body's content and override the specified type. Clients 559 that do so risk drawing incorrect conclusions, which might expose 560 additional security risks (e.g., "privilege escalation"). 561 Furthermore, it is impossible to determine the sender's intent by 562 examining the data format: many data formats match multiple media 563 types that differ only in processing semantics. Implementers are 564 encouraged to provide a means of disabling such "content sniffing" 565 when it is used. 567 Content-Encoding is used to indicate any additional content codings 568 applied to the data, usually for the purpose of data compression, 569 that are a property of the representation. If Content-Encoding is 570 not present, then there is no additional encoding beyond that defined 571 by the Content-Type. 573 5. Content Negotiation 575 HTTP responses include a representation which contains information 576 for interpretation, whether by a human user or for further 577 processing. Often, the server has different ways of representing the 578 same information; for example, in different formats, languages, or 579 using different character encodings. 581 HTTP clients and their users might have different or variable 582 capabilities, characteristics or preferences which would influence 583 which representation, among those available from the server, would be 584 best for the server to deliver. For this reason, HTTP provides 585 mechanisms for "content negotiation" -- a process of allowing 586 selection of a representation of a given resource, when more than one 587 is available. 589 This specification defines two patterns of content negotiation; 590 "server-driven", where the server selects the representation based 591 upon the client's stated preferences, and "agent-driven" negotiation, 592 where the server provides a list of representations for the client to 593 choose from, based upon their metadata. In addition, there are other 594 patterns: some applications use an "active content" pattern, where 595 the server returns active content which runs on the client and, based 596 on client available parameters, selects additional resources to 597 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 598 proposed. 600 These patterns are all widely used, and have trade-offs in 601 applicability and practicality. In particular, when the number of 602 preferences or capabilities to be expressed by a client are large 603 (such as when many different formats are supported by a user-agent), 604 server-driven negotiation becomes unwieldy, and might not be 605 appropriate. Conversely, when the number of representations to 606 choose from is very large, agent-driven negotiation might not be 607 appropriate. 609 Note that in all cases, the supplier of representations has the 610 responsibility for determining which representations might be 611 considered to be the "same information". 613 5.1. Server-driven Negotiation 615 If the selection of the best representation for a response is made by 616 an algorithm located at the server, it is called server-driven 617 negotiation. Selection is based on the available representations of 618 the response (the dimensions over which it can vary; e.g., language, 619 content-coding, etc.) and the contents of particular header fields in 620 the request message or on other information pertaining to the request 621 (such as the network address of the client). 623 Server-driven negotiation is advantageous when the algorithm for 624 selecting from among the available representations is difficult to 625 describe to the user agent, or when the server desires to send its 626 "best guess" to the client along with the first response (hoping to 627 avoid the round-trip delay of a subsequent request if the "best 628 guess" is good enough for the user). In order to improve the 629 server's guess, the user agent MAY include request header fields 630 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 631 preferences for such a response. 633 Server-driven negotiation has disadvantages: 635 1. It is impossible for the server to accurately determine what 636 might be "best" for any given user, since that would require 637 complete knowledge of both the capabilities of the user agent and 638 the intended use for the response (e.g., does the user want to 639 view it on screen or print it on paper?). 641 2. Having the user agent describe its capabilities in every request 642 can be both very inefficient (given that only a small percentage 643 of responses have multiple representations) and a potential 644 violation of the user's privacy. 646 3. It complicates the implementation of an origin server and the 647 algorithms for generating responses to a request. 649 4. It might limit a public cache's ability to use the same response 650 for multiple user's requests. 652 Server-driven negotiation allows the user agent to specify its 653 preferences, but it cannot expect responses to always honour them. 654 For example, the origin server might not implement server-driven 655 negotiation, or it might decide that sending a response that doesn't 656 conform to them is better than sending a 406 (Not Acceptable) 657 response. 659 Many of the mechanisms for expressing preferences use quality values 660 to declare relative preference. See Section 6.4 of [Part1] for more 661 information. 663 HTTP/1.1 includes the following header fields for enabling server- 664 driven negotiation through description of user agent capabilities and 665 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 666 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 667 User-Agent (Section 9.9 of [Part2]). However, an origin server is 668 not limited to these dimensions and MAY vary the response based on 669 any aspect of the request, including aspects of the connection (e.g., 670 IP address) or information within extension header fields not defined 671 by this specification. 673 Note: In practice, User-Agent based negotiation is fragile, 674 because new clients might not be recognized. 676 The Vary header field (Section 3.5 of [Part6]) can be used to express 677 the parameters the server uses to select a representation that is 678 subject to server-driven negotiation. 680 5.2. Agent-driven Negotiation 682 With agent-driven negotiation, selection of the best representation 683 for a response is performed by the user agent after receiving an 684 initial response from the origin server. Selection is based on a 685 list of the available representations of the response included within 686 the header fields or body of the initial response, with each 687 representation identified by its own URI. Selection from among the 688 representations can be performed automatically (if the user agent is 689 capable of doing so) or manually by the user selecting from a 690 generated (possibly hypertext) menu. 692 Agent-driven negotiation is advantageous when the response would vary 693 over commonly-used dimensions (such as type, language, or encoding), 694 when the origin server is unable to determine a user agent's 695 capabilities from examining the request, and generally when public 696 caches are used to distribute server load and reduce network usage. 698 Agent-driven negotiation suffers from the disadvantage of needing a 699 second request to obtain the best alternate representation. This 700 second request is only efficient when caching is used. In addition, 701 this specification does not define any mechanism for supporting 702 automatic selection, though it also does not prevent any such 703 mechanism from being developed as an extension and used within 704 HTTP/1.1. 706 This specification defines the 300 (Multiple Choices) and 406 (Not 707 Acceptable) status codes for enabling agent-driven negotiation when 708 the server is unwilling or unable to provide a varying response using 709 server-driven negotiation. 711 6. Header Field Definitions 713 This section defines the syntax and semantics of HTTP/1.1 header 714 fields related to the payload of messages. 716 6.1. Accept 718 The "Accept" header field can be used by user agents to specify 719 response media types that are acceptable. Accept header fields can 720 be used to indicate that the request is specifically limited to a 721 small set of desired types, as in the case of a request for an in- 722 line image. 724 Accept = #( media-range [ accept-params ] ) 726 media-range = ( "*/*" 727 / ( type "/" "*" ) 728 / ( type "/" subtype ) 729 ) *( OWS ";" OWS parameter ) 730 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 731 accept-ext = OWS ";" OWS token [ "=" word ] 733 The asterisk "*" character is used to group media types into ranges, 734 with "*/*" indicating all media types and "type/*" indicating all 735 subtypes of that type. The media-range MAY include media type 736 parameters that are applicable to that range. 738 Each media-range MAY be followed by one or more accept-params, 739 beginning with the "q" parameter for indicating a relative quality 740 factor. The first "q" parameter (if any) separates the media-range 741 parameter(s) from the accept-params. Quality factors allow the user 742 or user agent to indicate the relative degree of preference for that 743 media-range, using the qvalue scale from 0 to 1 (Section 6.4 of 744 [Part1]). The default value is q=1. 746 Note: Use of the "q" parameter name to separate media type 747 parameters from Accept extension parameters is due to historical 748 practice. Although this prevents any media type parameter named 749 "q" from being used with a media range, such an event is believed 750 to be unlikely given the lack of any "q" parameters in the IANA 751 media type registry and the rare usage of any media type 752 parameters in Accept. Future media types are discouraged from 753 registering any parameter named "q". 755 The example 757 Accept: audio/*; q=0.2, audio/basic 759 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 760 type if it is the best available after an 80% mark-down in quality". 762 If no Accept header field is present, then it is assumed that the 763 client accepts all media types. If an Accept header field is present 764 in a request, but the server cannot send a response which is 765 acceptable, then the server can either send a response in another 766 format, or a 406 (Not Acceptable) response. 768 A more elaborate example is 770 Accept: text/plain; q=0.5, text/html, 771 text/x-dvi; q=0.8, text/x-c 773 Verbally, this would be interpreted as "text/html and text/x-c are 774 the preferred media types, but if they do not exist, then send the 775 text/x-dvi representation, and if that does not exist, send the text/ 776 plain representation". 778 Media ranges can be overridden by more specific media ranges or 779 specific media types. If more than one media range applies to a 780 given type, the most specific reference has precedence. For example, 782 Accept: text/*, text/plain, text/plain;format=flowed, */* 784 have the following precedence: 786 1. text/plain;format=flowed 788 2. text/plain 790 3. text/* 792 4. */* 793 The media type quality factor associated with a given type is 794 determined by finding the media range with the highest precedence 795 which matches that type. For example, 797 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 798 text/html;level=2;q=0.4, */*;q=0.5 800 would cause the following values to be associated: 802 +-------------------+---------------+ 803 | Media Type | Quality Value | 804 +-------------------+---------------+ 805 | text/html;level=1 | 1 | 806 | text/html | 0.7 | 807 | text/plain | 0.3 | 808 | image/jpeg | 0.5 | 809 | text/html;level=2 | 0.4 | 810 | text/html;level=3 | 0.7 | 811 +-------------------+---------------+ 813 Note: A user agent might be provided with a default set of quality 814 values for certain media ranges. However, unless the user agent is a 815 closed system which cannot interact with other rendering agents, this 816 default set ought to be configurable by the user. 818 6.2. Accept-Charset 820 The "Accept-Charset" header field can be used by user agents to 821 indicate what character encodings are acceptable in a response 822 payload. This field allows clients capable of understanding more 823 comprehensive or special-purpose character encodings to signal that 824 capability to a server which is capable of representing documents in 825 those character encodings. 827 Accept-Charset = 1#( ( charset / "*" ) 828 [ OWS ";" OWS "q=" qvalue ] ) 830 Character encoding values (a.k.a., charsets) are described in 831 Section 2.1. Each charset MAY be given an associated quality value 832 which represents the user's preference for that charset. The default 833 value is q=1. An example is 835 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 837 The special value "*", if present in the Accept-Charset field, 838 matches every character encoding which is not mentioned elsewhere in 839 the Accept-Charset field. If no "*" is present in an Accept-Charset 840 field, then all character encodings not explicitly mentioned get a 841 quality value of 0. 843 If no Accept-Charset header field is present, the default is that any 844 character encoding is acceptable. If an Accept-Charset header field 845 is present in a request, but the server cannot send a response which 846 is acceptable, then the server can either use another character 847 encoding, or send a 406 (Not Acceptable) response. 849 6.3. Accept-Encoding 851 The "Accept-Encoding" header field can be used by user agents to 852 indicate what response content-codings (Section 2.2) are acceptable 853 in the response. 855 Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) 856 codings = ( content-coding / "*" ) 858 Each codings value MAY be given an associated quality value which 859 represents the preference for that encoding. The default value is 860 q=1. 862 Examples of its use are: 864 Accept-Encoding: compress, gzip 865 Accept-Encoding: 866 Accept-Encoding: * 867 Accept-Encoding: compress;q=0.5, gzip;q=1.0 868 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 870 A server tests whether a content-coding is acceptable, according to 871 an Accept-Encoding field, using these rules: 873 1. If the content-coding is one of the content-codings listed in the 874 Accept-Encoding field, then it is acceptable, unless it is 875 accompanied by a qvalue of 0. (As defined in Section 6.4 of 876 [Part1], a qvalue of 0 means "not acceptable".) 878 2. The special "*" symbol in an Accept-Encoding field matches any 879 available content-coding not explicitly listed in the header 880 field. 882 3. If multiple content-codings are acceptable, then the acceptable 883 content-coding with the highest non-zero qvalue is preferred. 885 4. The "identity" content-coding is always acceptable, unless 886 specifically refused because the Accept-Encoding field includes 887 "identity;q=0", or because the field includes "*;q=0" and does 888 not explicitly include the "identity" content-coding. If the 889 Accept-Encoding field-value is empty, then only the "identity" 890 encoding is acceptable. 892 If an Accept-Encoding field is present in a request, but the server 893 cannot send a response which is acceptable, then the server SHOULD 894 send a response without any encoding (i.e., the "identity" encoding). 896 If no Accept-Encoding field is present in a request, the server MAY 897 assume that the client will accept any content coding. In this case, 898 if "identity" is one of the available content-codings, then the 899 server SHOULD use the "identity" content-coding, unless it has 900 additional information that a different content-coding is meaningful 901 to the client. 903 Note: If the request does not include an Accept-Encoding field, 904 and if the "identity" content-coding is unavailable, then content- 905 codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and 906 "compress") are preferred; some older clients improperly display 907 messages sent with other content-codings. The server might also 908 make this decision based on information about the particular user- 909 agent or client. 911 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 912 associated with content-codings. This means that qvalues will not 913 work and are not permitted with x-gzip or x-compress. 915 6.4. Accept-Language 917 The "Accept-Language" header field can be used by user agents to 918 indicate the set of natural languages that are preferred in the 919 response. Language tags are defined in Section 2.4. 921 Accept-Language = 922 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 923 language-range = 924 926 Each language-range can be given an associated quality value which 927 represents an estimate of the user's preference for the languages 928 specified by that range. The quality value defaults to "q=1". For 929 example, 931 Accept-Language: da, en-gb;q=0.8, en;q=0.7 933 would mean: "I prefer Danish, but will accept British English and 934 other types of English". (see also Section 2.3 of [RFC4647]) 936 For matching, Section 3 of [RFC4647] defines several matching 937 schemes. Implementations can offer the most appropriate matching 938 scheme for their requirements. 940 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 941 identical to the matching scheme that was previously defined in 942 Section 14.4 of [RFC2616]. 944 It might be contrary to the privacy expectations of the user to send 945 an Accept-Language header field with the complete linguistic 946 preferences of the user in every request. For a discussion of this 947 issue, see Section 8.1. 949 As intelligibility is highly dependent on the individual user, it is 950 recommended that client applications make the choice of linguistic 951 preference available to the user. If the choice is not made 952 available, then the Accept-Language header field MUST NOT be given in 953 the request. 955 Note: When making the choice of linguistic preference available to 956 the user, we remind implementors of the fact that users are not 957 familiar with the details of language matching as described above, 958 and ought to be provided appropriate guidance. As an example, 959 users might assume that on selecting "en-gb", they will be served 960 any kind of English document if British English is not available. 961 A user agent might suggest in such a case to add "en" to get the 962 best matching behavior. 964 6.5. Content-Encoding 966 The "Content-Encoding" header field indicates what content-codings 967 have been applied to the representation, and thus what decoding 968 mechanisms must be applied in order to obtain the media-type 969 referenced by the Content-Type header field. Content-Encoding is 970 primarily used to allow a representation to be compressed without 971 losing the identity of its underlying media type. 973 Content-Encoding = 1#content-coding 975 Content codings are defined in Section 2.2. An example of its use is 977 Content-Encoding: gzip 979 The content-coding is a characteristic of the representation. 980 Typically, the representation body is stored with this encoding and 981 is only decoded before rendering or analogous usage. However, a 982 transforming proxy MAY modify the content-coding if the new coding is 983 known to be acceptable to the recipient, unless the "no-transform" 984 cache-control directive is present in the message. 986 If the content-coding of a representation is not "identity", then the 987 representation metadata MUST include a Content-Encoding header field 988 (Section 6.5) that lists the non-identity content-coding(s) used. 990 If the content-coding of a representation in a request message is not 991 acceptable to the origin server, the server SHOULD respond with a 992 status code of 415 (Unsupported Media Type). 994 If multiple encodings have been applied to a representation, the 995 content codings MUST be listed in the order in which they were 996 applied. Additional information about the encoding parameters MAY be 997 provided by other header fields not defined by this specification. 999 6.6. Content-Language 1001 The "Content-Language" header field describes the natural language(s) 1002 of the intended audience for the representation. Note that this 1003 might not be equivalent to all the languages used within the 1004 representation. 1006 Content-Language = 1#language-tag 1008 Language tags are defined in Section 2.4. The primary purpose of 1009 Content-Language is to allow a user to identify and differentiate 1010 representations according to the user's own preferred language. 1011 Thus, if the body content is intended only for a Danish-literate 1012 audience, the appropriate field is 1014 Content-Language: da 1016 If no Content-Language is specified, the default is that the content 1017 is intended for all language audiences. This might mean that the 1018 sender does not consider it to be specific to any natural language, 1019 or that the sender does not know for which language it is intended. 1021 Multiple languages MAY be listed for content that is intended for 1022 multiple audiences. For example, a rendition of the "Treaty of 1023 Waitangi", presented simultaneously in the original Maori and English 1024 versions, would call for 1026 Content-Language: mi, en 1028 However, just because multiple languages are present within a 1029 representation does not mean that it is intended for multiple 1030 linguistic audiences. An example would be a beginner's language 1031 primer, such as "A First Lesson in Latin", which is clearly intended 1032 to be used by an English-literate audience. In this case, the 1033 Content-Language would properly only include "en". 1035 Content-Language MAY be applied to any media type -- it is not 1036 limited to textual documents. 1038 6.7. Content-Location 1040 The "Content-Location" header field supplies a URI that can be used 1041 as a specific identifier for the representation in this message. In 1042 other words, if one were to perform a GET on this URI at the time of 1043 this message's generation, then a 200 response would contain the same 1044 representation that is enclosed as payload in this message. 1046 Content-Location = absolute-URI / partial-URI 1048 The Content-Location value is not a replacement for the effective 1049 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1050 It has the same syntax and semantics as the header field of the same 1051 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1052 its appearance in an HTTP message has some special implications for 1053 HTTP recipients. 1055 If Content-Location is included in a response message and its value 1056 is the same as the effective request URI, then the response payload 1057 SHOULD be considered the current representation of that resource. 1058 For a GET or HEAD request, this is the same as the default semantics 1059 when no Content-Location is provided by the server. For a state- 1060 changing request like PUT or POST, it implies that the server's 1061 response contains the new representation of that resource, thereby 1062 distinguishing it from representations that might only report about 1063 the action (e.g., "It worked!"). This allows authoring applications 1064 to update their local copies without the need for a subsequent GET 1065 request. 1067 If Content-Location is included in a response message and its value 1068 differs from the effective request URI, then the origin server is 1069 informing recipients that this representation has its own, presumably 1070 more specific, identifier. For a GET or HEAD request, this is an 1071 indication that the effective request URI identifies a resource that 1072 is subject to content negotiation and the representation selected for 1073 this response can also be found at the identified URI. For other 1074 methods, such a Content-Location indicates that this representation 1075 contains a report on the action's status and the same report is 1076 available (for future access with GET) at the given URI. For 1077 example, a purchase transaction made via a POST request might include 1078 a receipt document as the payload of the 200 response; the Content- 1079 Location value provides an identifier for retrieving a copy of that 1080 same receipt in the future. 1082 If Content-Location is included in a request message, then it MAY be 1083 interpreted by the origin server as an indication of where the user 1084 agent originally obtained the content of the enclosed representation 1085 (prior to any subsequent modification of the content by that user 1086 agent). In other words, the user agent is providing the same 1087 representation metadata that it received with the original 1088 representation. However, such interpretation MUST NOT be used to 1089 alter the semantics of the method requested by the client. For 1090 example, if a client makes a PUT request on a negotiated resource and 1091 the origin server accepts that PUT (without redirection), then the 1092 new set of values for that resource is expected to be consistent with 1093 the one representation supplied in that PUT; the Content-Location 1094 cannot be used as a form of reverse content selection that identifies 1095 only one of the negotiated representations to be updated. If the 1096 user agent had wanted the latter semantics, it would have applied the 1097 PUT directly to the Content-Location URI. 1099 A Content-Location field received in a request message is transitory 1100 information that SHOULD NOT be saved with other representation 1101 metadata for use in later responses. The Content-Location's value 1102 might be saved for use in other contexts, such as within source links 1103 or other metadata. 1105 A cache cannot assume that a representation with a Content-Location 1106 different from the URI used to retrieve it can be used to respond to 1107 later requests on that Content-Location URI. 1109 If the Content-Location value is a partial URI, the partial URI is 1110 interpreted relative to the effective request URI. 1112 6.8. Content-Type 1114 The "Content-Type" header field indicates the media type of the 1115 representation. In the case of responses to the HEAD method, the 1116 media type is that which would have been sent had the request been a 1117 GET. 1119 Content-Type = media-type 1121 Media types are defined in Section 2.3. An example of the field is 1123 Content-Type: text/html; charset=ISO-8859-4 1125 Further discussion of Content-Type is provided in Section 4.2. 1127 7. IANA Considerations 1128 7.1. Header Field Registration 1130 The Message Header Field Registry located at shall be 1132 updated with the permanent registrations below (see [RFC3864]): 1134 +-------------------+----------+----------+--------------+ 1135 | Header Field Name | Protocol | Status | Reference | 1136 +-------------------+----------+----------+--------------+ 1137 | Accept | http | standard | Section 6.1 | 1138 | Accept-Charset | http | standard | Section 6.2 | 1139 | Accept-Encoding | http | standard | Section 6.3 | 1140 | Accept-Language | http | standard | Section 6.4 | 1141 | Content-Encoding | http | standard | Section 6.5 | 1142 | Content-Language | http | standard | Section 6.6 | 1143 | Content-Location | http | standard | Section 6.7 | 1144 | Content-Type | http | standard | Section 6.8 | 1145 | MIME-Version | http | standard | Appendix A.1 | 1146 +-------------------+----------+----------+--------------+ 1148 The change controller is: "IETF (iesg@ietf.org) - Internet 1149 Engineering Task Force". 1151 7.2. Content Coding Registry 1153 The registration procedure for HTTP Content Codings is now defined by 1154 Section 2.2.1 of this document. 1156 The HTTP Content Codings Registry located at 1157 shall be updated 1158 with the registration below: 1160 +----------+-----------------------------------------+--------------+ 1161 | Name | Description | Reference | 1162 +----------+-----------------------------------------+--------------+ 1163 | compress | UNIX "compress" program method | Section | 1164 | | | 6.2.2.1 of | 1165 | | | [Part1] | 1166 | deflate | "deflate" compression mechanism | Section | 1167 | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | 1168 | | format ([RFC1950]) | [Part1] | 1169 | gzip | Same as GNU zip [RFC1952] | Section | 1170 | | | 6.2.2.3 of | 1171 | | | [Part1] | 1172 | identity | No transformation | Section 2.2 | 1173 +----------+-----------------------------------------+--------------+ 1175 8. Security Considerations 1177 This section is meant to inform application developers, information 1178 providers, and users of the security limitations in HTTP/1.1 as 1179 described by this document. The discussion does not include 1180 definitive solutions to the problems revealed, though it does make 1181 some suggestions for reducing security risks. 1183 8.1. Privacy Issues Connected to Accept Header Fields 1185 Accept headers fields can reveal information about the user to all 1186 servers which are accessed. The Accept-Language header field in 1187 particular can reveal information the user would consider to be of a 1188 private nature, because the understanding of particular languages is 1189 often strongly correlated to the membership of a particular ethnic 1190 group. User agents which offer the option to configure the contents 1191 of an Accept-Language header field to be sent in every request are 1192 strongly encouraged to let the configuration process include a 1193 message which makes the user aware of the loss of privacy involved. 1195 An approach that limits the loss of privacy would be for a user agent 1196 to omit the sending of Accept-Language header fields by default, and 1197 to ask the user whether or not to start sending Accept-Language 1198 header fields to a server if it detects, by looking for any Vary 1199 header fields generated by the server, that such sending could 1200 improve the quality of service. 1202 Elaborate user-customized accept header fields sent in every request, 1203 in particular if these include quality values, can be used by servers 1204 as relatively reliable and long-lived user identifiers. Such user 1205 identifiers would allow content providers to do click-trail tracking, 1206 and would allow collaborating content providers to match cross-server 1207 click-trails or form submissions of individual users. Note that for 1208 many users not behind a proxy, the network address of the host 1209 running the user agent will also serve as a long-lived user 1210 identifier. In environments where proxies are used to enhance 1211 privacy, user agents ought to be conservative in offering accept 1212 header configuration options to end users. As an extreme privacy 1213 measure, proxies could filter the accept header fields in relayed 1214 requests. General purpose user agents which provide a high degree of 1215 header configurability SHOULD warn users about the loss of privacy 1216 which can be involved. 1218 9. Acknowledgments 1220 See Section 12 of [Part1]. 1222 10. References 1223 10.1. Normative References 1225 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1226 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1227 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1228 and Message Parsing", draft-ietf-httpbis-p1-messaging-16 1229 (work in progress), August 2011. 1231 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1232 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1233 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1234 Semantics", draft-ietf-httpbis-p2-semantics-16 (work in 1235 progress), August 2011. 1237 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1238 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1239 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1240 Requests", draft-ietf-httpbis-p4-conditional-16 (work in 1241 progress), August 2011. 1243 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1244 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1245 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1246 Partial Responses", draft-ietf-httpbis-p5-range-16 (work 1247 in progress), August 2011. 1249 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1250 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1251 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1252 6: Caching", draft-ietf-httpbis-p6-cache-16 (work in 1253 progress), August 2011. 1255 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1256 Specification version 3.3", RFC 1950, May 1996. 1258 RFC 1950 is an Informational RFC, thus it might be less 1259 stable than this specification. On the other hand, this 1260 downward reference was present since the publication of 1261 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1262 cause problems in practice. See also [BCP97]. 1264 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1265 version 1.3", RFC 1951, May 1996. 1267 RFC 1951 is an Informational RFC, thus it might be less 1268 stable than this specification. On the other hand, this 1269 downward reference was present since the publication of 1270 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1271 cause problems in practice. See also [BCP97]. 1273 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1274 Randers-Pehrson, "GZIP file format specification version 1275 4.3", RFC 1952, May 1996. 1277 RFC 1952 is an Informational RFC, thus it might be less 1278 stable than this specification. On the other hand, this 1279 downward reference was present since the publication of 1280 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 1281 cause problems in practice. See also [BCP97]. 1283 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1284 Extensions (MIME) Part One: Format of Internet Message 1285 Bodies", RFC 2045, November 1996. 1287 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1288 Extensions (MIME) Part Two: Media Types", RFC 2046, 1289 November 1996. 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, March 1997. 1294 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1295 Tags", BCP 47, RFC 4647, September 2006. 1297 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1298 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1300 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1301 Languages", BCP 47, RFC 5646, September 2009. 1303 10.2. Informative References 1305 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 1306 to Standards-Track Documents", BCP 97, RFC 4897, 1307 June 2007. 1309 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1310 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1312 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1313 Extensions (MIME) Part Five: Conformance Criteria and 1314 Examples", RFC 2049, November 1996. 1316 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1317 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1318 RFC 2068, January 1997. 1320 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1321 February 1997. 1323 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1324 Languages", BCP 18, RFC 2277, January 1998. 1326 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1327 in HTTP", RFC 2295, March 1998. 1329 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1330 form-data", RFC 2388, August 1998. 1332 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1333 "MIME Encapsulation of Aggregate Documents, such as HTML 1334 (MHTML)", RFC 2557, March 1999. 1336 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1337 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1338 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1340 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1341 10646", STD 63, RFC 3629, November 2003. 1343 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1344 Procedures for Message Header Fields", BCP 90, RFC 3864, 1345 September 2004. 1347 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1348 Registration Procedures", BCP 13, RFC 4288, December 2005. 1350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1351 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1352 May 2008. 1354 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1355 October 2008. 1357 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1358 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1359 RFC 6151, March 2011. 1361 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1362 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1363 June 2011. 1365 Appendix A. Differences between HTTP and MIME 1367 HTTP/1.1 uses many of the constructs defined for Internet Mail 1368 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1369 [RFC2045]) to allow a message-body to be transmitted in an open 1370 variety of representations and with extensible mechanisms. However, 1371 RFC 2045 discusses mail, and HTTP has a few features that are 1372 different from those described in MIME. These differences were 1373 carefully chosen to optimize performance over binary connections, to 1374 allow greater freedom in the use of new media types, to make date 1375 comparisons easier, and to acknowledge the practice of some early 1376 HTTP servers and clients. 1378 This appendix describes specific areas where HTTP differs from MIME. 1379 Proxies and gateways to strict MIME environments SHOULD be aware of 1380 these differences and provide the appropriate conversions where 1381 necessary. Proxies and gateways from MIME environments to HTTP also 1382 need to be aware of the differences because some conversions might be 1383 required. 1385 A.1. MIME-Version 1387 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1388 MAY include a single MIME-Version header field to indicate what 1389 version of the MIME protocol was used to construct the message. Use 1390 of the MIME-Version header field indicates that the message is in 1391 full compliance with the MIME protocol (as defined in [RFC2045]). 1392 Proxies/gateways are responsible for ensuring full compliance (where 1393 possible) when exporting HTTP messages to strict MIME environments. 1395 MIME-Version = 1*DIGIT "." 1*DIGIT 1397 MIME version "1.0" is the default for use in HTTP/1.1. However, 1398 HTTP/1.1 message parsing and semantics are defined by this document 1399 and not the MIME specification. 1401 A.2. Conversion to Canonical Form 1403 MIME requires that an Internet mail body-part be converted to 1404 canonical form prior to being transferred, as described in Section 4 1405 of [RFC2049]. Section 2.3.1 of this document describes the forms 1406 allowed for subtypes of the "text" media type when transmitted over 1407 HTTP. [RFC2046] requires that content with a type of "text" 1408 represent line breaks as CRLF and forbids the use of CR or LF outside 1409 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1410 indicate a line break within text content when a message is 1411 transmitted over HTTP. 1413 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1414 environment SHOULD translate all line breaks within the text media 1415 types described in Section 2.3.1 of this document to the RFC 2049 1416 canonical form of CRLF. Note, however, that this might be 1417 complicated by the presence of a Content-Encoding and by the fact 1418 that HTTP allows the use of some character encodings which do not use 1419 octets 13 and 10 to represent CR and LF, respectively, as is the case 1420 for some multi-byte character encodings. 1422 Conversion will break any cryptographic checksums applied to the 1423 original content unless the original content is already in canonical 1424 form. Therefore, the canonical form is recommended for any content 1425 that uses such checksums in HTTP. 1427 A.3. Conversion of Date Formats 1429 HTTP/1.1 uses a restricted set of date formats (Section 6.1 of 1430 [Part1]) to simplify the process of date comparison. Proxies and 1431 gateways from other protocols SHOULD ensure that any Date header 1432 field present in a message conforms to one of the HTTP/1.1 formats 1433 and rewrite the date if necessary. 1435 A.4. Introduction of Content-Encoding 1437 MIME does not include any concept equivalent to HTTP/1.1's Content- 1438 Encoding header field. Since this acts as a modifier on the media 1439 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1440 either change the value of the Content-Type header field or decode 1441 the representation before forwarding the message. (Some experimental 1442 applications of Content-Type for Internet mail have used a media-type 1443 parameter of ";conversions=" to perform a function 1444 equivalent to Content-Encoding. However, this parameter is not part 1445 of the MIME standards). 1447 A.5. No Content-Transfer-Encoding 1449 HTTP does not use the Content-Transfer-Encoding field of MIME. 1450 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1451 remove any Content-Transfer-Encoding prior to delivering the response 1452 message to an HTTP client. 1454 Proxies and gateways from HTTP to MIME-compliant protocols are 1455 responsible for ensuring that the message is in the correct format 1456 and encoding for safe transport on that protocol, where "safe 1457 transport" is defined by the limitations of the protocol being used. 1458 Such a proxy or gateway SHOULD label the data with an appropriate 1459 Content-Transfer-Encoding if doing so will improve the likelihood of 1460 safe transport over the destination protocol. 1462 A.6. Introduction of Transfer-Encoding 1464 HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 1465 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1466 to forwarding a message via a MIME-compliant protocol. 1468 A.7. MHTML and Line Length Limitations 1470 HTTP implementations which share code with MHTML [RFC2557] 1471 implementations need to be aware of MIME line length limitations. 1472 Since HTTP does not have this limitation, HTTP does not fold long 1473 lines. MHTML messages being transported by HTTP follow all 1474 conventions of MHTML, including line length limitations and folding, 1475 canonicalization, etc., since HTTP transports all message-bodies as 1476 payload (see Section 2.3.2) and does not interpret the content or any 1477 MIME header lines that might be contained therein. 1479 Appendix B. Additional Features 1481 [RFC1945] and [RFC2068] document protocol elements used by some 1482 existing HTTP implementations, but not consistently and correctly 1483 across most HTTP/1.1 applications. Implementors are advised to be 1484 aware of these features, but cannot rely upon their presence in, or 1485 interoperability with, other HTTP/1.1 applications. Some of these 1486 describe proposed experimental features, and some describe features 1487 that experimental deployment found lacking that are now addressed in 1488 the base HTTP/1.1 specification. 1490 A number of other header fields, such as Content-Disposition and 1491 Title, from SMTP and MIME are also often implemented (see [RFC6266] 1492 and [RFC2076]). 1494 Appendix C. Changes from RFC 2616 1496 Clarify contexts that charset is used in. (Section 2.1) 1498 Remove the default character encoding for text media types; the 1499 default now is whatever the media type definition says. 1500 (Section 2.3.1) 1502 Change ABNF productions for header fields to only define the field 1503 value. (Section 6) 1505 Remove definition of Content-MD5 header field because it was 1506 inconsistently implemented with respect to partial responses, and 1507 also because of known deficiencies in the hash algorithm itself (see 1508 [RFC6151] for details). (Section 6) 1509 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) 1511 Remove base URI setting semantics for Content-Location due to poor 1512 implementation support, which was caused by too many broken servers 1513 emitting bogus Content-Location header fields, and also the 1514 potentially undesirable effect of potentially breaking relative links 1515 in content-negotiated resources. (Section 6.7) 1517 Remove discussion of Content-Disposition header field, it is now 1518 defined by [RFC6266]. (Appendix B) 1520 Remove reference to non-existant identity transfer-coding value 1521 tokens. (Appendix A.5) 1523 Appendix D. Collected ABNF 1525 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1526 OWS media-range [ accept-params ] ] ) ] 1527 Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1528 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1529 qvalue ] ] ) 1530 Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) 1531 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1532 Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1533 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1534 ] ) 1536 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 1537 content-coding ] ) 1538 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 1539 language-tag ] ) 1540 Content-Location = absolute-URI / partial-URI 1541 Content-Type = media-type 1543 MIME-Version = 1*DIGIT "." 1*DIGIT 1545 OWS = 1547 absolute-URI = 1548 accept-ext = OWS ";" OWS token [ "=" word ] 1549 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1550 attribute = token 1552 charset = token 1553 codings = ( content-coding / "*" ) 1554 content-coding = token 1556 language-range = 1557 language-tag = 1559 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1560 ";" OWS parameter ) 1561 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1563 parameter = attribute "=" value 1564 partial-URI = 1566 qvalue = 1568 subtype = token 1570 token = 1571 type = token 1573 value = word 1575 word = 1577 ABNF diagnostics: 1579 ; Accept defined but not used 1580 ; Accept-Charset defined but not used 1581 ; Accept-Encoding defined but not used 1582 ; Accept-Language defined but not used 1583 ; Content-Encoding defined but not used 1584 ; Content-Language defined but not used 1585 ; Content-Location defined but not used 1586 ; Content-Type defined but not used 1587 ; MIME-Version defined but not used 1589 Appendix E. Change Log (to be removed by RFC Editor before publication) 1591 E.1. Since RFC 2616 1593 Extracted relevant partitions from [RFC2616]. 1595 E.2. Since draft-ietf-httpbis-p3-payload-00 1597 Closed issues: 1599 o : "Media Type 1600 Registrations" () 1602 o : "Clarification 1603 regarding quoting of charset values" 1604 () 1606 o : "Remove 1607 'identity' token references" 1608 () 1610 o : "Accept- 1611 Encoding BNF" 1613 o : "Normative and 1614 Informative references" 1616 o : "RFC1700 1617 references" 1619 o : "Updating to 1620 RFC4288" 1622 o : "Informative 1623 references" 1625 o : "ISO-8859-1 1626 Reference" 1628 o : "Encoding 1629 References Normative" 1631 o : "Normative up- 1632 to-date references" 1634 E.3. Since draft-ietf-httpbis-p3-payload-01 1636 Ongoing work on ABNF conversion 1637 (): 1639 o Add explicit references to BNF syntax and rules imported from 1640 other parts of the specification. 1642 E.4. Since draft-ietf-httpbis-p3-payload-02 1644 Closed issues: 1646 o : "Quoting 1647 Charsets" 1649 o : 1650 "Classification for Allow header" 1652 o : "missing 1653 default for qvalue in description of Accept-Encoding" 1655 Ongoing work on IANA Message Header Field Registration 1656 (): 1658 o Reference RFC 3984, and update header field registrations for 1659 headers defined in this document. 1661 E.5. Since draft-ietf-httpbis-p3-payload-03 1663 Closed issues: 1665 o : "Quoting 1666 Charsets" 1668 o : "language tag 1669 matching (Accept-Language) vs RFC4647" 1671 o : "RFC 1806 has 1672 been replaced by RFC2183" 1674 Other changes: 1676 o : "Encoding 1677 References Normative" -- rephrase the annotation and reference 1678 [BCP97]. 1680 E.6. Since draft-ietf-httpbis-p3-payload-04 1682 Closed issues: 1684 o : "RFC 2822 is 1685 updated by RFC 5322" 1687 Ongoing work on ABNF conversion 1688 (): 1690 o Use "/" instead of "|" for alternatives. 1692 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1693 whitespace ("OWS") and required whitespace ("RWS"). 1695 o Rewrite ABNFs to spell out whitespace rules, factor out header 1696 field value format definitions. 1698 E.7. Since draft-ietf-httpbis-p3-payload-05 1700 Closed issues: 1702 o : "Join 1703 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1705 Final work on ABNF conversion 1706 (): 1708 o Add appendix containing collected and expanded ABNF, reorganize 1709 ABNF introduction. 1711 Other changes: 1713 o Move definition of quality values into Part 1. 1715 E.8. Since draft-ietf-httpbis-p3-payload-06 1717 Closed issues: 1719 o : "Content- 1720 Location isn't special" 1722 o : "Content 1723 Sniffing" 1725 E.9. Since draft-ietf-httpbis-p3-payload-07 1727 Closed issues: 1729 o : "Updated 1730 reference for language tags" 1732 o : "Clarify rules 1733 for determining what entities a response carries" 1735 o : "Content- 1736 Location base-setting problems" 1738 o : "Content 1739 Sniffing" 1741 o : "pick IANA 1742 policy (RFC5226) for Transfer Coding / Content Coding" 1744 o : "move 1745 definitions of gzip/deflate/compress to part 1" 1747 Partly resolved issues: 1749 o : "update IANA 1750 requirements wrt Transfer-Coding values" (add the IANA 1751 Considerations subsection) 1753 o : "update IANA 1754 requirements wrt Content-Coding values" (add the IANA 1755 Considerations subsection) 1757 E.10. Since draft-ietf-httpbis-p3-payload-08 1759 Closed issues: 1761 o : "Content 1762 Negotiation for media types" 1764 o : "Accept- 1765 Language: which RFC4647 filtering?" 1767 E.11. Since draft-ietf-httpbis-p3-payload-09 1769 Closed issues: 1771 o : "MIME-Version 1772 not listed in P1, general header fields" 1774 o : "IANA registry 1775 for content/transfer encodings" 1777 o : "Content 1778 Sniffing" 1780 o : "use of term 1781 "word" when talking about header structure" 1783 Partly resolved issues: 1785 o : "Term for the 1786 requested resource's URI" 1788 E.12. Since draft-ietf-httpbis-p3-payload-10 1790 Closed issues: 1792 o : "Clarify 1793 'Requested Variant'" 1795 o : "Content- 1796 Location isn't special" 1798 o : "Delimiting 1799 messages with multipart/byteranges" 1801 o : "Clarify 1802 entity / representation / variant terminology" 1804 o : "confusing 1805 req. language for Content-Location" 1807 o : "Content- 1808 Location on 304 responses" 1810 o : "'requested 1811 resource' in content-encoding definition" 1813 o : "consider 1814 removing the 'changes from 2068' sections" 1816 Partly resolved issues: 1818 o : "Content-MD5 1819 and partial responses" 1821 E.13. Since draft-ietf-httpbis-p3-payload-11 1823 Closed issues: 1825 o : "Factor out 1826 Content-Disposition" 1828 E.14. Since draft-ietf-httpbis-p3-payload-12 1830 Closed issues: 1832 o : "Header 1833 Classification" 1835 o : "untangle 1836 ABNFs for header fields" 1838 o : "potentially 1839 misleading MAY in media-type def" 1841 E.15. Since draft-ietf-httpbis-p3-payload-13 1843 Closed issues: 1845 o : "Default 1846 charsets for text media types" 1848 o : "Content-MD5 1849 and partial responses" 1851 o : "untangle 1852 ABNFs for header fields" 1854 o : "confusing 1855 undefined parameter in media range example" 1857 E.16. Since draft-ietf-httpbis-p3-payload-14 1859 None. 1861 E.17. Since draft-ietf-httpbis-p3-payload-15 1863 Closed issues: 1865 o : "Strength of 1866 requirements on Accept re: 406" 1868 Index 1870 A 1871 Accept header field 16 1872 Accept-Charset header field 18 1873 Accept-Encoding header field 19 1874 Accept-Language header field 20 1876 C 1877 Coding Format 1878 compress 7 1879 deflate 7 1880 gzip 7 1881 identity 7 1882 compress (Coding Format) 7 1883 content negotiation 5 1884 Content-Encoding header field 21 1885 Content-Language header field 22 1886 Content-Location header field 23 1887 Content-Type header field 24 1889 D 1890 deflate (Coding Format) 7 1892 G 1893 Grammar 1894 Accept 16 1895 Accept-Charset 18 1896 Accept-Encoding 19 1897 accept-ext 16 1898 Accept-Language 20 1899 accept-params 16 1900 attribute 8 1901 charset 6 1902 codings 19 1903 content-coding 7 1904 Content-Encoding 21 1905 Content-Language 22 1906 Content-Location 23 1907 Content-Type 24 1908 language-range 20 1909 language-tag 10 1910 media-range 16 1911 media-type 8 1912 MIME-Version 30 1913 parameter 8 1914 subtype 8 1915 type 8 1916 value 8 1917 gzip (Coding Format) 7 1919 H 1920 Header Fields 1921 Accept 16 1922 Accept-Charset 18 1923 Accept-Encoding 19 1924 Accept-Language 20 1925 Content-Encoding 21 1926 Content-Language 22 1927 Content-Location 23 1928 Content-Type 24 1929 MIME-Version 30 1931 I 1932 identity (Coding Format) 7 1934 M 1935 MIME-Version header field 30 1937 P 1938 payload 10 1940 R 1941 representation 11 1943 Authors' Addresses 1945 Roy T. Fielding (editor) 1946 Adobe Systems Incorporated 1947 345 Park Ave 1948 San Jose, CA 95110 1949 USA 1951 EMail: fielding@gbiv.com 1952 URI: http://roy.gbiv.com/ 1954 Jim Gettys 1955 Alcatel-Lucent Bell Labs 1956 21 Oak Knoll Road 1957 Carlisle, MA 01741 1958 USA 1960 EMail: jg@freedesktop.org 1961 URI: http://gettys.wordpress.com/ 1963 Jeffrey C. Mogul 1964 Hewlett-Packard Company 1965 HP Labs, Large Scale Systems Group 1966 1501 Page Mill Road, MS 1177 1967 Palo Alto, CA 94304 1968 USA 1970 EMail: JeffMogul@acm.org 1972 Henrik Frystyk Nielsen 1973 Microsoft Corporation 1974 1 Microsoft Way 1975 Redmond, WA 98052 1976 USA 1978 EMail: henrikn@microsoft.com 1979 Larry Masinter 1980 Adobe Systems Incorporated 1981 345 Park Ave 1982 San Jose, CA 95110 1983 USA 1985 EMail: LMM@acm.org 1986 URI: http://larry.masinter.net/ 1988 Paul J. Leach 1989 Microsoft Corporation 1990 1 Microsoft Way 1991 Redmond, WA 98052 1993 EMail: paulle@microsoft.com 1995 Tim Berners-Lee 1996 World Wide Web Consortium 1997 MIT Computer Science and Artificial Intelligence Laboratory 1998 The Stata Center, Building 32 1999 32 Vassar Street 2000 Cambridge, MA 02139 2001 USA 2003 EMail: timbl@w3.org 2004 URI: http://www.w3.org/People/Berners-Lee/ 2006 Yves Lafon (editor) 2007 World Wide Web Consortium 2008 W3C / ERCIM 2009 2004, rte des Lucioles 2010 Sophia-Antipolis, AM 06902 2011 France 2013 EMail: ylafon@w3.org 2014 URI: http://www.raubacapeu.net/people/yves/ 2015 Julian F. Reschke (editor) 2016 greenbytes GmbH 2017 Hafenweg 16 2018 Muenster, NW 48155 2019 Germany 2021 Phone: +49 251 2807760 2022 Fax: +49 251 2807761 2023 EMail: julian.reschke@greenbytes.de 2024 URI: http://greenbytes.de/tech/webdav/