rfc1867.txt

很多RFC的中文文档

否是过大以至于将不能完整地处理，从而返回一个错误代码并关闭该连接，而不用等到接受
了所有的数据才进行判断。目前一些现有的CGI应用对所有的POST事务都需要知道内容
总长度。

如果INPUT标记含有一个MAXLENGTH属性，客户端可以将这个属性值看作是服务器端
所能够接受的传送文件的最大字节数。在这种情况下，服务器能够在上传开始前，提示客户
端在服务器上有多少空间可以用来进行文件上传。但是应该引起注意的是，这仅仅是一个提
示，在表单被创建后和文件上传前，服务器的实际需求可能会发生改变。

在任何情况下，如果接受的文件过大的话，任何一个HTTP服务器都有可能在文件传输的
过程中中断传输。

5.3传输二进制数据的其他解决办法

有些人曾经建议使用一种新的MIME类型"aggregate"，比如说aggregate/mixed 或是
content-transfer-encoding "包"来描述那些不确定长度的二进制数据，而不是靠分解为多个
部分来表示。虽然我们并不反对这么做，但这需要增加额外的设计和标准化工作来让大家接
受并理解"aggregate"。 从另一方面来说，"分解为多部分"的机制工作得很好，能够非常简
单的在客户发送端和服务器接受端加以实现，而且能像其他一些综合处理二进制数据的方式
一样高效率地工作。

5.4 不修改<INPUT>

有些人曾经提到过，为什么要修改INPUT来实现文件上传功能，而不是为表单元素提供一
个完全不同的类型？在这种种考虑中，当我们使用<INPUT>时，最重要的考虑是兼容策略。
事实上，<INPUT>标记"早就已经"被修改过以用来包含各种输入的数据，相比较于创造不同
种类的<INPUT>标记，对<INPUT>进行加强看起来是更为合理的办法。INPUT的“类型”
并不是它所返回的内容类型，而更象是“多类型”的，也就是说，它表示了和用户互动的方
式。它的定义被仔细地斟酌以便其既能在文本浏览器，也能在声音标记中使用。

5.5字段内容的默认类型

HTML中许多字段都需要用户进行输入。过去人们对这些表单数据应该如何传回到服务器有
些意见分歧。但是将这些INPUT字段的内容看成是纯文本很明显将有助于消除这方面的分
歧。客户端再将这些数据传回到服务器以前应该将它们用CRLF分隔开，并进行适当的编
码。

5.6允许ACTION指向"mailto:"

虽然和本方案无关，但是如果允许客户端的表单的ACTION指向一个"mailto:"地址将肯定非
常有用。不管本方案本身怎么设想，这都是一个好主意。同样的，那些用来接受邮件的表单
的ACTION也应该默认指向"reply-to:"。这两个设想有助于让HTML表单借助于HTTP服务
器工作，但通过电子邮件发送内容。或者也可以这么做：允许HTML表单能够被电子邮件
发送，当HTML中指明的邮件收件人填写完表单后，再将结果发送作为邮件传送回来。

5.7第三方传输的远程文件
在某些情况下，那些操作客户端软件的用户可能希望通过指定一个URL地址来传送位于网
上，而不是本地的数据文件。在这种情况下，浏览器能够发送给客户一个指向远程数据的连
接，而不是实际的所有内容吗？这种要求实际上是可以办得到的，举例来说，只要让客户在
发送给服务器的数据当中，用"message/external-body"来指明数据的类型，同时将
"access-type"设置为连接的地址，并在发送的内容中包含远程数据的URL地址就可以了。

5.8用ENCTYPE=x-www-form-urlencoded来传输文件

如果一个表单包含了<INPUT TYPE=file>元素，但是表单本身未包含ENCTYPE属性，也
就是没有详细说明相应的行为的话。这将可能导致为服务器进行不恰当的对大量数据进行
URN编码，而这将是服务器端所不希望看到的

5.9将CRLF作为行分隔符

象所有的MIME传输一样，在用POST方式传送表单内容的时候，CRLF都被用作行的分
隔符。

5.10和multipart/related的关系
MIMESGML小组正在考虑制订一种新的类型，称为multipart/related。它包含和
multipart/form-data类似的特点。Form-data的使用和应用却是完全不同的，所以它被单独
进行描述。

在某些情况下，有可能将HTML表单的内容（包括文件）作为multipart/related进行编码，
但这和本方案所讨论的情况有很大的不同。

5.11含有非ASCII码的字段名

需要注意的是MIME的标题头通常是由7位的US-ASCII字符集构成。所以如果字段名的字
符不属于该字符集的话，就必须按照RFC 1522里面所提到的方法进行编码。在HTML 2.0
里面，默认的字符集是ISO-8859-1，而由非ASCII码字符组成的字段名就必须进行编码。

6.例子

假设服务器段提供的是如下的HTML：

     <FORM ACTION="http://server.dom/cgi/handle"
           ENCTYPE="multipart/form-data"
           METHOD=POST>
     What is your name? <INPUT TYPE=TEXT NAME=submitter>
     What files are you sending? <INPUT TYPE=FILE NAME=pics>
     </FORM>

