HTTP請求方式

　　以下內容綜合整理來自如下列連線的資料：

　　當瀏覽器向Web伺服器發出請求時，它向伺服器傳遞了一個數據塊，也就是請求資訊，HTTP請求資訊由3部分組成：

　　1).請求方法URI協議/版本

　　2).請求頭(Request Header)

　　3).請求正文

　　下面是一個HTTP請求的例子：

　　// 請求方法uri, 協議、版本

　　GET/sample.jsp HTTP/1.1

　　//  請求頭

　　Accept:image/gif.image/jpeg,*/*

　　Accept-Language:zh-cn

　　Connection:Keep-Alive

　　Host:localhost

　　User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

　　Accept-Encoding:gzip,deflate

　　// 請求正文

　　username=jinqiao&password=1234

　　（1）請求方法URI協議/版本

　　請求的第一行是“方法URL議/版本”：GET/sample.jsp HTTP/1.1

　　以上程式碼中“GET”代表請求方法，“/sample.jsp”表示URI，“HTTP/1.1代表協議和協議的版本。

　　根據HTTP標準，HTTP請求可以使用多種請求方法。例如：HTTP1.1目前支援7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。

　　GET          請求獲取由Request-URI所標識的資源。
POST        在Request-URI所標識的資源後附加新的資料，給伺服器提交資料。
HEAD        請求獲取由Request-URI所標識的資源的響應訊息報頭。

　　OPTIONS 請求查詢伺服器的效能，或查詢與資源相關的選項和需求。
PUT           請求伺服器儲存一個資源，並用Request-URI作為其標識。
DELETE    請求伺服器刪除由Request-URI所標識的資源。
TRACE      請求伺服器回送收到的請求資訊，主要用語測試或診斷。

　　
在Internet應用中，最常用的方法是GET和POST。

　　URI完整地指定了要訪問的網路資源，通常只要給出相對於伺服器的根目錄的相對目錄即可，因此總是以“/”開頭，最後，協議版本聲明瞭通訊過程中使用HTTP的版本。

　　（2）請求頭(Request Header)

　　請求頭包含許多有關的客戶端環境和請求正文的有用資訊。例如，請求頭可以宣告瀏覽器所用的語言，請求正文的長度等。

　　Accept:image/gif.image/jpeg.*/*

　　Accept-Language:zh-cn

　　Connection:Keep-Alive

　　Host:localhost

　　User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)

　　Accept-Encoding:gzip,deflate.

　　（3）請求正文

　　請求頭和請求正文之間是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中可以包含客戶提交的查詢字串資訊：

　　username=jinqiao&password=1234

　　在以上的例子的HTTP請求中，請求的正文只有一行內容。當然，在實際應用中，HTTP請求正文可以包含更多的內容。

　　HTTP請求方法我這裡只討論GET方法與POST方法

　　GET方法

　　GET方法是預設的HTTP請求方法，我們日常用GET方法來提交表單資料，然而用GET方法提交的表單資料只經過了簡單的編碼，同時它將作為URL的一部分向Web伺服器傳送，因此，如果使用GET方法來提交表單資料就存在著安全隱患上。例如

　　Http://127.0.0.1/login.jsp Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB

　　從上面的URL請求中，很容易就可以辯認出表單提交的內容。（？之後的內容）另外由於GET方法提交的資料是作為URL請求的一部分所以提交的資料量不能太大

　　POST方法

　　POST方法是GET方法的一個替代方法，它主要是向Web伺服器提交表單資料，尤其是大批量的資料。POST方法克服了GET方法的一些缺點。通過POST方法提交表單資料時，資料不是作為URL請求的一部分而是作為標準資料傳送給Web伺服器，這就克服了GET方法中的資訊無法保密和資料量太小的缺點。因此，出於安全的考慮以及對使用者隱私的尊重，通常表單提交時採用POST方法。

