draft-ietf-httpbis-p3-payload-00.txt   draft-ietf-httpbis-p3-payload-01.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2068, 2616 J. Gettys Obsoletes: 2616 (if approved) J. Gettys
(if approved) One Laptop per Child Intended status: Standards Track One Laptop per Child
Intended status: Standards Track J. Mogul Expires: July 15, 2008 J. Mogul
Expires: June 22, 2008 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
December 20, 2007 Y. Lafon, Ed.
W3C
J. Reschke, Ed.
greenbytes
January 12, 2008
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-00 draft-ietf-httpbis-p3-payload-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 49
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 June 22, 2008. This Internet-Draft will expire on July 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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)
This version of the HTTP specification contains only minimal
editorial changes from [RFC2616] (abstract, introductory paragraph,
and authors' addresses). All other changes are due to partitioning
the original into seven mostly independent parts. The intent is for
readers of future drafts to able to use draft 00 as the basis for
comparison when the WG makes later changes to the specification text.
This draft will shortly be followed by draft 01 (containing the first
round of changes that have already been agreed to on the mailing
list). There is no point in reviewing this draft other than to
verify that the partitioning has been done correctly. Roy T.
Fielding, Yves Lafon, and Julian Reschke will be the editors after
draft 00 is submitted.
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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://www.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://www3.tools.ietf.org/wg/httpbis/>. <http://www.tools.ietf.org/wg/httpbis/>.
This draft incorporates those issue resolutions that were either
collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5
2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6
2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 6 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 8 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9
2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 10 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 11
3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12
4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 12 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 12 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 13
4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14
4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 14 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15
5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15
5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 17 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 18
5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 19 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 20 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 21 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22
5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 22 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 23
5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 24 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 25
7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 25 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 26
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Differences Between HTTP Entities and RFC 2045 Appendix A. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 27 Entities . . . . . . . . . . . . . . . . . . . . . . 29
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 28 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 28 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30
A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 29 A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 30
A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 29 A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 30
A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 29 A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 31
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 29 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 31
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 30 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 31
B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 30 B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 31
Appendix C. Changes from RFC 2068 . . . . . . . . . . . . . . . . 31 Appendix C. Compatibility with Previous Versions . . . . . . . . 32
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 33
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 33
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 39
1. Introduction 1. Introduction
This document will define aspects of HTTP related to the payload of This document defines HTTP/1.1 message payloads (a.k.a., content),
messages (message content), including metadata and media types, along the associated metadata header fields that define how the payload is
with HTTP content negotiation. Right now it only includes the intended to be interpreted by a recipient, the request header fields
extracted relevant sections of RFC 2616 without edit. that may influence content selection, and the various selection
algorithms that are collectively referred to as HTTP content
negotiation.
This document is currently disorganized in order to minimize the
changes between drafts and enable reviewers to see the smaller errata
changes. The next draft will reorganize the sections to better
reflect the content. In particular, the sections on entities will be
renamed payload and moved to the first half of the document, while
the sections on content negotiation and associated request header
fields will be moved to the second half. The current mess reflects
how widely dispersed these topics and associated requirements had
become in [RFC2616].
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally
compliant."
2. Protocol Parameters 2. Protocol Parameters
2.1. Character Sets 2.1. Character Sets
HTTP uses the same definition of the term "character set" as that HTTP uses the same definition of the term "character set" as that
described for MIME: described for MIME:
The term "character set" is used in this document to refer to a The term "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of octets method used with one or more tables to convert a sequence of octets
skipping to change at page 5, line 40 skipping to change at page 6, line 20
to characters. In particular, use of external profiling information to characters. In particular, use of external profiling information
to determine the exact mapping is not permitted. to determine the exact mapping is not permitted.
Note: This use of the term "character set" is more commonly Note: This use of the term "character set" is more commonly
referred to as a "character encoding." However, since HTTP and referred to as a "character encoding." However, since HTTP and
MIME share the same registry, it is important that the terminology MIME share the same registry, it is important that the terminology
also be shared. also be shared.
HTTP character sets are identified by case-insensitive tokens. The HTTP character sets are identified by case-insensitive tokens. The
complete set of tokens is defined by the IANA Character Set registry complete set of tokens is defined by the IANA Character Set registry
[RFC1700]. (<http://www.iana.org/assignments/character-sets>).
charset = token charset = token
Although HTTP allows an arbitrary token to be used as a charset Although HTTP allows an arbitrary token to be used as a charset
value, any token that has a predefined value within the IANA value, any token that has a predefined value within the IANA
Character Set registry [RFC1700] MUST represent the character set Character Set registry MUST represent the character set defined by
defined by that registry. Applications SHOULD limit their use of that registry. Applications SHOULD limit their use of character sets
character sets to those defined by the IANA registry. to those defined by the IANA registry.
HTTP uses charset in two contexts: within an Accept-Charset request
header (in which the charset value is an unquoted token) and as the
value of a parameter in a Content-Type header (within a request or
response), in which case the parameter value of the charset parameter
may be quoted.
Implementors should be aware of IETF character set requirements Implementors should be aware of IETF character set requirements
[RFC2279] [RFC2277]. [RFC3629] [RFC2277].
2.1.1. Missing Charset 2.1.1. Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess." charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and
it is known that it will not confuse the recipient. SHOULD do so when it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See recipient's preference, when initially displaying a document. See
Section 2.3.1. Section 2.3.1.
2.2. Content Codings 2.2. Content Codings
skipping to change at page 6, line 46 skipping to change at page 7, line 31
indicates what decoding mechanism will be required to remove the indicates what decoding mechanism will be required to remove the
encoding. encoding.
The Internet Assigned Numbers Authority (IANA) acts as a registry for The Internet Assigned Numbers Authority (IANA) acts as a registry for
content-coding value tokens. Initially, the registry contains the content-coding value tokens. Initially, the registry contains the
following tokens: following tokens:
gzip gzip
An encoding format produced by the file compression program "gzip" An encoding format produced by the file compression program "gzip"
(GNU zip) as described in RFC 1952 [RFC1952]. This format is a (GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv
Lempel-Ziv coding (LZ77) with a 32 bit CRC. coding (LZ77) with a 32 bit CRC.
compress compress
The encoding format produced by the common UNIX file compression The encoding format produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW). coding (LZW).
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. Their use not desirable and is discouraged for future encodings. Their use
here is representative of historical practice, not good design. here is representative of historical practice, not good design.
For compatibility with previous implementations of HTTP, For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be applications SHOULD consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively. equivalent to "gzip" and "compress" respectively.
deflate deflate
The "zlib" format defined in RFC 1950 [RFC1950] in combination The "zlib" format defined in [RFC1950] in combination with the
with the "deflate" compression mechanism described in RFC 1951 "deflate" compression mechanism described in [RFC1951].
[RFC1951].
identity identity
The default (identity) encoding; the use of no transformation The default (identity) encoding; the use of no transformation
whatsoever. This content-coding is used only in the Accept- whatsoever. This content-coding is used only in the Accept-
Encoding header, and SHOULD NOT be used in the Content-Encoding Encoding header, and SHOULD NOT be used in the Content-Encoding
header. header.
New content-coding value tokens SHOULD be registered; to allow New content-coding value tokens SHOULD be registered; to allow
interoperability between clients and servers, specifications of the interoperability between clients and servers, specifications of the
content coding algorithms needed to implement a new value SHOULD be content coding algorithms needed to implement a new value SHOULD be
publicly available and adequate for independent implementation, and publicly available and adequate for independent implementation, and
conform to the purpose of content coding defined in this section. conform to the purpose of content coding defined in this section.
2.3. Media Types 2.3. Media Types
HTTP uses Internet Media Types [RFC1590] in the Content-Type HTTP uses Internet Media Types [RFC2046] in the Content-Type
(Section 5.9) and Accept (Section 5.1) header fields in order to (Section 5.9) and Accept (Section 5.1) header fields in order to
provide open and extensible data typing and type negotiation. provide open and extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter ) media-type = type "/" subtype *( ";" 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.
skipping to change at page 8, line 15 skipping to change at page 8, line 49
attribute and its value. The presence or absence of a parameter attribute and its value. The presence or absence of a parameter
might be significant to the processing of a media-type, depending on might be significant to the processing of a media-type, depending on
its definition within the media type registry. its definition within the media type registry.
Note that some older HTTP applications do not recognize media type Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications, parameters. When sending data to older HTTP applications,
implementations SHOULD only use media type parameters when they are implementations SHOULD only use media type parameters when they are
required by that type/subtype definition. required by that type/subtype definition.
Media-type values are registered with the Internet Assigned Number Media-type values are registered with the Internet Assigned Number
Authority (IANA [RFC1700]). The media type registration process is Authority (IANA). The media type registration process is outlined in
outlined in RFC 1590 [RFC1590]. Use of non-registered media types is [RFC4288]. Use of non-registered media types is discouraged.
discouraged.
2.3.1. Canonicalization and Text Defaults 2.3.1. Canonicalization and Text Defaults
Internet media types are registered with a canonical form. An Internet media types are registered with a canonical form. An
entity-body transferred via HTTP messages MUST be represented in the entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission except for appropriate canonical form prior to its transmission except for
"text" types, as defined in the next paragraph. "text" types, as defined in the next paragraph.
When in canonical form, media subtypes of the "text" type use CRLF as When in canonical form, media subtypes of the "text" type use CRLF as
the text line break. HTTP relaxes this requirement and allows the the text line break. HTTP relaxes this requirement and allows the
skipping to change at page 9, line 9 skipping to change at page 9, line 42
parameter is provided by the sender, media subtypes of the "text" parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value. See its subsets MUST be labeled with an appropriate charset value. See
Section 2.1.1 for compatibility problems. Section 2.1.1 for compatibility problems.
2.3.2. Multipart Types 2.3.2. Multipart Types
MIME provides for a number of "multipart" types -- encapsulations of MIME provides for a number of "multipart" types -- encapsulations of
one or more entities within a single message-body. All multipart one or more entities within a single message-body. All multipart
types share a common syntax, as defined in section 5.1.1 of RFC 2046 types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and MUST include a boundary parameter as part of the media [RFC2046], and MUST include a boundary parameter as part of the media
type value. The message body is itself a protocol element and MUST type value. The message body is itself a protocol element and MUST
therefore use only CRLF to represent line breaks between body-parts. therefore use only CRLF to represent line breaks between body-parts.
Unlike in RFC 2046, the epilogue of any multipart message MUST be Unlike in RFC 2046, the epilogue of any multipart message MUST be
empty; HTTP applications MUST NOT transmit the epilogue (even if the empty; HTTP applications MUST NOT transmit the epilogue (even if the
original multipart contains an epilogue). These restrictions exist original multipart contains an epilogue). These restrictions exist
in order to preserve the self-delimiting nature of a multipart in order to preserve the self-delimiting nature of a multipart
message-body, wherein the "end" of the message-body is indicated by message-body, wherein the "end" of the message-body is indicated by
the ending multipart boundary. the ending multipart boundary.
skipping to change at page 9, line 36 skipping to change at page 10, line 21
within each body-part of a multipart message-body do not have any within each body-part of a multipart message-body do not have any
significance to HTTP beyond that defined by their MIME semantics. significance to HTTP beyond that defined by their MIME semantics.
In general, an HTTP user agent SHOULD follow the same or similar In general, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type. behavior as a MIME user agent would upon receipt of a multipart type.
If an application receives an unrecognized multipart subtype, the If an application receives an unrecognized multipart subtype, the
application MUST treat it as being equivalent to "multipart/mixed". application MUST treat it as being equivalent to "multipart/mixed".
Note: The "multipart/form-data" type has been specifically defined Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST for carrying form data suitable for processing via the POST
request method, as described in RFC 1867 [RFC1867]. request method, as described in [RFC2388].
2.4. Quality Values 2.4. Quality Values
HTTP content negotiation (Section 4) uses short "floating point" HTTP content negotiation (Section 4) uses short "floating point"
numbers to indicate the relative importance ("weight") of various numbers to indicate the relative importance ("weight") of various
negotiable parameters. A weight is normalized to a real number in negotiable parameters. A weight is normalized to a real number in
the range 0 through 1, where 0 is the minimum and 1 the maximum the range 0 through 1, where 0 is the minimum and 1 the maximum
value. If a parameter has a quality value of 0, then content with value. If a parameter has a quality value of 0, then content with
this parameter is `not acceptable' for the client. HTTP/1.1 this parameter is `not acceptable' for the client. HTTP/1.1
applications MUST NOT generate more than three digits after the applications MUST NOT generate more than three digits after the
skipping to change at page 10, line 16 skipping to change at page 10, line 50
2.5. Language Tags 2.5. Language Tags
A language tag identifies a natural language spoken, written, or A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded. to other human beings. Computer languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
Language fields. Language fields.
The syntax and registry of HTTP language tags is the same as that The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [RFC1766]. In summary, a language tag is defined by [RFC1766]. In summary, a language tag is composed of 1 or
composed of 1 or more parts: A primary language tag and a possibly more parts: A primary language tag and a possibly empty series of
empty series of subtags: subtags:
language-tag = primary-tag *( "-" subtag ) language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA primary-tag = 1*8ALPHA
subtag = 1*8ALPHA subtag = 1*8ALPHA
White space is not allowed within the tag and all tags are case- White space is not allowed within the tag and all tags are case-
insensitive. The name space of language tags is administered by the insensitive. The name space of language tags is administered by the
IANA. Example tags include: IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin en, en-US, en-cockney, i-cherokee, x-pig-latin
skipping to change at page 10, line 49 skipping to change at page 11, line 34
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity. or the server, depending on who sends and who receives the entity.
3.1. Entity Header Fields 3.1. Entity Header Fields
Entity-header fields define metainformation about the entity-body or, Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request. if no body is present, about the resource identified by the request.
Some of this metainformation is OPTIONAL; some might be REQUIRED by
portions of this specification.
entity-header = Allow ; [Part2], Section 10.1 entity-header = Allow ; [Part2], Section 10.1
| Content-Encoding ; Section 5.5 | Content-Encoding ; Section 5.5
| Content-Language ; Section 5.6 | Content-Language ; Section 5.6
| Content-Length ; [Part1], Section 8.2 | Content-Length ; [Part1], Section 8.2
| Content-Location ; Section 5.7 | Content-Location ; Section 5.7
| Content-MD5 ; Section 5.8 | Content-MD5 ; Section 5.8
| Content-Range ; [Part5], Section 5.2 | Content-Range ; [Part5], Section 5.2
| Content-Type ; Section 5.9 | Content-Type ; Section 5.9
| Expires ; [Part6], Section 3.3 | Expires ; [Part6], Section 15.3
| Last-Modified ; [Part4], Section 6.6 | Last-Modified ; [Part4], Section 6.6
| extension-header | extension-header
extension-header = message-header extension-header = message-header
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies. transparent proxies.
skipping to change at page 13, line 48 skipping to change at page 14, line 34
HTTP/1.1 includes the following request-header fields for enabling HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation through description of user agent server-driven negotiation through description of user agent
capabilities and user preferences: Accept (Section 5.1), Accept- capabilities and user preferences: Accept (Section 5.1), Accept-
Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
(Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an (Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an
origin server is not limited to these dimensions and MAY vary the origin server is not limited to these dimensions and MAY vary the
response based on any aspect of the request, including information response based on any aspect of the request, including information
outside the request-header fields or within extension header fields outside the request-header fields or within extension header fields
not defined by this specification. not defined by this specification.
The Vary header field [Part6] can be used to express the parameters The Vary header field (Section 15.5 of [Part6]) can be used to
the server uses to select a representation that is subject to server- express the parameters the server uses to select a representation
driven negotiation. that is subject to server-driven negotiation.
4.2. Agent-driven Negotiation 4.2. Agent-driven Negotiation
With agent-driven negotiation, selection of the best representation With agent-driven negotiation, selection of the best representation
for a response is performed by the user agent after receiving an for a response is performed by the user agent after receiving an
initial response from the origin server. Selection is based on a initial response from the origin server. Selection is based on a
list of the available representations of the response included within list of the available representations of the response included within
the header fields or entity-body of the initial response, with each the header fields or entity-body of the initial response, with each
representation identified by its own URI. Selection from among the representation identified by its own URI. Selection from among the
representations may be performed automatically (if the user agent is representations may be performed automatically (if the user agent is
skipping to change at page 15, line 9 skipping to change at page 15, line 42
server and also removing the second request delay of agent-driven server and also removing the second request delay of agent-driven
negotiation when the cache is able to correctly guess the right negotiation when the cache is able to correctly guess the right
response. response.
This specification does not define any mechanism for transparent This specification does not define any mechanism for transparent
negotiation, though it also does not prevent any such mechanism from negotiation, though it also does not prevent any such mechanism from
being developed as an extension that could be used within HTTP/1.1. being developed as an extension that could be used within HTTP/1.1.
5. Header Field Definitions 5. Header Field Definitions
This section defines the syntax and semantics of all standard This section defines the syntax and semantics of HTTP/1.1 header
HTTP/1.1 header fields. For entity-header fields, both sender and fields related to the payload of messages.
recipient refer to either the client or the server, depending on who
sends and who receives the entity. For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the
entity.
5.1. Accept 5.1. Accept
The Accept request-header field can be used to specify certain media The Accept request-header field can be used to specify certain media
types which are acceptable for the response. Accept headers can be types which are acceptable for the response. Accept headers can be
used to indicate that the request is specifically limited to a small used to indicate that the request is specifically limited to a small
set of desired types, as in the case of a request for an in-line set of desired types, as in the case of a request for an in-line
image. image.
Accept = "Accept" ":" Accept = "Accept" ":"
skipping to change at page 16, line 18 skipping to change at page 17, line 7
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality." type if it is the best available after an 80% mark-down in quality."
If no Accept header field is present, then it is assumed that the If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is client accepts all media types. If an Accept header field is
present, and if the server cannot send a response which is acceptable present, and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response. send a 406 (Not Acceptable) response.
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the preferred media types, but if they do not exist, then send the the preferred media types, but if they do not exist, then send the
text/x-dvi entity, and if that does not exist, send the text/plain text/x-dvi entity, and if that does not exist, send the text/plain
entity." entity."
skipping to change at page 17, line 46 skipping to change at page 18, line 34
matches every character set (including ISO-8859-1) which is not matches every character set (including ISO-8859-1) which is not
mentioned elsewhere in the Accept-Charset field. If no "*" is mentioned elsewhere in the Accept-Charset field. If no "*" is
present in an Accept-Charset field, then all character sets not present in an Accept-Charset field, then all character sets not
explicitly mentioned get a quality value of 0, except for ISO-8859-1, explicitly mentioned get a quality value of 0, except for ISO-8859-1,
which gets a quality value of 1 if not explicitly mentioned. which gets a quality value of 1 if not explicitly mentioned.
If no Accept-Charset header is present, the default is that any If no Accept-Charset header is present, the default is that any
character set is acceptable. If an Accept-Charset header is present, character set is acceptable. If an Accept-Charset header is present,
and if the server cannot send a response which is acceptable and if the server cannot send a response which is acceptable
according to the Accept-Charset header, then the server SHOULD send according to the Accept-Charset header, then the server SHOULD send
an error response with the 406 (not acceptable) status code, though an error response with the 406 (Not Acceptable) status code, though
the sending of an unacceptable response is also allowed. the sending of an unacceptable response is also allowed.
5.3. Accept-Encoding 5.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (Section 2.2) that are acceptable in restricts the content-codings (Section 2.2) that are acceptable in
the response. the response.
Accept-Encoding = "Accept-Encoding" ":" Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] ) #( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" ) codings = ( content-coding | "*" )
Examples of its use are: Examples of its use are:
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
skipping to change at page 22, line 37 skipping to change at page 23, line 24
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request. corresponding to this particular entity at the time of the request.
Future requests MAY specify the Content-Location URI as the request- Future requests MAY specify the Content-Location URI as the request-
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
entity. entity.
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 [Part6]. retrieved from a single requested resource, as described in Section 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-URI. interpreted relative to the Request-URI.
The meaning of the Content-Location header in PUT or POST requests is The meaning of the Content-Location header in PUT or POST requests is
undefined; servers are free to ignore it in those cases. undefined; 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 RFC 1864 The Content-MD5 entity-header field, as defined in [RFC1864], is an
[RFC1864], is an MD5 digest of the entity-body for the purpose of MD5 digest of the entity-body for the purpose of providing an end-to-
providing an end-to-end message integrity check (MIC) of the entity- end message integrity check (MIC) of the entity-body. (Note: a MIC
body. (Note: a MIC is good for detecting accidental modification of is good for detecting accidental modification of the entity-body in
the entity-body in transit, but is not proof against malicious transit, but is not proof against malicious attacks.)
attacks.)
Content-MD5 = "Content-MD5" ":" md5-digest Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> md5-digest = <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.
The MD5 digest is computed based on the content of the entity-body, The MD5 digest is computed based on the content of the entity-body,
skipping to change at page 25, line 27 skipping to change at page 26, line 16
identifier. In environments where proxies are used to enhance identifier. In environments where proxies are used to enhance
privacy, user agents ought to be conservative in offering accept privacy, user agents ought to be conservative in offering accept
header configuration options to end users. As an extreme privacy header configuration options to end users. As an extreme privacy
measure, proxies could filter the accept headers in relayed requests. measure, proxies could filter the accept headers in relayed requests.
General purpose user agents which provide a high degree of header General purpose user agents which provide a high degree of header
configurability SHOULD warn users about the loss of privacy which can configurability SHOULD warn users about the loss of privacy which can
be involved. be involved.
7.2. Content-Disposition Issues 7.2. Content-Disposition Issues
RFC 1806 [RFC1806], from which the often implemented Content- [RFC1806], from which the often implemented Content-Disposition (see
Disposition (see Appendix B.1) header in HTTP is derived, has a Appendix B.1) header in HTTP is derived, has a number of very serious
number of very serious security considerations. Content-Disposition security considerations. Content-Disposition is not part of the HTTP
is not part of the HTTP standard, but since it is widely implemented, standard, but since it is widely implemented, we are documenting its
we are documenting its use and risks for implementors. See RFC 2183 use and risks for implementors. See [RFC2183] (which updates
[RFC2183] (which updates RFC 1806) for details. [RFC1806]) for details.
8. Acknowledgments 8. Acknowledgments
Based on an XML translation of RFC 2616 by Julian Reschke.
9. References 9. References
9.1. Normative References
[ISO-8859-1]
International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/
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., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 1: URIs, Connections, and Message Parsing", and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
draft-ietf-httpbis-p1-messaging-00 (work in progress), and Message Parsing", draft-ietf-httpbis-p1-messaging-01
December 2007. (work in progress), January 2008.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 2: Message Semantics", and J. Reschke, Ed., "HTTP/1.1, part 2: Message
draft-ietf-httpbis-p2-semantics-00 (work in progress), Semantics", draft-ietf-httpbis-p2-semantics-01 (work in
December 2007. progress), January 2008.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 4: Conditional Requests", and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
draft-ietf-httpbis-p4-conditional-00 (work in progress), Requests", draft-ietf-httpbis-p4-conditional-01 (work in
December 2007. progress), January 2008.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 5: Range Requests and Partial Responses", and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
draft-ietf-httpbis-p5-range-00 (work in progress), Partial Responses", draft-ietf-httpbis-p5-range-01 (work
December 2007. in progress), January 2008.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
progress), December 2007. draft-ietf-httpbis-p6-cache-01 (work in progress),
January 2008.
[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590,
November 1996.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[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.
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 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.
[RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in
HTML", RFC 1867, November 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.
RFC1950 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this
downward reference was present since [RFC2068] (published
in 1997), therefore it is unlikely to cause problems in
practice.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
RFC1951 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this
downward reference was present since [RFC2068] (published
in 1997), therefore it is unlikely to cause problems in
practice.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996. 4.3", RFC 1952, May 1996.
RFC1952 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this
downward reference was present since [RFC2068] (published
in 1997), therefore it is unlikely to cause problems in
practice.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
9.2. Informative References
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "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 Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996. 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 T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. 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.
[RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2110,
March 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.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
10646", RFC 2279, January 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as 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.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
text messages", STD 11, RFC 822, August 1982. April 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
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 (RFC HTTP/1.1 uses many of the constructs defined for Internet Mail
822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME ([RFC2822]) 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
freedom in the use of new media types, to make date comparisons freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers easier, and to acknowledge the practice of some early HTTP servers
and clients. and clients.
This appendix describes specific areas where HTTP differs from RFC This appendix describes specific areas where HTTP differs from RFC
skipping to change at page 28, line 23 skipping to change at page 29, line 41
where necessary. Proxies and gateways from MIME environments to HTTP where necessary. Proxies and gateways from MIME environments to HTTP
also need to be aware of the differences because some conversions also need to be aware of the differences because some conversions
might be required. might be required.
A.1. MIME-Version A.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
MAY include a single MIME-Version general-header field to indicate MAY include a single MIME-Version general-header field to indicate
what version of the MIME protocol was used to construct the message. what version of the MIME protocol was used to construct the message.
Use of the MIME-Version header field indicates that the message is in Use of the MIME-Version header field indicates that the message is in
full compliance with the MIME protocol (as defined in RFC full compliance with the MIME protocol (as defined in [RFC2045]).
2045[RFC2045]). Proxies/gateways are responsible for ensuring full Proxies/gateways are responsible for ensuring full compliance (where
compliance (where possible) when exporting HTTP messages to strict possible) when exporting HTTP messages to strict MIME environments.
MIME environments.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME version "1.0" is the default for use in HTTP/1.1. However, MIME version "1.0" is the default for use in HTTP/1.1. However,
HTTP/1.1 message parsing and semantics are defined by this document HTTP/1.1 message parsing and semantics are defined by this document
and not the MIME specification. and not the MIME specification.
A.2. Conversion to Canonical Form A.2. Conversion to Canonical Form
RFC 2045 [RFC2045] requires that an Internet mail entity be converted [RFC2045] requires that an Internet mail entity be converted to
to canonical form prior to being transferred, as described in section canonical form prior to being transferred, as described in Section 4
4 of RFC 2049 [RFC2049]. Section 2.3.1 of this document describes of [RFC2049]. Section 2.3.1 of this document describes the forms
the forms allowed for subtypes of the "text" media type when allowed for subtypes of the "text" media type when transmitted over
transmitted over HTTP. RFC 2046 requires that content with a type of HTTP. [RFC2046] requires that content with a type of "text"
"text" represent line breaks as CRLF and forbids the use of CR or LF represent line breaks as CRLF and forbids the use of CR or LF outside
outside of line break sequences. HTTP allows CRLF, bare CR, and bare of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
LF to indicate a line break within text content when a message is indicate a line break within text content when a message is
transmitted over HTTP. transmitted over HTTP.
Where it is possible, a proxy or gateway from HTTP to a strict MIME Where it is possible, a proxy or gateway from HTTP to a strict MIME
environment SHOULD translate all line breaks within the text media environment SHOULD translate all line breaks within the text media
types described in Section 2.3.1 of this document to the RFC 2049 types described in Section 2.3.1 of this document to the RFC 2049
canonical form of CRLF. Note, however, that this might be canonical form of CRLF. Note, however, that this might be
complicated by the presence of a Content-Encoding and by the fact complicated by the presence of a Content-Encoding and by the fact
that HTTP allows the use of some character sets which do not use that HTTP allows the use of some character sets which do not use
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.
skipping to change at page 29, line 26 skipping to change at page 30, line 45
media type, proxies and gateways from HTTP to MIME-compliant media type, proxies and gateways from HTTP to MIME-compliant
protocols MUST either change the value of the Content-Type header protocols MUST either change the value of the Content-Type header
field or decode the entity-body before forwarding the message. (Some field or decode the entity-body before forwarding the message. (Some
experimental applications of Content-Type for Internet mail have used experimental applications of Content-Type for Internet mail have used
a media-type parameter of ";conversions=<content-coding>" to perform a media-type parameter of ";conversions=<content-coding>" to perform
a function equivalent to Content-Encoding. However, this parameter a function equivalent to Content-Encoding. However, this parameter
is not part of RFC 2045). is not part of RFC 2045).
A.4. No Content-Transfer-Encoding A.4. No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
2045. Proxies and gateways from MIME-compliant protocols to HTTP Proxies and gateways from MIME-compliant protocols to HTTP MUST
MUST remove any non-identity CTE ("quoted-printable" or "base64") remove any Content-Transfer-Encoding prior to delivering the response
encoding prior to delivering the response message to an HTTP client. message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used. transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway SHOULD label the data with an appropriate Such a proxy or gateway SHOULD label the data with an appropriate
Content-Transfer-Encoding if doing so will improve the likelihood of Content-Transfer-Encoding if doing so will improve the likelihood of
safe transport over the destination protocol. safe transport over the destination protocol.
A.5. Introduction of Transfer-Encoding A.5. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7
of [Part1]). Proxies/gateways MUST remove any transfer-coding prior of [Part1]). Proxies/gateways MUST remove any transfer-coding prior
to forwarding a message via a MIME-compliant protocol. to forwarding a message via a MIME-compliant protocol.
A.6. MHTML and Line Length Limitations A.6. MHTML and Line Length Limitations
HTTP implementations which share code with MHTML [RFC2110] HTTP implementations which share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transports all message-bodies as canonicalization, etc., since HTTP transports all message-bodies as
payload (see Section 2.3.2) and does not interpret the content or any payload (see Section 2.3.2) and does not interpret the content or any
MIME header lines that might be contained therein. MIME header lines that might be contained therein.
Appendix B. Additional Features Appendix B. Additional Features
RFC 1945 and RFC 2068 document protocol elements used by some [RFC1945] and [RFC2068] document protocol elements used by some
existing HTTP implementations, but not consistently and correctly existing HTTP implementations, but not consistently and correctly
across most HTTP/1.1 applications. Implementors are advised to be across most HTTP/1.1 applications. Implementors are advised to be
aware of these features, but cannot rely upon their presence in, or aware of these features, but cannot rely upon their presence in, or
interoperability with, other HTTP/1.1 applications. Some of these interoperability with, other HTTP/1.1 applications. Some of these
describe proposed experimental features, and some describe features describe proposed experimental features, and some describe features
that experimental deployment found lacking that are now addressed in that experimental deployment found lacking that are now addressed in
the base HTTP/1.1 specification. the base HTTP/1.1 specification.
A number of other headers, such as Content-Disposition and Title, A number of other headers, such as Content-Disposition and Title,
from SMTP and MIME are also often implemented (see RFC 2076 from SMTP and MIME are also often implemented (see [RFC2076]).
[RFC2076]).
B.1. Content-Disposition B.1. Content-Disposition
The Content-Disposition response-header field has been proposed as a The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user means for the origin server to suggest a default filename if the user
requests that the content is saved to a file. This usage is derived requests that the content is saved to a file. This usage is derived
from the definition of Content-Disposition in RFC 1806 [RFC1806]. from the definition of Content-Disposition in [RFC1806].
content-disposition = "Content-Disposition" ":" content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm ) disposition-type *( ";" 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 "=" ( token | quoted-string )
An example is An example is
skipping to change at page 31, line 7 skipping to change at page 32, line 29
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.
If this header is used in a response with the application/ If this header is used in a response with the application/
octet-stream content-type, the implied suggestion is that the user octet-stream content-type, the implied suggestion is that the user
agent should not display the response, but directly enter a `save agent should not display the response, but directly enter a `save
response as...' dialog. response as...' dialog.
See Section 7.2 for Content-Disposition security issues. See Section 7.2 for Content-Disposition security issues.
Appendix C. Changes from RFC 2068 Appendix C. Compatibility with Previous Versions
C.1. Changes from RFC 2068
Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed.
(Section 3.2.2, see also [Part1], [Part5] and [Part6]).
Charset wildcarding is introduced to avoid explosion of character set Charset wildcarding is introduced to avoid explosion of character set
names in accept headers. (Section 5.2) names in accept headers. (Section 5.2)
Content-Base was deleted from the specification: it was not Content-Base was deleted from the specification: it was not
implemented widely, and there is no simple, safe way to introduce it implemented widely, and there is no simple, safe way to introduce it
without a robust extension mechanism. In addition, it is used in a without a robust extension mechanism. In addition, it is used in a
similar, but not identical fashion in MHTML [RFC2110]. similar, but not identical fashion in MHTML [RFC2557].
A content-coding of "identity" was introduced, to solve problems A content-coding of "identity" was introduced, to solve problems
discovered in caching. (Section 2.2) discovered in caching. (Section 2.2)
Quality Values of zero should indicate that "I don't want something" Quality Values of zero should indicate that "I don't want something"
to allow clients to refuse a representation. (Section 2.4) to allow clients to refuse a representation. (Section 2.4)
The Alternates, Content-Version, Derived-From, Link, URI, Public and The Alternates, Content-Version, Derived-From, Link, URI, Public and
Content-Base header fields were defined in previous versions of this Content-Base header fields were defined in previous versions of this
specification, but not commonly implemented. See RFC 2068 [RFC2068]. specification, but not commonly implemented. See [RFC2068].
C.2. Changes from RFC 2616
Clarify contexts that charset is used in. (Section 2.1)
Remove reference to non-existant identity transfer-coding value
tokens. (Appendix A.4)
Appendix D. Change Log (to be removed by RFC Editor before publication)
D.1. Since RFC2616
Extracted relevant partitions from [RFC2616].
D.2. Since draft-ietf-httpbis-p3-payload-00
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
Registrations" (<http://purl.org/NET/http-errata#media-reg>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/14>:
"Clarification regarding quoting of charset values"
(<http://purl.org/NET/http-errata#charactersets>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
'identity' token references"
(<http://purl.org/NET/http-errata#identity>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
Encoding BNF"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
and Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
"Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:
"ISO-8859-1 Reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
References Normative"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
up-to-date references"
Index Index
A A
Accept header 15 Accept header 16
Accept-Charset header 17 Accept-Charset header 18
Accept-Encoding header 17 Accept-Encoding header 18
Accept-Language header 19 Accept-Language header 20
Alternates header 31 Alternates header 33
C C
compress 6 compress 7
Content-Base header 31 Content-Base header 33
Content-Disposition header 30 Content-Disposition header 31
Content-Encoding header 20 Content-Encoding header 21
Content-Language header 21 Content-Language header 22
Content-Location header 22 Content-Location header 22
Content-MD5 header 22 Content-MD5 header 23
Content-Type header 24 Content-Type header 24
Content-Version header 31 Content-Version header 33
D D
deflate 7 deflate 7
Derived-From header 31 Derived-From header 33
G G
Grammar Grammar
Accept 15 Accept 16
Accept-Charset 17 Accept-Charset 18
Accept-Encoding 18 Accept-Encoding 18
accept-extension 15 accept-extension 16
Accept-Language 19 Accept-Language 20
accept-params 15 accept-params 16
attribute 7 attribute 8
charset 5 charset 6
codings 18 codings 18
content-coding 6 content-coding 7
content-disposition 30 content-disposition 32
Content-Encoding 20 Content-Encoding 21
Content-Language 21 Content-Language 22
Content-Location 22 Content-Location 23
Content-MD5 23 Content-MD5 23
Content-Type 24 Content-Type 24
disp-extension-parm 30 disp-extension-parm 32
disp-extension-token 30 disp-extension-token 32
disposition-parm 30 disposition-parm 32
disposition-type 30 disposition-type 32
entity-body 11 entity-body 12
entity-header 11 entity-header 11
extension-header 11 extension-header 11
filename-parm 30 filename-parm 32
language-range 19 language-range 20
language-tag 10 language-tag 11
md5-digest 23 md5-digest 23
media-range 15 media-range 16
media-type 7 media-type 8
MIME-Version 28 MIME-Version 29
parameter 7 parameter 8
primary-tag 10 primary-tag 11
qvalue 9 qvalue 10
subtag 10 subtag 11
subtype 7 subtype 8
type 7 type 8
value 7 value 8
gzip 6 gzip 7
H H
Headers Headers
Accept 15 Accept 16
Accept-Charset 17 Accept-Charset 18
Accept-Encoding 17 Accept-Encoding 18
Accept-Language 19 Accept-Language 20
Alternate 31 Alternate 33
Content-Base 31 Content-Base 33
Content-Disposition 30 Content-Disposition 31
Content-Encoding 20 Content-Encoding 21
Content-Language 21 Content-Language 22
Content-Location 22 Content-Location 22
Content-MD5 22 Content-MD5 23
Content-Type 24 Content-Type 24
Content-Version 31 Content-Version 33
Derived-From 31 Derived-From 33
Link 31 Link 33
Public 31 Public 33
URI 31 URI 33
I I
identity 7 identity 8
L L
Link header 31 Link header 33
P P
Public header 31 Public header 33
U U
URI header 31 URI header 33
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
skipping to change at page 36, line 4 skipping to change at page 38, line 4
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)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France
Email: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Phone: +49 251 2807760
Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 89 change blocks. 
245 lines changed or deleted 387 lines changed or added

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