用户在“姓名”字段里面填写"Joe Blow"，对问题'What files are you sending?'，用户选择
了一个文本文件"file1.txt"。

客户段可能发送回如下的数据：

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"; filename="file1.txt"
        Content-Type: text/plain

         ... file1.txt 的内容...
        --AaB03x--

如果用户同时还选择了另一个图片文件"file2.gif"，那么客户端可能发送的数据将是：

        Content-type: multipart/form-data, boundary=AaB03x

        --AaB03x
        content-disposition: form-data; name="field1"

        Joe Blow
        --AaB03x
        content-disposition: form-data; name="pics"
        Content-type: multipart/mixed, boundary=BbC04y

        --BbC04y
        Content-disposition: attachment; filename="file1.txt"

        Content-Type: text/plain

        ... file1.txt 的内容...
        --BbC04y
        Content-disposition: attachment; filename="file2.gif"
        Content-type: image/gif
        Content-Transfer-Encoding: binary

          ... file2.gif的内容...
        --BbC04y--
        --AaB03x--

7. multipart/form-data的登记
multipart/form-data的媒体内容遵从RFC 1521所规定的多部分的数据流规则。它主要被用
来描述表单填写后返回的数据。在一个表单中（这里指的是HTML，当然其他一些应用也可
能使用表单），有一系列字段提供给用户进行填写，每个字段都有自己的名字。在一个确定
的表单中，每个名字都是唯一的。

multipart/form-data由多个部分组成，每一部分都有一个content-disposition标题头，它的
值是"form-data"，它的属性指明了其在表单内的字段名。举例来说，'content-disposition: 
form-data; name="xxxxx"'，这里的xxxxx就是对应于该字段的字段名。如果字段名包含非
ASCII码字符的话，还应该按照RFC 1522里面所规定的方法进行编码。

对所有的多部分MIME类型来说，每一部分有一个可选的Content-Type，默认的值是
text/plain。如果文件的内容是通过表单填写上传返回的话，那么输入的文件就被定义为
application/octet-stream，或者，如果知道是什么类型的话，就定义为相应的媒体类型。如
果一个表单返回多个文件，那么它们就作为multipart/form-data中所结合的multipart/mixed
被返回。

如果所传送的内容不符合默认的编码方式的话，该部分都将被编码，并加上
"content-transfer-encoding"的标题头。

上传的文件也可能被指定文件名，文件名可以由标题头"content-disposition"中的filename
参数所指定。虽然这并不是必需的，但我们强烈建议在能够得知原始文件名的情况下这么做。
对于很多应用程序来说，这都是必需的或者是有用的。

8.安全性考虑

如果用户没有明确要求发送某个文件，用户端就不应该发送该文件，这点非常重要。所以，
在碰到<INPUT TYPE=file VALUE="yyyy">的标记的时候，HTML解释器应该能够让用户确
认默认的文件名。不要使用隐含的字段来指定任何文件。

本方案并没有包括对数据加密的讨论；这应该是保密数据传输协议，或者是加密HTTP，或
者是MOSS所提供的加密协议（在RFC 1848中有具体的描述）所讨论的问题。

一旦文件上传成功，就将取决于文件接受方来处理文件或者是储存在适当的地方。

9.结论

我们所建议的应用让客户端有很大的弹性来决定它发送到服务器的文件的类型和数量，也让
服务器端有权决定是否接受上传的文件，同时也让服务器有机会和那些不支持类型为file的
INPUT的浏览器进行互动。

对HTML DTD的改动虽然很简单，但却有很大的作用。能够让目前这种缺少文件上传机制
的万维网实现很多种服务。这将给万维网实际的性能增加许多惊人的价值。

作者地址：

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone:  [phone]
   Fax:    [phone]
   EMail:   [e-mail]

   Ernesto Nebel
   XSoft, Xerox Corporation
   10875 Rancho Bernardo Road, Suite 200
   San Diego, CA 92127-2116

   Phone:  [phone]
   Fax:    [phone]
   EMail:   [e-mail]

A.为multipart/form-data登记的媒体类型
媒体类型名称:
 multipart

子类型名称:
 form-data

必需的参数:
 无

可选参数:
 无

编码考虑:
和其他类型相比没有额外的考虑。

发行的规范:
 RFC 1867

安全性考虑

multipart/form-data并未引进新的安全性考虑来针对那些可能存在所附的内容中的问题。

参考：

[RFC 1521] MIME (多用途的网际邮件扩充协议) 第一部分:
	  网上邮件内容格式的确定和规范机制
	  N. Borenstein & N. Freed.
           1993年9月.

[RFC 1522] MIME (多用途的网际邮件扩充协议) 第二部分:
	  非ASCII码文本的邮件头扩充
           K. Moore.
           1993年9月.

[RFC 1806] 英特网上的信息通讯和表达
           信息: Content-Disposition标题头. 
	  R. Troost & S. Dorner, 
	  1995年6月.
RFC 1867 Form-based File Upload in HTML	HTML中基于表单的文件上传
RFC文档中文翻译计划		1