文檔提交1.txt

1、行家看用ASP上傳文件為什么要上傳HTTP對比FTP以及其他方法HTTP上傳的形式RFC1867HTTP1.1PutWebDAV用ASP來實現(xiàn)PostingAcceptSAFileUp普遍認同的問題結論參考★為什么上傳“瘦客戶端“的觀念在今天看來是個神話。也許隨著電視瀏覽器或者是掌上型瀏覽器的繁衍，情況會有所變化。但是在今天，大量的web客戶端使用功能強大的PC，它們擁有很大的存貯空間和許多有趣的客戶端內(nèi)容。事實上，文件上傳對于任何we

2、b應用程序都是很有用的一個功能。以下是我們的一些客戶如何在他們的web應用程序中集成文件上傳的例子：基于web的email使用文件上傳在消息中加入附件。外部網(wǎng)絡應用程序使用文件上傳在合作對象間發(fā)送文件，比如一致性驗證、軟件更新或者是軟件管理。技術支持站點使用文件上傳從用戶處接收錯誤日志和缺陷報告文檔。內(nèi)部網(wǎng)文檔出版使用文件上傳，通過友好的web界面在用戶間共享文件。圖形庫使用文件上傳控制提交，并且生成小圖標。ISP經(jīng)營的店面使用文件上傳

3、發(fā)送產(chǎn)品圖型。對比其他通過Inter協(xié)議將文件發(fā)送到中央服務器的方法，基于web的文件上傳是一種高級得多的替代手段。讓我們檢查一下為什么會這樣。★HTTP對比FTP想法：在表單字段中定義一個新類型。并且在表單本身加入了不同的編碼方案，不再使用典型的：而是使用這種編碼方案在傳送大量數(shù)據(jù)的時候，比起缺省的“applicationxurlencoded“表單編碼方案，顯得效率要高得多。象你可能會意識到的那樣，URL編碼只有很有限的字符集。使用

4、任何超出字符集的字符，必須用%nn代替，這里的nn表示相應的2個十六進制數(shù)字。例如，即使是普通的空格字符也要用%20代替。如果瀏覽器不得不使用這種低效的手段對整個文件編碼，那么傳送的文件會是原始文件的23倍大！取而代之，RFC1867使用多部分MIME編碼，就象通常在email消息中看到的那樣，不編碼來傳送大量數(shù)據(jù)，而只是在數(shù)據(jù)周圍加上很少的簡單但實用的頭部。結果看起來象是通常的HTML的fmPost，但是說起來是4KB的表單數(shù)據(jù)，卻有

5、可能達到上兆字節(jié)的長度！RFC1867也建議瀏覽器廠商必須采納對TYPE=“FILE“標簽提出的幾個屬性的建議。包括：ACCEPT:讓web站點在接受文件前限制文件類型。SIZE:讓站點設置單個文件名文本框的大小或者用一個標簽允許多個文件。MAXLENGTH:在客戶端潛在的設置將要傳送的文件的最大長度。Wildcardsdirectyuploads:雖然RFC建議使用通配符或者字典，但IE和Navigat都不支持幸運的是，兩個瀏覽器的廠

6、商都采用了建議的“瀏覽...”按鈕，是用戶能很容易的使用本地“打開文件...“對話框選擇要上傳的文件。數(shù)值項的使用很有趣。通常出于用戶方便考慮，讓web站點預設表單字段的值是很自然的。但是這樣的話，就會使得不法web站點能夠預設要上傳的文件名，并伴隨一個客戶端的表單提交，從而不經(jīng)過用戶的允許就“竊取”他們PC里的文件。在1997年夏季，CERT協(xié)同一名貝爾實驗室的雇員，針對這個問題發(fā)布了安全性警告，網(wǎng)景和微軟迅速發(fā)布補丁來阻止預設文件被

7、上傳。(請見iesecuritybell.htm)這很不幸，因為原本RFC1867就清楚的祥述過“用戶代理不應該發(fā)送任何用戶沒有明確要求被發(fā)送的文件，這是非常重要的?！币虼?，與其整個關掉名字預設功能，倒不如瀏覽器簡單的產(chǎn)生一個警告對話框，比如：“你想傳送文件xyz到服務器嗎？”。然而作為這件事最后的一個麻煩，10月中旬在IE4.01中發(fā)現(xiàn)了另外一個安全漏洞，這個漏洞能夠讓web站點繞過IE現(xiàn)有的安全機制。(見windowsiesecur