轉載自: http://zhangbq168.blog.163.com/blog/static/237353052011515113724/
track http://www.cnblogs.com/xiaotaomaomao/articles/986070.html
這個問題在我的開發中也遇到，所以在此貼出來(也是在網上搜出來的，呵呵)
這是原貼地址http://blog.csdn.net/somat/archive/2004/10/29/158707.aspx
兩個長度限制 問 題的分析(來源於項目)
一、問題起因
在某項目釋放后Bug統計的附件《釋放后問題》里有：
問題 原因 分析 備注
CSV處理時，如果處理的主題數過多，發生URL參數上限的錯誤； 可變長度的參數通過URL方式傳遞，會造成這種潛在的錯誤發生。 1、屬於2次發生問題，開發方面沒有及時通過checklist等方式向組員傳達相關注意事項；
2、測試時沒有作大批量數據的測試； 1、作為經驗添加至CheckList中，加強組內共享、檢查的效果；
2、加強測試點是否完備的檢查，重點關注對開發方面共性問題的測試；
通過對模塊原有GUI狀況確認，進行CSV輸出時，輸出結果很大的場合，CSV文件的內容不能輸出。 沒有考慮到POST數據量存在128K的大小限制。 這屬於新問題，以前從未遇見過，也沒有進行過大規模的數據量測試 已將此類檢查列出CheckList中
做為一種經驗積累，這些問題、原因及解決辦法將被列入Checklist，那么：
第一個問題：URL參數上限的提法准確嗎？上限是多少？
第二個問題：為什么POST時數據有限制？限制是128K嗎？
二、問題分析
1、第一個：
1）URL不存在參數上限的說法。該問題實際是IE對URL有長度限制 的問題。
2）HTTP協議規范也沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。IE對URL長度的限制是2083字節(2K+35)。對 於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制 ，其限制取決於操作系統的支持。[參1]
3）“可變長度的參數通過URL方式傳遞”實際是說提交表單時使用了GET方法，而不是POST方法。造成這種潛在錯誤的是使用GET方法提交表單數據。 因為GET方法將數據放在URL里傳遞給服務器處理。
4）注意這個限制是整個URL長度，而不僅僅是你的參數值數據長度。
5）既然是IE對URL長度的限制，那么不管是GET方法還是POST方法都存在這個限制。
(關於FORM的GET和POST方法具體內容請參考相關資料[參2])
建議：
1）了解應用程序所在的環境，如Web應用的瀏覽器、服務器環境，了解其特定的參數限制情況。
2）提交復雜數據盡量使用POST方法。注意FORM不寫method屬性時默認是使用GET方法。
結論(寫入Checklist)：
對使用GET方法提交數據時，在IE環境下，需要考慮URL長度2083字節的限制。
2、第二個：
1）理論上講，POST是沒有大小限制的。HTTP協議規范也沒有進行大小限制。
2）“POST數據量存在128K的大小限制”不夠准確，POST數據是沒有限制的，起限制作用的是服務器的處理程序的處理能力。
3）對於ASP程序，Request對象處理每個表單域時存在100K的數據長度限制 。但如果使用 Request.BinaryRead則沒有這個限制。對於需要處理超過100K表單域數據的解決辦法，請參考后面的[參3]。
4）由這個延伸出去，對於IIS 6.0，微軟出於安全考慮，加大了限制[參4]。我們還需要注意：
IIS 6.0默認ASP POST數據量最大為200KB，每個表單域限制是100KB。
IIS 6.0默認上傳文件的最大大小是4MB。
IIS 6.0默認最大請求頭是16KB。
IIS 6.0之前沒有這些限制。
建議：
1）弄清楚運行環境的默認設定值有助於你的設計及對出現的問題做快速的解決。
2）應該考慮服務器版本。各個版本的IIS對這些參數的默認設定都不一樣，有必要的話，找資料整理出一份對照表。這樣開發與測試時都有個參考。
3）IIS 6.0的這些限制實際只是它的默認設定值而已，實際應用環境你可以修改它們。
在WINNT\system32\inetsrv\MetaBase.xml里默認定義了：
AspBufferingLimit="4194304" 對應於上傳文件最大大小
AspMaxRequestEntityAllowed="204800" 對應於POST最大數據量
結論(寫入Checklist)：
使用ASP時，需要考慮POST表單每個域一般讀取處理時有100KB的限制。充分考慮是否使用Request.Binary
*******************************************************************************************************************************
1. get是從服務器上獲取數據，post是向服務器傳送數據。
2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數 據。
4. get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為 100KB。
5. get安全性非常低，post安全性較高。
HTTP請求：GET與POST方法的區別
HTTP 定義了與服務器交互的不同方法，最基本的方法是 GET 和 POST。事實上 GET 適用於多數請求，而保留 POST 僅用於更新站點。根據 HTTP 規范，GET 用於信息獲取，而且應該是 安全的和冪等的。所謂安全的意味着該操作用於獲取信息而非修改信息。換句話說，GET 請求一般不應產生副作用。冪等的意味着對同一 URL 的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。 比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST 請求就不那么輕松了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST 請求實現，因為在注解提交之后站點已經不同了（比方說文章下面出現一條注解）；
在FORM提交的時候，如果不指定Method，則默認為GET請求，Form中提交的數據將會附加在url之后，以?分開與url分開。字母數字字符原 樣發送，但空格轉換為“+“號，其它符號轉換為%XX,其中XX為該符號以16進制表示的ASCII（或ISO Latin-1）值。GET請求請提交的數據放置在HTTP請求協議頭中，而POST提交的數據則放在實體數據中；
GET方式提交的數據最多只能有1024字節，而POST則沒有此限制。
在表單里使用”post”和”get”有什么區別
在Form里面，可以使用post也可以使用get。它們都是method的合法取值。但是，post和get方法在使用上至少有兩點不同：
1、Get方法通過URL請求來傳遞用戶的輸入。Post方法通過另外的形式。
2、Get方式的提交你需要用Request.QueryString來取得變量的值，而Post方式提交時，你必須通過Request.Form來訪問 提交的內容。
仔細研究下面的代碼。你可以運行之來感受一下：
代碼
<!--兩個Form只有Method屬性不同-->
<FORM ACTION=“getpost.asp” METHOD=“get”>
<INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”></INPUT>
<INPUT TYPE=“submit ” VALUE=“Method=Get”></INPUT>
</FORM>
<BR>
<FORM ACTION=“getpost.asp” METHOD=“post”>
<INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”></INPUT>
<INPUT TYPE=“submit ” VALUE=“Method=Post”></INPUT>
</FORM>
<BR>
<BR>
<% If Request.QueryString(“Text”) <> ““ Then %>
通過get方法傳遞來的字符串是： “<B><%= Request.QueryString(“Text”) %></B>“<BR>
<% End If %>
<% If Request.Form(“Text”) <> ““ Then %>
通過Post方法傳遞來的字符串是： “<B><%= Request.Form(“Text”) %></B>“<BR>
<% End If %>
說明
把上面的代碼保存為getpost.asp，然后運行，首先測試post方法，這時候，瀏覽器的url並沒有什么變化，返回的結果是：
通過Post方法傳遞來的字符串是： "Hello World"
然后測試用get方法提交，請注意，瀏覽器的url變成了：
http://localhost/general/form/getpost.asp?Text=Hello+World
而返回的結果是：
通過get方法傳遞來的字符串是： "Hello World"
最后再通過post方法提交，瀏覽器的url還是：
http://localhost/general/form/getpost.asp?Text=Hello+World
而返回的結果變成：
通過get方法傳遞來的字符串是： "Hello World"
通過Post方法傳遞來的字符串是： "Hello World"
提示
通過get方法提交數據，可能會帶來安全性的問題。比如一個登陸頁面。當通過get方法提交數據時，用戶名和密碼將出現在URL上。如果：
１、 登陸頁面可以被瀏覽器緩存；
２、 其他人可以訪問客戶的這台機器。
那么，別人即可以從瀏覽器的歷史記錄中，讀取到此客戶的賬號和密碼。所以，在某些情況下，get方法會帶來嚴重的安全性問題。
建議
在Form中，建議使用post方法。
http://blog.csdn.net/zlf0727/archive/2010/05/19/5607965.aspx
Get方法提交URL的最大長度限制
詳情見：
1.http://support.microsoft.com/kb/208427/zh-cn
2.http://support.microsoft.com/kb/254786/zh-cn
注：以上鏈接地址均來自微軟的中文MSDN。
另外就是受服務器軟件的限制了。
當我們要嘗試用GET方式傳遞WEB頁面參數時,不得不考慮會不會因為瀏覽器地址欄長度限制導致錯誤。雖然用google能得到一堆,但是也許這些數據會互相矛盾。眼見為實,我用下面的方法測試了一下目前的各種瀏覽器的地址長度限制。
1.自己搭建一個本地的apache+php的web平台,這個不在本文的討論范圍。
2.在web服務器的根目錄建立名為index.php的文件,寫入如下內容：
<form method='get' action='index.php'>
$char='';
$len=1000;
$total_len=strlen('http://localhost/index.php?submit=submit&char=')+$len;
for($i=0;$i<$len;$i++){
$char.='1';
}
echo $_REQUEST['char'];
echo "<p>Address length: ".$total_len;
echo "<p><input type='submit' name='submit' value='submit'>";
echo "<p><input type='hidden' name='char' value='".$char."'>";
</form>
3.訪問http://localhost/index.php, 通過修改”$len=1000；”這行1000這個數字后點擊submit測試各瀏覽器到地址欄極限。結果為$len所賦值加上”http://localhost/index.php”的46字節的和。
結果如下：
1. Firefox 3.0.3: 當$len 賦值為4053時出錯,可見最長字長4098
2. IE7.0: 2083, 結果與官方說法一致
3. Opera 9.60: 4098 , Firefox3.0.3 相同
4. google chrome 0.2.149.30: 4098, 與Firefox3.0.3,Opera 9.60相同
可見Firefox, Opera, Chrome 雖然各自使用了不同的內核,至少在地址欄長度上有高度的默契。
另外,如果用POST方式傳遞數據,無論傳遞數據有多大,結果只會讓瀏覽器死掉而不是報錯。因為post的數據是放在header里傳輸的。可見POST傳遞數據無限制的傳言基本上可以認為是正確的。
總結:
上面的文章是asp語言的情況,php語言里面:
1. get可以認為是有限制的, 原理是: 雖然http協議規范沒有對url長度限制, 但是不同的瀏覽器對url地址長度有限制.
ie下url地址長度可以認為是2083字節, ff/opera/chrome等瀏覽器對url長度限制可以認為是4098字節
注: 不同版本的瀏覽器又有不同, 不詳細列出.
2. post數據量理論上是沒有限制的.
實際上受到操作系統和瀏覽器的限制, 過大的數據量會導致瀏覽器死掉.
[完]