draft-ietf-httpbis-p3-payload-06.txt   draft-ietf-httpbis-p3-payload-07.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 One Laptop per Child
Expires: September 10, 2009 J. Mogul Expires: January 14, 2010 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 9, 2009 July 13, 2009
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-06 draft-ietf-httpbis-p3-payload-07
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 41
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/11> 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.7. The changes in this draft are summarized in Appendix E.8.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 6 Specification . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 37 skipping to change at page 3, line 37
4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15
4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . . . . . . 24
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
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 . . . . . . . . 27
7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 27 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Differences Between HTTP Entities and RFC 2045 Appendix A. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 31 Entities . . . . . . . . . . . . . . . . . . . . . . 31
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32
A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32
A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33
B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 34
Appendix C. Compatibility with Previous Versions . . . . . . . . 34 Appendix C. Compatibility with Previous Versions . . . . . . . . 34
C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34
C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 37 publication) . . . . . . . . . . . . . . . . . . . . 37
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 39
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 12, line 51 skipping to change at page 12, line 51
message. message.
3.2.1. Type 3.2.1. Type
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. Content-Type specifies the media type of the underlying data. Any
HTTP/1.1 message containing an entity-body SHOULD include a Content-
Type header field defining the media type of that body, unless that
information is unknown. If the Content-Type header field is not
present, it indicates that the sender does not know the media type of
the data; recipients MAY either assume that it is "application/
octet-stream" ([RFC2046], Section 4.5.1) or examine the content to
determine its type.
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.
Any HTTP/1.1 message containing an entity-body SHOULD include a Note that neither the interpretation of the data type of a message
Content-Type header field defining the media type of that body. If nor the behaviors caused by it are defined by HTTP; this potentially
and only if the media type is not given by a Content-Type field, the includes examination of the content to override any indicated type
recipient MAY attempt to guess the media type via inspection of its ("sniffing").
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
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 4.4 of before any transfer-codings have been applied. Section 4.4 of
[Part1] defines how the transfer-length of a message-body is [Part1] defines how the transfer-length of a message-body is
determined. determined.
4. Content Negotiation 4. Content Negotiation
skipping to change at page 24, line 33 skipping to change at page 24, line 42
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.6 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 request-target.
The meaning of the Content-Location header in PUT or POST requests is The meaning of the Content-Location header in requests is undefined;
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 entity-header field "Content-MD5", as defined in [RFC1864], is an The entity-header field "Content-MD5", as defined in [RFC1864], is an
MD5 digest of the entity-body for the purpose of providing an end-to- MD5 digest of the entity-body for the purpose of providing an end-to-
end message integrity check (MIC) of the entity-body. (Note: a MIC end message integrity check (MIC) of the entity-body. (Note: a MIC
is good for detecting accidental modification of the entity-body in is good for detecting accidental modification of the entity-body in
transit, but is not proof against malicious attacks.) transit, but is not proof against malicious attacks.)
Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
The Content-MD5 header field MAY be generated by an origin server or The Content-MD5 header field MAY be generated by an origin server or
client to function as an integrity check of the entity-body. Only client to function as an integrity check of the entity-body. Only
origin servers or clients MAY generate the Content-MD5 header field; origin servers or clients MAY generate the Content-MD5 header field;
proxies and gateways MUST NOT generate it, as this would defeat its proxies and gateways MUST NOT generate it, as this would defeat its
value as an end-to-end integrity check. Any recipient of the entity- value as an end-to-end integrity check. Any recipient of the entity-
body, including gateways and proxies, MAY check that the digest value body, including gateways and proxies, MAY check that the digest value
in this header field matches that of the entity-body as received. in this header field matches that of the entity-body as received.
skipping to change at page 28, line 23 skipping to change at page 28, line 29
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 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., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-06 and Message Parsing", draft-ietf-httpbis-p1-messaging-07
(work in progress), March 2009. (work in progress), July 2009.
[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., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-06 (work in Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
progress), March 2009. progress), July 2009.
[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., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-06 (work in Requests", draft-ietf-httpbis-p4-conditional-07 (work in
progress), March 2009. progress), July 2009.
[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., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-06 (work Partial Responses", draft-ietf-httpbis-p5-range-07 (work
in progress), March 2009. in progress), July 2009.
[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., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
draft-ietf-httpbis-p6-cache-06 (work in progress), 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
March 2009. progress), July 2009.
[RFC1766] Alvestrand, H., "Tags for the Identification of [RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995. Languages", RFC 1766, March 1995.
[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 Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
skipping to change at page 32, line 28 skipping to change at page 32, line 33
octets 13 and 10 to represent CR and LF, as is the case for some octets 13 and 10 to represent CR and LF, as is the case for some
multi-byte character sets. multi-byte character sets.
Implementors should note that conversion will break any cryptographic Implementors should note that conversion will break any cryptographic
checksums applied to the original content unless the original content checksums applied to the original content unless the original content
is already in canonical form. Therefore, the canonical form is is already in canonical form. Therefore, the canonical form is
recommended for any content that uses such checksums in HTTP. recommended for any content that uses such checksums in HTTP.
A.3. Conversion of Date Formats A.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 3.2.1 of HTTP/1.1 uses a restricted set of date formats (Section 3.2 of
[Part1]) to simplify the process of date comparison. Proxies and [Part1]) to simplify the process of date comparison. Proxies and
gateways from other protocols SHOULD ensure that any Date header gateways from other protocols SHOULD ensure that any Date header
field present in a message conforms to one of the HTTP/1.1 formats field present in a message conforms to one of the HTTP/1.1 formats
and rewrite the date if necessary. and rewrite the date if necessary.
A.4. Introduction of Content-Encoding A.4. Introduction of Content-Encoding
RFC 2045 does not include any concept equivalent to HTTP/1.1's RFC 2045 does not include any concept equivalent to HTTP/1.1's
Content-Encoding header field. Since this acts as a modifier on the Content-Encoding header field. Since this acts as a modifier on the
media type, proxies and gateways from HTTP to MIME-compliant media type, proxies and gateways from HTTP to MIME-compliant
skipping to change at page 40, line 5 skipping to change at page 40, line 13
Final work on ABNF conversion Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add appendix containing collected and expanded ABNF, reorganize o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction. ABNF introduction.
Other changes: Other changes:
o Move definition of quality values into Part 1. o Move definition of quality values into Part 1.
E.8. Since draft-ietf-httpbis-p3-payload-06
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
Location isn't special"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
Sniffing"
Index Index
A A
Accept header 16 Accept header 16
Accept-Charset header 18 Accept-Charset header 18
Accept-Encoding header 19 Accept-Encoding header 19
Accept-Language header 20 Accept-Language header 20
Alternates header 35 Alternates header 35
C C
compress 8 compress 8
Content Type Sniffing 13
Content-Base header 35 Content-Base header 35
Content-Disposition header 33 Content-Disposition header 34
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 24
Content-Type header 26 Content-Type header 26
Content-Version header 35 Content-Version header 35
D D
deflate 8 deflate 8
Derived-From header 35 Derived-From header 35
G G
Grammar Grammar
Accept 16 Accept 16
Accept-Charset 18 Accept-Charset 18
Accept-Charset-v 18 Accept-Charset-v 18
Accept-Encoding 19 Accept-Encoding 19
Accept-Encoding-v 19 Accept-Encoding-v 19
accept-ext 16 accept-ext 16
Accept-Language 20 Accept-Language 21
Accept-Language-v 20 Accept-Language-v 21
accept-params 16 accept-params 16
Accept-v 16 Accept-v 16
attribute 9 attribute 9
charset 7 charset 7
codings 19 codings 19
content-coding 8 content-coding 8
content-disposition 34 content-disposition 34
content-disposition-v 34 content-disposition-v 34
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 34
disp-extension-token 34 disp-extension-token 34
disposition-parm 34 disposition-parm 34
disposition-type 34 disposition-type 34
entity-body 12 entity-body 12
entity-header 12 entity-header 12
extension-header 12 extension-header 12
filename-parm 34 filename-parm 34
language-range 20 language-range 21
language-tag 11 language-tag 11
media-range 16 media-range 16
media-type 9 media-type 9
MIME-Version 31 MIME-Version 31
MIME-Version-v 31 MIME-Version-v 31
parameter 9 parameter 9
primary-tag 11 primary-tag 11
subtag 11 subtag 11
subtype 9 subtype 9
type 9 type 9
skipping to change at page 41, line 38 skipping to change at page 42, line 11
gzip 8 gzip 8
H H
Headers Headers
Accept 16 Accept 16
Accept-Charset 18 Accept-Charset 18
Accept-Encoding 19 Accept-Encoding 19
Accept-Language 20 Accept-Language 20
Alternate 35 Alternate 35
Content-Base 35 Content-Base 35
Content-Disposition 33 Content-Disposition 34
Content-Encoding 22 Content-Encoding 22
Content-Language 23 Content-Language 23
Content-Location 23 Content-Location 24
Content-MD5 24 Content-MD5 24
Content-Type 26 Content-Type 26
Content-Version 35 Content-Version 35
Derived-From 35 Derived-From 35
Link 35 Link 35
MIME-Version 31 MIME-Version 31
Public 35 Public 35
URI 35 URI 35
I I
 End of changes. 31 change blocks. 
43 lines changed or deleted 58 lines changed or added

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