|
現在“瘦客戶”的觀點已經是一個神話了，但隨著電視或掌上型瀏覽器的繁榮，這一狀況會有所改變。今天絕大多數的網絡客戶仍使用功能強大的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（大�。涸O置單個文件名文本框的大小或允許多個文件使用單個< INPUT > 語句。
MAXLENGTH（長度最大值）：在客戶端設置的上載文件的最大規模。
通配符和上載路徑：雖然RFC有此建議，但IE和 Navigator都不支持通配符和路徑上載。
好在兩種瀏覽器都支持"Browse..."按鈕，用戶可以用"Open File..."對話框很容易地選出即將上載的文件。
VALUE子句的使用很有趣。為了用戶方便，可以讓WEB預先設置表單域的值。但是在這種情況下，它使一些不良網站可以預設上載文件名，加上一個客戶端提交的表單，就可不經用戶許可而從他們的PC上盜竊文件。1997年夏天，CERT和Bell實驗室的一名雇員一起對此發出了安全警告，Netscape和 Microsoft很快就發行了防止預設上載文件的補丁程序。
最初的RFC1867明確規定：“在用戶沒有明確要求的情況下，代理不得向其傳送任何文件，這一點很重要�！彼詾g覽器本可以只是簡單地發出一個警告對話框，例如“你想向服務器傳送文件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應用程序上增加文件上載的網絡開發人員來說，它能做的很少。
|