　　從程式設計的角度來講，如果使用者通過GET方法提交資料，則資料存放在QUERY＿STRING環境變數中，而POST方法提交的資料則可以從標準輸入流中獲取。

http響應格式

　　HTTP應答與HTTP請求相似，HTTP響應也由3個部分構成，分別是：

　　1　狀態行

　　2　響應頭(Response Header)

　　3　響應正文

　　在接收和解釋請求訊息後，伺服器會返回一個HTTP響應訊息。

　　狀態行由協議版本、數字形式的狀態程式碼、及相應的狀態描述，各元素之間以空格分隔。

　　格式:   HTTP-Version Status-Code Reason-Phrase CRLF

　　例如:   HTTP/1.1 200 OK \r\n

狀態程式碼：

　　狀態程式碼由3位數字組成，表示請求是否被理解或被滿足。

　　狀態描述：

　　狀態描述給出了關於狀態程式碼的簡短的文字描述。

　　狀態程式碼的第一個數字定義了響應的類別，後面兩位沒有具體的分類。

　　第一個數字有五種可能的取值：

　　- 1xx:  指示資訊—表示請求已接收，繼續處理。

　　- 2xx:  成功—表示請求已經被成功接收、理解、接受。

　　- 3xx:  重定向—要完成請求必須進行更進一步的操作。

　　- 4xx:  客戶端錯誤—請求有語法錯誤或請求無法實現。

　　- 5xx:伺服器端錯誤—伺服器未能實現合法的請求。

　　狀態程式碼狀態描述   說明

　　200      OK   客戶端請求成功

　　400         Bad Request  由於客戶端請求有語法錯誤，不能被伺服器所理解。

　　401         Unauthonzed  請求未經授權。這個狀態程式碼必須和WWW-Authenticate報頭域一起使用

　　403   Forbidden  伺服器收到請求，但是拒絕提供服務。伺服器通常會在響應正文中給出不提供服務的原因

　　404   Not Found  請求的資源不存在，例如，輸入了錯誤的URL。

　　500     Internal Server Error 伺服器發生不可預期的錯誤，導致無法完成客戶端的請求。

　　503      Service Unavailable  伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常。

　　響應頭

　　響應頭可能包括：

　　Location：

　　Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，伺服器端可以發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的伺服器上的資源。當我們在JSP中使用重定向語句的時候，伺服器端向客戶端發回的響應報頭中，就會有Location響應報頭域。

　　Server：

　　Server響應報頭域包含了伺服器用來處理請求的軟體資訊。它和User-Agent請求報頭域是相對應的，前者傳送伺服器端軟體的資訊，後者傳送客戶端軟體(瀏覽器)和作業系統的資訊。下面是Server響應報頭域的一個例子：Server: Apache-Coyote/1.1

　　WWW-Authenticate：

　　WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應訊息中，這個報頭域和前面講到的Authorization請求報頭域是相關的，當客戶端收到401響應訊息，就要決定是否請求伺服器對其進行驗證。如果要求伺服器對其進行驗證，就可以傳送一個包含了 Authorization報頭域的請求，下面是WWW-Authenticate響應報頭域的一個例子：WWW-Authenticate: Basic realm="Basic Auth Test!"

　　從這個響應報頭域，可以知道伺服器端對我們所請求的資源採用的是基本驗證機制。

　　Content-Encoding：

　　Content-Encoding實體報頭域被使用作媒體型別的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，因而要獲得Content- Type報頭域中所引用的媒體型別，必須採用相應的解碼機制。Content-Encoding主要用語記錄文件的壓縮方法，下面是它的一個例子： Content-Encoding: gzip。如果一個實體正文采用了編碼方式儲存，在使用之前就必須進行解碼。

　　Content-Language：

　　Content-Language實體報頭域描述了資源所用的自然語言。Content-Language允許使用者遵照自身的首選語言來識別和區分實體。如果這個實體內容僅僅打算提供給丹麥的閱讀者，那麼可以按照如下的方式設定這個實體報頭域：Content-Language: da。

