1、options：這個方法可使伺服器傳回該資源所支援的所有http
請求方法。用
'*'來代替資源名稱，向
web伺服器傳送
options
請求，可以測試伺服器功能是否正常運作。
2、head：與get
方法一樣，都是向伺服器發出指定資源的請求。只不過伺服器將不傳回資源的本文部份。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中「關於該資源的資訊」
(元資訊或稱元資料)。
3、get：向指定的資源發出「顯示」請求。使用get
方法應該只用在讀取資料，而不應當被用於產生「***」的操作中，例如在
中。其中乙個原因是
get可能會被網路蜘蛛等隨意訪問。參見安全方法
6、delete：請求伺服器刪除request-uri
所標識的資源。
7、trace：回顯伺服器收到的請求，主要用於測試或診斷。
8、connect： http/1.1協議中預留給能夠將連線改為管道方式的**伺服器。通常用於
ssl加密伺服器的鏈結
(經由非加密的
**伺服器)。
方法名 安全性 冪等性
get 是 是
head 是 是
options 是 是
delete 否 是
put 否 是
post 否 否
1、http請求方法的安全性指的是：server處理這些方法時，資源的一致性，穩定性等問題（資源狀態）。
2、http的冪等性指的是：不會改變資源的狀態，不論呼叫一次還是n
次都有相同的***。請注意，這裡強調的是一次和
n次具有相同的***，而不是每次請求的結果。本質上，冪等性的設計就是替代分布式事務的設計，通過增加乙個
id來解決事務過程的「衝突」。
3、可以認為安全的方法都是唯讀的方法(get, head, options)
，不會改變資源狀態，顯然，這三個方法也是冪等的。
4、delete方法是不安全的，但是是冪等的。
5、put和
post
方法語義中都有修改資源狀態的意思，因此都不是安全的。但是
put方法是冪等的，
post
方法不是冪等的，這麼設計的理由是：
協議規定，
post
方法修改資源狀態時，
url指示的是該資源的父級資源，待修改資源的
id資訊在請求體中攜帶。而
put方法修改資源狀態時，
url直接指示待修改資源。因此，同樣是建立資源，重複提交
post
請求可能產生兩個不同的資源，而重複提交
put請求只會對其
url中指定的資源起作用，也就是只會建立乙個資源。
1、get、
ead是獲取某資源，是安全的，等冪的，所有ua、
server
能夠快取相關資訊。
2、get、
head
提交資訊時，將資料放入到
url中，協議雖為限制其長度，不過一般不超過2k。
3、post 是對相關資源進行新增操作，是不安全，不等冪的，
server
不能快取相關資訊。
4、post 提交資訊是資料放在
實體中，長度受
server
配置的限制。
5、在通訊中get
的安全性較低，
post
的安全性較高。
HTTP協議之請求
http請求由三部分組成，分別是 請求行 訊息報頭 請求正文。1 請求行以乙個方法符號開頭，以空格分開，後面跟著請求的uri和協議的版本，格式如下 method request uri http version crlf，其中 method表示請求方法 request uri是乙個統一資源識別符號 ...
HTTP協議之請求
http請求由三部分組成，分別是 請求行 訊息報頭 請求正文。1 請求行以乙個方法符號開頭，以空格分開，後面跟著請求的uri和協議的版本，格式如下 method request uri http version crlf，其中 method表示請求方法 request uri是乙個統一資源識別符號 ...
HTTP協議之請求協議
請求首行 請求方式 請求路徑 協議和版本，例如 get index.html http 1.1 請求頭資訊 請求頭名稱 請求頭內容，即為key value 格式，例如 host localhost 空行 用來與請求體分隔開 請求體 get沒有請求體，只有post有請求體http預設請求方法為get請...