post請求機(jī)制

1、JAVA中Get和Post請求的區(qū)別收集整理

一 原理區(qū)別

一般在瀏覽器中輸入網(wǎng)址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認(rèn)為GET提交

Http定義了與服務(wù)器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE

URL全稱是資源描述符，我們可以這樣認(rèn)為：一個URL地址，它用于描述一個網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對應(yīng)著對這個資源的查 ，改 ，增 ，刪 4個操作。到這里，大家應(yīng)該有個大概的了解了，GET一般用于獲取/查詢 資源信息，而POST一般用于更新 資源信息(個人認(rèn)為這是GET和POST的本質(zhì)區(qū)別，也是協(xié)議設(shè)計者的本意，其它區(qū)別都是具體表現(xiàn)形式的差異 )。

根據(jù)HTTP規(guī)范，GET用于信息獲取，而且應(yīng)該是安全的和冪等的 。

1.所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET請求一般不應(yīng)產(chǎn)生副作用。就是說，它僅僅是獲取資源信息，就像數(shù)據(jù)庫查詢一樣，不會修改，增加數(shù)據(jù)，不會影響資源的狀態(tài)。

* 注意：這里安全的含義僅僅是指是非修改信息。

2.冪等的意味著對同一URL的多個請求應(yīng)該返回同樣的結(jié)果。這里我再解釋一下冪等 這個概念：

冪等 （idempotent、idempotence）是一個數(shù)學(xué)或計算機(jī)學(xué)概念，常見于抽象代數(shù)中。
冪等有以下幾種定義：
對于單目運(yùn)算，如果一個運(yùn)算對于在范圍內(nèi)的所有的一個數(shù)多次進(jìn)行該運(yùn)算所得的結(jié)果和進(jìn)行一次該運(yùn)算所得的結(jié)果是一樣的，那么我們就稱該運(yùn)算是冪等的。 比如絕對值運(yùn)算就是一個例子，在實(shí)數(shù)集中，有abs(a) = abs(abs(a)) 。
對于雙目運(yùn)算，則要求當(dāng)參與運(yùn)算的兩個值是等值的情況下，如果滿足運(yùn)算結(jié)果與參與運(yùn)算的兩個值相等，則稱該運(yùn)算冪等，如求兩個數(shù)的最大值的函數(shù)，有在實(shí)數(shù)集中冪等，即max(x,x) = x 。

看完上述解釋后，應(yīng)該可以理解GET冪等的含義了。

但在實(shí)際應(yīng)用中，以上2條規(guī)定并沒有這么嚴(yán)格。引用別人文章的例子：比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。從根本上說，如果目標(biāo)是當(dāng)用戶打開一個鏈接時，他可以確信從自身的角度來看沒有改變資源即可。

根據(jù)HTTP規(guī)范，POST表示可能修改變服務(wù)器上的資源的請求 。繼續(xù)引用上面的例子：還是新聞以網(wǎng)站為例，讀者對新聞發(fā)表自己的評論應(yīng)該通過POST實(shí)現(xiàn)，因?yàn)樵谠u論提交后站點(diǎn)的資源已經(jīng)不同了，或者說資源被修改了。

上面大概說了一下HTTP規(guī)范中，GET和POST的一些原理性的問題。但在實(shí)際的做的時候，很多人卻沒有按照HTTP規(guī)范去做，導(dǎo)致這個問題的原因有很多，比如說：

1.很多人貪方便，更新資源時用了GET，因?yàn)橛肞OST必須要到FORM（表單），這樣會麻煩一點(diǎn)。

2.對資源的增，刪，改，查操作，其實(shí)都可以通過GET/POST完成，不需要用到PUT和DELETE。

3.另外一個是，早期的但是Web MVC框架設(shè)計者們并沒有有意識地將URL當(dāng)作抽象的資源來看待和設(shè)計 。還有一個較為嚴(yán)重的問題是傳統(tǒng)的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。