　　如果沒有指定Content-Language報頭域，那麼實體內容將提供給所以語言的閱讀者。

　　Content-Length：

　　Content-Length實體報頭域用於指明正文的長度，以位元組方式儲存的十進位制數字來表示，也就是一個數字字元佔一個位元組，用其對應的ASCII碼儲存傳輸。

　　要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。

　　Content-Type

　　Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體型別。例如：

　　Content-Type: text/html;charset=ISO-8859-1

　　Content-Type: text/html;charset=GB2312

　　Last-Modified

　　Last-Modified實體報頭域用於指示資源最後的修改日期及時間。

　　Expires

　　Expires實體報頭域給出響應過期的日期和時間。通常，代理伺服器或瀏覽器會快取一些頁面。當用戶再次訪問這些頁面時，直接從快取中載入並顯示給使用者，這樣縮短了響應的時間，減少伺服器的負載。為了讓代理伺服器或瀏覽器在一段時間後更新頁面，我們可以使用Expires實體報頭域指定頁面過期的時間。當用戶又一次訪問頁面時，如果Expires報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早(或相同)，那麼代理伺服器或瀏覽器就不會再使用快取的頁面而是從伺服器上請求更新的頁面。不過要注意，即使頁面過期了，也並不意味著伺服器上的原始資源在此時間之前或之後發生了改變。

　　Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式，例如：

　　Expires: Thu, 15 Sep 2005 16:00:00 GMT

　　HTTP1.1的客戶端和快取必須將其他非法的日期格式(也包括0)看作已過期。例如，為了讓瀏覽器不要快取頁面，我們也可以利用Expires實體報頭域，設定它的值為0，如下(JSP)：response.setDateHeader("Expires",0);

　　下面是一個HTTP響應的例子：

　　HTTP/1.1 200 OK

　　Server:Apache Tomcat/5.0.12

　　Date:Mon,6Oct2003 13:23:42 GMT

　　Content-Length:112

Get請求與Post請求的區別

　　Http方法：Get請求與Post請求的區別
Get是向伺服器發索取資料的一種請求，而Post是向伺服器提交資料的一種請求
Get是獲取資訊，而不是修改資訊，類似資料庫查詢功能一樣，資料不會被修改
Get請求的引數會跟在url後進行傳遞，請求的資料會附在URL之後，以 分割URL和傳輸資料，引數之間以&相連,％XX中的XX為該符號以16進製表示的ASCII，如果資料是英文字母/數字，原樣傳送，如果是空格，轉換為+，如果是中文/其他字元，則直接把字串用BASE64加密。
Get傳輸的資料有大小限制，因為GET是通過URL提交資料，那麼GET可提交的資料量就跟URL的長度有直接關係了，不同的瀏覽器對URL的長度的限制是不同的。

　　GET請求的資料會被瀏覽器快取起來，使用者名稱和密碼將明文出現在URL上，其他人可以查到歷史瀏覽記錄，資料不太安全。在伺服器端，用Request.QueryString來獲取Get方式提交來的資料

　　Post請求則作為http訊息的實際內容傳送給web伺服器，資料放置在HTML Header內提交，Post沒有限制提交的資料。Post比Get安全，當資料是中文或者不敏感的資料，則用get，因為使用get，引數會顯示在地址，對於敏感資料和不是中文字元的資料，則用post
POST表示可能修改變伺服器上的資源的請求，在伺服器端，用Post方式提交的資料只能用Request.Form來獲取

HTTP常用請求方法詳解

　　GET

　　GET方法意思是獲取被請求URI（Request-URI）指定的資訊（以實體的格式）。如果請求
URI涉及到一個數據生成過程，那麼這個過程生成的資料應該被作為實體在響應中返回而不是
過程的源文字，除非源文字恰好是過程的輸出。
     如果請求訊息包含 If-Modified-Since,，If-Unmodified-Since，If-Match，If-None-Match 或者
