MIME: Difference between revisions

The RFC initially defined four subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognized subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.

 

 

The type is defined in RFC 2046.<ref>[http://tools.ietf.org/html/rfc2046#section-5.1.3 RFC 2046, Section 5.1.3]</ref>

 

 

The MIME type is defined in RFC 2046.<ref>[http://tools.ietf.org/html/rfc2046#section-5.1.5 RFC 2046, Section 5.1.5]</ref>

 

The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The order of the parts is significant. RFC1341 states: ''In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last.''<ref>{{cite web|url=http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html|title=RFC1341 Section 7.2 The Multipart Content-Type|access-date=2014-07-15}}</ref>

 

The type is defined in RFC 2046.<ref>[http://tools.ietf.org/html/rfc2046#section-5.1.4 RFC 2046, Section 5.1.4]</ref>

 

A multipart/related is used to indicate that each message part is a component of an aggregate whole. It is for compound objects consisting of several inter-related components{{snd}} proper display cannot be achieved by individually displaying the constituent parts. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by ''Content-ID''. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.

 

The type is defined in RFC 2387.

 

 

The type is defined in RFC 6522.

 

A multipart/signed message is used to attach a [[digital signature]] to a message. It has exactly two body parts, a body part and a signature part. The whole of the body part, including mime fields, is used to create the signature part. Many signature types are possible, like "application/pgp-signature" (RFC 3156) and "application/pkcs7-signature" ([[S/MIME]]).

 

The type is defined in RFC 1847.<ref>[http://tools.ietf.org/html/rfc1847#section-2.1 RFC 1847, Section 2.1]</ref>

 

A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are

identified by their separate content types for the control part. The most common types are

The MIME type defined in RFC 1847.<ref>[http://tools.ietf.org/html/rfc1847#section-2.2 RFC 1847, Section 2.2]</ref>

 

The MIME type ''multipart/form-data'' is used to express values submitted through a form. Originally defined as part of [[HTML]] 4.0, it is most commonly used for submitting files with [[HTTP]]. It is specified in RFC 7578, superseding RFC 2388.

 

The content type multipart/x-mixed-replace was developed as part of a technology to emulate [[Push technology|server push]] and streaming over HTTP.

 

Originally developed by [[Netscape]],<ref>{{Cite web|url=http://fishcam.netscape.com/assist/net_sites/pushpull.html |archive-url=https://web.archive.org/web/19981203153836/http://fishcam.netscape.com/assist/net_sites/pushpull.html |archive-date=1998-12-03 |title=An Exploration of Dynamic Documents |publisher=Netscape |url-status=dead }}</ref> it is still supported by [[Mozilla]], [[Mozilla Firefox|Firefox]], [[Safari (web browser)|Safari]], and [[Opera (web browser)|Opera]]. It is commonly used in [[IP camera]]s as the MIME type for [[MJPEG]] streams.<ref>{{Cite web|archive-url=https://web.archive.org/web/20100511090539/http://www.deskshare.com/Resources/articles/wcm_ip_CameraSecuritySetup.aspx|archive-date=2010-05-11|url-status=live|url=http://www.deskshare.com/Resources/articles/wcm_ip_CameraSecuritySetup.aspx|publisher=DeskShare|title=WebCam Monitor setup documentation}}</ref> It was supported by Chrome for main resources until 2013 (images can still be displayed using this content type).<ref>{{Cite web|url=https://bugs.chromium.org/p/chromium/issues/detail?id=249132|title=249132 - Remove support for multipart/x-mixed-replace main resources - chromium - Monorail|website=bugs.chromium.org|language=en|access-date=2017-10-10}}</ref>

 

The multipart/byterange is used to represent noncontiguous byte ranges of a single message. It is used by HTTP when a server returns multiple byte ranges and is defined in RFC 2616.