起因是我们的教材[1]在对比SMTP协议和HTTP协议的时候提到的一个差异：
A third important difference concerns how a document consisting of text and images (along with possibly other media types) is handled. As we learned in Section 2.2, HTTP encapsulates each object in its own HTTP response message. Internet mail places all of the message’s objects into one message.
其中提到在处理一个既包含文本又包含图片（有可能还有其他类型）时，HTTP会把每个对象封装到自己的HTTP响应消息中，而因特网邮件（注意这里泛指所有因特网邮件协议而非特指SMTP）则把所有消息对象封装在一个消息里。
现在的问题是SMTP究竟如何处理非文本数据，是否真的如教材所言将所有类型的数据其封装成一个消息？
SMTP的局限及其扩展MIME
原始的SMTP[2]规定了SMTP传输的数据需要通过7位ASCII码进行传输，高位的比特数据作废。对于英文文本来说绰绰有余，但对于其他语言的文本或者非文本数据来说就造成了很大的障碍。解决这个问题有两种方法[3]:MIME和SMTP服务扩展（SMTP Service Extension）
多用途互联网邮件扩展（MIME）
MIME最早是为SMTP设计的扩展标准[4]，当然后来也被扩展并用于HTTP。
在RFC1521的摘要中就已经明确了：
In particular, this document is designed to provide facilities to include multiple objects in a single message
MIME标准是一个将多个媒体对象封装在一个消息中的方案。具体做法就是在原来的报文头部增加五个域：
-
MIME-VersionMIME的版本号 -
Content-Type内容类型，通过Content-Type:<type/subtype; parameters>定义消息中传送的内容的类型 -
Content-Transfer-Encoding内容传输编码，提供了除了7位ASCII码以外的编码方式 -
Content-Id内容标识，可选，多消息环境中的消息唯一的标识 -
Content-Description内容描述，可选
通过增加这些字段可以把原来只限于文本的数据扩展成其他类型。然而遇到多个对象的时候应该如何处理？
处理多个对象
Content-Type中有一种数据类型为Multipart意为含有多个不同类型的数据部分。对于Multipart类型的数据，Content-Type域除了原来的参数还会增加一个参数boundary，意为封装这些不同类型的数据部分的边界。两个连字符-后加上这个边界参数值可以分隔不同类型的数据，最后再加上两个连字符-则为最后的边界。
借用RFC1521中的例子，这是一个包含不同编码的文本的消息：
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble.
It is to be ignored, though it is a handy place for mail composers to include an explanatory note to non-MIME conformant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
再借用一个RFC2046[5]中的例子演示alternative子类型
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... plain text version of message goes here ...
--boundary42
Content-Type: text/enriched
... RFC 1896 text/enriched version of same message goes here ...
--boundary42
Content-Type: application/x-whatever
... fanciest version of same message goes here ...
--boundary42--
这里除了包含文本对象还有应用对象（x-whatever)，而这个应用对象是否显示则取决于对方使用的版本是否支持。
正如在SMTP最新的标准RFC5321[6]中所述：
SMTP transports a mail object. A mail object contains an envelope and content.
SMTP传送的是一个邮件对象，只封装一次。
HTTP
那么HTTP呢？既然前面提到了MIME也被借鉴到了HTTP中，处理多对象数据的时候会有什么不同么？
光说不练假把式，一言不合先抓包。
这里打开苏州续江数码科技有限公司的官网在页面加载期间进行抓包得到
续江的进程
很显然各个对象之间是独立封装的，连GET的时间都是不一样的，第一个报文被归为文档类点开可以看到响应头部
响应头部
Content-Type是text/html，这里包含了整个网页的文本信息。其他的报文则是网页中的图片。
HTTP支持Multipart么？当然啦，它是MIME标准，我们怎么能不支持它。但是这么早说支持，给人一种SMTP的感觉。这也是HTTP所支持的MIME与SMTP支持的MIME不同的地方。
HTTP支持特有的子类Multipart/Byteranges[5]而非严格服从MIME，原始的HTTP一开始不支持multipart，当然后续也并不推荐这种封装策略[7]，大概是出于作为拉协议本身的需求。
The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request method
-
GB/T 7714
Kurose J, Ross K. Computer Networking: A top-down approach[J]. 2013. ↩ -
Postel J. RFC 821: Simple Mail Tranfer Protocol[R]. IETF Network Working Group, 1982. ↩
-
Riabov V V. SMTP (Simple Mail Transfer Protocol)[J]. River College, 2005. ↩
-
Moore K. MIME (Multipurpose Internet Mail Extensions) part two: Message header extensions for non-ascii text[J]. 1993. ↩
-
RFC2046 A. Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types[J]. ↩ ↩
-
Klensin J. RFC 5321—Simple mail transfer protocol (SMTP)[R]. RFC 5321, 2008. ↩
-
Nebel E, Masinter L. RFC 1867: Form-based File Upload in HTML[J]. Internet Engineering Task Force< URL: ftp: ds. internic. net rfc rfc1867. txt, 1995. ↩
网友评论