If-Range頭域，GET的語義將變成“條件（conditionall） GET”。一個條件GET方法會請求滿
足條件頭域的實體。條件GET方法的目的是為了減少不必要的網路使用，這通過允許利用快取
裡仍然保鮮的實體而不用多次請求或傳輸客戶端已經擁有的實體來實現的。.
如果請求方法包含一個Range頭域，那麼GET方法就變成“部分Get”（partial GET）方法。
一個部分GET會請求實體的一部分，這在14.35節裡描述了。 部分GET方法的目的是為了減
少不必要的網路使用，可以允許客戶端從伺服器獲取實體的部分資料，而不需要獲取客戶端本
地已經擁有的部分實體資料。
GET請求的響應是可快取的（cacheable）如果此響應滿足第13節HTTP快取的要求。
看15.1.3節關於GET請求用於表單時安全考慮。

　　HEAD

　　HEAD 方法和GET 方法一致，除了伺服器不能在響應裡返回訊息主體。HEAD請求響應裡
HTTP頭域裡的元資訊（譯註：元資訊就是頭域資訊）應該和GET請求響應裡的元資訊一致。
此方法被用來獲取請求實體的元資訊而不需要傳輸實體主體（entity-body）。此方法經常被用
來測試超文字連結的有效性，可訪問性，和最近的改變。.
HEAD請求的響應是可快取的，因為響應裡的資訊可能被快取用於更新以前那個資源對應快取
的實體.。如果出現一個新的域值指明快取的實體和當前源伺服器上的實體有所不同（可能因為
Content-Length，Content-MD5，ETag或Last-Modified值的改變），那麼快取（cache）必
須認為快取項是過時的（stale）。

　　POST

　　POST 方法被用於請求源伺服器接受請求中的實體作為請求資源的一個新的從屬物。POST被
設計涵蓋下面的功能。
--已存在的資源的註釋；
--釋出訊息給一個佈告板，新聞組，郵件列表，或者相似的文章組。
--提供一個數據塊，如提交一個表單給一個數據處理過程。
--通過追加操作來擴充套件資料庫。
POST方法的實際功能是由伺服器決定的，並且經常依賴於請求URI（Request-URI）。POST
提交的實體是請求URI的從屬物，就好像一個檔案從屬於一個目錄，一篇新聞文章從屬於一個
新聞組，或者一條記錄從屬於一個數據庫。
POST方法執行的動作可能不會對請求URI所指的資源起作用。在這種情況下，200（成功）或
者204（沒有內容）將是適合的響應狀態，這依賴於響應是否包含一個描述結果的實體。
如果資源被源伺服器建立，響應應該是201（Created）並且包含一個實體，此實體描述了請
求的狀態。並且引用了這個新資源和一個Location頭域（見14.30節）。
POST方法的響應是不可快取的。除非響應裡有合適的Cache-Control或者Expires頭域。然而，
303（見其他）響應能被使用者代理利用去獲得可快取的響應。
POST 請求必須遵循8.2節裡指明的訊息傳送的要求。
參見15.1.3節關於安全性的考慮.

　　PUT

