现在“瘦客户”的观点已经是一个神话了，但随着电视或掌上型浏览器的繁荣，这一状况会有所改变。今天绝大多数的网络客户仍使用功能强大的PC，附着着大量的客户端存储器和客户端感兴趣的内容。在Internet协议下，将文件传递到中央服务器有一些方法可供选择，但基于WEB的文件上载比其它方法都要高级。下面来检验这一点。
一、HTTP与FTP的方式比较
为什么要上载？
文件上载对任何网络应用程序来说都起到重要作用。这里有一些例子，是关于我们的一些客户如何把文件上载并他们的WEB应用程序结合起来的：
1、基于WEB的e-mail形式，用文件上载给邮件信息增加附件
2、外部互联网应用程序用文件上载在伙伴间传送文件，如协议证明、软件更新或文件
3、技术支持站点用文件上载从用户中接收错误记录和有问题文件
4、企业内部互联网的文献出版用友好的网络接口在用户间分享文件
5、图形库用文件上载控制提交、产生略图
6、ISP主机店面用文件上载发送产品图象
HTTP与FTP的方式比较
在TCP/IP的早期，FTP是向服务器传输文件的标准机制。它可靠、可接受文本和二进制格式，客户可以在任何地方执行，但是它远远不及HTTP的适应性强。下面来比较一下：
■ 可靠性：用FTP上载，要么管理大量的用户帐号，要么就允许匿名访问。用WEB应用程序上载，应用程序可以确定允许谁上载，免除了极大的管理负担。
■ 安全性：通过HTTP上载可用SSL编码，这样一来信息可以在传输过程中加密。用FTP就无法作到。
■ 配置难易：FTP上载要求管理员精确地调节NTFS许可。用基于HTTP的上载和应用程序，管理员和应用程序都可以决定，如果需要的话。
■ 适应性：你想在一个地方存储DOC文件，在另一处存储图形吗？使用FTP的话，用户必须知道这些存储路径。而在WEB应用程序中，你可以自行控制，不用打扰用户就可以进行修改。
■ 能力：用WEB应用程序，每次调用都可以动态地控制上载文件的大小，甚至可以根据同一个表单中的信息改变大小。另外还可以冲掉符合一定标准的上载文件，如错误的MIME类型或文件类型。
■ 界面的简易友好性：招人喜欢的网页可以提供指导、建议、在线帮助，而基于批处理的FTP是不可能作到的。更重要的是发生错误时，WEB方式可以立刻向用户提供反馈并作出纠正。
■ 防火墙支持：出于安全和知识产权方面的考虑，许多机构不允许外部的FTP。通过简单的配置，大多数防火墙都支持HTTP。
■ 补充信息：一个HTTP上载（用RFC1867）还提供其它可用信息，例如用户的原始文件名，这在内部互联网环境下特别有用。
■ 上载到一个数据库：利用服务器端组件，如SA-FileUp，允许上载到OLE DB数据库。但用FTP，却绝对做不到这点！
■ 性能：FTP和HTTP最终都是用TCP协议，这是决定传输性能的决定因素。
■ 可靠性及重新上载：FTP和HTTP 1.1都允许传输重新启动。不幸地是许多服务器包括IIS，现在都不能支持任意一种协议的重新上载功能。FTP的重新上载功能将在IIS5版本中实现。
总之，同WEB本身一样，服务器的可编程性使HTTP上载比FTP具有极大的优势。
HTTP上载格式
通过HTTP上载有三种文件机制，它们是RFC1867、PUT和WebDAV。
HTTP上载方法1：RFC1867
HTML 3.2最终推出W3C之前的一段时期，RFC1867 (http://info.internet.isi.edu/in-notes/rfc/files/rfc1867.txt) 是IETF的建议标准。首先是Netscape在Navigator 2.0中运行，跟着Microsoft 把它作为IE 3.02 (32-bit) 的附加和IE 3.03 (16-bit)的自带内容。它是一个非常简单但又很强大的概念：定义一个格式域的新类型
< INPUT TYPE= "FILE" >
然后向表单中填加不同的编码方案：
< FORM ACTION="formproc.asp" METHOD="POST" ENCTYPE="multipart/form-data" >
而不是用典型的：
< FORM ACTION="formproc.asp" METHOD= "POST" >
在传输大量数据时，这种编码方案比默认的"application/x-url-encoded"格式编码方案效率高。正如你也许知道的，URL可用的字符集是很有限的。任何超出范围的字符集都要用'%nn'来代替，在这里nn是相应的两位十六进制数。即使是最常用的空格字符也要用'%20'来代替。如果浏览器不得不用效率如此低的编码方法对整个文件进行编码，那么上载文件的传输规模有可能比原始文件大2到3倍。而RFC1867用Multipart MIME编码，就象通常在e-mail信息中所见到的，在传输大量数据时不用编码，而只是在数据周围有几个简单有用的头。
结果看起来就象一个规则的HTML POST表单，实现上，通过4 KB的表单格式，代表的数据可以是几兆字节。RFC1867还提出了一些有待被浏览器提供者采纳的建议，即TYPE="FILE"语句的一些属性。其中包括：
ACCEPT（接受）：接收文件之前允许网站限制将要上载的文件类型。
SIZE（大小）：设置单个文件名文本框的大小或允许多个文件使用单个< INPUT > 语句。
MAXLENGTH（长度最大值）：在客户端设置的上载文件的最大规模。
通配符和上载路径：虽然RFC有此建议，但IE和 Navigator都不支持通配符和路径上载。
好在两种浏览器都支持"Browse..."按钮，用户可以用"Open File..."对话框很容易地选出即将上载的文件。
VALUE子句的使用很有趣。为了用户方便，可以让WEB预先设置表单域的值。但是在这种情况下，它使一些不良网站可以预设上载文件名，加上一个客户端提交的表单，就可不经用户许可而从他们的PC上盗窃文件。1997年夏天，CERT和Bell实验室的一名雇员一起对此发出了安全警告，Netscape和 Microsoft很快就发行了防止预设上载文件的补丁程序。
最初的RFC1867明确规定：“在用户没有明确要求的情况下，代理不得向其传送任何文件，这一点很重要。”所以浏览器本可以只是简单地发出一个警告对话框，例如“你想向服务器传送文件x, y, z吗？”，而不用完全禁止预设文件名。但是，在IE4.01中出现了一个安全空洞，使网站可以饶过IE现有的安全机制。（见http://www.microsoft.com/windows/ie/security/paste.htm)
HTTP上载方法2：HTTP PUT
HTTP 1.1 介绍了一个新的HTTP动词：PUT。当网络服务器收到了一个HTTP PUT 且对象名为("/myweb/image/x.gif"), 它要鉴别用户，取HTTP流的内容并直接存储 到网络服务器。这种方法会给网络带来很大的破坏，因此不常使用。而且它将HTTP 最大的优势---服务器可编程性放弃了。在使用PUT的情况下，由WEB服务器自身处理请求，没有CGI或ASP应用程序介入的空间。应用程序捕捉PUT的唯一方法是在低水平、ISAPI水平上操作。由于各种原因，大多数网络开发人员对此没有兴趣。
HTTP上载方法3：WebDAV
WebDAV (http://www.ietf.org/html.charters/webdav-charter.html) 允许网络内容的分布式授权和发布。它引入几个动词，可以对HTTP内容上载、锁定/开锁、进入/退出。我们可以把它看作一个非特有的配置管理（如来源安全）外加网络文件传输。Microsoft已经公开宣布IIS5、Office 2000 及未来IE版本都将支持它。ISP们很愿意把它来取代那些低级、易出故障的FrontPage服务器附加部分的机制。要注意的是它并不是取代FrontPage服务器附加部分，它只是简单地提供低级标准服务来支持服务器附加部分正在进行的更复杂的功能。在98年10月的PDC，你能看到Office 2000通过WebDAV完成了“保存到网络”（"Save to web" ）这样漂亮的任务。
听起来很棒，是不是？如果你想上载内容，WebDAV是很好的，它可以解决许多问题。但如果你想在网络应用程序内上载文件，WebDAV就无能为力了。同HTTP PUT一样, WebDAV这个动词是由服务器而不是应用程序来解释的，需要在ISAPI过滤器水平上使用WebDAV动作，并在应用程序中解释内容。
HTTP上载机制：总结
在WEB应用程序上载文件时，RFC1867仍然是最灵活的方法。PUT的用途很有限，WebDAV对内容作者，如FrontPage的用户来说很好，但是，它对于那些想往WEB应用程序上增加文件上载的网络开发人员来说，它能做的很少。