idnits 2.17.1 draft-ietf-httpbis-p3-payload-18.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 (January 4, 2012) is 4496 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-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-18 ** 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: July 7, 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 January 4, 2012 22 HTTP/1.1, part 3: Message Payload and Content Negotiation 23 draft-ietf-httpbis-p3-payload-18 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.19. 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 July 7, 2012. 67 Copyright Notice 69 Copyright (c) 2012 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 This document may contain material from IETF Documents or IETF 83 Contributions published or made publicly available before November 84 10, 2008. The person(s) controlling the copyright in some of this 85 material may not have granted the IETF Trust the right to allow 86 modifications of such material outside the IETF Standards Process. 87 Without obtaining an adequate license from the person(s) controlling 88 the copyright in such materials, this document may not be modified 89 outside the IETF Standards Process, and derivative works of it may 90 not be created outside the IETF Standards Process, except to format 91 it for publication as an RFC or to translate it into languages other 92 than English. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 97 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 98 1.2. Conformance and Error Handling . . . . . . . . . . . . . . 5 99 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 100 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 101 1.3.2. ABNF Rules defined in other Parts of the 102 Specification . . . . . . . . . . . . . . . . . . . . 6 103 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 104 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6 105 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 106 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 107 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 108 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 109 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 110 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 111 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 112 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 113 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 114 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 115 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 116 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 117 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 118 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 119 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 120 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 121 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 122 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 123 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 124 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 125 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 126 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 127 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 128 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 129 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 130 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 131 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 133 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 134 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 136 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 137 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 138 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 29 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 E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 40 170 E.19. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . . 40 171 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 173 1. Introduction 175 This document defines HTTP/1.1 message payloads (a.k.a., content), 176 the associated metadata header fields that define how the payload is 177 intended to be interpreted by a recipient, the request header fields 178 that might influence content selection, and the various selection 179 algorithms that are collectively referred to as HTTP content 180 negotiation. 182 This document is currently disorganized in order to minimize the 183 changes between drafts and enable reviewers to see the smaller errata 184 changes. A future draft will reorganize the sections to better 185 reflect the content. In particular, the sections on entities will be 186 renamed payload and moved to the first half of the document, while 187 the sections on content negotiation and associated request header 188 fields will be moved to the second half. The current mess reflects 189 how widely dispersed these topics and associated requirements had 190 become in [RFC2616]. 192 1.1. Terminology 194 This specification uses a number of terms to refer to the roles 195 played by participants in, and objects of, the HTTP communication. 197 content negotiation 199 The mechanism for selecting the appropriate representation when 200 servicing a request. The representation in any response can be 201 negotiated (including error responses). 203 1.2. Conformance and Error Handling 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 This document defines conformance criteria for several roles in HTTP 210 communication, including Senders, Recipients, Clients, Servers, User- 211 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 212 Section 2 of [Part1] for definitions of these terms. 214 An implementation is considered conformant if it complies with all of 215 the requirements associated with its role(s). Note that SHOULD-level 216 requirements are relevant here, unless one of the documented 217 exceptions is applicable. 219 This document also uses ABNF to define valid protocol elements 220 (Section 1.3). In addition to the prose requirements placed upon 221 them, Senders MUST NOT generate protocol elements that are invalid. 223 Unless noted otherwise, Recipients MAY take steps to recover a usable 224 protocol element from an invalid construct. However, HTTP does not 225 define specific error handling mechanisms, except in cases where it 226 has direct impact on security. This is because different uses of the 227 protocol require different error handling strategies; for example, a 228 Web browser may wish to transparently recover from a response where 229 the Location header field doesn't parse according to the ABNF, 230 whereby in a systems control protocol using HTTP, this type of error 231 recovery could lead to dangerous consequences. 233 1.3. Syntax Notation 235 This specification uses the ABNF syntax defined in Section 1.2 of 236 [Part1] (which extends the syntax defined in [RFC5234] with a list 237 rule). Appendix D shows the collected ABNF, with the list rule 238 expanded. 240 The following core rules are included by reference, as defined in 241 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 242 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 243 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 244 sequence of data), SP (space), and VCHAR (any visible US-ASCII 245 character). 247 1.3.1. Core Rules 249 The core rules below are defined in [Part1]: 251 OWS = 252 token = 253 word = 255 1.3.2. ABNF Rules defined in other Parts of the Specification 257 The ABNF rules below are defined in other parts: 259 absolute-URI = 260 partial-URI = 261 qvalue = 263 2. Protocol Parameters 265 2.1. Character Encodings (charset) 267 HTTP uses charset names to indicate the character encoding of a 268 textual representation. 270 A character encoding is identified by a case-insensitive token. The 271 complete set of tokens is defined by the IANA Character Set registry 272 (). 274 charset = token 276 Although HTTP allows an arbitrary token to be used as a charset 277 value, any token that has a predefined value within the IANA 278 Character Set registry MUST represent the character encoding defined 279 by that registry. Applications SHOULD limit their use of character 280 encodings to those defined within the IANA registry. 282 HTTP uses charset in two contexts: within an Accept-Charset request 283 header field (in which the charset value is an unquoted token) and as 284 the value of a parameter in a Content-Type header field (within a 285 request or response), in which case the parameter value of the 286 charset parameter can be quoted. 288 Implementors need to be aware of IETF character set requirements 289 [RFC3629] [RFC2277]. 291 2.2. Content Codings 293 Content coding values indicate an encoding transformation that has 294 been or can be applied to a representation. Content codings are 295 primarily used to allow a representation to be compressed or 296 otherwise usefully transformed without losing the identity of its 297 underlying media type and without loss of information. Frequently, 298 the representation is stored in coded form, transmitted directly, and 299 only decoded by the recipient. 301 content-coding = token 303 All content-coding values are case-insensitive. HTTP/1.1 uses 304 content-coding values in the Accept-Encoding (Section 6.3) and 305 Content-Encoding (Section 6.5) header fields. Although the value 306 describes the content-coding, what is more important is that it 307 indicates what decoding mechanism will be required to remove the 308 encoding. 310 compress 312 See Section 5.1.2.1 of [Part1]. 314 deflate 316 See Section 5.1.2.2 of [Part1]. 318 gzip 320 See Section 5.1.2.3 of [Part1]. 322 2.2.1. Content Coding Registry 324 The HTTP Content Coding Registry defines the name space for the 325 content coding names. 327 Registrations MUST include the following fields: 329 o Name 331 o Description 333 o Pointer to specification text 335 Names of content codings MUST NOT overlap with names of transfer 336 codings (Section 5.1 of [Part1]), unless the encoding transformation 337 is identical (as it is the case for the compression codings defined 338 in Section 5.1.2 of [Part1]). 340 Values to be added to this name space require a specification (see 341 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 342 conform to the purpose of content coding defined in this section. 344 The registry itself is maintained at 345 . 347 2.3. Media Types 349 HTTP uses Internet Media Types [RFC2046] in the Content-Type 350 (Section 6.8) and Accept (Section 6.1) header fields in order to 351 provide open and extensible data typing and type negotiation. 353 media-type = type "/" subtype *( OWS ";" OWS parameter ) 354 type = token 355 subtype = token 357 The type/subtype MAY be followed by parameters in the form of 358 attribute/value pairs. 360 parameter = attribute "=" value 361 attribute = token 362 value = word 364 The type, subtype, and parameter attribute names are case- 365 insensitive. Parameter values might or might not be case-sensitive, 366 depending on the semantics of the parameter name. The presence or 367 absence of a parameter might be significant to the processing of a 368 media-type, depending on its definition within the media type 369 registry. 371 A parameter value that matches the token production can be 372 transmitted as either a token or within a quoted-string. The quoted 373 and unquoted values are equivalent. 375 Note that some older HTTP applications do not recognize media type 376 parameters. When sending data to older HTTP applications, 377 implementations SHOULD only use media type parameters when they are 378 required by that type/subtype definition. 380 Media-type values are registered with the Internet Assigned Number 381 Authority (IANA). The media type registration process is outlined in 382 [RFC4288]. Use of non-registered media types is discouraged. 384 2.3.1. Canonicalization and Text Defaults 386 Internet media types are registered with a canonical form. A 387 representation transferred via HTTP messages MUST be in the 388 appropriate canonical form prior to its transmission except for 389 "text" types, as defined in the next paragraph. 391 When in canonical form, media subtypes of the "text" type use CRLF as 392 the text line break. HTTP relaxes this requirement and allows the 393 transport of text media with plain CR or LF alone representing a line 394 break when it is done consistently for an entire representation. 395 HTTP applications MUST accept CRLF, bare CR, and bare LF as 396 indicating a line break in text media received via HTTP. In 397 addition, if the text is in a character encoding that does not use 398 octets 13 and 10 for CR and LF respectively, as is the case for some 399 multi-byte character encodings, HTTP allows the use of whatever octet 400 sequences are defined by that character encoding to represent the 401 equivalent of CR and LF for line breaks. This flexibility regarding 402 line breaks applies only to text media in the payload body; a bare CR 403 or LF MUST NOT be substituted for CRLF within any of the HTTP control 404 structures (such as header fields and multipart boundaries). 406 If a representation is encoded with a content-coding, the underlying 407 data MUST be in a form defined above prior to being encoded. 409 2.3.2. Multipart Types 411 MIME provides for a number of "multipart" types -- encapsulations of 412 one or more representations within a single message-body. All 413 multipart types share a common syntax, as defined in Section 5.1.1 of 415 [RFC2046], and MUST include a boundary parameter as part of the media 416 type value. The message body is itself a protocol element and MUST 417 therefore use only CRLF to represent line breaks between body-parts. 419 In general, HTTP treats a multipart message-body no differently than 420 any other media type: strictly as payload. HTTP does not use the 421 multipart boundary as an indicator of message-body length. In all 422 other respects, an HTTP user agent SHOULD follow the same or similar 423 behavior as a MIME user agent would upon receipt of a multipart type. 424 The MIME header fields within each body-part of a multipart message- 425 body do not have any significance to HTTP beyond that defined by 426 their MIME semantics. 428 If an application receives an unrecognized multipart subtype, the 429 application MUST treat it as being equivalent to "multipart/mixed". 431 Note: The "multipart/form-data" type has been specifically defined 432 for carrying form data suitable for processing via the POST 433 request method, as described in [RFC2388]. 435 2.4. Language Tags 437 A language tag, as defined in [RFC5646], identifies a natural 438 language spoken, written, or otherwise conveyed by human beings for 439 communication of information to other human beings. Computer 440 languages are explicitly excluded. HTTP uses language tags within 441 the Accept-Language and Content-Language fields. 443 In summary, a language tag is composed of one or more parts: A 444 primary language subtag followed by a possibly empty series of 445 subtags: 447 language-tag = 449 White space is not allowed within the tag and all tags are case- 450 insensitive. The name space of language subtags is administered by 451 the IANA (see 452 ). 454 Example tags include: 456 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 458 See [RFC5646] for further information. 460 3. Payload 462 HTTP messages MAY transfer a payload if not otherwise restricted by 463 the request method or response status code. The payload consists of 464 metadata, in the form of header fields, and data, in the form of the 465 sequence of octets in the message-body after any transfer-coding has 466 been decoded. 468 A "payload" in HTTP is always a partial or complete representation of 469 some resource. We use separate terms for payload and representation 470 because some messages contain only the associated representation's 471 header fields (e.g., responses to HEAD) or only some part(s) of the 472 representation (e.g., the 206 status code). 474 3.1. Payload Header Fields 476 HTTP header fields that specifically define the payload, rather than 477 the associated representation, are referred to as "payload header 478 fields". The following payload header fields are defined by 479 HTTP/1.1: 481 +-------------------+------------------------+ 482 | Header Field Name | Defined in... | 483 +-------------------+------------------------+ 484 | Content-Length | Section 8.2 of [Part1] | 485 | Content-Range | Section 5.2 of [Part5] | 486 +-------------------+------------------------+ 488 3.2. Payload Body 490 A payload body is only present in a message when a message-body is 491 present, as described in Section 3.3 of [Part1]. The payload body is 492 obtained from the message-body by decoding any Transfer-Encoding that 493 might have been applied to ensure safe and proper transfer of the 494 message. 496 4. Representation 498 A "representation" is information in a format that can be readily 499 communicated from one party to another. A resource representation is 500 information that reflects the state of that resource, as observed at 501 some point in the past (e.g., in a response to GET) or to be desired 502 at some point in the future (e.g., in a PUT request). 504 Most, but not all, representations transferred via HTTP are intended 505 to be a representation of the target resource (the resource 506 identified by the effective request URI). The precise semantics of a 507 representation are determined by the type of message (request or 508 response), the request method, the response status code, and the 509 representation metadata. For example, the above semantic is true for 510 the representation in any 200 (OK) response to GET and for the 511 representation in any PUT request. A 200 response to PUT, in 512 contrast, contains either a representation that describes the 513 successful action or a representation of the target resource, with 514 the latter indicated by a Content-Location header field with the same 515 value as the effective request URI. Likewise, response messages with 516 an error status code usually contain a representation that describes 517 the error and what next steps are suggested for resolving it. 519 4.1. Representation Header Fields 521 Representation header fields define metadata about the representation 522 data enclosed in the message-body or, if no message-body is present, 523 about the representation that would have been transferred in a 200 524 response to a simultaneous GET request with the same effective 525 request URI. 527 The following header fields are defined as representation metadata: 529 +-------------------+------------------------+ 530 | Header Field Name | Defined in... | 531 +-------------------+------------------------+ 532 | Content-Encoding | Section 6.5 | 533 | Content-Language | Section 6.6 | 534 | Content-Location | Section 6.7 | 535 | Content-Type | Section 6.8 | 536 | Expires | Section 3.3 of [Part6] | 537 | Last-Modified | Section 2.2 of [Part4] | 538 +-------------------+------------------------+ 540 4.2. Representation Data 542 The representation body associated with an HTTP message is either 543 provided as the payload body of the message or referred to by the 544 message semantics and the effective request URI. The representation 545 data is in a format and encoding defined by the representation 546 metadata header fields. 548 The data type of the representation data is determined via the header 549 fields Content-Type and Content-Encoding. These define a two-layer, 550 ordered encoding model: 552 representation-data := Content-Encoding( Content-Type( bits ) ) 554 Content-Type specifies the media type of the underlying data, which 555 defines both the data format and how that data SHOULD be processed by 556 the recipient (within the scope of the request method semantics). 557 Any HTTP/1.1 message containing a payload body SHOULD include a 558 Content-Type header field defining the media type of the associated 559 representation unless that metadata is unknown to the sender. If the 560 Content-Type header field is not present, it indicates that the 561 sender does not know the media type of the representation; recipients 562 MAY either assume that the media type is "application/octet-stream" 563 ([RFC2046], Section 4.5.1) or examine the content to determine its 564 type. 566 In practice, resource owners do not always properly configure their 567 origin server to provide the correct Content-Type for a given 568 representation, with the result that some clients will examine a 569 response body's content and override the specified type. Clients 570 that do so risk drawing incorrect conclusions, which might expose 571 additional security risks (e.g., "privilege escalation"). 572 Furthermore, it is impossible to determine the sender's intent by 573 examining the data format: many data formats match multiple media 574 types that differ only in processing semantics. Implementers are 575 encouraged to provide a means of disabling such "content sniffing" 576 when it is used. 578 Content-Encoding is used to indicate any additional content codings 579 applied to the data, usually for the purpose of data compression, 580 that are a property of the representation. If Content-Encoding is 581 not present, then there is no additional encoding beyond that defined 582 by the Content-Type. 584 5. Content Negotiation 586 HTTP responses include a representation which contains information 587 for interpretation, whether by a human user or for further 588 processing. Often, the server has different ways of representing the 589 same information; for example, in different formats, languages, or 590 using different character encodings. 592 HTTP clients and their users might have different or variable 593 capabilities, characteristics or preferences which would influence 594 which representation, among those available from the server, would be 595 best for the server to deliver. For this reason, HTTP provides 596 mechanisms for "content negotiation" -- a process of allowing 597 selection of a representation of a given resource, when more than one 598 is available. 600 This specification defines two patterns of content negotiation; 601 "server-driven", where the server selects the representation based 602 upon the client's stated preferences, and "agent-driven" negotiation, 603 where the server provides a list of representations for the client to 604 choose from, based upon their metadata. In addition, there are other 605 patterns: some applications use an "active content" pattern, where 606 the server returns active content which runs on the client and, based 607 on client available parameters, selects additional resources to 608 invoke. "Transparent Content Negotiation" ([RFC2295]) has also been 609 proposed. 611 These patterns are all widely used, and have trade-offs in 612 applicability and practicality. In particular, when the number of 613 preferences or capabilities to be expressed by a client are large 614 (such as when many different formats are supported by a user-agent), 615 server-driven negotiation becomes unwieldy, and might not be 616 appropriate. Conversely, when the number of representations to 617 choose from is very large, agent-driven negotiation might not be 618 appropriate. 620 Note that in all cases, the supplier of representations has the 621 responsibility for determining which representations might be 622 considered to be the "same information". 624 5.1. Server-driven Negotiation 626 If the selection of the best representation for a response is made by 627 an algorithm located at the server, it is called server-driven 628 negotiation. Selection is based on the available representations of 629 the response (the dimensions over which it can vary; e.g., language, 630 content-coding, etc.) and the contents of particular header fields in 631 the request message or on other information pertaining to the request 632 (such as the network address of the client). 634 Server-driven negotiation is advantageous when the algorithm for 635 selecting from among the available representations is difficult to 636 describe to the user agent, or when the server desires to send its 637 "best guess" to the client along with the first response (hoping to 638 avoid the round-trip delay of a subsequent request if the "best 639 guess" is good enough for the user). In order to improve the 640 server's guess, the user agent MAY include request header fields 641 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its 642 preferences for such a response. 644 Server-driven negotiation has disadvantages: 646 1. It is impossible for the server to accurately determine what 647 might be "best" for any given user, since that would require 648 complete knowledge of both the capabilities of the user agent and 649 the intended use for the response (e.g., does the user want to 650 view it on screen or print it on paper?). 652 2. Having the user agent describe its capabilities in every request 653 can be both very inefficient (given that only a small percentage 654 of responses have multiple representations) and a potential 655 violation of the user's privacy. 657 3. It complicates the implementation of an origin server and the 658 algorithms for generating responses to a request. 660 4. It might limit a public cache's ability to use the same response 661 for multiple user's requests. 663 Server-driven negotiation allows the user agent to specify its 664 preferences, but it cannot expect responses to always honour them. 665 For example, the origin server might not implement server-driven 666 negotiation, or it might decide that sending a response that doesn't 667 conform to them is better than sending a 406 (Not Acceptable) 668 response. 670 Many of the mechanisms for expressing preferences use quality values 671 to declare relative preference. See Section 5.3 of [Part1] for more 672 information. 674 HTTP/1.1 includes the following header fields for enabling server- 675 driven negotiation through description of user agent capabilities and 676 user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), 677 Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and 678 User-Agent (Section 9.10 of [Part2]). However, an origin server is 679 not limited to these dimensions and MAY vary the response based on 680 any aspect of the request, including aspects of the connection (e.g., 681 IP address) or information within extension header fields not defined 682 by this specification. 684 Note: In practice, User-Agent based negotiation is fragile, 685 because new clients might not be recognized. 687 The Vary header field (Section 3.5 of [Part6]) can be used to express 688 the parameters the server uses to select a representation that is 689 subject to server-driven negotiation. 691 5.2. Agent-driven Negotiation 693 With agent-driven negotiation, selection of the best representation 694 for a response is performed by the user agent after receiving an 695 initial response from the origin server. Selection is based on a 696 list of the available representations of the response included within 697 the header fields or body of the initial response, with each 698 representation identified by its own URI. Selection from among the 699 representations can be performed automatically (if the user agent is 700 capable of doing so) or manually by the user selecting from a 701 generated (possibly hypertext) menu. 703 Agent-driven negotiation is advantageous when the response would vary 704 over commonly-used dimensions (such as type, language, or encoding), 705 when the origin server is unable to determine a user agent's 706 capabilities from examining the request, and generally when public 707 caches are used to distribute server load and reduce network usage. 709 Agent-driven negotiation suffers from the disadvantage of needing a 710 second request to obtain the best alternate representation. This 711 second request is only efficient when caching is used. In addition, 712 this specification does not define any mechanism for supporting 713 automatic selection, though it also does not prevent any such 714 mechanism from being developed as an extension and used within 715 HTTP/1.1. 717 This specification defines the 300 (Multiple Choices) and 406 (Not 718 Acceptable) status codes for enabling agent-driven negotiation when 719 the server is unwilling or unable to provide a varying response using 720 server-driven negotiation. 722 6. Header Field Definitions 724 This section defines the syntax and semantics of HTTP/1.1 header 725 fields related to the payload of messages. 727 6.1. Accept 729 The "Accept" header field can be used by user agents to specify 730 response media types that are acceptable. Accept header fields can 731 be used to indicate that the request is specifically limited to a 732 small set of desired types, as in the case of a request for an in- 733 line image. 735 Accept = #( media-range [ accept-params ] ) 737 media-range = ( "*/*" 738 / ( type "/" "*" ) 739 / ( type "/" subtype ) 740 ) *( OWS ";" OWS parameter ) 741 accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) 742 accept-ext = OWS ";" OWS token [ "=" word ] 744 The asterisk "*" character is used to group media types into ranges, 745 with "*/*" indicating all media types and "type/*" indicating all 746 subtypes of that type. The media-range MAY include media type 747 parameters that are applicable to that range. 749 Each media-range MAY be followed by one or more accept-params, 750 beginning with the "q" parameter for indicating a relative quality 751 factor. The first "q" parameter (if any) separates the media-range 752 parameter(s) from the accept-params. Quality factors allow the user 753 or user agent to indicate the relative degree of preference for that 754 media-range, using the qvalue scale from 0 to 1 (Section 5.3 of 755 [Part1]). The default value is q=1. 757 Note: Use of the "q" parameter name to separate media type 758 parameters from Accept extension parameters is due to historical 759 practice. Although this prevents any media type parameter named 760 "q" from being used with a media range, such an event is believed 761 to be unlikely given the lack of any "q" parameters in the IANA 762 media type registry and the rare usage of any media type 763 parameters in Accept. Future media types are discouraged from 764 registering any parameter named "q". 766 The example 768 Accept: audio/*; q=0.2, audio/basic 770 SHOULD be interpreted as "I prefer audio/basic, but send me any audio 771 type if it is the best available after an 80% mark-down in quality". 773 A request without any Accept header field implies that the user agent 774 will accept any media type in response. If an Accept header field is 775 present in a request and none of the available representations for 776 the response have a media type that is listed as acceptable, the 777 origin server MAY either honor the Accept header field by sending a 778 406 (Not Acceptable) response or disregard the Accept header field by 779 treating the response as if it is not subject to content negotiation. 781 A more elaborate example is 783 Accept: text/plain; q=0.5, text/html, 784 text/x-dvi; q=0.8, text/x-c 786 Verbally, this would be interpreted as "text/html and text/x-c are 787 the preferred media types, but if they do not exist, then send the 788 text/x-dvi representation, and if that does not exist, send the text/ 789 plain representation". 791 Media ranges can be overridden by more specific media ranges or 792 specific media types. If more than one media range applies to a 793 given type, the most specific reference has precedence. For example, 795 Accept: text/*, text/plain, text/plain;format=flowed, */* 797 have the following precedence: 799 1. text/plain;format=flowed 801 2. text/plain 803 3. text/* 805 4. */* 807 The media type quality factor associated with a given type is 808 determined by finding the media range with the highest precedence 809 which matches that type. For example, 811 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 812 text/html;level=2;q=0.4, */*;q=0.5 814 would cause the following values to be associated: 816 +-------------------+---------------+ 817 | Media Type | Quality Value | 818 +-------------------+---------------+ 819 | text/html;level=1 | 1 | 820 | text/html | 0.7 | 821 | text/plain | 0.3 | 822 | image/jpeg | 0.5 | 823 | text/html;level=2 | 0.4 | 824 | text/html;level=3 | 0.7 | 825 +-------------------+---------------+ 827 Note: A user agent might be provided with a default set of quality 828 values for certain media ranges. However, unless the user agent is a 829 closed system which cannot interact with other rendering agents, this 830 default set ought to be configurable by the user. 832 6.2. Accept-Charset 834 The "Accept-Charset" header field can be used by user agents to 835 indicate what character encodings are acceptable in a response 836 payload. This field allows clients capable of understanding more 837 comprehensive or special-purpose character encodings to signal that 838 capability to a server which is capable of representing documents in 839 those character encodings. 841 Accept-Charset = 1#( ( charset / "*" ) 842 [ OWS ";" OWS "q=" qvalue ] ) 844 Character encoding values (a.k.a., charsets) are described in 845 Section 2.1. Each charset MAY be given an associated quality value 846 which represents the user's preference for that charset. The default 847 value is q=1. An example is 849 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 851 The special value "*", if present in the Accept-Charset field, 852 matches every character encoding which is not mentioned elsewhere in 853 the Accept-Charset field. If no "*" is present in an Accept-Charset 854 field, then all character encodings not explicitly mentioned get a 855 quality value of 0. 857 A request without any Accept-Charset header field implies that the 858 user agent will accept any character encoding in response. If an 859 Accept-Charset header field is present in a request and none of the 860 available representations for the response have a character encoding 861 that is listed as acceptable, the origin server MAY either honor the 862 Accept-Charset header field by sending a 406 (Not Acceptable) 863 response or disregard the Accept-Charset header field by treating the 864 response as if it is not subject to content negotiation. 866 6.3. Accept-Encoding 868 The "Accept-Encoding" header field can be used by user agents to 869 indicate what response content-codings (Section 2.2) are acceptable 870 in the response. An "identity" token is used as a synonym for "no 871 encoding" in order to communicate when no encoding is preferred. 873 Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) 874 codings = content-coding / "identity" / "*" 876 Each codings value MAY be given an associated quality value which 877 represents the preference for that encoding. The default value is 878 q=1. 880 For example, 882 Accept-Encoding: compress, gzip 883 Accept-Encoding: 884 Accept-Encoding: * 885 Accept-Encoding: compress;q=0.5, gzip;q=1.0 886 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 888 A server tests whether a content-coding for a given representation is 889 acceptable, according to an Accept-Encoding field, using these rules: 891 1. The special "*" symbol in an Accept-Encoding field matches any 892 available content-coding not explicitly listed in the header 893 field. 895 2. If the representation has no content-coding, then it is 896 acceptable by default unless specifically excluded by the Accept- 897 Encoding field stating either "identity;q=0" or "*;q=0" without a 898 more specific entry for "identity". 900 3. If the representation's content-coding is one of the content- 901 codings listed in the Accept-Encoding field, then it is 902 acceptable unless it is accompanied by a qvalue of 0. (As 903 defined in Section 5.3 of [Part1], a qvalue of 0 means "not 904 acceptable".) 906 4. If multiple content-codings are acceptable, then the acceptable 907 content-coding with the highest non-zero qvalue is preferred. 909 An Accept-Encoding header field with a combined field-value that is 910 empty implies that the user agent does not want any content-coding in 911 response. If an Accept-Encoding header field is present in a request 912 and none of the available representations for the response have a 913 content-coding that is listed as acceptable, the origin server SHOULD 914 send a response without any content-coding. 916 A request without an Accept-Encoding header field implies that the 917 user agent will accept any content-coding in response, but a 918 representation without content-coding is preferred for compatibility 919 with the widest variety of user agents. 921 Note: Most HTTP/1.0 applications do not recognize or obey qvalues 922 associated with content-codings. This means that qvalues will not 923 work and are not permitted with x-gzip or x-compress. 925 6.4. Accept-Language 927 The "Accept-Language" header field can be used by user agents to 928 indicate the set of natural languages that are preferred in the 929 response. Language tags are defined in Section 2.4. 931 Accept-Language = 932 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 933 language-range = 934 936 Each language-range can be given an associated quality value which 937 represents an estimate of the user's preference for the languages 938 specified by that range. The quality value defaults to "q=1". For 939 example, 940 Accept-Language: da, en-gb;q=0.8, en;q=0.7 942 would mean: "I prefer Danish, but will accept British English and 943 other types of English". (see also Section 2.3 of [RFC4647]) 945 For matching, Section 3 of [RFC4647] defines several matching 946 schemes. Implementations can offer the most appropriate matching 947 scheme for their requirements. 949 Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is 950 identical to the matching scheme that was previously defined in 951 Section 14.4 of [RFC2616]. 953 It might be contrary to the privacy expectations of the user to send 954 an Accept-Language header field with the complete linguistic 955 preferences of the user in every request. For a discussion of this 956 issue, see Section 8.1. 958 As intelligibility is highly dependent on the individual user, it is 959 recommended that client applications make the choice of linguistic 960 preference available to the user. If the choice is not made 961 available, then the Accept-Language header field MUST NOT be given in 962 the request. 964 Note: When making the choice of linguistic preference available to 965 the user, we remind implementors of the fact that users are not 966 familiar with the details of language matching as described above, 967 and ought to be provided appropriate guidance. As an example, 968 users might assume that on selecting "en-gb", they will be served 969 any kind of English document if British English is not available. 970 A user agent might suggest in such a case to add "en" to get the 971 best matching behavior. 973 6.5. Content-Encoding 975 The "Content-Encoding" header field indicates what content-codings 976 have been applied to the representation beyond those inherent in the 977 media type, and thus what decoding mechanisms must be applied in 978 order to obtain the media-type referenced by the Content-Type header 979 field. Content-Encoding is primarily used to allow a representation 980 to be compressed without losing the identity of its underlying media 981 type. 983 Content-Encoding = 1#content-coding 985 Content codings are defined in Section 2.2. An example of its use is 987 Content-Encoding: gzip 989 The content-coding is a characteristic of the representation. 990 Typically, the representation body is stored with this encoding and 991 is only decoded before rendering or analogous usage. However, a 992 transforming proxy MAY modify the content-coding if the new coding is 993 known to be acceptable to the recipient, unless the "no-transform" 994 cache-control directive is present in the message. 996 If the media type includes an inherent encoding, such as a data 997 format that is always compressed, then that encoding would not be 998 restated as a Content-Encoding even if it happens to be the same 999 algorithm as one of the content-codings. Such a content-coding would 1000 only be listed if, for some bizarre reason, it is applied a second 1001 time to form the representation. Likewise, an origin server might 1002 choose to publish the same payload data as multiple representations 1003 that differ only in whether the coding is defined as part of Content- 1004 Type or Content-Encoding, since some user agents will behave 1005 differently in their handling of each response (e.g., open a "Save as 1006 ..." dialog instead of automatic decompression and rendering of 1007 content). 1009 A representation that has a content-coding applied to it MUST include 1010 a Content-Encoding header field (Section 6.5) that lists the content- 1011 coding(s) applied. 1013 If multiple encodings have been applied to a representation, the 1014 content codings MUST be listed in the order in which they were 1015 applied. Additional information about the encoding parameters MAY be 1016 provided by other header fields not defined by this specification. 1018 If the content-coding of a representation in a request message is not 1019 acceptable to the origin server, the server SHOULD respond with a 1020 status code of 415 (Unsupported Media Type). 1022 6.6. Content-Language 1024 The "Content-Language" header field describes the natural language(s) 1025 of the intended audience for the representation. Note that this 1026 might not be equivalent to all the languages used within the 1027 representation. 1029 Content-Language = 1#language-tag 1031 Language tags are defined in Section 2.4. The primary purpose of 1032 Content-Language is to allow a user to identify and differentiate 1033 representations according to the user's own preferred language. 1034 Thus, if the body content is intended only for a Danish-literate 1035 audience, the appropriate field is 1036 Content-Language: da 1038 If no Content-Language is specified, the default is that the content 1039 is intended for all language audiences. This might mean that the 1040 sender does not consider it to be specific to any natural language, 1041 or that the sender does not know for which language it is intended. 1043 Multiple languages MAY be listed for content that is intended for 1044 multiple audiences. For example, a rendition of the "Treaty of 1045 Waitangi", presented simultaneously in the original Maori and English 1046 versions, would call for 1048 Content-Language: mi, en 1050 However, just because multiple languages are present within a 1051 representation does not mean that it is intended for multiple 1052 linguistic audiences. An example would be a beginner's language 1053 primer, such as "A First Lesson in Latin", which is clearly intended 1054 to be used by an English-literate audience. In this case, the 1055 Content-Language would properly only include "en". 1057 Content-Language MAY be applied to any media type -- it is not 1058 limited to textual documents. 1060 6.7. Content-Location 1062 The "Content-Location" header field supplies a URI that can be used 1063 as a specific identifier for the representation in this message. In 1064 other words, if one were to perform a GET on this URI at the time of 1065 this message's generation, then a 200 response would contain the same 1066 representation that is enclosed as payload in this message. 1068 Content-Location = absolute-URI / partial-URI 1070 The Content-Location value is not a replacement for the effective 1071 Request URI (Section 4.3 of [Part1]). It is representation metadata. 1072 It has the same syntax and semantics as the header field of the same 1073 name defined for MIME body parts in Section 4 of [RFC2557]. However, 1074 its appearance in an HTTP message has some special implications for 1075 HTTP recipients. 1077 If Content-Location is included in a response message and its value 1078 is the same as the effective request URI, then the response payload 1079 SHOULD be considered the current representation of that resource. 1080 For a GET or HEAD request, this is the same as the default semantics 1081 when no Content-Location is provided by the server. For a state- 1082 changing request like PUT or POST, it implies that the server's 1083 response contains the new representation of that resource, thereby 1084 distinguishing it from representations that might only report about 1085 the action (e.g., "It worked!"). This allows authoring applications 1086 to update their local copies without the need for a subsequent GET 1087 request. 1089 If Content-Location is included in a response message and its value 1090 differs from the effective request URI, then the origin server is 1091 informing recipients that this representation has its own, presumably 1092 more specific, identifier. For a GET or HEAD request, this is an 1093 indication that the effective request URI identifies a resource that 1094 is subject to content negotiation and the representation selected for 1095 this response can also be found at the identified URI. For other 1096 methods, such a Content-Location indicates that this representation 1097 contains a report on the action's status and the same report is 1098 available (for future access with GET) at the given URI. For 1099 example, a purchase transaction made via a POST request might include 1100 a receipt document as the payload of the 200 response; the Content- 1101 Location value provides an identifier for retrieving a copy of that 1102 same receipt in the future. 1104 If Content-Location is included in a request message, then it MAY be 1105 interpreted by the origin server as an indication of where the user 1106 agent originally obtained the content of the enclosed representation 1107 (prior to any subsequent modification of the content by that user 1108 agent). In other words, the user agent is providing the same 1109 representation metadata that it received with the original 1110 representation. However, such interpretation MUST NOT be used to 1111 alter the semantics of the method requested by the client. For 1112 example, if a client makes a PUT request on a negotiated resource and 1113 the origin server accepts that PUT (without redirection), then the 1114 new set of values for that resource is expected to be consistent with 1115 the one representation supplied in that PUT; the Content-Location 1116 cannot be used as a form of reverse content selection that identifies 1117 only one of the negotiated representations to be updated. If the 1118 user agent had wanted the latter semantics, it would have applied the 1119 PUT directly to the Content-Location URI. 1121 A Content-Location field received in a request message is transitory 1122 information that SHOULD NOT be saved with other representation 1123 metadata for use in later responses. The Content-Location's value 1124 might be saved for use in other contexts, such as within source links 1125 or other metadata. 1127 A cache cannot assume that a representation with a Content-Location 1128 different from the URI used to retrieve it can be used to respond to 1129 later requests on that Content-Location URI. 1131 If the Content-Location value is a partial URI, the partial URI is 1132 interpreted relative to the effective request URI. 1134 6.8. Content-Type 1136 The "Content-Type" header field indicates the media type of the 1137 representation. In the case of responses to the HEAD method, the 1138 media type is that which would have been sent had the request been a 1139 GET. 1141 Content-Type = media-type 1143 Media types are defined in Section 2.3. An example of the field is 1145 Content-Type: text/html; charset=ISO-8859-4 1147 Further discussion of Content-Type is provided in Section 4.2. 1149 7. IANA Considerations 1151 7.1. Header Field Registration 1153 The Message Header Field Registry located at shall be 1155 updated with the permanent registrations below (see [RFC3864]): 1157 +-------------------+----------+----------+--------------+ 1158 | Header Field Name | Protocol | Status | Reference | 1159 +-------------------+----------+----------+--------------+ 1160 | Accept | http | standard | Section 6.1 | 1161 | Accept-Charset | http | standard | Section 6.2 | 1162 | Accept-Encoding | http | standard | Section 6.3 | 1163 | Accept-Language | http | standard | Section 6.4 | 1164 | Content-Encoding | http | standard | Section 6.5 | 1165 | Content-Language | http | standard | Section 6.6 | 1166 | Content-Location | http | standard | Section 6.7 | 1167 | Content-Type | http | standard | Section 6.8 | 1168 | MIME-Version | http | standard | Appendix A.1 | 1169 +-------------------+----------+----------+--------------+ 1171 The change controller is: "IETF (iesg@ietf.org) - Internet 1172 Engineering Task Force". 1174 7.2. Content Coding Registry 1176 The registration procedure for HTTP Content Codings is now defined by 1177 Section 2.2.1 of this document. 1179 The HTTP Content Codings Registry located at 1180 shall be updated 1181 with the registration below: 1183 +----------+-----------------------------------------+--------------+ 1184 | Name | Description | Reference | 1185 +----------+-----------------------------------------+--------------+ 1186 | compress | UNIX "compress" program method | Section | 1187 | | | 5.1.2.1 of | 1188 | | | [Part1] | 1189 | deflate | "deflate" compression mechanism | Section | 1190 | | ([RFC1951]) used inside the "zlib" data | 5.1.2.2 of | 1191 | | format ([RFC1950]) | [Part1] | 1192 | gzip | Same as GNU zip [RFC1952] | Section | 1193 | | | 5.1.2.3 of | 1194 | | | [Part1] | 1195 | identity | reserved (synonym for "no encoding" in | Section 6.3 | 1196 | | Accept-Encoding header field) | | 1197 +----------+-----------------------------------------+--------------+ 1199 8. Security Considerations 1201 This section is meant to inform application developers, information 1202 providers, and users of the security limitations in HTTP/1.1 as 1203 described by this document. The discussion does not include 1204 definitive solutions to the problems revealed, though it does make 1205 some suggestions for reducing security risks. 1207 8.1. Privacy Issues Connected to Accept Header Fields 1209 Accept headers fields can reveal information about the user to all 1210 servers which are accessed. The Accept-Language header field in 1211 particular can reveal information the user would consider to be of a 1212 private nature, because the understanding of particular languages is 1213 often strongly correlated to the membership of a particular ethnic 1214 group. User agents which offer the option to configure the contents 1215 of an Accept-Language header field to be sent in every request are 1216 strongly encouraged to let the configuration process include a 1217 message which makes the user aware of the loss of privacy involved. 1219 An approach that limits the loss of privacy would be for a user agent 1220 to omit the sending of Accept-Language header fields by default, and 1221 to ask the user whether or not to start sending Accept-Language 1222 header fields to a server if it detects, by looking for any Vary 1223 header fields generated by the server, that such sending could 1224 improve the quality of service. 1226 Elaborate user-customized accept header fields sent in every request, 1227 in particular if these include quality values, can be used by servers 1228 as relatively reliable and long-lived user identifiers. Such user 1229 identifiers would allow content providers to do click-trail tracking, 1230 and would allow collaborating content providers to match cross-server 1231 click-trails or form submissions of individual users. Note that for 1232 many users not behind a proxy, the network address of the host 1233 running the user agent will also serve as a long-lived user 1234 identifier. In environments where proxies are used to enhance 1235 privacy, user agents ought to be conservative in offering accept 1236 header configuration options to end users. As an extreme privacy 1237 measure, proxies could filter the accept header fields in relayed 1238 requests. General purpose user agents which provide a high degree of 1239 header configurability SHOULD warn users about the loss of privacy 1240 which can be involved. 1242 9. Acknowledgments 1244 See Section 11 of [Part1]. 1246 10. References 1248 10.1. Normative References 1250 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1251 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1252 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1253 and Message Parsing", draft-ietf-httpbis-p1-messaging-18 1254 (work in progress), January 2012. 1256 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1257 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1258 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1259 Semantics", draft-ietf-httpbis-p2-semantics-18 (work in 1260 progress), January 2012. 1262 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1263 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1264 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1265 Requests", draft-ietf-httpbis-p4-conditional-18 (work in 1266 progress), January 2012. 1268 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1269 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1270 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1271 Partial Responses", draft-ietf-httpbis-p5-range-18 (work 1272 in progress), January 2012. 1274 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1275 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1276 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 1277 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in 1278 progress), January 2012. 1280 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 1281 Specification version 3.3", RFC 1950, May 1996. 1283 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 1284 version 1.3", RFC 1951, May 1996. 1286 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 1287 Randers-Pehrson, "GZIP file format specification version 1288 4.3", RFC 1952, May 1996. 1290 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1291 Extensions (MIME) Part One: Format of Internet Message 1292 Bodies", RFC 2045, November 1996. 1294 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1295 Extensions (MIME) Part Two: Media Types", RFC 2046, 1296 November 1996. 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, March 1997. 1301 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language 1302 Tags", BCP 47, RFC 4647, September 2006. 1304 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1305 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1307 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1308 Languages", BCP 47, RFC 5646, September 2009. 1310 10.2. Informative References 1312 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 1313 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 1315 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1316 Extensions (MIME) Part Five: Conformance Criteria and 1317 Examples", RFC 2049, November 1996. 1319 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 1320 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 1321 RFC 2068, January 1997. 1323 [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, 1324 February 1997. 1326 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1327 Languages", BCP 18, RFC 2277, January 1998. 1329 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1330 in HTTP", RFC 2295, March 1998. 1332 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 1333 form-data", RFC 2388, August 1998. 1335 [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, 1336 "MIME Encapsulation of Aggregate Documents, such as HTML 1337 (MHTML)", RFC 2557, March 1999. 1339 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1340 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1341 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1343 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1344 10646", STD 63, RFC 3629, November 2003. 1346 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1347 Procedures for Message Header Fields", BCP 90, RFC 3864, 1348 September 2004. 1350 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1351 Registration Procedures", BCP 13, RFC 4288, December 2005. 1353 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1354 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1355 May 2008. 1357 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 1358 October 2008. 1360 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1361 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1362 RFC 6151, March 2011. 1364 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1365 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1366 June 2011. 1368 Appendix A. Differences between HTTP and MIME 1370 HTTP/1.1 uses many of the constructs defined for Internet Mail 1371 ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME 1373 [RFC2045]) to allow a message-body to be transmitted in an open 1374 variety of representations and with extensible mechanisms. However, 1375 RFC 2045 discusses mail, and HTTP has a few features that are 1376 different from those described in MIME. These differences were 1377 carefully chosen to optimize performance over binary connections, to 1378 allow greater freedom in the use of new media types, to make date 1379 comparisons easier, and to acknowledge the practice of some early 1380 HTTP servers and clients. 1382 This appendix describes specific areas where HTTP differs from MIME. 1383 Proxies and gateways to strict MIME environments SHOULD be aware of 1384 these differences and provide the appropriate conversions where 1385 necessary. Proxies and gateways from MIME environments to HTTP also 1386 need to be aware of the differences because some conversions might be 1387 required. 1389 A.1. MIME-Version 1391 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages 1392 MAY include a single MIME-Version header field to indicate what 1393 version of the MIME protocol was used to construct the message. Use 1394 of the MIME-Version header field indicates that the message is in 1395 full compliance with the MIME protocol (as defined in [RFC2045]). 1396 Proxies/gateways are responsible for ensuring full compliance (where 1397 possible) when exporting HTTP messages to strict MIME environments. 1399 MIME-Version = 1*DIGIT "." 1*DIGIT 1401 MIME version "1.0" is the default for use in HTTP/1.1. However, 1402 HTTP/1.1 message parsing and semantics are defined by this document 1403 and not the MIME specification. 1405 A.2. Conversion to Canonical Form 1407 MIME requires that an Internet mail body-part be converted to 1408 canonical form prior to being transferred, as described in Section 4 1409 of [RFC2049]. Section 2.3.1 of this document describes the forms 1410 allowed for subtypes of the "text" media type when transmitted over 1411 HTTP. [RFC2046] requires that content with a type of "text" 1412 represent line breaks as CRLF and forbids the use of CR or LF outside 1413 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to 1414 indicate a line break within text content when a message is 1415 transmitted over HTTP. 1417 Where it is possible, a proxy or gateway from HTTP to a strict MIME 1418 environment SHOULD translate all line breaks within the text media 1419 types described in Section 2.3.1 of this document to the RFC 2049 1420 canonical form of CRLF. Note, however, that this might be 1421 complicated by the presence of a Content-Encoding and by the fact 1422 that HTTP allows the use of some character encodings which do not use 1423 octets 13 and 10 to represent CR and LF, respectively, as is the case 1424 for some multi-byte character encodings. 1426 Conversion will break any cryptographic checksums applied to the 1427 original content unless the original content is already in canonical 1428 form. Therefore, the canonical form is recommended for any content 1429 that uses such checksums in HTTP. 1431 A.3. Conversion of Date Formats 1433 HTTP/1.1 uses a restricted set of date formats (Section 8 of [Part2]) 1434 to simplify the process of date comparison. Proxies and gateways 1435 from other protocols SHOULD ensure that any Date header field present 1436 in a message conforms to one of the HTTP/1.1 formats and rewrite the 1437 date if necessary. 1439 A.4. Introduction of Content-Encoding 1441 MIME does not include any concept equivalent to HTTP/1.1's Content- 1442 Encoding header field. Since this acts as a modifier on the media 1443 type, proxies and gateways from HTTP to MIME-compliant protocols MUST 1444 either change the value of the Content-Type header field or decode 1445 the representation before forwarding the message. (Some experimental 1446 applications of Content-Type for Internet mail have used a media-type 1447 parameter of ";conversions=" to perform a function 1448 equivalent to Content-Encoding. However, this parameter is not part 1449 of the MIME standards). 1451 A.5. No Content-Transfer-Encoding 1453 HTTP does not use the Content-Transfer-Encoding field of MIME. 1454 Proxies and gateways from MIME-compliant protocols to HTTP MUST 1455 remove any Content-Transfer-Encoding prior to delivering the response 1456 message to an HTTP client. 1458 Proxies and gateways from HTTP to MIME-compliant protocols are 1459 responsible for ensuring that the message is in the correct format 1460 and encoding for safe transport on that protocol, where "safe 1461 transport" is defined by the limitations of the protocol being used. 1462 Such a proxy or gateway SHOULD label the data with an appropriate 1463 Content-Transfer-Encoding if doing so will improve the likelihood of 1464 safe transport over the destination protocol. 1466 A.6. Introduction of Transfer-Encoding 1468 HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.6 1469 of [Part1]). Proxies/gateways MUST remove any transfer-coding prior 1470 to forwarding a message via a MIME-compliant protocol. 1472 A.7. MHTML and Line Length Limitations 1474 HTTP implementations which share code with MHTML [RFC2557] 1475 implementations need to be aware of MIME line length limitations. 1476 Since HTTP does not have this limitation, HTTP does not fold long 1477 lines. MHTML messages being transported by HTTP follow all 1478 conventions of MHTML, including line length limitations and folding, 1479 canonicalization, etc., since HTTP transports all message-bodies as 1480 payload (see Section 2.3.2) and does not interpret the content or any 1481 MIME header lines that might be contained therein. 1483 Appendix B. Additional Features 1485 [RFC1945] and [RFC2068] document protocol elements used by some 1486 existing HTTP implementations, but not consistently and correctly 1487 across most HTTP/1.1 applications. Implementors are advised to be 1488 aware of these features, but cannot rely upon their presence in, or 1489 interoperability with, other HTTP/1.1 applications. Some of these 1490 describe proposed experimental features, and some describe features 1491 that experimental deployment found lacking that are now addressed in 1492 the base HTTP/1.1 specification. 1494 A number of other header fields, such as Content-Disposition and 1495 Title, from SMTP and MIME are also often implemented (see [RFC6266] 1496 and [RFC2076]). 1498 Appendix C. Changes from RFC 2616 1500 Clarify contexts that charset is used in. (Section 2.1) 1502 Remove the default character encoding for text media types; the 1503 default now is whatever the media type definition says. 1504 (Section 2.3.1) 1506 Change ABNF productions for header fields to only define the field 1507 value. (Section 6) 1509 Remove definition of Content-MD5 header field because it was 1510 inconsistently implemented with respect to partial responses, and 1511 also because of known deficiencies in the hash algorithm itself (see 1512 [RFC6151] for details). (Section 6) 1513 Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2) 1515 Remove base URI setting semantics for Content-Location due to poor 1516 implementation support, which was caused by too many broken servers 1517 emitting bogus Content-Location header fields, and also the 1518 potentially undesirable effect of potentially breaking relative links 1519 in content-negotiated resources. (Section 6.7) 1521 Remove discussion of Content-Disposition header field, it is now 1522 defined by [RFC6266]. (Appendix B) 1524 Remove reference to non-existant identity transfer-coding value 1525 tokens. (Appendix A.5) 1527 Appendix D. Collected ABNF 1529 Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 1530 OWS media-range [ accept-params ] ] ) ] 1531 Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" 1532 qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" 1533 qvalue ] ] ) 1534 Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) ) 1535 *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] 1536 Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q=" 1537 qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] 1538 ] ) 1540 Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS 1541 content-coding ] ) 1542 Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS 1543 language-tag ] ) 1544 Content-Location = absolute-URI / partial-URI 1545 Content-Type = media-type 1547 MIME-Version = 1*DIGIT "." 1*DIGIT 1549 OWS = 1551 absolute-URI = 1552 accept-ext = OWS ";" OWS token [ "=" word ] 1553 accept-params = OWS ";" OWS "q=" qvalue *accept-ext 1554 attribute = token 1556 charset = token 1557 codings = content-coding / "identity" / "*" 1558 content-coding = token 1560 language-range = 1561 language-tag = 1563 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 1564 ";" OWS parameter ) 1565 media-type = type "/" subtype *( OWS ";" OWS parameter ) 1567 parameter = attribute "=" value 1568 partial-URI = 1570 qvalue = 1572 subtype = token 1574 token = 1575 type = token 1577 value = word 1579 word = 1581 ABNF diagnostics: 1583 ; Accept defined but not used 1584 ; Accept-Charset defined but not used 1585 ; Accept-Encoding defined but not used 1586 ; Accept-Language defined but not used 1587 ; Content-Encoding defined but not used 1588 ; Content-Language defined but not used 1589 ; Content-Location defined but not used 1590 ; Content-Type defined but not used 1591 ; MIME-Version defined but not used 1593 Appendix E. Change Log (to be removed by RFC Editor before publication) 1595 E.1. Since RFC 2616 1597 Extracted relevant partitions from [RFC2616]. 1599 E.2. Since draft-ietf-httpbis-p3-payload-00 1601 Closed issues: 1603 o : "Media Type 1604 Registrations" () 1606 o : "Clarification 1607 regarding quoting of charset values" 1608 () 1610 o : "Remove 1611 'identity' token references" 1612 () 1614 o : "Accept- 1615 Encoding BNF" 1617 o : "Normative and 1618 Informative references" 1620 o : "RFC1700 1621 references" 1623 o : "Updating to 1624 RFC4288" 1626 o : "Informative 1627 references" 1629 o : "ISO-8859-1 1630 Reference" 1632 o : "Encoding 1633 References Normative" 1635 o : "Normative up- 1636 to-date references" 1638 E.3. Since draft-ietf-httpbis-p3-payload-01 1640 Ongoing work on ABNF conversion 1641 (): 1643 o Add explicit references to BNF syntax and rules imported from 1644 other parts of the specification. 1646 E.4. Since draft-ietf-httpbis-p3-payload-02 1648 Closed issues: 1650 o : "Quoting 1651 Charsets" 1653 o : 1654 "Classification for Allow header" 1656 o : "missing 1657 default for qvalue in description of Accept-Encoding" 1659 Ongoing work on IANA Message Header Field Registration 1660 (): 1662 o Reference RFC 3984, and update header field registrations for 1663 headers defined in this document. 1665 E.5. Since draft-ietf-httpbis-p3-payload-03 1667 Closed issues: 1669 o : "Quoting 1670 Charsets" 1672 o : "language tag 1673 matching (Accept-Language) vs RFC4647" 1675 o : "RFC 1806 has 1676 been replaced by RFC2183" 1678 Other changes: 1680 o : "Encoding 1681 References Normative" -- rephrase the annotation and reference 1682 BCP97. 1684 E.6. Since draft-ietf-httpbis-p3-payload-04 1686 Closed issues: 1688 o : "RFC 2822 is 1689 updated by RFC 5322" 1691 Ongoing work on ABNF conversion 1692 (): 1694 o Use "/" instead of "|" for alternatives. 1696 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1697 whitespace ("OWS") and required whitespace ("RWS"). 1699 o Rewrite ABNFs to spell out whitespace rules, factor out header 1700 field value format definitions. 1702 E.7. Since draft-ietf-httpbis-p3-payload-05 1704 Closed issues: 1706 o : "Join 1707 "Differences Between HTTP Entities and RFC 2045 Entities"?" 1709 Final work on ABNF conversion 1710 (): 1712 o Add appendix containing collected and expanded ABNF, reorganize 1713 ABNF introduction. 1715 Other changes: 1717 o Move definition of quality values into Part 1. 1719 E.8. Since draft-ietf-httpbis-p3-payload-06 1721 Closed issues: 1723 o : "Content- 1724 Location isn't special" 1726 o : "Content 1727 Sniffing" 1729 E.9. Since draft-ietf-httpbis-p3-payload-07 1731 Closed issues: 1733 o : "Updated 1734 reference for language tags" 1736 o : "Clarify rules 1737 for determining what entities a response carries" 1739 o : "Content- 1740 Location base-setting problems" 1742 o : "Content 1743 Sniffing" 1745 o : "pick IANA 1746 policy (RFC5226) for Transfer Coding / Content Coding" 1748 o : "move 1749 definitions of gzip/deflate/compress to part 1" 1751 Partly resolved issues: 1753 o : "update IANA 1754 requirements wrt Transfer-Coding values" (add the IANA 1755 Considerations subsection) 1757 o : "update IANA 1758 requirements wrt Content-Coding values" (add the IANA 1759 Considerations subsection) 1761 E.10. Since draft-ietf-httpbis-p3-payload-08 1763 Closed issues: 1765 o : "Content 1766 Negotiation for media types" 1768 o : "Accept- 1769 Language: which RFC4647 filtering?" 1771 E.11. Since draft-ietf-httpbis-p3-payload-09 1773 Closed issues: 1775 o : "MIME-Version 1776 not listed in P1, general header fields" 1778 o : "IANA registry 1779 for content/transfer encodings" 1781 o : "Content 1782 Sniffing" 1784 o : "use of term 1785 "word" when talking about header structure" 1787 Partly resolved issues: 1789 o : "Term for the 1790 requested resource's URI" 1792 E.12. Since draft-ietf-httpbis-p3-payload-10 1794 Closed issues: 1796 o : "Clarify 1797 'Requested Variant'" 1799 o : "Content- 1800 Location isn't special" 1802 o : "Delimiting 1803 messages with multipart/byteranges" 1805 o : "Clarify 1806 entity / representation / variant terminology" 1808 o : "confusing 1809 req. language for Content-Location" 1811 o : "Content- 1812 Location on 304 responses" 1814 o : "'requested 1815 resource' in content-encoding definition" 1817 o : "consider 1818 removing the 'changes from 2068' sections" 1820 Partly resolved issues: 1822 o : "Content-MD5 1823 and partial responses" 1825 E.13. Since draft-ietf-httpbis-p3-payload-11 1827 Closed issues: 1829 o : "Factor out 1830 Content-Disposition" 1832 E.14. Since draft-ietf-httpbis-p3-payload-12 1834 Closed issues: 1836 o : "Header 1837 Classification" 1839 o : "untangle 1840 ABNFs for header fields" 1842 o : "potentially 1843 misleading MAY in media-type def" 1845 E.15. Since draft-ietf-httpbis-p3-payload-13 1847 Closed issues: 1849 o : "Default 1850 charsets for text media types" 1852 o : "Content-MD5 1853 and partial responses" 1855 o : "untangle 1856 ABNFs for header fields" 1858 o : "confusing 1859 undefined parameter in media range example" 1861 E.16. Since draft-ietf-httpbis-p3-payload-14 1863 None. 1865 E.17. Since draft-ietf-httpbis-p3-payload-15 1867 Closed issues: 1869 o : "Strength of 1870 requirements on Accept re: 406" 1872 E.18. Since draft-ietf-httpbis-p3-payload-16 1874 Closed issues: 1876 o : "Document 1877 HTTP's error-handling philosophy" 1879 E.19. Since draft-ietf-httpbis-p3-payload-17 1881 Closed issues: 1883 o : "intended 1884 maturity level vs normative references" 1886 Index 1888 A 1889 Accept header field 16 1890 Accept-Charset header field 18 1891 Accept-Encoding header field 19 1892 Accept-Language header field 20 1894 C 1895 Coding Format 1896 compress 7 1897 deflate 7 1898 gzip 8 1899 compress (Coding Format) 7 1900 content negotiation 5 1901 Content-Encoding header field 21 1902 Content-Language header field 22 1903 Content-Location header field 23 1904 Content-Type header field 25 1906 D 1907 deflate (Coding Format) 7 1909 G 1910 Grammar 1911 Accept 16 1912 Accept-Charset 18 1913 Accept-Encoding 19 1914 accept-ext 16 1915 Accept-Language 20 1916 accept-params 16 1917 attribute 8 1918 charset 7 1919 codings 19 1920 content-coding 7 1921 Content-Encoding 21 1922 Content-Language 22 1923 Content-Location 23 1924 Content-Type 25 1925 language-range 20 1926 language-tag 10 1927 media-range 16 1928 media-type 8 1929 MIME-Version 30 1930 parameter 8 1931 subtype 8 1932 type 8 1933 value 8 1934 gzip (Coding Format) 8 1936 H 1937 Header Fields 1938 Accept 16 1939 Accept-Charset 18 1940 Accept-Encoding 19 1941 Accept-Language 20 1942 Content-Encoding 21 1943 Content-Language 22 1944 Content-Location 23 1945 Content-Type 25 1946 MIME-Version 30 1948 M 1949 MIME-Version header field 30 1951 P 1952 payload 11 1954 R 1955 representation 11 1957 Authors' Addresses 1959 Roy T. Fielding (editor) 1960 Adobe Systems Incorporated 1961 345 Park Ave 1962 San Jose, CA 95110 1963 USA 1965 EMail: fielding@gbiv.com 1966 URI: http://roy.gbiv.com/ 1968 Jim Gettys 1969 Alcatel-Lucent Bell Labs 1970 21 Oak Knoll Road 1971 Carlisle, MA 01741 1972 USA 1974 EMail: jg@freedesktop.org 1975 URI: http://gettys.wordpress.com/ 1977 Jeffrey C. Mogul 1978 Hewlett-Packard Company 1979 HP Labs, Large Scale Systems Group 1980 1501 Page Mill Road, MS 1177 1981 Palo Alto, CA 94304 1982 USA 1984 EMail: JeffMogul@acm.org 1985 Henrik Frystyk Nielsen 1986 Microsoft Corporation 1987 1 Microsoft Way 1988 Redmond, WA 98052 1989 USA 1991 EMail: henrikn@microsoft.com 1993 Larry Masinter 1994 Adobe Systems Incorporated 1995 345 Park Ave 1996 San Jose, CA 95110 1997 USA 1999 EMail: LMM@acm.org 2000 URI: http://larry.masinter.net/ 2002 Paul J. Leach 2003 Microsoft Corporation 2004 1 Microsoft Way 2005 Redmond, WA 98052 2007 EMail: paulle@microsoft.com 2009 Tim Berners-Lee 2010 World Wide Web Consortium 2011 MIT Computer Science and Artificial Intelligence Laboratory 2012 The Stata Center, Building 32 2013 32 Vassar Street 2014 Cambridge, MA 02139 2015 USA 2017 EMail: timbl@w3.org 2018 URI: http://www.w3.org/People/Berners-Lee/ 2019 Yves Lafon (editor) 2020 World Wide Web Consortium 2021 W3C / ERCIM 2022 2004, rte des Lucioles 2023 Sophia-Antipolis, AM 06902 2024 France 2026 EMail: ylafon@w3.org 2027 URI: http://www.raubacapeu.net/people/yves/ 2029 Julian F. Reschke (editor) 2030 greenbytes GmbH 2031 Hafenweg 16 2032 Muenster, NW 48155 2033 Germany 2035 Phone: +49 251 2807760 2036 Fax: +49 251 2807761 2037 EMail: julian.reschke@greenbytes.de 2038 URI: http://greenbytes.de/tech/webdav/