* 簡單解釋一下MVC：MVC本來是存在于Desktop程序中的，M是指數(shù)據(jù)模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實(shí)現(xiàn)代碼分離，從而使同一個程序可以使用不同的表現(xiàn)形式。

以上3點(diǎn)典型地描述了老一套的風(fēng)格（沒有嚴(yán)格遵守HTTP規(guī)范），隨著架構(gòu)的發(fā)展，現(xiàn)在出現(xiàn)REST(Representational State Transfer)，一套支持HTTP規(guī)范的新風(fēng)格，這里不多說了，可以參考《RESTful Web Services》。

二 表現(xiàn)形式區(qū)別

搞清了兩者的原理區(qū)別，我們再來看一下他們實(shí)際應(yīng)用中的區(qū)別：

為了理解兩者在傳輸過程中的不同，我們先看一下HTTP協(xié)議的格式：

HTTP請求：
<request line>          //http請求行
<headers>               //http請求消息報頭
<blank line>             // 回 車 換行
[<request-body>]     //http請求正文

在HTTP請求中，第一行必須是一個請求行（request line），用來說明請求類型、要訪問的資源以及使用的HTTP版本。緊接著是一個首部（header）小節(jié)，用來說明服務(wù)器要使用的附加信息。在首部之后是一個空行，再此之后可以添加任意的其他數(shù)據(jù)[稱之為主體（body）]。

GET與POST方法實(shí)例：

GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（----此處空一行----）
name=Professional%20Ajax&publisher=Wiley

有了以上對HTTP請求的了解和示例，我們再來看兩種提交方式的區(qū)別：

（1）GET提交，請求的數(shù)據(jù)會附在URL之后（就是把數(shù)據(jù)放置在HTTP協(xié)議頭中），以?分割URL和傳輸數(shù)據(jù)，多個參數(shù)用&連接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送，如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進(jìn)制表示的ASCII。

POST提交：把提交的數(shù)據(jù)放置在是HTTP包的包體中。上文示例中紅色字體標(biāo)明的就是實(shí)際的傳輸數(shù)據(jù)

因此，GET提交的數(shù)據(jù)會在地址欄中顯示出來，而POST提交，地址欄不會改變

(2)傳輸數(shù)據(jù)的大小：首先聲明：HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進(jìn)行限制。

而在實(shí)際開發(fā)中存在的限制主要有：

GET:特定瀏覽器和服務(wù)器對URL長度有限制，例如 IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系 統(tǒng)的支持。

因此對于GET提交時，傳輸數(shù)據(jù)就會受到URL長度的 限制。

POST:由于不是通過URL傳值，理論上數(shù)據(jù)不受 限。但實(shí)際各個WEB服務(wù)器會規(guī)定對post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。

(3)安全性：

POST的安全性要比GET的安全性高。注意：這里所說的安全性和上面GET提到的“安全”不是同個概念。上面 “安全”的含義僅僅是不作數(shù)據(jù)修 改，而這 里安全的含義是真正的Security的含義，比如：通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)?1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號和密碼了，除此之外，使用GET提交數(shù)據(jù)還可能會造成Cross-site request forgery攻擊

（4）Http get,post,soap協(xié)議都是在http上運(yùn)行的
1）get：請求參數(shù)是作為一個key/value對的序列（查詢字符串）附加到URL上的
查詢字符串的長度受到web瀏覽器和web服務(wù)器的限制（如IE最多支持2048個字符），不適合傳輸大型數(shù)據(jù)集同時，它很不安全
2）post：請求參數(shù)是在http標(biāo)題的一個不同部分（名為entity body）傳輸?shù)模@一部分用來傳輸表單信息，因此必須將Content-type設(shè)置為:application/x-www-form- urlencoded。post設(shè)計用來支持web窗體上的用戶字段，其參數(shù)也是作為key/value對傳輸。
但是：它不支持復(fù)雜數(shù)據(jù)類型，因?yàn)閜ost沒有定義傳輸數(shù)據(jù)結(jié)構(gòu)的語義和規(guī)則。
3）soap：是http post的一個專用版本，遵循一種特殊的xml消息格式
Content-type設(shè)置為: text/xml   任何數(shù)據(jù)都可以xml化

