文檔提交1.txt

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

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

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

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

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

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

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