- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 12 Feb 1998 18:11:59 -0800
- To: http-wg@cuckoo.hpl.hp.com
- Cc: jg@w3.org
I think this is the most appropriate set of changes needed to resolve
the confusion regarding multiparts (and other MIMEness) in HTTP.
In some cases this is walking a tightrope, but that's better than
falling off the tightrope. I don't think it changes the protocol at all,
just the words used to describe it (and the addition of application/http).
....Roy
p.s. I also fixed some minor typos (and my address) in the process
===========================================================
*** draft-ietf-http-v11-spec-rev-01.txt Thu Feb 12 15:17:03 1998
--- multidraft.txt Thu Feb 12 18:00:38 1998
***************
*** 431,443 ****
19.2 Internet Media Type multipart/byteranges ..........152
19.3 Tolerant Applications .............................152
1.4 Differences Between HTTP Entities and RFC 2045 Entities 153
! 1.4.1 Conversion to Canonical Form ...................153
! 1.4.2 Conversion of Date Formats .....................154
! 1.4.3 Introduction of Content-Encoding ...............154
! 1.4.4 No Content-Transfer-Encoding ...................154
! 1.4.5 HTTP Header Fields in Multipart Body-Parts .....155
1.4.6 Introduction of Transfer-Encoding ..............155
- 1.4.7 MIME-Version ...................................155
1.5 Changes from HTTP/1.0 .............................156
1.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses .............................................156
--- 431,442 ----
19.2 Internet Media Type multipart/byteranges ..........152
19.3 Tolerant Applications .............................152
1.4 Differences Between HTTP Entities and RFC 2045 Entities 153
! 1.4.1 MIME-Version ...................................155
! 1.4.2 Conversion to Canonical Form ...................153
! 1.4.3 Conversion of Date Formats .....................154
! 1.4.4 Introduction of Content-Encoding ...............154
! 1.4.5 No Content-Transfer-Encoding ...................154
1.4.6 Introduction of Transfer-Encoding ..............155
1.5 Changes from HTTP/1.0 .............................156
1.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses .............................................156
***************
*** 1435,1445 ****
Parameter values may or may not be case-sensitive, depending on the
semantics of the parameter name. Linear white space (LWS) MUST NOT be
used between the type and subtype, nor between an attribute and its
! value. User agents that recognize the media-type MUST process (or
! arrange to be processed by any external applications used to process
! that type/subtype by the user agent) the parameters for that MIME type
! as described by that type/subtype definition to the and inform the user
! of any problems discovered.
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
--- 1434,1442 ----
Parameter values may or may not be case-sensitive, depending on the
semantics of the parameter name. Linear white space (LWS) MUST NOT be
used between the type and subtype, nor between an attribute and its
! value. The presence or absence of a parameter may be significant to
! the processing of a media-type, depending on its definition within the
! media type registry.
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
***************
*** 1502,1525 ****
CRLF to represent line breaks between body-parts. Unlike in RFC 2046,
the epilogue of any multipart message MUST be empty; HTTP applications
MUST NOT transmit the epilogue (even if the original multipart contains
! an epilogue).
!
!
! Fielding, et al [Page 26]
!
!
! INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997
!
!
! In HTTP, multipart body-parts MAY contain header fields which are
! significant to the meaning of that part. A Content-Location header field
! (section 14.15) SHOULD be included in the body-part of each enclosed
! entity that can be identified by a URL.
!
! 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. If
! an application receives an unrecognized multipart subtype, the
! application MUST treat it as being equivalent to "multipart/mixed".
Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST request
--- 1499,1520 ----
CRLF to represent line breaks between body-parts. Unlike in RFC 2046,
the epilogue of any multipart message MUST be empty; HTTP applications
MUST NOT transmit the epilogue (even if the original multipart contains
! an epilogue). These restrictions exist in order to preserve the
! self-delimiting nature of a multipart message-body, wherein the "end"
! of the message-body is indicated by the ending multipart boundary.
!
! In general, HTTP treats a multipart message-body no differently than any
! other media type: as payload. The one exception is the
! "multipart/byteranges" type (appendix 19.2) when it appears in a 206
! (Partial Content) response, which will be interpreted by some HTTP
! caching mechanisms as described in sections 13.5.4 and 14.17.
! In all other cases, an HTTP user agent SHOULD follow the same
! or similar behavior as a MIME user agent would upon receipt of a
! multipart type. If an application receives an unrecognized multipart
! subtype, the application MUST treat it as being equivalent to
! "multipart/mixed". The MIME header fields within each body-part of a
! multipart message-body do not have any significance to HTTP beyond that
! defined by their MIME semantics.
Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST request
***************
*** 6572,6578 ****
The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity-body the partial body should be
inserted. It SHOULD indicate the total length of the full entity-body,
! unless length this is unknown or difficult to determine.
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
--- 6567,6573 ----
The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity-body the partial body should be
inserted. It SHOULD indicate the total length of the full entity-body,
! unless this length is unknown or difficult to determine.
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
***************
*** 6634,6645 ****
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping ranges),
! these are transmitted as a multipart MIME message. The multipart MIME
! content-type used for this purpose is defined in this specification to
! be "multipart/byteranges". See appendix 19.2 for its definition. See
! appendix 19.8.3 for a compatibility issue.
! A client that cannot decode a MIME multipart/byteranges message should
not ask for multiple byte-ranges in a single request.
When a client requests multiple byte-ranges in one request, the server
--- 6629,6639 ----
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping ranges),
! these are transmitted as a multipart message. The multipart media type
! used for this purpose is "multipart/byteranges" as defined in
! appendix 19.2. See appendix 19.8.3 for a compatibility issue.
! A client that cannot decode a "multipart/byteranges" media type should
not ask for multiple byte-ranges in a single request.
When a client requests multiple byte-ranges in one request, the server
***************
*** 8364,8370 ****
will help reduce past confusion over the relationship between HTTP and
Internet mail message formats.
! The HTTP protocol has evolved considerably over the past four years. It
has benefited from a large and active developer community--the many
people who have participated on the www-talk mailing list--and it is
that community which has been most responsible for the success of HTTP
--- 8358,8364 ----
will help reduce past confusion over the relationship between HTTP and
Internet mail message formats.
! The HTTP protocol has evolved considerably over the past seven years. It
has benefited from a large and active developer community--the many
people who have participated on the www-talk mailing list--and it is
that community which has been most responsible for the success of HTTP
***************
*** 8672,8679 ****
Roy T. Fielding
Department of Information and Computer Science
University of California
! Irvine, CA 92717-3425, USA
! Fax: +1 (714) 824-4056
Email: fielding@ics.uci.edu
James Gettys
--- 8666,8673 ----
Roy T. Fielding
Department of Information and Computer Science
University of California
! Irvine, CA 92697-3425, USA
! Fax: +1 (714) 824-1715
Email: fielding@ics.uci.edu
James Gettys
***************
*** 8731,8741 ****
19 Appendices
! 19.1 Internet Media Type message/http
In addition to defining the HTTP/1.1 protocol, this document serves as
! the specification for the Internet media type "message/http". The
! following is to be registered with IANA [17].
Media Type name: message
Media subtype name: http
--- 8725,8741 ----
19 Appendices
! 19.1 Internet Media Types message/http and application/http
In addition to defining the HTTP/1.1 protocol, this document serves as
! the specification for the Internet media types "message/http" and
! "application/http". The message/http type can be used to enclose a
! single HTTP request or response message, provided that it obeys the
! MIME restrictions for all "message" types regarding line length and
! encodings. The application/http type can be used to enclose a pipeline
! of one or more HTTP request or response messages (not intermixed).
!
! The following is to be registered with IANA [17].
Media Type name: message
Media subtype name: http
***************
*** 8752,8757 ****
--- 8752,8772 ----
Security considerations: none
+ Media Type name: application
+ Media subtype name: http
+ Required parameters: none
+ Optional parameters: version, msgtype
+ version: The HTTP-Version number of the enclosed messages
+ (e.g., "1.1"). If not present, the version can be
+ determined from the first line of the body.
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first
+ line of the body.
+ Encoding considerations: HTTP messages enclosed by this type are
+ in "binary" format; use of an appropriate
+ Content-Transfer-Encoding is required when
+ transmitted via E-mail.
+ Security considerations: none
***************
*** 8763,8776 ****
19.2 Internet Media Type multipart/byteranges
! When an HTTP message includes the content of multiple ranges (for
! example, a response to a request for multiple non-overlapping ranges),
! these are transmitted as a multipart MIME message. The multipart media
type for this purpose is called "multipart/byteranges".
The multipart/byteranges media type includes two or more parts, each
! with its own Content-Type and Content-Range fields. The parts are
! separated using a MIME boundary parameter.
Media Type name: multipart
Media subtype name: byteranges
--- 8778,8791 ----
19.2 Internet Media Type multipart/byteranges
! When an HTTP 206 (Partial Content) response message includes the content
! of multiple ranges (a response to a request for multiple non-overlapping
! ranges), these are transmitted as a multipart message-body. The media
type for this purpose is called "multipart/byteranges".
The multipart/byteranges media type includes two or more parts, each
! with its own Content-Type and Content-Range fields. The required boundary
! parameter specifies the boundary string used to separate each body-part.
Media Type name: multipart
Media subtype name: byteranges
***************
*** 8779,8797 ****
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
For example:
! HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
--- 8794,8816 ----
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
+
For example:
! HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
+
...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
+
...the second range
--THIS_STRING_SEPARATES--
***************
*** 8853,8868 ****
types, to make date comparisons easier, and to acknowledge the practice
of some early HTTP servers and clients.
-
-
This appendix describes specific areas where HTTP differs from RFC 2045.
Proxies and gateways to strict MIME environments SHOULD be aware of
these differences and provide the appropriate conversions where
necessary. Proxies and gateways from MIME environments to HTTP also need
to be aware of the differences because some conversions may be required.
! 19.4.1 Conversion to Canonical Form
RFC 2045 requires that an Internet mail entity be converted to canonical
form prior to being transferred, as described in Appendix G of RFC 2045
--- 8872,8901 ----
types, to make date comparisons easier, and to acknowledge the practice
of some early HTTP servers and clients.
This appendix describes specific areas where HTTP differs from RFC 2045.
Proxies and gateways to strict MIME environments SHOULD be aware of
these differences and provide the appropriate conversions where
necessary. Proxies and gateways from MIME environments to HTTP also need
to be aware of the differences because some conversions may be required.
+ 19.4.1 MIME-Version
! HTTP is not a MIME-compliant protocol. However, HTTP is capable of
! transmitting MIME-compliant messages.
! HTTP/1.1 messages may include a single MIME-Version general-header field
! to indicate 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 full compliance with the MIME protocol (as defined in RFC
! 2045[7]). Proxies/gateways are responsible for ensuring full compliance
! (where possible) when exporting HTTP messages to strict MIME
! environments.
!
! MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
! 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 and not the
! MIME specification.
!
! 19.4.2 Conversion to Canonical Form
RFC 2045 requires that an Internet mail entity be converted to canonical
form prior to being transferred, as described in Appendix G of RFC 2045
***************
*** 8888,8895 ****
of some character sets which do not use octets 13 and 10 to represent CR
and LF, as is the case for some multi-byte character sets.
! 19.4.2 Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
simplify the process of date comparison. Proxies and gateways from other
--- 8921,8932 ----
of some character sets which do not use octets 13 and 10 to represent CR
and LF, as is the case for some multi-byte character sets.
+ Implementers should note that conversion will break any cryptographic
+ checksums applied to the original content unless the original content
+ is already in canonical form. Therefore, the canonical form is
+ recommended for any content that uses such checksums in HTTP.
! 19.4.3 Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
simplify the process of date comparison. Proxies and gateways from other
***************
*** 8898,8904 ****
necessary.
! 19.4.3 Introduction of Content-Encoding
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 media type,
--- 8935,8941 ----
necessary.
! 19.4.4 Introduction of Content-Encoding
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 media type,
***************
*** 8910,8916 ****
Content-Encoding. However, this parameter is not part of RFC 2045.)
! 19.4.4 No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
Proxies and gateways from MIME-compliant protocols to HTTP MUST remove
--- 8947,8953 ----
Content-Encoding. However, this parameter is not part of RFC 2045.)
! 19.4.5 No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045.
Proxies and gateways from MIME-compliant protocols to HTTP MUST remove
***************
*** 8935,8948 ****
INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997
- 19.4.5 HTTP Header Fields in Multipart Body-Parts
-
- In RFC 2045, most header fields in multipart body-parts are generally
- ignored unless the field name begins with "Content-". In HTTP/1.1,
- multipart body-parts may contain any HTTP header fields which are
- significant to the meaning of that part.
-
-
19.4.6 Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field (section 14.40).
--- 8972,8977 ----
***************
*** 8967,8989 ****
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
-
- 19.4.7 MIME-Version
-
- HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
- HTTP/1.1 messages may include a single MIME-Version general-header field
- to indicate 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 full compliance with the MIME protocol (as defined in RFC
- 2045[7]). Proxies/gateways are responsible for ensuring full compliance
- (where possible) when exporting HTTP messages to strict MIME
- environments.
-
- MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
- 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 and not the
- MIME specification.
-
--- 8996,9001 ----
Received on Thursday, 12 February 1998 18:37:17 UTC