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方法，此方法是為了能用於能動態切換到隧道的**
HTTP請求方法詳解
1 get獲取資源 用來請求已經被 uri所標識的資源 要查詢的內容需要用encodeurlcomponent 進行編碼 2 post傳輸實體文字在 uri所標識的資源後附加新的資料 3 head獲取報文首部 用來請求已經被 uri所標識的資源的響應訊息報頭 4 put傳輸檔案 傳輸檔案，要求在請求...
HTTP請求方法詳解
http請求方法詳解 請求方法 指定了客戶端想對指定的資源 伺服器作何種操作 下面我們介紹http 1.1中可用的請求方法 get 獲取資源 get方法用來請求已被uri識別的資源。指定的資源經伺服器端解析後返回響應內容 也就是說，如果請求的資源是文字，那就保持原樣返回 如果是cgi 通用閘道器介面...
詳解 HTTP協議 （三） HTTP 請求方法
http 請求方法 根據http標準，http請求可以使用多種請求方法 方法 描述get 請求指定頁面資訊，返回實體主體 head 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 post 向指定資源提交資料進行處理請求 例如提交表單或者上傳檔案 資料被包含在請求體中。post請求...