W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

MULTIPART issue

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
Message-Id: <9802121818.aa23436@paris.ics.uci.edu>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:12 EDT