idnits 2.17.1 draft-ietf-httpbis-p3-payload-19.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2012) is 4418 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-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-19 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-19 ** 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 (~~), 6 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) Y. Lafon, Ed. 5 Intended status: Standards Track W3C 6 Expires: September 13, 2012 J. Reschke, Ed. 7 greenbytes 8 March 12, 2012 10 HTTP/1.1, part 3: Message Payload and Content Negotiation 11 draft-ietf-httpbis-p3-payload-19 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is an application-level 16 protocol for distributed, collaborative, hypertext information 17 systems. HTTP has been in use by the World Wide Web global 18 information initiative since 1990. This document is Part 3 of the 19 seven-part specification that defines the protocol referred to as 20 "HTTP/1.1" and, taken together, obsoletes RFC 2616. 22 Part 3 defines HTTP message content, metadata, and content 23 negotiation. 25 Editorial Note (To be removed by RFC Editor) 27 Discussion of this draft should take place on the HTTPBIS working 28 group mailing list (ietf-http-wg@w3.org), which is archived at 29 . 31 The current issues list is at 32 and related 33 documents (including fancy diffs) can be found at 34 . 36 The changes in this draft are summarized in Appendix E.20. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 13, 2012. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 86 1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5 87 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 88 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 89 1.3.2. ABNF Rules defined in other Parts of the 90 Specification . . . . . . . . . . . . . . . . . . . . 6 91 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 92 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 7 93 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 94 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 95 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 96 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 97 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 98 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 99 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 101 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 102 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 103 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 104 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 105 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 106 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 107 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 108 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 109 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 111 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 112 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 113 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 114 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 115 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 116 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 118 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 119 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 26 120 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 121 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 27 122 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 123 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 124 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 125 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 126 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 127 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 128 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 129 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 130 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 131 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 132 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 133 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 134 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 135 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 33 136 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 137 Appendix E. Change Log (to be removed by RFC Editor before 138 publication) . . . . . . . . . . . . . . . . . . . . 35 139 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 35 140 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 141 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 142 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 143 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 144 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 145 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 37 146 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 147 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 38 148 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 149 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39 150 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 39 151 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 40 152 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 40 153 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 40 154 E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 155 E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 41 156 E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 41 157 E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 41 158 E.20. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . . 41 159 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 161 1. Introduction 163 This document defines HTTP/1.1 message payloads (a.k.a., content), 164 the associated metadata header fields that define how the payload is 165 intended to be interpreted by a recipient, the request header fields 166 that might influence content selection, and the various selection 167 algorithms that are collectively referred to as HTTP content 168 negotiation. 170 This document is currently disorganized in order to minimize the 171 changes between drafts and enable reviewers to see the smaller errata 172 changes. A future draft will reorganize the sections to better 173 reflect the content. In particular, the sections on entities will be 174 renamed payload and moved to the first half of the document, while 175 the sections on content negotiation and associated request header 176 fields will be moved to the second half. The current mess reflects 177 how widely dispersed these topics and associated requirements had 178 become in [RFC2616]. 180 1.1. Terminology 182 This specification uses a number of terms to refer to the roles 183 played by participants in, and objects of, the HTTP communication. 185 content negotiation 187 The mechanism for selecting the appropriate representation when 188 servicing a request. The representation in any response can be 189 negotiated (including error responses). 191 selected representation 193 The current representation of the target resource that would have 194 been selected in a successful response if the same request had 195 used the method GET and excluded any conditional request header 196 fields. 198 1.2. Conformance and Error Handling 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 This document defines conformance criteria for several roles in HTTP 205 communication, including Senders, Recipients, Clients, Servers, User- 206 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 207 Section 2 of [Part1] for definitions of these terms. 209 An implementation is considered conformant if it complies with all of 210 the requirements associated with its role(s). Note that SHOULD-level 211 requirements are relevant here, unless one of the documented 212 exceptions is applicable. 214 This document also uses ABNF to define valid protocol elements 215 (Section 1.3). In addition to the prose requirements placed upon 216 them, Senders MUST NOT generate protocol elements that are invalid. 218 Unless noted otherwise, Recipients MAY take steps to recover a usable 219 protocol element from an invalid construct. However, HTTP does not 220 define specific error handling mechanisms, except in cases where it 221 has direct impact on security. This is because different uses of the 222 protocol require different error handling strategies; for example, a 223 Web browser may wish to transparently recover from a response where 224 the Location header field doesn't parse according to the ABNF, 225 whereby in a systems control protocol using HTTP, this type of error 226 recovery could lead to dangerous consequences. 228 1.3. Syntax Notation 230 This specification uses the Augmented Backus-Naur Form (ABNF) 231 notation of [RFC5234] with the list rule extension defined in Section 232 1.2 of [Part1]. Appendix D shows the collected ABNF with the list 233 rule expanded. 235 The following core rules are included by reference, as defined in 236 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 237 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 238 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 239 sequence of data), SP (space), and VCHAR (any visible US-ASCII 240 character). 242 1.3.1. Core Rules 244 The core rules below are defined in [Part1]: 246 OWS = 247 token = 248 word = 250 1.3.2. ABNF Rules defined in other Parts of the Specification 252 The ABNF rules below are defined in other parts: 254 absolute-URI = 255 partial-URI = 256 qvalue = 258 2. Protocol Parameters 260 2.1. Character Encodings (charset) 262 HTTP uses charset names to indicate the character encoding of a 263 textual representation. 265 A character encoding is identified by a case-insensitive token. The 266 complete set of tokens is defined by the IANA Character Set registry 267 (). 269 charset = token 271 Although HTTP allows an arbitrary token to be used as a charset 272 value, any token that has a predefined value within the IANA 273 Character Set registry MUST represent the character encoding defined 274 by that registry. Applications SHOULD limit their use of character 275 encodings to those defined within the IANA registry. 277 HTTP uses charset in two contexts: within an Accept-Charset request 278 header field (in which the charset value is an unquoted token) and as 279 the value of a parameter in a Content-Type header field (within a 280 request or response), in which case the parameter value of the 281 charset parameter can be quoted. 283 Implementors need to be aware of IETF character set requirements 284 [RFC3629] [RFC2277]. 286 2.2. Content Codings 288 Content coding values indicate an encoding transformation that has 289 been or can be applied to a representation. Content codings are 290 primarily used to allow a representation to be compressed or 291 otherwise usefully transformed without losing the identity of its 292 underlying media type and without loss of information. Frequently, 293 the representation is stored in coded form, transmitted directly, and 294 only decoded by the recipient. 296 content-coding = token 298 All content-coding values are case-insensitive. HTTP/1.1 uses 299 content-coding values in the Accept-Encoding (Section 6.3) and 300 Content-Encoding (Section 6.5) header fields. Although the value 301 describes the content-coding, what is more important is that it 302 indicates what decoding mechanism will be required to remove the 303 encoding. 305 compress 306 See Section 4.2.1 of [Part1]. 308 deflate 310 See Section 4.2.2 of [Part1]. 312 gzip 314 See Section 4.2.3 of [Part1]. 316 2.2.1. Content Coding Registry 318 The HTTP Content Coding Registry defines the name space for the 319 content coding names. 321 Registrations MUST include the following fields: 323 o Name 325 o Description 327 o Pointer to specification text 329 Names of content codings MUST NOT overlap with names of transfer 330 codings (Section 4 of [Part1]), unless the encoding transformation is 331 identical (as is the case for the compression codings defined in 332 Section 4.2 of [Part1]). 334 Values to be added to this name space require IETF Review (see 335 Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 336 coding defined in this section. 338 The registry itself is maintained at 339 . 341 2.3. Media Types 343 HTTP uses Internet Media Types [RFC2046] in the Content-Type 344 (Section 6.8) and Accept (Section 6.1) header fields in order to 345 provide open and extensible data typing and type negotiation. 347 media-type = type "/" subtype *( OWS ";" OWS parameter ) 348 type = token 349 subtype = token 351 The type/subtype MAY be followed by parameters in the form of 352 attribute/value pairs. 354 parameter = attribute "=" value 355 attribute = token 356 value = word 358 The type, subtype, and parameter attribute names are case- 359 insensitive. Parameter values might or might not be case-sensitive, 360 depending on the semantics of the parameter name. The presence or 361 absence of a parameter might be significant to the processing of a 362 media-type, depending on its definition within the media type 363 registry. 365 A parameter value that matches the token production can be 366 transmitted as either a token or within a quoted-string. The quoted 367 and unquoted values are equivalent. 369 Note that some older HTTP applications do not recognize media type 370 parameters. When sending data to older HTTP applications, 371 implementations SHOULD only use media type parameters when they are 372 required by that type/subtype definition. 374 Media-type values are registered with the Internet Assigned Number 375 Authority (IANA). The media type registration process is outlined in 376 [RFC4288]. Use of non-registered media types is discouraged. 378 2.3.1. Canonicalization and Text Defaults 380 Internet media types are registered with a canonical form. A 381 representation transferred via HTTP messages MUST be in the 382 appropriate canonical form prior to its transmission except for 383 "text" types, as defined in the next paragraph. 385 When in canonical form, media subtypes of the "text" type use CRLF as 386 the text line break. HTTP relaxes this requirement and allows the 387 transport of text media with plain CR or LF alone representing a line 388 break when it is done consistently for an entire representation. 389 HTTP applications MUST accept CRLF, bare CR, and bare LF as 390 indicating a line break in text media received via HTTP. In 391 addition, if the text is in a character encoding that does not use 392 octets 13 and 10 for CR and LF respectively, as is the case for some 393 multi-byte character encodings, HTTP allows the use of whatever octet 394 sequences are defined by that character encoding to represent the 395 equivalent of CR and LF for line breaks. This flexibility regarding 396 line breaks applies only to text media in the payload body; a bare CR 397 or LF MUST NOT be substituted for CRLF within any of the HTTP control 398 structures (such as header fields and multipart boundaries). 400 If a representation is encoded with a content-coding, the underlying 401 data MUST be in a form defined above prior to being encoded. 403 2.3.2. Multipart Types 405 MIME provides for a number of "multipart" types -- encapsulations of 406 one or more representations within a single message body. All 407 multipart types share a common syntax, as defined in Section 5.1.1 of 408 [RFC2046], and MUST include a boundary parameter as part of the media 409 type value. The message body is itself a protocol element and MUST 410 therefore use only CRLF to represent line breaks between body-parts. 412 In general, HTTP treats a multipart message body no differently than 413 any other media type: strictly as payload. HTTP does not use the 414 multipart boundary as an indicator of message body length. In all 415 other respects, an HTTP user agent SHOULD follow the same or similar 416 behavior as a MIME user agent would upon receipt of a multipart type. 417 The MIME header fields within each body-part of a multipart message 418 body do not have any significance to HTTP beyond that defined by 419 their MIME semantics. 421 If an application receives an unrecognized multipart subtype, the 422 application MUST treat it as being equivalent to "multipart/mixed". 424 Note: The "multipart/form-data" type has been specifically defined 425 for carrying form data suitable for processing via the POST 426 request method, as described in [RFC2388]. 428 2.4. Language Tags 430 A language tag, as defined in [RFC5646], identifies a natural 431 language spoken, written, or otherwise conveyed by human beings for 432 communication of information to other human beings. Computer 433 languages are explicitly excluded. HTTP uses language tags within 434 the Accept-Language and Content-Language fields. 436 In summary, a language tag is composed of one or more parts: A 437 primary language subtag followed by a possibly empty series of 438 subtags: 440 language-tag = 442 White space is not allowed within the tag and all tags are case- 443 insensitive. The name space of language subtags is administered by 444 the IANA (see 445 ). 447 Example tags include: 449 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 451 See [RFC5646] for further information. 453 3. Payload 455 HTTP messages MAY transfer a payload if not otherwise restricted by 456 the request method or response status code. The payload consists of 457 metadata, in the form of header fields, and data, in the form of the 458 sequence of octets in the message body after any transfer-coding has 459 been decoded. 461 A "payload" in HTTP is always a partial or complete representation of 462 some resource. We use separate terms for payload and representation 463 because some messages contain only the associated representation's 464 header fields (e.g., responses to HEAD) or only some part(s) of the 465 representation (e.g., the 206 status code). 467 3.1. Payload Header Fields 469 HTTP header fields that specifically define the payload, rather than 470 the associated representation, are referred to as "payload header 471 fields". The following payload header fields are defined by 472 HTTP/1.1: 474 +-------------------+--------------------------+ 475 | Header Field Name | Defined in... | 476 +-------------------+--------------------------+ 477 | Content-Length | Section 3.3.2 of [Part1] | 478 | Content-Range | Section 5.2 of [Part5] | 479 +-------------------+--------------------------+ 481 3.2. Payload Body 483 A payload body is only present in a message when a message body is 484 present, as described in Section 3.3 of [Part1]. The payload body is 485 obtained from the message body by decoding any Transfer-Encoding that 486 might have been applied to ensure safe and proper transfer of the 487 message. 489 4. Representation 491 A "representation" is information in a format that can be readily 492 communicated from one party to another. A resource representation is 493 information that reflects the state of that resource, as observed at 494 some point in the past (e.g., in a response to GET) or to be desired 495 at some point in the future (e.g., in a PUT request). 497 Most, but not all, representations transferred via HTTP are intended 498 to be a representation of the target resource (the resource 499 identified by the effective request URI). The precise semantics of a 500 representation are determined by the type of message (request or 501 response), the request method, the response status code, and the 502 representation metadata. For example, the above semantic is true for 503 the representation in any 200 (OK) response to GET and for the 504 representation in any PUT request. A 200 response to PUT, in 505 contrast, contains either a representation that describes the 506 successful action or a representation of the target resource, with 507 the latter indicated by a Content-Location header field with the same 508 value as the effective request URI. Likewise, response messages with 509 an error status code usually contain a representation that describes 510 the error and what next steps are suggested for resolving it. 512 4.1. Representation Header Fields 514 Representation header fields define metadata about the representation 515 data enclosed in the message body or, if no message body is present, 516 about the representation that would have been transferred in a 200 517 response to a simultaneous GET request with the same effective 518 request URI. 520 The following header fields are defined as representation metadata: 522 +-------------------+------------------------+ 523 | Header Field Name | Defined in... | 524 +-------------------+------------------------+ 525 | Content-Encoding | Section 6.5 | 526 | Content-Language | Section 6.6 | 527 | Content-Location | Section 6.7 | 528 | Content-Type | Section 6.8 | 529 | Expires | Section 3.3 of [Part6] | 530 +-------------------+------------------------+ 532 Additional header fields define metadata about the selected 533 representation, which might differ from the representation included 534 in the message for responses to some state-changing methods. The 535 following header fields are defined as selected representation 536 metadata: 538 +-------------------+------------------------+ 539 | Header Field Name | Defined in... | 540 +-------------------+------------------------+ 541 | ETag | Section 2.3 of [Part4] | 542 | Last-Modified | Section 2.2 of [Part4] | 543 +-------------------+------------------------+ 545 4.2. Representation Data 547 The representation body associated with an HTTP message is either 548 provided as the payload body of the message or referred to by the 549 message semantics and the effective request URI. The representation 550 data is in a format and encoding defined by the representation 551 metadata header fields. 553 The data type of the representation data is determined via the header 554 fields Content-Type and Content-Encoding. These define a two-layer, 555 ordered encoding model: 557 representation-data := Content-Encoding( Content-Type( bits ) ) 559 Content-Type specifies the media type of the underlying data, which 560 defines both the data format and how that data SHOULD be processed by 561 the recipient (within the scope of the request method semantics). 562 Any HTTP/1.1 message containing a payload body SHOULD include a 563 Content-Type header field defining the media type of the associated 564 representation unless that metadata is unknown to the sender. If the 565 Content-Type header field is not present, it indicates that the 566 sender does not know the media type of the representation; recipients 567 MAY either assume that the media type is "application/octet-stream" 568 ([RFC2046], Section 4.5.1) or examine the content to determine its 569 type. 571 In practice, resource owners do not always properly configure their 572 origin server to provide the correct Content-Type for a given 573 representation, with the result that some clients will examine a 574 response body's content and override the specified type. Clients 575 that do so risk drawing incorrect conclusions, which might expose 576 additional security risks (e.g., "privilege escalation"). 577 Furthermore, it is impossible to determine the sender's intent by 578 examining the data format: many data formats match multiple media 579 types that differ only in processing semantics. Implementers are 580 encouraged to provide a means of disabling such "content sniffing" 581 when it is used. 583 Content-Encoding is used to indicate any additional content codings 584 applied to the data, usually for the purpose of data compression, 585 that are a property of the representation. If Content-Encoding is 586 not present, then there is no additional encoding beyond that defined 587 by the Content-Type. 589 5. Content Negotiation 591 HTTP responses include a representation which contains information 592 for interpretation, whether by a human user or for further 593 processing. Often, the server has different ways of representing the 594 same information; for example, in different formats, languages, or 595 using different character encodings. 597 HTTP clients and their users might have different or variable 598 capabilities, characteristics or preferences which would influence 599 which representation, among those available from the server, would be 600 best for the server to deliver. For this reason, HTTP provides 601 mechanisms for "content negotiation" -- a process of allowing 602 selection of a representation of a given resource, when more than one 603 is available. 605 This specification defines two patterns of content negotiation; 606 "server-driven", where the server selects the representation based 607 upon the client's stated preferences, and "agent-driven" negotiation, 608 where the server provides a list of representations for the client to 609 choose from, based upon their metadata. In addition, there are other 610 patterns: some applications use an "active content" pattern, where 611 the server returns active content which runs on the client and, based 612 on client available parameters, selects additional resources to 613 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 614 proposed. 616 These patterns are all widely used, and have trade-offs in 617 applicability and practicality. In particular, when the number of 618 preferences or capabilities to be expressed by a client are large 619 (such as when many different formats are supported by a user-agent), 620 server-driven negotiation becomes unwieldy, and might not be 621 appropriate. Conversely, when the number of representations to 622 choose from is very large, agent-driven negotiation might not be 623 appropriate. 625 Note that in all cases, the supplier of representations has the 626 responsibility for determining which representations might be 627 considered to be the "same information". 629 5.1. Server-driven Negotiation 631 If the selection of the best representation for a response is made by 632 an algorithm located at the server, it is called server-driven 633 negotiation. Selection is based on the available representations of 634 the response (the dimensions over which it can vary; e.g., language, 635 content-coding, etc.) and the contents of particular header fields in 636 the request message or on other information pertaining to the request 637 (such as the network address of the client). 639 Server-driven negotiation is advantageous when the algorithm for 640 selecting from among the available representations is difficult to 641 describe to the user agent, or when the server desires to send its 642 "best guess" to the client along with the first response (hoping to 643 avoid the round-trip delay of a subsequent request if the "best 644 guess" is good enough for the user). In order to improve the 645 server's guess, the user agent MAY include request header fields 646 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 647 preferences for such a response. 649 Server-driven negotiation has disadvantages: 651 1. It is impossible for the server to accurately determine what 652 might be "best" for any given user, since that would require 653 complete knowledge of both the capabilities of the user agent and 654 the intended use for the response (e.g., does the user want to 655 view it on screen or print it on paper?). 657 2. Having the user agent describe its capabilities in every request 658 can be both very inefficient (given that only a small percentage 659 of responses have multiple representations) and a potential 660 violation of the user's privacy. 662 3. It complicates the implementation of an origin server and the 663 algorithms for generating responses to a request. 665 4. It might limit a public cache's ability to use the same response 666 for multiple user's requests. 668 Server-driven negotiation allows the user agent to specify its 669 preferences, but it cannot expect responses to always honor them. 670 For example, the origin server might not implement server-driven 671 negotiation, or it might decide that sending a response that doesn't 672 conform to them is better than sending a 406 (Not Acceptable) 673 response. 675 Many of the mechanisms for expressing preferences use quality values 676 to declare relative preference. See Section 4.3.1 of [Part1] for 677 more information. 679 HTTP/1.1 includes the following header fields for enabling server- 680 driven negotiation through description of user agent capabilities and 681 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 682 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 683 User-Agent (Section 10.10 of [Part2]). However, an origin server is 684 not limited to these dimensions and MAY vary the response based on 685 any aspect of the request, including aspects of the connection (e.g., 686 IP address) or information within extension header fields not defined 687 by this specification. 689 Note: In practice, User-Agent based negotiation is fragile, 690 because new clients might not be recognized. 692 The Vary header field (Section 3.5 of [Part6]) can be used to express 693 the parameters the server uses to select a representation that is 694 subject to server-driven negotiation. 696 5.2. Agent-driven Negotiation 698 With agent-driven negotiation, selection of the best representation 699 for a response is performed by the user agent after receiving an 700 initial response from the origin server. Selection is based on a 701 list of the available representations of the response included within 702 the header fields or body of the initial response, with each 703 representation identified by its own URI. Selection from among the 704 representations can be performed automatically (if the user agent is 705 capable of doing so) or manually by the user selecting from a 706 generated (possibly hypertext) menu. 708 Agent-driven negotiation is advantageous when the response would vary 709 over commonly-used dimensions (such as type, language, or encoding), 710 when the origin server is unable to determine a user agent's 711 capabilities from examining the request, and generally when public 712 caches are used to distribute server load and reduce network usage. 714 Agent-driven negotiation suffers from the disadvantage of needing a 715 second request to obtain the best alternate representation. This 716 second request is only efficient when caching is used. In addition, 717 this specification does not define any mechanism for supporting 718 automatic selection, though it also does not prevent any such 719 mechanism from being developed as an extension and used within 720 HTTP/1.1. 722 This specification defines the 300 (Multiple Choices) and 406 (Not 723 Acceptable) status codes for enabling agent-driven negotiation when 724 the server is unwilling or unable to provide a varying response using 725 server-driven negotiation. 727 6. Header Field Definitions 729 This section defines the syntax and semantics of HTTP/1.1 header 730 fields related to the payload of messages. 732 6.1. Accept 734 The "Accept" header field can be used by user agents to specify 735 response media types that are acceptable. Accept header fields can 736 be used to indicate that the request is specifically limited to a 737 small set of desired types, as in the case of a request for an in- 738 line image. 740 Accept = #( media-range [ accept-params ] ) 742 media-range = ( "*/*" 743 / ( type "/" "*" ) 744 / ( type "/" subtype ) 745 ) *( OWS ";" OWS parameter ) 746 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 747 accept-ext = OWS ";" OWS token [ "=" word ] 749 The asterisk "*" character is used to group media types into ranges, 750 with "*/*" indicating all media types and "type/*" indicating all 751 subtypes of that type. The media-range MAY include media type 752 parameters that are applicable to that range. 754 Each media-range MAY be followed by one or more accept-params, 755 beginning with the "q" parameter for indicating a relative quality 756 factor. The first "q" parameter (if any) separates the media-range 757 parameter(s) from the accept-params. Quality factors allow the user 758 or user agent to indicate the relative degree of preference for that 759 media-range, using the qvalue scale from 0 to 1 (Section 4.3.1 of 760 [Part1]). The default value is q=1. 762 Note: Use of the "q" parameter name to separate media type 763 parameters from Accept extension parameters is due to historical 764 practice. Although this prevents any media type parameter named 765 "q" from being used with a media range, such an event is believed 766 to be unlikely given the lack of any "q" parameters in the IANA 767 media type registry and the rare usage of any media type 768 parameters in Accept. Future media types are discouraged from 769 registering any parameter named "q". 771 The example 773 Accept: audio/*; q=0.2, audio/basic 775 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 776 type if it is the best available after an 80% mark-down in quality". 778 A request without any Accept header field implies that the user agent 779 will accept any media type in response. If an Accept header field is 780 present in a request and none of the available representations for 781 the response have a media type that is listed as acceptable, the 782 origin server MAY either honor the Accept header field by sending a 783 406 (Not Acceptable) response or disregard the Accept header field by 784 treating the response as if it is not subject to content negotiation. 786 A more elaborate example is 788 Accept: text/plain; q=0.5, text/html, 789 text/x-dvi; q=0.8, text/x-c 791 Verbally, this would be interpreted as "text/html and text/x-c are 792 the preferred media types, but if they do not exist, then send the 793 text/x-dvi representation, and if that does not exist, send the text/ 794 plain representation". 796 Media ranges can be overridden by more specific media ranges or 797 specific media types. If more than one media range applies to a 798 given type, the most specific reference has precedence. For example, 800 Accept: text/*, text/plain, text/plain;format=flowed, */* 802 have the following precedence: 804 1. text/plain;format=flowed 806 2. text/plain 808 3. text/* 810 4. */* 812 The media type quality factor associated with a given type is 813 determined by finding the media range with the highest precedence 814 which matches that type. For example, 816 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 817 text/html;level=2;q=0.4, */*;q=0.5 819 would cause the following values to be associated: 821 +-------------------+---------------+ 822 | Media Type | Quality Value | 823 +-------------------+---------------+ 824 | text/html;level=1 | 1 | 825 | text/html | 0.7 | 826 | text/plain | 0.3 | 827 | image/jpeg | 0.5 | 828 | text/html;level=2 | 0.4 | 829 | text/html;level=3 | 0.7 | 830 +-------------------+---------------+ 832 Note: A user agent might be provided with a default set of quality 833 values for certain media ranges. However, unless the user agent is a 834 closed system which cannot interact with other rendering agents, this 835 default set ought to be configurable by the user. 837 6.2. Accept-Charset 839 The "Accept-Charset" header field can be used by user agents to 840 indicate what character encodings are acceptable in a response 841 payload. This field allows clients capable of understanding more 842 comprehensive or special-purpose character encodings to signal that 843 capability to a server which is capable of representing documents in 844 those character encodings. 846 Accept-Charset = 1#( ( charset / "*" ) 847 [ OWS ";" OWS "q=" qvalue ] ) 849 Character encoding values (a.k.a., charsets) are described in 850 Section 2.1. Each charset MAY be given an associated quality value 851 which represents the user's preference for that charset. The default 852 value is q=1. An example is 854 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 856 The special value "*", if present in the Accept-Charset field, 857 matches every character encoding which is not mentioned elsewhere in 858 the Accept-Charset field. If no "*" is present in an Accept-Charset 859 field, then all character encodings not explicitly mentioned get a 860 quality value of 0. 862 A request without any Accept-Charset header field implies that the 863 user agent will accept any character encoding in response. If an 864 Accept-Charset header field is present in a request and none of the 865 available representations for the response have a character encoding 866 that is listed as acceptable, the origin server MAY either honor the 867 Accept-Charset header field by sending a 406 (Not Acceptable) 868 response or disregard the Accept-Charset header field by treating the 869 response as if it is not subject to content negotiation. 871 6.3. Accept-Encoding 873 The "Accept-Encoding" header field can be used by user agents to 874 indicate what response content-codings (Section 2.2) are acceptable 875 in the response. An "identity" token is used as a synonym for "no 876 encoding" in order to communicate when no encoding is preferred. 878 Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) 879 codings = content-coding / "identity" / "*" 881 Each codings value MAY be given an associated quality value which 882 represents the preference for that encoding. The default value is 883 q=1. 885 For example, 887 Accept-Encoding: compress, gzip 888 Accept-Encoding: 889 Accept-Encoding: * 890 Accept-Encoding: compress;q=0.5, gzip;q=1.0 891 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 893 A server tests whether a content-coding for a given representation is 894 acceptable, according to an Accept-Encoding field, using these rules: 896 1. The special "*" symbol in an Accept-Encoding field matches any 897 available content-coding not explicitly listed in the header 898 field. 900 2. If the representation has no content-coding, then it is 901 acceptable by default unless specifically excluded by the Accept- 902 Encoding field stating either "identity;q=0" or "*;q=0" without a 903 more specific entry for "identity". 905 3. If the representation's content-coding is one of the content- 906 codings listed in the Accept-Encoding field, then it is 907 acceptable unless it is accompanied by a qvalue of 0. (As 908 defined in Section 4.3.1 of [Part1], a qvalue of 0 means "not 909 acceptable".) 911 4. If multiple content-codings are acceptable, then the acceptable 912 content-coding with the highest non-zero qvalue is preferred. 914 An Accept-Encoding header field with a combined field-value that is 915 empty implies that the user agent does not want any content-coding in 916 response. If an Accept-Encoding header field is present in a request 917 and none of the available representations for the response have a 918 content-coding that is listed as acceptable, the origin server SHOULD 919 send a response without any content-coding. 921 A request without an Accept-Encoding header field implies that the 922 user agent will accept any content-coding in response, but a 923 representation without content-coding is preferred for compatibility 924 with the widest variety of user agents. 926 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 927 associated with content-codings. This means that qvalues will not 928 work and are not permitted with x-gzip or x-compress. 930 6.4. Accept-Language 932 The "Accept-Language" header field can be used by user agents to 933 indicate the set of natural languages that are preferred in the 934 response. Language tags are defined in Section 2.4. 936 Accept-Language = 937 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 938 language-range = 939 941 Each language-range can be given an associated quality value which 942 represents an estimate of the user's preference for the languages 943 specified by that range. The quality value defaults to "q=1". For 944 example, 946 Accept-Language: da, en-gb;q=0.8, en;q=0.7 948 would mean: "I prefer Danish, but will accept British English and 949 other types of English". (see also Section 2.3 of [RFC4647]) 951 For matching, Section 3 of [RFC4647] defines several matching 952 schemes. Implementations can offer the most appropriate matching 953 scheme for their requirements. 955 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 956 identical to the matching scheme that was previously defined in 957 Section 14.4 of [RFC2616]. 959 It might be contrary to the privacy expectations of the user to send 960 an Accept-Language header field with the complete linguistic 961 preferences of the user in every request. For a discussion of this 962 issue, see Section 8.1. 964 As intelligibility is highly dependent on the individual user, it is 965 recommended that client applications make the choice of linguistic 966 preference available to the user. If the choice is not made 967 available, then the Accept-Language header field MUST NOT be given in 968 the request. 970 Note: When making the choice of linguistic preference available to 971 the user, we remind implementors of the fact that users are not 972 familiar with the details of language matching as described above, 973 and ought to be provided appropriate guidance. As an example, 974 users might assume that on selecting "en-gb", they will be served 975 any kind of English document if British English is not available. 976 A user agent might suggest in such a case to add "en" to get the 977 best matching behavior. 979 6.5. Content-Encoding 981 The "Content-Encoding" header field indicates what content-codings 982 have been applied to the representation beyond those inherent in the 983 media type, and thus what decoding mechanisms must be applied in 984 order to obtain the media-type referenced by the Content-Type header 985 field. Content-Encoding is primarily used to allow a representation 986 to be compressed without losing the identity of its underlying media 987 type. 989 Content-Encoding = 1#content-coding 991 Content codings are defined in Section 2.2. An example of its use is 993 Content-Encoding: gzip 995 The content-coding is a characteristic of the representation. 996 Typically, the representation body is stored with this encoding and 997 is only decoded before rendering or analogous usage. However, a 998 transforming proxy MAY modify the content-coding if the new coding is 999 known to be acceptable to the recipient, unless the "no-transform" 1000 cache-control directive is present in the message. 1002 If the media type includes an inherent encoding, such as a data 1003 format that is always compressed, then that encoding would not be 1004 restated as a Content-Encoding even if it happens to be the same 1005 algorithm as one of the content-codings. Such a content-coding would 1006 only be listed if, for some bizarre reason, it is applied a second 1007 time to form the representation. Likewise, an origin server might 1008 choose to publish the same payload data as multiple representations 1009 that differ only in whether the coding is defined as part of Content- 1010 Type or Content-Encoding, since some user agents will behave 1011 differently in their handling of each response (e.g., open a "Save as 1012 ..." dialog instead of automatic decompression and rendering of 1013 content). 1015 A representation that has a content-coding applied to it MUST include 1016 a Content-Encoding header field (Section 6.5) that lists the content- 1017 coding(s) applied. 1019 If multiple encodings have been applied to a representation, the 1020 content codings MUST be listed in the order in which they were 1021 applied. Additional information about the encoding parameters MAY be 1022 provided by other header fields not defined by this specification. 1024 If the content-coding of a representation in a request message is not 1025 acceptable to the origin server, the server SHOULD respond with a 1026 status code of 415 (Unsupported Media Type). 1028 6.6. Content-Language 1030 The "Content-Language" header field describes the natural language(s) 1031 of the intended audience for the representation. Note that this 1032 might not be equivalent to all the languages used within the 1033 representation. 1035 Content-Language = 1#language-tag 1037 Language tags are defined in Section 2.4. The primary purpose of 1038 Content-Language is to allow a user to identify and differentiate 1039 representations according to the user's own preferred language. 1040 Thus, if the body content is intended only for a Danish-literate 1041 audience, the appropriate field is 1043 Content-Language: da 1045 If no Content-Language is specified, the default is that the content 1046 is intended for all language audiences. This might mean that the 1047 sender does not consider it to be specific to any natural language, 1048 or that the sender does not know for which language it is intended. 1050 Multiple languages MAY be listed for content that is intended for 1051 multiple audiences. For example, a rendition of the "Treaty of 1052 Waitangi", presented simultaneously in the original Maori and English 1053 versions, would call for 1055 Content-Language: mi, en 1057 However, just because multiple languages are present within a 1058 representation does not mean that it is intended for multiple 1059 linguistic audiences. An example would be a beginner's language 1060 primer, such as "A First Lesson in Latin", which is clearly intended 1061 to be used by an English-literate audience. In this case, the 1062 Content-Language would properly only include "en". 1064 Content-Language MAY be applied to any media type -- it is not 1065 limited to textual documents. 1067 6.7. Content-Location 1069 The "Content-Location" header field supplies a URI that can be used 1070 as a specific identifier for the representation in this message. In 1071 other words, if one were to perform a GET on this URI at the time of 1072 this message's generation, then a 200 response would contain the same 1073 representation that is enclosed as payload in this message. 1075 Content-Location = absolute-URI / partial-URI 1077 The Content-Location value is not a replacement for the effective 1078 Request URI (Section 5.5 of [Part1]). It is representation metadata. 1079 It has the same syntax and semantics as the header field of the same 1080 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1081 its appearance in an HTTP message has some special implications for 1082 HTTP recipients. 1084 If Content-Location is included in a response message and its value 1085 is the same as the effective request URI, then the response payload 1086 SHOULD be considered a current representation of that resource. For 1087 a GET or HEAD request, this is the same as the default semantics when 1088 no Content-Location is provided by the server. For a state-changing 1089 request like PUT or POST, it implies that the server's response 1090 contains the new representation of that resource, thereby 1091 distinguishing it from representations that might only report about 1092 the action (e.g., "It worked!"). This allows authoring applications 1093 to update their local copies without the need for a subsequent GET 1094 request. 1096 If Content-Location is included in a response message and its value 1097 differs from the effective request URI, then the origin server is 1098 informing recipients that this representation has its own, presumably 1099 more specific, identifier. For a GET or HEAD request, this is an 1100 indication that the effective request URI identifies a resource that 1101 is subject to content negotiation and the selected representation for 1102 this response can also be found at the identified URI. For other 1103 methods, such a Content-Location indicates that this representation 1104 contains a report on the action's status and the same report is 1105 available (for future access with GET) at the given URI. For 1106 example, a purchase transaction made via a POST request might include 1107 a receipt document as the payload of the 200 response; the Content- 1108 Location value provides an identifier for retrieving a copy of that 1109 same receipt in the future. 1111 If Content-Location is included in a request message, then it MAY be 1112 interpreted by the origin server as an indication of where the user 1113 agent originally obtained the content of the enclosed representation 1114 (prior to any subsequent modification of the content by that user 1115 agent). In other words, the user agent is providing the same 1116 representation metadata that it received with the original 1117 representation. However, such interpretation MUST NOT be used to 1118 alter the semantics of the method requested by the client. For 1119 example, if a client makes a PUT request on a negotiated resource and 1120 the origin server accepts that PUT (without redirection), then the 1121 new set of values for that resource is expected to be consistent with 1122 the one representation supplied in that PUT; the Content-Location 1123 cannot be used as a form of reverse content selection that identifies 1124 only one of the negotiated representations to be updated. If the 1125 user agent had wanted the latter semantics, it would have applied the 1126 PUT directly to the Content-Location URI. 1128 A Content-Location field received in a request message is transitory 1129 information that SHOULD NOT be saved with other representation 1130 metadata for use in later responses. The Content-Location's value 1131 might be saved for use in other contexts, such as within source links 1132 or other metadata. 1134 A cache cannot assume that a representation with a Content-Location 1135 different from the URI used to retrieve it can be used to respond to 1136 later requests on that Content-Location URI. 1138 If the Content-Location value is a partial URI, the partial URI is 1139 interpreted relative to the effective request URI. 1141 6.8. Content-Type 1143 The "Content-Type" header field indicates the media type of the 1144 representation. In the case of responses to the HEAD method, the 1145 media type is that which would have been sent had the request been a 1146 GET. 1148 Content-Type = media-type 1150 Media types are defined in Section 2.3. An example of the field is 1152 Content-Type: text/html; charset=ISO-8859-4 1154 Further discussion of Content-Type is provided in Section 4.2. 1156 7. IANA Considerations 1158 7.1. Header Field Registration 1160 The Message Header Field Registry located at shall be 1162 updated with the permanent registrations below (see [RFC3864]): 1164 +-------------------+----------+----------+--------------+ 1165 | Header Field Name | Protocol | Status | Reference | 1166 +-------------------+----------+----------+--------------+ 1167 | Accept | http | standard | Section 6.1 | 1168 | Accept-Charset | http | standard | Section 6.2 | 1169 | Accept-Encoding | http | standard | Section 6.3 | 1170 | Accept-Language | http | standard | Section 6.4 | 1171 | Content-Encoding | http | standard | Section 6.5 | 1172 | Content-Language | http | standard | Section 6.6 | 1173 | Content-Location | http | standard | Section 6.7 | 1174 | Content-Type | http | standard | Section 6.8 | 1175 | MIME-Version | http | standard | Appendix A.1 | 1176 +-------------------+----------+----------+--------------+ 1178 The change controller is: "IETF (iesg@ietf.org) - Internet 1179 Engineering Task Force". 1181 7.2. Content Coding Registry 1183 The registration procedure for HTTP Content Codings is now defined by 1184 Section 2.2.1 of this document. 1186 The HTTP Content Codings Registry located at 1187 shall be updated 1188 with the registration below: 1190 +----------+------------------------------------------+-------------+ 1191 | Name | Description | Reference | 1192 +----------+------------------------------------------+-------------+ 1193 | compress | UNIX "compress" program method | Section | 1194 | | | 4.2.1 of | 1195 | | | [Part1] | 1196 | deflate | "deflate" compression mechanism | Section | 1197 | | ([RFC1951]) used inside the "zlib" data | 4.2.2 of | 1198 | | format ([RFC1950]) | [Part1] | 1199 | gzip | Same as GNU zip [RFC1952] | Section | 1200 | | | 4.2.3 of | 1201 | | | [Part1] | 1202 | identity | reserved (synonym for "no encoding" in | Section 6.3 | 1203 | | Accept-Encoding header field) | | 1204 +----------+------------------------------------------+-------------+ 1206 8. Security Considerations 1208 This section is meant to inform application developers, information 1209 providers, and users of the security limitations in HTTP/1.1 as 1210 described by this document. The discussion does not include 1211 definitive solutions to the problems revealed, though it does make 1212 some suggestions for reducing security risks. 1214 8.1. Privacy Issues Connected to Accept Header Fields 1216 Accept header fields can reveal information about the user to all 1217 servers which are accessed. The Accept-Language header field in 1218 particular can reveal information the user would consider to be of a 1219 private nature, because the understanding of particular languages is 1220 often strongly correlated to the membership of a particular ethnic 1221 group. User agents which offer the option to configure the contents 1222 of an Accept-Language header field to be sent in every request are 1223 strongly encouraged to let the configuration process include a 1224 message which makes the user aware of the loss of privacy involved. 1226 An approach that limits the loss of privacy would be for a user agent 1227 to omit the sending of Accept-Language header fields by default, and 1228 to ask the user whether or not to start sending Accept-Language 1229 header fields to a server if it detects, by looking for any Vary 1230 header fields generated by the server, that such sending could 1231 improve the quality of service. 1233 Elaborate user-customized accept header fields sent in every request, 1234 in particular if these include quality values, can be used by servers 1235 as relatively reliable and long-lived user identifiers. Such user 1236 identifiers would allow content providers to do click-trail tracking, 1237 and would allow collaborating content providers to match cross-server 1238 click-trails or form submissions of individual users. Note that for 1239 many users not behind a proxy, the network address of the host 1240 running the user agent will also serve as a long-lived user 1241 identifier. In environments where proxies are used to enhance 1242 privacy, user agents ought to be conservative in offering accept 1243 header configuration options to end users. As an extreme privacy 1244 measure, proxies could filter the accept header fields in relayed 1245 requests. General purpose user agents which provide a high degree of 1246 header configurability SHOULD warn users about the loss of privacy 1247 which can be involved. 1249 9. Acknowledgments 1251 See Section 9 of [Part1]. 1253 10. References 1255 10.1. Normative References 1257 [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1258 "HTTP/1.1, part 1: URIs, Connections, and Message 1259 Parsing", draft-ietf-httpbis-p1-messaging-19 (work in 1260 progress), March 2012. 1262 [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1263 "HTTP/1.1, part 2: Message Semantics", 1264 draft-ietf-httpbis-p2-semantics-19 (work in progress), 1265 March 2012. 1267 [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1268 "HTTP/1.1, part 4: Conditional Requests", 1269 draft-ietf-httpbis-p4-conditional-19 (work in progress), 1270 March 2012. 1272 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1273 "HTTP/1.1, part 5: Range Requests and Partial Responses", 1274 draft-ietf-httpbis-p5-range-19 (work in progress), 1275 March 2012. 1277 [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., 1278 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 1279 draft-ietf-httpbis-p6-cache-19 (work in progress), 1280 March 2012. 1282 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1283 Specification version 3.3", RFC 1950, May 1996. 1285 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1286 version 1.3", RFC 1951, May 1996. 1288 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1289 Randers-Pehrson, "GZIP file format specification version 1290 4.3", RFC 1952, May 1996. 1292 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1293 Extensions (MIME) Part One: Format of Internet Message 1294 Bodies", RFC 2045, November 1996. 1296 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1297 Extensions (MIME) Part Two: Media Types", RFC 2046, 1298 November 1996. 1300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1301 Requirement Levels", BCP 14, RFC 2119, March 1997. 1303 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1304 Tags", BCP 47, RFC 4647, September 2006. 1306 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1307 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1309 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1310 Languages", BCP 47, RFC 5646, September 2009. 1312 10.2. Informative References 1314 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1315 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1317 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1318 Extensions (MIME) Part Five: Conformance Criteria and 1319 Examples", RFC 2049, November 1996. 1321 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1322 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1323 RFC 2068, January 1997. 1325 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1326 February 1997. 1328 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1329 Languages", BCP 18, RFC 2277, January 1998. 1331 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1332 in HTTP", RFC 2295, March 1998. 1334 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1335 form-data", RFC 2388, August 1998. 1337 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1338 "MIME Encapsulation of Aggregate Documents, such as HTML 1339 (MHTML)", RFC 2557, March 1999. 1341 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1342 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1343 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1345 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1346 10646", STD 63, RFC 3629, November 2003. 1348 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1349 Procedures for Message Header Fields", BCP 90, RFC 3864, 1350 September 2004. 1352 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1353 Registration Procedures", BCP 13, RFC 4288, December 2005. 1355 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1356 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1357 May 2008. 1359 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1360 October 2008. 1362 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1363 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1364 RFC 6151, March 2011. 1366 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1367 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1368 June 2011. 1370 Appendix A. Differences between HTTP and MIME 1372 HTTP/1.1 uses many of the constructs defined for Internet Mail 1373 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1374 [RFC2045]) to allow a message body to be transmitted in an open 1375 variety of representations and with extensible mechanisms. However, 1376 RFC 2045 discusses mail, and HTTP has a few features that are 1377 different from those described in MIME. These differences were 1378 carefully chosen to optimize performance over binary connections, to 1379 allow greater freedom in the use of new media types, to make date 1380 comparisons easier, and to acknowledge the practice of some early 1381 HTTP servers and clients. 1383 This appendix describes specific areas where HTTP differs from MIME. 1384 Proxies and gateways to strict MIME environments SHOULD be aware of 1385 these differences and provide the appropriate conversions where 1386 necessary. Proxies and gateways from MIME environments to HTTP also 1387 need to be aware of the differences because some conversions might be 1388 required. 1390 A.1. MIME-Version 1392 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1393 MAY include a single MIME-Version header field to indicate what 1394 version of the MIME protocol was used to construct the message. Use 1395 of the MIME-Version header field indicates that the message is in 1396 full conformance with the MIME protocol (as defined in [RFC2045]). 1397 Proxies/gateways are responsible for ensuring full conformance (where 1398 possible) when exporting HTTP messages to strict MIME environments. 1400 MIME-Version = 1*DIGIT "." 1*DIGIT 1402 MIME version "1.0" is the default for use in HTTP/1.1. However, 1403 HTTP/1.1 message parsing and semantics are defined by this document 1404 and not the MIME specification. 1406 A.2. Conversion to Canonical Form 1408 MIME requires that an Internet mail body-part be converted to 1409 canonical form prior to being transferred, as described in Section 4 1410 of [RFC2049]. Section 2.3.1 of this document describes the forms 1411 allowed for subtypes of the "text" media type when transmitted over 1412 HTTP. [RFC2046] requires that content with a type of "text" 1413 represent line breaks as CRLF and forbids the use of CR or LF outside 1414 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1415 indicate a line break within text content when a message is 1416 transmitted over HTTP. 1418 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1419 environment SHOULD translate all line breaks within the text media 1420 types described in Section 2.3.1 of this document to the RFC 2049 1421 canonical form of CRLF. Note, however, that this might be 1422 complicated by the presence of a Content-Encoding and by the fact 1423 that HTTP allows the use of some character encodings which do not use 1424 octets 13 and 10 to represent CR and LF, respectively, as is the case 1425 for some multi-byte character encodings. 1427 Conversion will break any cryptographic checksums applied to the 1428 original content unless the original content is already in canonical 1429 form. Therefore, the canonical form is recommended for any content 1430 that uses such checksums in HTTP. 1432 A.3. Conversion of Date Formats 1434 HTTP/1.1 uses a restricted set of date formats (Section 8 of [Part2]) 1435 to simplify the process of date comparison. Proxies and gateways 1436 from other protocols SHOULD ensure that any Date header field present 1437 in a message conforms to one of the HTTP/1.1 formats and rewrite the 1438 date if necessary. 1440 A.4. Introduction of Content-Encoding 1442 MIME does not include any concept equivalent to HTTP/1.1's Content- 1443 Encoding header field. Since this acts as a modifier on the media 1444 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1445 either change the value of the Content-Type header field or decode 1446 the representation before forwarding the message. (Some experimental 1447 applications of Content-Type for Internet mail have used a media-type 1448 parameter of ";conversions=" to perform a function 1449 equivalent to Content-Encoding. However, this parameter is not part 1450 of the MIME standards). 1452 A.5. No Content-Transfer-Encoding 1454 HTTP does not use the Content-Transfer-Encoding field of MIME. 1455 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1456 remove any Content-Transfer-Encoding prior to delivering the response 1457 message to an HTTP client. 1459 Proxies and gateways from HTTP to MIME-compliant protocols are 1460 responsible for ensuring that the message is in the correct format 1461 and encoding for safe transport on that protocol, where "safe 1462 transport" is defined by the limitations of the protocol being used. 1463 Such a proxy or gateway SHOULD label the data with an appropriate 1464 Content-Transfer-Encoding if doing so will improve the likelihood of 1465 safe transport over the destination protocol. 1467 A.6. Introduction of Transfer-Encoding 1469 HTTP/1.1 introduces the Transfer-Encoding header field (Section 3.3.1 1470 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1471 to forwarding a message via a MIME-compliant protocol. 1473 A.7. MHTML and Line Length Limitations 1475 HTTP implementations which share code with MHTML [RFC2557] 1476 implementations need to be aware of MIME line length limitations. 1477 Since HTTP does not have this limitation, HTTP does not fold long 1478 lines. MHTML messages being transported by HTTP follow all 1479 conventions of MHTML, including line length limitations and folding, 1480 canonicalization, etc., since HTTP transports all message-bodies as 1481 payload (see Section 2.3.2) and does not interpret the content or any 1482 MIME header lines that might be contained therein. 1484 Appendix B. Additional Features 1486 [RFC1945] and [RFC2068] document protocol elements used by some 1487 existing HTTP implementations, but not consistently and correctly 1488 across most HTTP/1.1 applications. Implementors are advised to be 1489 aware of these features, but cannot rely upon their presence in, or 1490 interoperability with, other HTTP/1.1 applications. Some of these 1491 describe proposed experimental features, and some describe features 1492 that experimental deployment found lacking that are now addressed in 1493 the base HTTP/1.1 specification. 1495 A number of other header fields, such as Content-Disposition and 1496 Title, from SMTP and MIME are also often implemented (see [RFC6266] 1497 and [RFC2076]). 1499 Appendix C. Changes from RFC 2616 1501 Clarify contexts that charset is used in. (Section 2.1) 1503 Registration of Content Codings now requires IETF Review 1504 (Section 2.2.1) 1506 Remove the default character encoding for text media types; the 1507 default now is whatever the media type definition says. 1508 (Section 2.3.1) 1510 Change ABNF productions for header fields to only define the field 1511 value. (Section 6) 1513 Remove definition of Content-MD5 header field because it was 1514 inconsistently implemented with respect to partial responses, and 1515 also because of known deficiencies in the hash algorithm itself (see 1516 [RFC6151] for details). (Section 6) 1518 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) 1520 Remove base URI setting semantics for Content-Location due to poor 1521 implementation support, which was caused by too many broken servers 1522 emitting bogus Content-Location header fields, and also the 1523 potentially undesirable effect of potentially breaking relative links 1524 in content-negotiated resources. (Section 6.7) 1526 Remove reference to non-existant identity transfer-coding value 1527 tokens. (Appendix A.5) 1529 Remove discussion of Content-Disposition header field, it is now 1530 defined by [RFC6266]. (Appendix B) 1532 Appendix D. Collected ABNF 1534 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1535 OWS media-range [ accept-params ] ] ) ] 1536 Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1537 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1538 qvalue ] ] ) 1539 Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) 1540 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1541 Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1542 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1543 ] ) 1545 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 1546 content-coding ] ) 1548 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 1549 language-tag ] ) 1550 Content-Location = absolute-URI / partial-URI 1551 Content-Type = media-type 1553 MIME-Version = 1*DIGIT "." 1*DIGIT 1555 OWS = 1557 absolute-URI = 1558 accept-ext = OWS ";" OWS token [ "=" word ] 1559 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1560 attribute = token 1562 charset = token 1563 codings = content-coding / "identity" / "*" 1564 content-coding = token 1566 language-range = 1567 language-tag = 1569 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1570 ";" OWS parameter ) 1571 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1573 parameter = attribute "=" value 1574 partial-URI = 1576 qvalue = 1578 subtype = token 1580 token = 1581 type = token 1583 value = word 1585 word = 1586 ABNF diagnostics: 1588 ; Accept defined but not used 1589 ; Accept-Charset defined but not used 1590 ; Accept-Encoding defined but not used 1591 ; Accept-Language defined but not used 1592 ; Content-Encoding defined but not used 1593 ; Content-Language defined but not used 1594 ; Content-Location defined but not used 1595 ; Content-Type defined but not used 1596 ; MIME-Version defined but not used 1598 Appendix E. Change Log (to be removed by RFC Editor before publication) 1600 E.1. Since RFC 2616 1602 Extracted relevant partitions from [RFC2616]. 1604 E.2. Since draft-ietf-httpbis-p3-payload-00 1606 Closed issues: 1608 o : "Media Type 1609 Registrations" () 1611 o : "Clarification 1612 regarding quoting of charset values" 1613 () 1615 o : "Remove 1616 'identity' token references" 1617 () 1619 o : "Accept- 1620 Encoding BNF" 1622 o : "Normative and 1623 Informative references" 1625 o : "RFC1700 1626 references" 1628 o : "Updating to 1629 RFC4288" 1631 o : "Informative 1632 references" 1634 o : "ISO-8859-1 1635 Reference" 1637 o : "Encoding 1638 References Normative" 1640 o : "Normative up- 1641 to-date references" 1643 E.3. Since draft-ietf-httpbis-p3-payload-01 1645 Ongoing work on ABNF conversion 1646 (): 1648 o Add explicit references to BNF syntax and rules imported from 1649 other parts of the specification. 1651 E.4. Since draft-ietf-httpbis-p3-payload-02 1653 Closed issues: 1655 o : "Quoting 1656 Charsets" 1658 o : 1659 "Classification for Allow header" 1661 o : "missing 1662 default for qvalue in description of Accept-Encoding" 1664 Ongoing work on IANA Message Header Field Registration 1665 (): 1667 o Reference RFC 3984, and update header field registrations for 1668 headers defined in this document. 1670 E.5. Since draft-ietf-httpbis-p3-payload-03 1672 Closed issues: 1674 o : "Quoting 1675 Charsets" 1677 o : "language tag 1678 matching (Accept-Language) vs RFC4647" 1680 o : "RFC 1806 has 1681 been replaced by RFC2183" 1683 Other changes: 1685 o : "Encoding 1686 References Normative" -- rephrase the annotation and reference 1687 BCP97. 1689 E.6. Since draft-ietf-httpbis-p3-payload-04 1691 Closed issues: 1693 o : "RFC 2822 is 1694 updated by RFC 5322" 1696 Ongoing work on ABNF conversion 1697 (): 1699 o Use "/" instead of "|" for alternatives. 1701 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1702 whitespace ("OWS") and required whitespace ("RWS"). 1704 o Rewrite ABNFs to spell out whitespace rules, factor out header 1705 field value format definitions. 1707 E.7. Since draft-ietf-httpbis-p3-payload-05 1709 Closed issues: 1711 o : "Join 1712 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1714 Final work on ABNF conversion 1715 (): 1717 o Add appendix containing collected and expanded ABNF, reorganize 1718 ABNF introduction. 1720 Other changes: 1722 o Move definition of quality values into Part 1. 1724 E.8. Since draft-ietf-httpbis-p3-payload-06 1726 Closed issues: 1728 o : "Content- 1729 Location isn't special" 1731 o : "Content 1732 Sniffing" 1734 E.9. Since draft-ietf-httpbis-p3-payload-07 1736 Closed issues: 1738 o : "Updated 1739 reference for language tags" 1741 o : "Clarify rules 1742 for determining what entities a response carries" 1744 o : "Content- 1745 Location base-setting problems" 1747 o : "Content 1748 Sniffing" 1750 o : "pick IANA 1751 policy (RFC5226) for Transfer Coding / Content Coding" 1753 o : "move 1754 definitions of gzip/deflate/compress to part 1" 1756 Partly resolved issues: 1758 o : "update IANA 1759 requirements wrt Transfer-Coding values" (add the IANA 1760 Considerations subsection) 1762 o : "update IANA 1763 requirements wrt Content-Coding values" (add the IANA 1764 Considerations subsection) 1766 E.10. Since draft-ietf-httpbis-p3-payload-08 1768 Closed issues: 1770 o : "Content 1771 Negotiation for media types" 1773 o : "Accept- 1774 Language: which RFC4647 filtering?" 1776 E.11. Since draft-ietf-httpbis-p3-payload-09 1778 Closed issues: 1780 o : "MIME-Version 1781 not listed in P1, general header fields" 1783 o : "IANA registry 1784 for content/transfer encodings" 1786 o : "Content 1787 Sniffing" 1789 o : "use of term 1790 "word" when talking about header structure" 1792 Partly resolved issues: 1794 o : "Term for the 1795 requested resource's URI" 1797 E.12. Since draft-ietf-httpbis-p3-payload-10 1799 Closed issues: 1801 o : "Clarify 1802 'Requested Variant'" 1804 o : "Content- 1805 Location isn't special" 1807 o : "Delimiting 1808 messages with multipart/byteranges" 1810 o : "Clarify 1811 entity / representation / variant terminology" 1813 o : "confusing 1814 req. language for Content-Location" 1816 o : "Content- 1817 Location on 304 responses" 1819 o : "'requested 1820 resource' in content-encoding definition" 1822 o : "consider 1823 removing the 'changes from 2068' sections" 1825 Partly resolved issues: 1827 o : "Content-MD5 1828 and partial responses" 1830 E.13. Since draft-ietf-httpbis-p3-payload-11 1832 Closed issues: 1834 o : "Factor out 1835 Content-Disposition" 1837 E.14. Since draft-ietf-httpbis-p3-payload-12 1839 Closed issues: 1841 o : "Header 1842 Classification" 1844 o : "untangle 1845 ABNFs for header fields" 1847 o : "potentially 1848 misleading MAY in media-type def" 1850 E.15. Since draft-ietf-httpbis-p3-payload-13 1852 Closed issues: 1854 o : "Default 1855 charsets for text media types" 1857 o : "Content-MD5 1858 and partial responses" 1860 o : "untangle 1861 ABNFs for header fields" 1863 o : "confusing 1864 undefined parameter in media range example" 1866 E.16. Since draft-ietf-httpbis-p3-payload-14 1868 None. 1870 E.17. Since draft-ietf-httpbis-p3-payload-15 1872 Closed issues: 1874 o : "Strength of 1875 requirements on Accept re: 406" 1877 E.18. Since draft-ietf-httpbis-p3-payload-16 1879 Closed issues: 1881 o : "Document 1882 HTTP's error-handling philosophy" 1884 E.19. Since draft-ietf-httpbis-p3-payload-17 1886 Closed issues: 1888 o : "intended 1889 maturity level vs normative references" 1891 E.20. Since draft-ietf-httpbis-p3-payload-18 1893 Closed issues: 1895 o : "is ETag a 1896 representation header field?" 1898 o : "Content- 1899 Location doesn't constrain the cardinality of representations" 1901 o : "make IANA 1902 policy definitions consistent" 1904 Index 1906 A 1907 Accept header field 16 1908 Accept-Charset header field 19 1909 Accept-Encoding header field 19 1910 Accept-Language header field 21 1912 C 1913 Coding Format 1914 compress 7 1915 deflate 8 1916 gzip 8 1917 compress (Coding Format) 7 1918 content negotiation 5 1919 Content-Encoding header field 22 1920 Content-Language header field 23 1921 Content-Location header field 23 1922 Content-Transfer-Encoding header field 32 1923 Content-Type header field 25 1925 D 1926 deflate (Coding Format) 8 1928 G 1929 Grammar 1930 Accept 17 1931 Accept-Charset 19 1932 Accept-Encoding 19 1933 accept-ext 17 1934 Accept-Language 21 1935 accept-params 17 1936 attribute 9 1937 charset 7 1938 codings 19 1939 content-coding 7 1940 Content-Encoding 22 1941 Content-Language 23 1942 Content-Location 23 1943 Content-Type 25 1944 language-range 21 1945 language-tag 10 1946 media-range 17 1947 media-type 8 1948 MIME-Version 30 1949 parameter 9 1950 subtype 8 1951 type 8 1952 value 9 1953 gzip (Coding Format) 8 1955 H 1956 Header Fields 1957 Accept 16 1958 Accept-Charset 19 1959 Accept-Encoding 19 1960 Accept-Language 21 1961 Content-Encoding 22 1962 Content-Language 23 1963 Content-Location 23 1964 Content-Transfer-Encoding 32 1965 Content-Type 25 1966 MIME-Version 30 1968 M 1969 MIME-Version header field 30 1971 P 1972 payload 11 1974 R 1975 representation 11 1977 S 1978 selected representation 5 1980 Authors' Addresses 1982 Roy T. Fielding (editor) 1983 Adobe Systems Incorporated 1984 345 Park Ave 1985 San Jose, CA 95110 1986 USA 1988 EMail: fielding@gbiv.com 1989 URI: http://roy.gbiv.com/ 1991 Yves Lafon (editor) 1992 World Wide Web Consortium 1993 W3C / ERCIM 1994 2004, rte des Lucioles 1995 Sophia-Antipolis, AM 06902 1996 France 1998 EMail: ylafon@w3.org 1999 URI: http://www.raubacapeu.net/people/yves/ 2001 Julian F. Reschke (editor) 2002 greenbytes GmbH 2003 Hafenweg 16 2004 Muenster, NW 48155 2005 Germany 2007 Phone: +49 251 2807760 2008 Fax: +49 251 2807761 2009 EMail: julian.reschke@greenbytes.de 2010 URI: http://greenbytes.de/tech/webdav/