draft-ietf-httpbis-p3-payload-09.txt   draft-ietf-httpbis-p3-payload-10.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track Alcatel-Lucent
Expires: September 9, 2010 J. Mogul Expires: January 13, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 8, 2010 July 12, 2010
HTTP/1.1, part 3: Message Payload and Content Negotiation HTTP/1.1, part 3: Message Payload and Content Negotiation
draft-ietf-httpbis-p3-payload-09 draft-ietf-httpbis-p3-payload-10
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 3 of the information initiative since 1990. This document is Part 3 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
HTTP message content, metadata, and content negotiation. HTTP message content, metadata, and content negotiation.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.10. The changes in this draft are summarized in Appendix E.11.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 14 skipping to change at page 3, line 4
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. ABNF Rules defined in other Parts of the 1.3.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 6 Specification . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 7
2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 8
2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9
2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10
2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11
2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 12
3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12
3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 14
4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15
4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20
5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. Message Header Registration . . . . . . . . . . . . . . . 26 6.1. Message Header Registration . . . . . . . . . . . . . . . 26
6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 6.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28
7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Differences Between HTTP Entities and RFC 2045 Appendix A. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 31 Entities . . . . . . . . . . . . . . . . . . . . . . 32
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33
A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 33
A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34
A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35
Appendix C. Compatibility with Previous Versions . . . . . . . . 35 Appendix C. Compatibility with Previous Versions . . . . . . . . 35
C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 35
C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 36
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 38 publication) . . . . . . . . . . . . . . . . . . . . 38
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 41
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41
E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41
E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 41 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document defines HTTP/1.1 message payloads (a.k.a., content), This document defines HTTP/1.1 message payloads (a.k.a., content),
the associated metadata header fields that define how the payload is the associated metadata header fields that define how the payload is
intended to be interpreted by a recipient, the request header fields intended to be interpreted by a recipient, the request header fields
that may influence content selection, and the various selection that may influence content selection, and the various selection
algorithms that are collectively referred to as HTTP content algorithms that are collectively referred to as HTTP content
negotiation. negotiation.
skipping to change at page 6, line 13 skipping to change at page 6, line 13
does not necessarily imply that the resource is subject to content does not necessarily imply that the resource is subject to content
negotiation. negotiation.
1.2. Requirements 1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the "MUST" or
REQUIRED level and all the SHOULD level requirements for its "REQUIRED" level and all the "SHOULD" level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the "MUST" level requirements but not all the "SHOULD"
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant".
1.3. Syntax Notation 1.3. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix D shows the collected ABNF, with the list rule rule). Appendix D shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
skipping to change at page 6, line 41 skipping to change at page 6, line 41
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), VCHAR (any visible USASCII character),
and WSP (whitespace). and WSP (whitespace).
1.3.1. Core Rules 1.3.1. Core Rules
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in Section 1.2.2 of [Part1]:
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
word = <word, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
1.3.2. ABNF Rules defined in other Parts of the Specification 1.3.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
Content-Length = <Content-Length, defined in [Part1], Section 9.2> Content-Length = <Content-Length, defined in [Part1], Section 9.2>
header-field = <header-field, defined in [Part1], Section 3.2> header-field = <header-field, defined in [Part1], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
skipping to change at page 9, line 30 skipping to change at page 9, line 30
content coding names. content coding names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer
codings (Section 6.2 of [Part1]), unless the encoding transformation
is identical (as it is the case for the compression codings defined
in Section 6.2.2 of [Part1]).
Values to be added to this name space require expert review and a Values to be added to this name space require expert review and a
specification (see "Expert Review" and "Specification Required" in specification (see "Expert Review" and "Specification Required" in
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
coding defined in this section. coding defined in this section.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
2.3. Media Types 2.3. Media Types
skipping to change at page 10, line 7 skipping to change at page 10, line 10
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value Parameters MAY follow the type/subtype in the form of attribute/value
pairs. pairs.
parameter = attribute "=" value parameter = attribute "=" value
attribute = token attribute = token
value = token / quoted-string value = word
The type, subtype, and parameter attribute names are case- The type, subtype, and parameter attribute names are case-
insensitive. Parameter values might or might not be case-sensitive, insensitive. Parameter values might or might not be case-sensitive,
depending on the semantics of the parameter name. The presence or depending on the semantics of the parameter name. The presence or
absence of a parameter might be significant to the processing of a absence of a parameter might be significant to the processing of a
media-type, depending on its definition within the media type media-type, depending on its definition within the media type
registry. registry.
A parameter value that matches the token production may be A parameter value that matches the token production may be
transmitted as either a token or within a quoted-string. The quoted transmitted as either a token or within a quoted-string. The quoted
skipping to change at page 13, line 32 skipping to change at page 13, line 48
When an entity-body is included with a message, the data type of that When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content- body is determined via the header fields Content-Type and Content-
Encoding. These define a two-layer, ordered encoding model: Encoding. These define a two-layer, ordered encoding model:
entity-body := Content-Encoding( Content-Type( data ) ) entity-body := Content-Encoding( Content-Type( data ) )
Content-Type specifies the media type of the underlying data. Any Content-Type specifies the media type of the underlying data. Any
HTTP/1.1 message containing an entity-body SHOULD include a Content- HTTP/1.1 message containing an entity-body SHOULD include a Content-
Type header field defining the media type of that body, unless that Type header field defining the media type of that body, unless that
information is unknown. If the Content-Type header field is not information is unknown.
present, it indicates that the sender does not know the media type of
the data; recipients MAY either assume that it is "application/ If the Content-Type header field is not present, it indicates that
octet-stream" ([RFC2046], Section 4.5.1) or examine the content to the sender does not know the media type of the data; recipients MAY
determine its type. either assume that it is "application/octet-stream" ([RFC2046],
Section 4.5.1) or examine the content to determine its type.
In practice, currently-deployed servers sometimes provide a Content-
Type header which does not correctly convey the intended
interpretation of the content sent, with the result that some clients
will examine the response body's content and override the specified
type.
Client that do so risk drawing incorrect conclusions, which may
expose additional security risks (e.g., "privilege escalation").
Implementers are encouraged to provide a means of disabling such
"content sniffing" when it is used.
Content-Encoding may be used to indicate any additional content Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is compression, that are a property of the requested resource. There is
no default encoding. no default encoding.
3.2.2. Entity Length 3.2.2. Entity Length
The entity-length of a message is the length of the message-body The entity-length of a message is the length of the message-body
before any transfer-codings have been applied. Section 3.4 of before any transfer-codings have been applied. Section 3.4 of
skipping to change at page 17, line 14 skipping to change at page 17, line 38
Accept = "Accept" ":" OWS Accept-v Accept = "Accept" ":" OWS Accept-v
Accept-v = #( media-range [ accept-params ] ) Accept-v = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) *( OWS ";" OWS parameter )
accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )
accept-ext = OWS ";" OWS token accept-ext = OWS ";" OWS token
[ "=" ( token / quoted-string ) ] [ "=" word ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params, Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user parameter(s) from the accept-params. Quality factors allow the user
skipping to change at page 22, line 32 skipping to change at page 23, line 10
the identity of its underlying media type. the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v
Content-Encoding-v = 1#content-coding Content-Encoding-v = 1#content-coding
Content codings are defined in Section 2.2. An example of its use is Content codings are defined in Section 2.2. An example of its use is
Content-Encoding: gzip Content-Encoding: gzip
The content-coding is a characteristic of the entity identified by The content-coding is a characteristic of the entity identified by
the request-target. Typically, the entity-body is stored with this the Effective Request URI (Section 4.3 of [Part1]). Typically, the
encoding and is only decoded before rendering or analogous usage. entity-body is stored with this encoding and is only decoded before
However, a non-transparent proxy MAY modify the content-coding if the rendering or analogous usage. However, a non-transparent proxy MAY
new coding is known to be acceptable to the recipient, unless the modify the content-coding if the new coding is known to be acceptable
"no-transform" cache-control directive is present in the message. to the recipient, unless the "no-transform" cache-control directive
is present in the message.
If the content-coding of an entity is not "identity", then the If the content-coding of an entity is not "identity", then the
response MUST include a Content-Encoding entity-header (Section 5.5) response MUST include a Content-Encoding entity-header (Section 5.5)
that lists the non-identity content-coding(s) used. that lists the non-identity content-coding(s) used.
If the content-coding of an entity in a request message is not If the content-coding of an entity in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to an entity, the content If multiple encodings have been applied to an entity, the content
skipping to change at page 24, line 14 skipping to change at page 24, line 40
resource has multiple entities associated with it, and those entities resource has multiple entities associated with it, and those entities
actually have separate locations by which they might be individually actually have separate locations by which they might be individually
accessed, the server SHOULD provide a Content-Location for the accessed, the server SHOULD provide a Content-Location for the
particular variant which is returned. particular variant which is returned.
Content-Location = "Content-Location" ":" OWS Content-Location = "Content-Location" ":" OWS
Content-Location-v Content-Location-v
Content-Location-v = Content-Location-v =
absolute-URI / partial-URI absolute-URI / partial-URI
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the Effective
requested URI; it is only a statement of the location of the resource Request URI (Section 4.3 of [Part1]); it is only a statement of the
corresponding to this particular entity at the time of the request. location of the resource corresponding to this particular entity at
Future requests MAY specify the Content-Location URI as the request- the time of the request. Future requests MAY may be addressed to the
target if the desire is to identify the source of that particular Content-Location URI if the desire is to identify the source of that
entity. particular entity.
Section 6.1 of [Part2] describes how clients may process the Content- Section 6.1 of [Part2] describes how clients may process the Content-
Location header field. Location header field.
A cache cannot assume that an entity with a Content-Location A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content- later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in Section retrieved from a single requested resource, as described in Section
2.6 of [Part6]. 2.7 of [Part6].
If the Content-Location is a relative URI, the relative URI is If the Content-Location is a relative URI, the relative URI is
interpreted relative to the request-target. interpreted relative to the Effective Request URI.
The meaning of the Content-Location header in requests is undefined; The meaning of the Content-Location header in requests is undefined;
servers are free to ignore it in those cases. servers are free to ignore it in those cases.
5.8. Content-MD5 5.8. Content-MD5
The "Content-MD5" entity-header field, as defined in [RFC1864], is an The "Content-MD5" entity-header field, as defined in [RFC1864], is an
MD5 digest of the entity-body that provides an end-to-end message MD5 digest of the entity-body that provides an end-to-end message
integrity check (MIC) of the entity-body. Note that a MIC is good integrity check (MIC) of the entity-body. Note that a MIC is good
for detecting accidental modification of the entity-body in transit, for detecting accidental modification of the entity-body in transit,
skipping to change at page 27, line 14 skipping to change at page 27, line 33
6.2. Content Coding Registry 6.2. Content Coding Registry
The registration procedure for HTTP Content Codings is now defined by The registration procedure for HTTP Content Codings is now defined by
Section 2.2.1 of this document. Section 2.2.1 of this document.
The HTTP Content Codings Registry located at The HTTP Content Codings Registry located at
<http://www.iana.org/assignments/http-parameters> should be updated <http://www.iana.org/assignments/http-parameters> should be updated
with the registration below: with the registration below:
+----------+-----------------------------------+--------------------+ +----------+-----------------------------------------+--------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+-----------------------------------+--------------------+ +----------+-----------------------------------------+--------------+
| compress | UNIX "compress" program method | Section 6.2.2.1 of | | compress | UNIX "compress" program method | Section |
| | | [Part1] | | | | 6.2.2.1 of |
| deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 of | | | | [Part1] |
| | "deflate" compression | [Part1] | | deflate | "deflate" compression mechanism | Section |
| gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 of | | | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of |
| | | [Part1] | | | format ([RFC1950]) | [Part1] |
| identity | No transformation | Section 2.2 | | gzip | Same as GNU zip [RFC1952] | Section |
+----------+-----------------------------------+--------------------+ | | | 6.2.2.3 of |
| | | [Part1] |
| identity | No transformation | Section 2.2 |
+----------+-----------------------------------------+--------------+
7. Security Considerations 7. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
7.1. Privacy Issues Connected to Accept Headers 7.1. Privacy Issues Connected to Accept Headers
skipping to change at page 28, line 36 skipping to change at page 29, line 11
standard, but since it is widely implemented, we are documenting its standard, but since it is widely implemented, we are documenting its
use and risks for implementors. See Section 5 of [RFC2183] for use and risks for implementors. See Section 5 of [RFC2183] for
details. details.
8. Acknowledgments 8. Acknowledgments
9. References 9. References
9.1. Normative References 9.1. Normative References
[ISO-8859-1] [ISO-8859-1] International Organization for Standardization,
International Organization for Standardization, "Information technology -- 8-bit single-byte coded
"Information technology -- 8-bit single-byte coded graphic graphic character sets -- Part 1: Latin alphabet No.
character sets -- Part 1: Latin alphabet No. 1", ISO/ 1", ISO/IEC 8859-1:1998, 1998.
IEC 8859-1:1998, 1998.
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
and Message Parsing", draft-ietf-httpbis-p1-messaging-09 Connections, and Message Parsing",
(work in progress), March 2010. draft-ietf-httpbis-p1-messaging-10 (work in progress),
July 2010.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-09 (work in Semantics", draft-ietf-httpbis-p2-semantics-10 (work in
progress), March 2010. progress), July 2010.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
Requests", draft-ietf-httpbis-p4-conditional-09 (work in Conditional Requests",
progress), March 2010. draft-ietf-httpbis-p4-conditional-10 (work in
progress), July 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
Partial Responses", draft-ietf-httpbis-p5-range-09 (work Requests and Partial Responses",
in progress), March 2010. draft-ietf-httpbis-p5-range-10 (work in progress),
July 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
6: Caching", draft-ietf-httpbis-p6-cache-09 (work in "HTTP/1.1, part 6: Caching",
progress), March 2010. draft-ietf-httpbis-p6-cache-10 (work in progress),
July 2010.
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995. RFC 1864, October 1995.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it may be less RFC 1950 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand,
downward reference was present since the publication of this downward reference was present since the
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to publication of RFC 2068 in 1997 ([RFC2068]), therefore
cause problems in practice. See also [BCP97]. it is unlikely to cause problems in practice. See also
[BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Randers-Pehrson, "GZIP file format specification version Specification version 1.3", RFC 1951, May 1996.
4.3", RFC 1952, May 1996.
RFC 1952 is an Informational RFC, thus it may be less RFC 1951 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand,
downward reference was present since the publication of this downward reference was present since the
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to publication of RFC 2068 in 1997 ([RFC2068]), therefore
cause problems in practice. See also [BCP97]. it is unlikely to cause problems in practice. See also
[BCP97].
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
Extensions (MIME) Part One: Format of Internet Message G. Randers-Pehrson, "GZIP file format specification
Bodies", RFC 2045, November 1996. version 4.3", RFC 1952, May 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail RFC 1952 is an Informational RFC, thus it may be less
Extensions (MIME) Part Two: Media Types", RFC 2046, stable than this specification. On the other hand,
November 1996. this downward reference was present since the
publication of RFC 2068 in 1997 ([RFC2068]), therefore
it is unlikely to cause problems in practice. See also
[BCP97].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Requirement Levels", BCP 14, RFC 2119, March 1997. Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Tags", BCP 47, RFC 4647, September 2006. Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Specifications: ABNF", STD 68, RFC 5234, January 2008. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of
Languages", BCP 47, RFC 5646, September 2009. Language Tags", BCP 47, RFC 4647, September 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646,
September 2009.
9.2. Informative References 9.2. Informative References
[BCP97] Klensin, J. and S. Hartman, "Handling Normative References [BCP97] Klensin, J. and S. Hartman, "Handling Normative
to Standards-Track Documents", BCP 97, RFC 4897, References to Standards-Track Documents", BCP 97,
June 2007. RFC 4897, June 2007.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Five: Conformance Criteria and Mail Extensions (MIME) Part Five: Conformance Criteria
Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", T. Berners-Lee, "Hypertext Transfer Protocol --
RFC 2068, January 1997. HTTP/1.1", RFC 2068, January 1997.
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997. February 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content
in HTTP", RFC 2295, March 1998. Negotiation in HTTP", RFC 2295, March 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as
(MHTML)", RFC 2557, March 1999. HTML (MHTML)", RFC 2557, March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003. 10646", RFC 3629, STD 63, November 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90,
September 2004. RFC 3864, September 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
Registration Procedures", BCP 13, RFC 4288, December 2005. and Registration Procedures", BCP 13, RFC 4288,
December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
Appendix A. Differences Between HTTP Entities and RFC 2045 Entities Appendix A. Differences Between HTTP Entities and RFC 2045 Entities
HTTP/1.1 uses many of the constructs defined for Internet Mail HTTP/1.1 uses many of the constructs defined for Internet Mail
([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
[RFC2045]) to allow entities to be transmitted in an open variety of [RFC2045]) to allow entities to be transmitted in an open variety of
representations and with extensible mechanisms. However, RFC 2045 representations and with extensible mechanisms. However, RFC 2045
discusses mail, and HTTP has a few features that are different from discusses mail, and HTTP has a few features that are different from
those described in RFC 2045. These differences were carefully chosen those described in RFC 2045. These differences were carefully chosen
to optimize performance over binary connections, to allow greater to optimize performance over binary connections, to allow greater
skipping to change at page 34, line 34 skipping to change at page 35, line 21
derived from the definition of Content-Disposition in [RFC2183]. derived from the definition of Content-Disposition in [RFC2183].
content-disposition = "Content-Disposition" ":" OWS content-disposition = "Content-Disposition" ":" OWS
content-disposition-v content-disposition-v
content-disposition-v = disposition-type content-disposition-v = disposition-type
*( OWS ";" OWS disposition-parm ) *( OWS ";" OWS disposition-parm )
disposition-type = "attachment" / disp-extension-token disposition-type = "attachment" / disp-extension-token
disposition-parm = filename-parm / disp-extension-parm disposition-parm = filename-parm / disp-extension-parm
filename-parm = "filename" "=" quoted-string filename-parm = "filename" "=" quoted-string
disp-extension-token = token disp-extension-token = token
disp-extension-parm = token "=" ( token / quoted-string ) disp-extension-parm = token "=" word
An example is An example is
Content-Disposition: attachment; filename="fname.ext" Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path The receiving user agent SHOULD NOT respect any directory path
information present in the filename-parm parameter, which is the only information present in the filename-parm parameter, which is the only
parameter believed to apply to HTTP implementations at this time. parameter believed to apply to HTTP implementations at this time.
The filename SHOULD be treated as a terminal component only. The filename SHOULD be treated as a terminal component only.
skipping to change at page 36, line 38 skipping to change at page 37, line 25
Expires = <Expires, defined in [Part6], Section 3.3> Expires = <Expires, defined in [Part6], Section 3.3>
Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
MIME-Version = "MIME-Version:" OWS MIME-Version-v MIME-Version = "MIME-Version:" OWS MIME-Version-v
MIME-Version-v = 1*DIGIT "." 1*DIGIT MIME-Version-v = 1*DIGIT "." 1*DIGIT
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" word ]
accept-params = OWS ";" OWS "q=" qvalue *accept-ext accept-params = OWS ";" OWS "q=" qvalue *accept-ext
attribute = token attribute = token
charset = token charset = token
codings = ( content-coding / "*" ) codings = ( content-coding / "*" )
content-coding = token content-coding = token
content-disposition = "Content-Disposition:" OWS content-disposition = "Content-Disposition:" OWS
content-disposition-v content-disposition-v
content-disposition-v = disposition-type *( OWS ";" OWS content-disposition-v = disposition-type *( OWS ";" OWS
disposition-parm ) disposition-parm )
disp-extension-parm = token "=" ( token / quoted-string ) disp-extension-parm = token "=" word
disp-extension-token = token disp-extension-token = token
disposition-parm = filename-parm / disp-extension-parm disposition-parm = filename-parm / disp-extension-parm
disposition-type = "attachment" / disp-extension-token disposition-type = "attachment" / disp-extension-token
entity-body = *OCTET entity-body = *OCTET
entity-header = Content-Encoding / Content-Language / Content-Length entity-header = Content-Encoding / Content-Language / Content-Length
/ Content-Location / Content-MD5 / Content-Range / Content-Type / / Content-Location / Content-MD5 / Content-Range / Content-Type /
Expires / Last-Modified / extension-header Expires / Last-Modified / extension-header
extension-header = header-field extension-header = header-field
skipping to change at page 37, line 35 skipping to change at page 38, line 22
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
qvalue = <qvalue, defined in [Part1], Section 6.4> qvalue = <qvalue, defined in [Part1], Section 6.4>
subtype = token subtype = token
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
type = token type = token
value = token / quoted-string value = word
word = <word, defined in [Part1], Section 1.2.2>
ABNF diagnostics: ABNF diagnostics:
; Accept defined but not used ; Accept defined but not used
; Accept-Charset defined but not used ; Accept-Charset defined but not used
; Accept-Encoding defined but not used ; Accept-Encoding defined but not used
; Accept-Language defined but not used ; Accept-Language defined but not used
; MIME-Version defined but not used ; MIME-Version defined but not used
; content-disposition defined but not used ; content-disposition defined but not used
; entity-body defined but not used ; entity-body defined but not used
skipping to change at page 41, line 47 skipping to change at page 42, line 25
E.10. Since draft-ietf-httpbis-p3-payload-08 E.10. Since draft-ietf-httpbis-p3-payload-08
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
Negotiation for media types" Negotiation for media types"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept- o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
Language: which RFC4647 filtering?" Language: which RFC4647 filtering?"
E.11. Since draft-ietf-httpbis-p3-payload-09
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
for content/transfer encodings"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
Sniffing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
"word" when talking about header structure"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI"
Index Index
A A
Accept header 16 Accept header 17
Accept-Charset header 19 Accept-Charset header 19
Accept-Encoding header 19 Accept-Encoding header 20
Accept-Language header 21 Accept-Language header 21
Alternates header 35 Alternates header 36
C C
Coding Format Coding Format
compress 8 compress 8
deflate 8 deflate 8
gzip 9 gzip 9
identity 9 identity 9
compress (Coding Format) 8 compress (Coding Format) 8
content negotiation 5 content negotiation 5
Content-Base header 35 Content-Base header 36
Content-Disposition header 34 Content-Disposition header 35
Content-Encoding header 22 Content-Encoding header 22
Content-Language header 23 Content-Language header 23
Content-Location header 23 Content-Location header 24
Content-MD5 header 24 Content-MD5 header 25
Content-Type header 26 Content-Type header 26
Content-Version header 35 Content-Version header 36
D D
deflate (Coding Format) 8 deflate (Coding Format) 8
Derived-From header 35 Derived-From header 36
E E
entity 5 entity 5
G G
Grammar Grammar
Accept 17 Accept 17
Accept-Charset 19 Accept-Charset 19
Accept-Charset-v 19 Accept-Charset-v 19
Accept-Encoding 19 Accept-Encoding 20
Accept-Encoding-v 19 Accept-Encoding-v 20
accept-ext 17 accept-ext 17
Accept-Language 21 Accept-Language 21
Accept-Language-v 21 Accept-Language-v 21
accept-params 17 accept-params 17
Accept-v 17 Accept-v 17
attribute 10 attribute 10
charset 7 charset 7
codings 19 codings 20
content-coding 8 content-coding 8
content-disposition 34 content-disposition 35
content-disposition-v 34 content-disposition-v 35
Content-Encoding 22 Content-Encoding 22
Content-Encoding-v 22 Content-Encoding-v 22
Content-Language 23 Content-Language 23
Content-Language-v 23 Content-Language-v 23
Content-Location 24 Content-Location 24
Content-Location-v 24 Content-Location-v 24
Content-MD5 24 Content-MD5 25
Content-MD5-v 24 Content-MD5-v 25
Content-Type 26 Content-Type 26
Content-Type-v 26 Content-Type-v 26
disp-extension-parm 34 disp-extension-parm 35
disp-extension-token 34 disp-extension-token 35
disposition-parm 34 disposition-parm 35
disposition-type 34 disposition-type 35
entity-body 13 entity-body 13
entity-header 12 entity-header 13
extension-header 12 extension-header 13
filename-parm 34 filename-parm 35
language-range 21 language-range 21
language-tag 12 language-tag 12
media-range 17 media-range 17
media-type 9 media-type 9
MIME-Version 32 MIME-Version 32
MIME-Version-v 32 MIME-Version-v 32
parameter 10 parameter 10
subtype 9 subtype 9
type 9 type 9
value 10 value 10
gzip (Coding Format) 9 gzip (Coding Format) 9
H H
Headers Headers
Accept 16 Accept 17
Accept-Charset 19 Accept-Charset 19
Accept-Encoding 19 Accept-Encoding 20
Accept-Language 21 Accept-Language 21
Alternate 35 Alternate 36
Content-Base 35 Content-Base 36
Content-Disposition 34 Content-Disposition 35
Content-Encoding 22 Content-Encoding 22
Content-Language 23 Content-Language 23
Content-Location 23 Content-Location 24
Content-MD5 24 Content-MD5 25
Content-Type 26 Content-Type 26
Content-Version 35 Content-Version 36
Derived-From 35 Derived-From 36
Link 35 Link 36
MIME-Version 32 MIME-Version 32
Public 35 Public 36
URI 35 URI 36
I I
identity (Coding Format) 9 identity (Coding Format) 9
L L
Link header 35 Link header 36
M M
MIME-Version header 32 MIME-Version header 32
P P
Public header 35 Public header 36
R R
representation 5 representation 5
U U
URI header 35 URI header 36
V V
variant 5 variant 5
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
Email: jg@laptop.org EMail: jg@freedesktop.org
URI: http://www.laptop.org/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems, Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
Email: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: paulle@microsoft.com EMail: paulle@microsoft.com
Tim Berners-Lee Tim Berners-Lee
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 110 change blocks. 
238 lines changed or deleted 295 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/