　　PUT方法請求伺服器去把請求裡的實體儲存在請求URI（Request-URI）標識下。如果請求
URI（Request-URI）指定的的資源已經在源伺服器上存在，那麼此請求裡的實體應該被當作
是源伺服器關於此URI所指定資源實體的最新修改版本。如果請求URI（Request-URI）指定
的資源不存在，並且此URI被使用者代理定義為一個新資源，那麼源伺服器就應該根據請求裡的
實體建立一個此URI所標識下的資源。如果一個新的資源被建立了，源伺服器必須能向用戶代
理（user agent） 傳送201（已建立）響應。如果已存在的資源被改變了，那麼源伺服器應該
傳送200（Ok）或者204（無內容）響應。如果資源不能根據請求URI建立或者改變，一個合
適的錯誤響應應該給出以反應問題的性質。實體的接收者不能忽略任何它不理解和不能實現的
Content-*（如：Content-Range）頭域，並且必須返回501（沒有被實現）響應。
如果請求穿過一個快取（cache），並且此請求URI（Request-URI）指示了一個或多個當前
快取的實體，那麼這些實體應該被看作是舊的。PUT方法的響應是不可快取的。
POST方法和PUT方法請求最根本的區別是請求URI（Request-URI）的含義不同。POST請
求裡的URI 指示一個能處理請求實體的資源（譯註：此資源可能是一段程式，如jsp 裡的
servlet） 。此資源可能是一個數據接收過程，一個閘道器（gateway，譯註：閘道器和代理的區別
是：閘道器可以進行協議轉換，而代理不能，只是起代理的作用，比如快取伺服器其實就是一個
代理），或者一個單獨接收註釋的實體。對比而言，PUT方法請求裡的URI標識請求裡封裝的
實體一一使用者代理知道URI 意指什麼，並且伺服器不能把此請求應用於其它資源
（resource）。如果伺服器期望請求被應用於一個不同的URI，那麼它必須傳送301（永久移
動）響應；使用者代理可以自己決定是否重定向請求。
一個單獨的資源可能會被許多不同的URI指定。如：一篇文章可能會有一個URI指定當前版本，
而這個URI區別於這篇文章其它特殊版本的URI。這種情況下，對一個通用URI的PUT請求可
能會導致其資源的其它URI請求被源伺服器重定義。
HTTP/1.1沒有定義PUT方法對源伺服器的狀態影響。
PUT請求必須遵循8.2節中的訊息傳送的要求。
除非特別指出，PUT方法請求裡的實體頭域應該被用於資源的建立或修改。

　　DELETE（刪除）

　　DELETE方法請求源伺服器刪除請求URI指定的資源。此方法可能會在源伺服器上被人為的幹
涉（或通過其他方法）。客戶端不能保證此操作能被執行，即使源伺服器返回成功狀態碼。然而，
伺服器不應該指明成功除非它打算刪除資源或把此資源移到一個不可訪問的位置。
如果響應裡包含描述成功的實體，響應應該是200（OK）；如果DELETE動作還沒有執行，
應該以202（已接受）響應；如果DELETE請求方法已經執行但響應不包含實體，那麼應該以
204（無內容）響應。
如果請求穿過快取，並且請求URI（Request-URI）指定了一個或多個快取當前實體，那麼這
些快取項應該被認為是舊的。DELETE方法的響應是不能被快取的。

　　TRACE

　　TRACE方法被用於激發一個遠端的，應用層的請求訊息迴路（譯註：TRACE方法讓客戶端測
試到伺服器的網路通路，迴路的意思如傳送一個請返回一個響應，這就是一個請求響應迴路，）。

　　最後的接收者也許是源伺服器，也許是接收到包含Max-Forwards頭域值為0請求的代理
或閘道器。TRACE請求不能包含一個實體。
TRACE方法允許客戶端去了解資料被請求鏈的另一端接收的情況，並且利用那些資料資訊去
測試或診斷。Via頭域值（見14.45）有特殊的用途，因為它可以作為請求鏈的跟蹤資訊。利用
Max-Forwards頭域允許客戶端限制請求鏈的長度，這是非常有用的，因為可以利用此去測試代
理鏈在無限迴圈裡轉發訊息。
如果請求是有效的，響應應該在實體主體裡包含整個請求訊息，並且響應應該包含一個
Content-Type頭域值為”message/http”的頭域。此方法的響應不能被快取。

　　CONNECT（連線）

　　HTTP1.1 協議規範保留了CONNECT方法，此方法是為了能用於能動態切換到隧道的代理