三 HTTP響應(yīng) 
1．HTTP響應(yīng)格式：

<status line>          //http響應(yīng)狀態(tài)行
<headers>             //http響應(yīng)消息報頭
<blank line>            //回車換行
[<response-body>]  //http響應(yīng)正文

在響應(yīng)中唯一真正的區(qū)別在于第一行中用狀態(tài)信息代替了請求信息。狀態(tài)行（status line）通過提供一個狀態(tài)碼來說明所請求的資源情況。 

HTTP響應(yīng)實(shí)例：

HTTP/1.1 200 OKDate: Sat, 31 Dec 2005 23:59:59 GMTContent-Type: text/html;charset=ISO-8859-1 Content-Length: 122
 
＜html＞
 ＜head＞
  ＜title＞W(wǎng)rox Homepage＜/title＞
 ＜/head＞
 ＜body＞＜!-- body goes here --＞＜/body＞
＜/html＞

2．最常用的狀態(tài)碼有：

◆200 (OK): 找到了該資源，并且一切正常。
◆304 (NOT MODIFIED): 該資源在上次請求之后沒有任何修改。這通常用于瀏覽器的緩存機(jī)制。
◆401 (UNAUTHORIZED): 客戶端無權(quán)訪問該資源。這通常會使得瀏覽器要求用戶輸入用戶名和密碼，以登錄到服務(wù)器。
◆403 (FORBIDDEN): 客戶端未能獲得授權(quán)。這通常是在401之后輸入了不正確的用戶名或密碼。
◆404 (NOT FOUND): 在指定的位置不存在所申請的資源.四 完整示例

例子：

HTTP GET 發(fā)送

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com

Response :

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

Http Post 發(fā)送

POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
UserID=string&PWD=string&OrderConfirmation=string

Response : 

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

SOAP 1.2 

發(fā)送

POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>

Response : 

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
</soap12:Envelope>

1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。 get 和 post只是一種傳遞數(shù)據(jù)的方式，get也可以把數(shù)據(jù)傳到服務(wù)器，他們的本質(zhì)都是發(fā)送請求和接收結(jié)果。只是組織格式和數(shù)據(jù)量上面有差別，http協(xié)議里面有介紹

2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看到。post是通過HTTP post機(jī)制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。 
因?yàn)間et設(shè)計成傳輸小數(shù)據(jù)，而且最好是不修改服務(wù)器的數(shù)據(jù)，所以瀏覽器一般都在地址欄里面可以看到，但post一般都用來傳遞大數(shù)據(jù)，或比較隱私的數(shù)據(jù)，所以在地址欄看不到，能不能看到不是協(xié)議規(guī)定，是瀏覽器規(guī)定的。
3. 對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。 
沒明白，怎么獲得變量和你的服務(wù)器有關(guān)，和get或post無關(guān)，服務(wù)器都對這些請求做了封裝
4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。 
post基本沒有限制，我想大家都上傳過文件，都是用post方式的。只不過要修改form里面的那個type參數(shù)
5. get安全性非常低，post安全性較高。 
如果沒有加密，他們安全級別都是一樣的，隨便一個監(jiān)聽器都可以把所有的數(shù)據(jù)監(jiān)聽到，不信你自己下一個監(jiān)聽網(wǎng)絡(luò)資源的軟件，

1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看到。post是通過HTTP post機(jī)制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。
4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。

建議：
1、get方式的安全性較Post方式要差些，包含機(jī)密信息的話，建議用Post數(shù)據(jù)提交方式；
2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式； Get：是以實(shí)體的方式得到由請求URI所指定資源的信息，如果請求URI只是一個數(shù)據(jù)產(chǎn)生過程，那么最終要在響應(yīng)實(shí)體中返回的是處理過程的結(jié)果所指向的資源，而不是處理過程的描述。

