http請求詳解

標籤：http   io   os   使用   ar   for   檔案   資料   art   

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請求詳解