Post：用來向目的服務(wù)器發(fā)出請求，要求它接受被附在請求后的實(shí)體，并把它當(dāng)作請求隊列中請求URI所指定資源的附加新子項，Post被設(shè)計成用統(tǒng)一的方法實(shí)現(xiàn)下列功能：
1：對現(xiàn)有資源的解釋
2：向電子公告欄、新聞組、郵件列表或類似討論組發(fā)信息。
3：提交數(shù)據(jù)塊
4：通過附加操作來擴(kuò)展數(shù)據(jù)庫

從上面描述可以看出，Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求；而Post是向服務(wù)器提交數(shù)據(jù)的一種請求，要提交的數(shù)據(jù)位于信息頭后面的實(shí)體中。

get請求參數(shù)會在地址欄暴露，安全性不好，相反post請求不會將所傳參數(shù)暴露在地址欄中相對較安全。

get是從服務(wù)器中獲取參數(shù)，post是上傳數(shù)據(jù)。

get傳輸數(shù)據(jù)量小,主要是受URL長度的限制;post可以傳送大量數(shù)據(jù)，所以上傳文件只能用post。

get是form的默認(rèn)方法。

get限制form表單數(shù)據(jù)集必須是ASCII字符，而post支持整個ISO10646字符集。（編碼）

2、POST方法的底層機(jī)制是什么? - 技術(shù)問答

post雖然封裝了，但是并沒有加密，你抓到的數(shù)據(jù)包當(dāng)然可以看到post的內(nèi)容。這是http協(xié)議的設(shè)計，沒辦法。除非你用https加密，抓到的數(shù)據(jù)包都看不懂。get的url模式，直觀的說是指你可以訪問諸如test.php?id=110的地址來提交數(shù)據(jù)，用戶可以顯示的看到這個URL。 謝謝 yzhou86， yibin001，zwws，lxylxy888666POST數(shù)據(jù)是在http報文體內(nèi)的，GET方法的數(shù)據(jù)在URL的Query String里，經(jīng)HTTP Header的start line發(fā)送。很多教材都語焉不詳。 謝謝樓上。post數(shù)據(jù)不在頭部，而在請求主體第一行，是瀏覽器加上去的。 經(jīng)常做的事:用firebug調(diào)試ajax，在控制臺里就能看到post

3、get和post請求的區(qū)別

GET請求和POST請求的區(qū)別：

1、 get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。

2、 get請求時通過URL直接請求數(shù)據(jù)，數(shù)據(jù)信息可以在URL中直接看到，比如瀏覽器訪問；而post請求是放在請求頭中的，用戶無法直接看到。

3、 get傳送的數(shù)據(jù)量較小，有限制，不能大于2KB；這主要是因?yàn)樗芗s于URL長度的限制。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制，但理論上，IIS4中最大量為80KB，IIS5中為100KB。.....

4、get請求因?yàn)閿?shù)據(jù)參數(shù)是暴露在URL中的，所以安全性比較低，如密碼不能暴露的就不能用get請求；post請求中，請求信息是放在請求頭的，安全性較高，可以使用。

4、http請求中PUT GET POST區(qū)別?

GET 是將你的請求直接以網(wǎng)址連接發(fā)送出去(到服務(wù)器端) , 并後臺可能是靜態(tài)的 html 檔, 也可以是 cgi 的腳本, 如你這條問題的連結(jié)就是 http://zhidao.baidu.com/question/648362608116639645.html?entry=qb_ihome_tag <-- 這種就為之 GET
由於你給出的連接是"明顯"的, 所以在服務(wù)器端你要存取的整個連結(jié)都會被寫到 LOG 中, 所以, 你將不應(yīng)該用 GET 作為提交 ID / 密碼 的方式. GET 還有一個限制就是字串的請求長度為 8K 字節(jié)(BYTES)

POST 是將你表單中的內(nèi)容, 以二進(jìn)位式的串流發(fā)送到服務(wù)器端, 其對像大多數(shù)是 CGI 腳本 (當(dāng)然也有 mailto 之類 -- 啟動本地作業(yè) ). 絕大多數(shù)表單的提交都用 POST, 就像登入帳號, 你在這里發(fā)表提問, 都是用 POST 的形式進(jìn)行. 資料的傳送相對 GET 是 "不明顯的" ( 不會在 LOG 中看到你在表單里寫了甚麼 ), 相對 GET, POST 的長度可以上 MB ( 你可以在服務(wù)器內(nèi)自行設(shè)成多大都可以 )

PUT 跟 POST 也很相似, 但一般 (只是一般) 我們用 PUT 都是用來上傳一些小檔案, 且連結(jié)的位置就是檔案的位置 (亦即是, 你 PUT 到一個連結(jié)之後, 你就直接用 GET 的方法將這檔案下載回來), 例如 WebDAV ( 日歷卡服務(wù) ), 就很多時會用到 PUT, 但如果沒有相關(guān)的需要時, 一般在考慮到安全問題的方向下, 都會從服務(wù)器內(nèi)關(guān)掉接收這種請求 ( 其實(shí)還有 "DELETE", PUT 的反向動作 ). 1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看到。post是通過HTTP post機(jī)制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。
4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。

建議：
1、get方式的安全性較Post方式要差些，包含機(jī)密信息的話，建議用Post數(shù)據(jù)提交方式；
2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式；

5、客戶端請求方式get和post的區(qū)別

GET和POST是HTTP的兩個常用方法。

什么是HTTP?
超文本傳輸協(xié)議(HyperText Transfer Protocol -- HTTP)是一個設(shè)計來使客戶端和服務(wù)器順利進(jìn)行通訊的協(xié)議。
HTTP在客戶端和服務(wù)器之間以request-response protocol（請求-回復(fù)協(xié)議）工作。

GET - 從指定的服務(wù)器中獲取數(shù)據(jù)
POST - 提交數(shù)據(jù)給指定的服務(wù)器處理

GET方法：
使用GET方法時，查詢字符串（鍵值對）被附加在URL地址后面一起發(fā)送到服務(wù)器：
/test/demo_form.jsp?name1=value1&name2=value2
特點(diǎn)：
GET請求能夠被緩存
GET請求會保存在瀏覽器的瀏覽記錄中
以GET請求的URL能夠保存為瀏覽器書簽
GET請求有長度限制
GET請求主要用以獲取數(shù)據(jù)
POST方法：
使用POST方法時，查詢字符串在POST信息中單獨(dú)存在，和HTTP請求一起發(fā)送到服務(wù)器：
POST /test/demo_form.jsp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
特點(diǎn)：
POST請求不能被緩存下來
POST請求不會保存在瀏覽器瀏覽記錄中
以POST請求的URL無法保存為瀏覽器書簽
POST請求沒有長度限制
GET和POST的區(qū)別：
GET POST
點(diǎn)擊返回/刷新按鈕 沒有影響 數(shù)據(jù)會重新發(fā)送（瀏覽器將會提示用戶“數(shù)據(jù)被從新提交”）
添加書簽 可以 不可以
緩存 可以 不可以
編碼類型(Encoding type) application/x-www-form-urlencoded
application/x-www-form-urlencoded or multipart/form-data. 請為二進(jìn)制數(shù)據(jù)使用multipart編碼
歷史記錄 有 沒有
長度限制 有 沒有
數(shù)據(jù)類型限制 只允許ASCII字符類型 沒有限制。允許二進(jìn)制數(shù)據(jù)
安全性 查詢字符串會顯示在地址欄的URL中，不安全，請不要使用GET請求提交敏感數(shù)據(jù) 因?yàn)閿?shù)據(jù)不會顯示在地址欄中，也不會緩存下來或保存在瀏覽記錄中，所以看POST求情比GET請求安全，但也不是最安全的方式。如需要傳送敏感數(shù)據(jù)，請使用加密方式傳輸
可見性 查詢字符串顯示在地址欄的URL中，可見 查詢字符串不會顯示在地址欄中，不可見其他HTTP請求方式
方式 描述
HEAD 與GET請求類似，不同在與服務(wù)器只返回HTTP頭部信息，沒有頁面內(nèi)容
PUT 上傳指定URL的描述
DELETE 刪除指定資源
OPTIONS 返回服務(wù)器支持的HTTP方法
CONNECT 轉(zhuǎn)換為透明TCP/IP隧道的連接請求 get請求方式：
直接在瀏覽器地址輸入的訪問地址，或提交表單時，該表單對應(yīng)的form元素沒有設(shè)置method方式或者method方式為get，get方式的請求會將請求參數(shù)的名和值轉(zhuǎn)換成字符串，并附加在原rul之后，因此，可以在地址欄中看到請求參數(shù)名和值。且get請求方式傳送的數(shù)據(jù)量小，一般不能大于2kb
post請求方式：
通過表單提交，且需要設(shè)置form的元素為post。post方式傳送的數(shù)據(jù)量較大，取決于服務(wù)器的設(shè)置，post方式發(fā)送的請求參數(shù)以及對應(yīng)的值放在html header中傳輸，用戶不能在地址欄里看到請求參數(shù)之，安全性相對較高。
對比以上兩種參數(shù)傳遞方式，我們應(yīng)該采用post方式。

post請求方式處理非西歐字符：
必須在獲取請求參數(shù)之前先調(diào)用setCharacterEncoding方法設(shè)置編碼的字符集，因此當(dāng)發(fā)送請求的表單頁采用gb2312字符集
Jsp代碼
<%@ page language="java" contentType="text/html;charset="gb2312"%>
<html>
request.setCharacterEncoding("gb2312");
String name = request.getParameter("name");
String [] colors = request.getParamterValues("color");
<!--下面依次輸出表單域的值-->
您的名字：<%=name%>
您喜歡的顏色<%for(String c:colors){out.println(c+"");}%>
</html>

get請求方式處理非西歐字符：
在獲取請求參數(shù)值之后對請求參數(shù)值重新編碼，也就是將其轉(zhuǎn)換成字節(jié)數(shù)組，再將字節(jié)數(shù)組重新編碼成字符串
Jsp代碼
<%@ page language="java" contentType="text/html;charset="gb2312"%>
<html>
String rawName = request.getParametet("name");
bytes[] rawBytes = rawName.getBytes("ISO-8859-1");
String name = new String(rawBytes,"gb2312");
</html>

首先是"GET方式提交的數(shù)據(jù)最多只能是1024字節(jié)"，因?yàn)镚ET是通過URL提交數(shù)據(jù)，那么GET可提交的數(shù)據(jù)量就跟URL的長度有直接關(guān)系了。而實(shí)際上，URL不存在參數(shù)上限的問題，HTTP協(xié)議規(guī)范沒有對URL長度進(jìn)行限制。這個限制是特定的瀏覽器及服務(wù)器對它的限制。IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持　注意這是限制是整個URL長度，而不僅僅是你的參數(shù)值數(shù)據(jù)長度。

理論上講，POST是沒有大小限制的，HTTP協(xié)議規(guī)范也沒有進(jìn)行大小限制，說“POST數(shù)據(jù)量存在80K/100K的大小限制”是不準(zhǔn)確的，POST數(shù)據(jù)是沒有限制的，起限制作用的是服務(wù)器的處理程序的處理能力。

轉(zhuǎn)載請帶上網(wǎng)址：http://www.keemji.com/posjifour/236327.html