關於HTTP報文請求方法和狀態響應碼
1. Method
請求方法，表明客戶端希望伺服器對資源執行的動作；
1.1 GET
向伺服器請求資源。
1.2 HEAD
和GET方法的行為類似，但伺服器在響應中只返回首部，不會返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。
可以做到：
- 不獲取資源的情況下了解資源的情況(比如，判斷器型別)
- 通過檢視響應中的狀態碼，看看某個物件是否存在；
- 通過檢視首部，測試資源是否被修改了；
1.3 PUT
與GET從伺服器讀取檔案相反，PUT方法迴向伺服器寫入檔案。有些釋出系統允許使用者建立WEB頁面，並用PUT直接將其安裝到WEB伺服器上；
PUT方法的語義就是讓伺服器用請求的主體部分來建立一個由所請求的URL命令的新文件，或者如果那個URL已經存在的話，就用這個主體來代替它；
因為PUT允許使用者對內容進行修改，所以很多WEB伺服器都要求在執行PUT之前，用密碼登入。
1.4 POST
向伺服器傳送要處理的資料；
一般伺服器通常提供一個表單，客戶端填入資料後點擊提交(提交是資料都會放在請求報文的實體部分當中)，然後由伺服器將其傳送到它要去的地方（比如，送到一個伺服器的閘道器程式中，然後由這個程式對其進行處理）；
1.5 TRACE
客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、閘道器或其他一些應用程式。每個中間節點都可能會修改原始的HTTP請求。TRACE方法允許客戶端在最終將請求發給伺服器時，看看它變成了什麼樣子；
TRACE請求會在目的伺服器發起一個“環回”針對。行程最後一站的伺服器會彈出一條TRACE響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以檢視所有中間HTTP應用程式組成的請求/響應鏈上，原始包文是否,以及如何被毀壞或修改過；
TRACE方法主要用於診斷；也就是說，用於驗證請求是否如願的穿過了請求/響應鏈。它是一種很好的工具，可以用來檢視代理和其他應用程式對使用者請求所產生的效果。
儘管TRACE可以很方便的用於診斷，但是它確實也有缺點，它假定中間應用程式對各種不同型別請求（GET、HEAD、POST等）的處理是相同的。很多HTTP應用程式會根據方法的不同做出不同的事情，比如，代理可能會將POST請求直接發給伺服器，而將GET請求傳送給另一個HTTP應用程式（比如WEB快取）。TRACE並不提供區分這些方法的機制。通常，中間應用程式會自行決定對TRACE請求的處理方式。
TRACE請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應伺服器收到的請求的精確副本。
1.6 DELETE
DELETE方法所做的事情就是請求伺服器刪除請求URL所指定的資源。但是客戶端應用程式無法保證刪除操作一定會被執行。因為HTTP規範允許伺服器在不通知客戶端的情況下撤銷請求。
1.7 擴充套件方法
2 狀態返回碼
1xx：100-101, （額外）資訊提示類的狀態碼；
2xx：200-206, 成功類的狀態碼；
3xx：300-305, 重定向類的狀態碼；沒有把請求的頁面響應給客戶端，而是重定向到其它地方，或是無需獲取此資源；
4xx：400-415, 錯誤類資訊，客戶端的錯誤類的狀態碼；例如請求不存在的資源；
5xx：500-505, 錯誤類資訊，伺服器端錯誤類的狀態碼；例如伺服器內部的問題，因為資源有語法錯誤執行部成功，無法響應，不是資源不存在；
2.1 200~299--成功狀態碼
200：OK
成功，請求的所有資料通過響應報文的entity-body部分發送；原因短語為OK；
201：Created
用於建立伺服器物件的請求（比如，PUT）。響應實體主體部分中應該包含各種引用了已建立的資源的URL。Location首部包含的則是最具體的引用。伺服器必須在傳送這個狀態碼之前建立好物件；
202：Accepted
請求已被接受，但伺服器還未對其執行任何動作。不能保證伺服器會完成這個請求；這只是意味著接受請求時，他看起來是有效的。伺服器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計（或者包含一個指標，指向可以獲取此資訊的位置）；
203：Non-Authoritative Information
實體首部包含的資訊不是來自於源端伺服器，而是來自資源的一份副本。如果中間節點上有一份資源副本，但無法或者沒有對它所傳送的與資源有關的原資訊（首部）進行驗證，就會出現這種情況；
這種響應嗎並不是非用不可的；如果實體首部來自源端伺服器，相應為200狀態的應用程式就可以將其作為一種可選項使用；
204：No Content
響應報文中包含若干首部和一個狀態行，但沒有實體的主體部分。主要用於在瀏覽器不轉為顯示新文件的情況下，對其進行更新（比如重新整理一個表單頁面）；
205：Rest Content
另一個主要用於瀏覽器的程式碼。負責告知瀏覽器清除當前頁面中的所有HTML表單元素；
206：Partial Content
成功執行了一個部分或Range（範圍）請求。客戶端可以通過一些特殊的首部來獲取部分或某個範圍內的文件--這個狀態碼就說明範文請求成功了；
206相應中必須包含Content-Range、Date以及ETag或Content-Location首部；
2.2 300~399--重定向狀態碼
可以通過某些重定向狀態碼對瀏覽器本地快取的資源副本與遠端伺服器上的資源進行驗證。比如：用來檢視本地的副本是否仍為最新的，或者遠端伺服器上的資源是否被修改過；
下圖是客戶端傳送了一個特殊的if-Modified-Since首部，說明會讀取1997年10月之後修改過的文件。因為這個日期之後，此文件並未修改過，因此，伺服器回送了一個304狀態碼，而不是文件的內容；
300：Multiple Choices
客戶端請求一個實際指向多個資源的URL時就會返回這個狀態碼，比如伺服器上有某個HTML文件的英語和法語版本。返回這個程式碼時會帶有一個選項列表；這樣使用者就可以選擇他希望使用的那一項了。
301：Move Permanently
請求的URL指向的資源已經被刪除（移動到其它位置）是永久重定向，資源被永久刪除；但在響應報文中通過首部Location指明瞭資源現在所處的新位置；原因短語為Moved Permanently；
302：Found
與301相似，但在響應報文中通過Location指明資源現在所處臨時新位置，資源不是永久刪除，是臨時重定向; 原因短語為Found；
303：See Other
告知客戶端應該用另一個URL來獲取資源。新的URL位於響應報文的Location首部。其主要目的是允許POST請求的響應將客戶端定向到某個資源上去；
304：Not Modified
客戶端發出了條件式請求，但伺服器上的資源未曾發生改變，則通過通過此響應狀態碼通知客戶端（帶有這個狀態碼的響應不應該包含實體的主體部分），客戶端可繼續使用本地網頁快取；原因短語為Not Modified；
305：Use Proxy
用來說明必須通過一個代理來訪問資源；代理的位置有Location首部給出。
很重要的一點是，客戶端只是對某個特定資源來解析這條響應的；而不是對所有請求，甚至所有具有相同資源的伺服器都通過這個代理進行；如果客戶端錯誤的讓代理介入了某個請求，可能會引發破壞性的行為，而且會造成安全漏洞；
306：未使用
307：Temporary Redirect
與301程式碼類似；但客戶端應該使用Location首部給出URL來臨時定位資源。將來的請求還使用老的URL；
注意：
302、303、307狀態碼之間存在一些交叉。這些狀態碼的用法有細微的區別，大部分區別都源於HTTP/1.0和HTTP/1.1應用程式對這些狀態碼處理方式的不同。
當HTTP/1.0客戶端發起一個POST請求，並在響應中收到302重定向狀態碼時，它會接受Location首部的重定向URL，並向那個URL發起一個GET請求（而不會向原始請求中那樣發起POST請求）。
HTTP/1.0伺服器希望HTTP/1.0客戶端這麼做---如果HTTP/1.0伺服器收到來自HTTP/1.0客戶端的POST請求之後傳送了302狀態碼，伺服器就期望客戶端能夠接受重定向URL，並向重定向的URL傳送一個GET請求；
問題出在HTTP/1.1。HTTP/1.1規範您使用了303狀態碼來實現同樣的行為（伺服器傳送303狀態碼來重定向客戶端的POST請求，在它後面跟上一個GET請求）。
為避開這個問題，HTTP/1.1規範指出，對於HTTP/1.1客戶端，用307狀態碼取代302狀態碼來進行臨時重定向。這樣伺服器就可以將302狀態碼保留起來，為HTTP/1.0客戶端使用。
這樣一來，伺服器要選擇適當的重定向狀態碼放入重定向響應中傳送，就需要檢視客戶端的HTTP版本了。
2.3 400~499--客戶端錯誤狀態碼
400：Bad Request
告知客戶端它傳送了一個錯誤的請求；
401：Unauthorized
與適當的首部一同返回，在這些首部中要求客戶端在訪問資源之前，需要進行認證（如基於basic認證時就是401）。
402：Payment Required
保留
403：Forbidden
用於說明請求被伺服器拒絕了。如果伺服器想說明為什麼拒絕請求，可以在包含請求實體的主體部分來對原因進行描述。但這個狀態碼通常是在伺服器不想說明拒絕原因的時候使用的；
404：Not Found
用於說明伺服器無法找到所請求的URL。通常會包含一個實體，以便客戶端應用程式顯示給使用者看；
405：Methord Not Allowed
發起的請求中帶有所請求的URL不支援的方法時，使用此狀態嗎。應該在響應中包含Allow首部，已告知客戶端對所請求資源可以使用哪些方法。
406：Not Acceptable
客���端可以指定引數來說明它們願意接受什麼型別的實體。伺服器沒有與客戶端可接受的URL相匹配的資源時，使用此程式碼。通常，伺服器會包含一些首部，以便客戶端弄清楚為什麼請求無法滿足。
407：Porxy Authentication Required
與401狀態碼類似，但用於要求對資源進行認證的代理伺服器；
408：Request Timeout
如果客戶端完成請求所花的時間太長，伺服器可以回送此狀態碼，並關閉連線。超時時長隨著伺服器的不同有所不同，但通常對所有的合法請求來說，都是夠長的；
409：Conflict
用於說明請求可能在資源上引發的一些衝突。伺服器擔心請求會引發衝突時，可以傳送此狀態碼。響應中應該包含描述衝突的主體；
410：Gone
與404類似，只是伺服器曾經擁有過此資源。主要用於WEB站點的維護，這樣伺服器的管理員就可以在資源被移除的情況下通知客戶端了；
412：Precondition Failed
客戶端發起了條件請求，且其中一個條件失敗了的時候使用。客戶端包含了Expect首部時就是條件請求。
413：Request Entity Too Large
客戶端傳送的實體主體部分比伺服器能夠或希望處理的要大時，使用此狀態；
414：Request URI Too Long
客戶端所傳送的請求中請求的URL比伺服器能夠或者希望處理的要長時，使用此狀態碼；
415：Unsupported Media Type
伺服器無法理解或無法支援客戶端所發實體的內容型別時，使用此狀態碼；
416：Requested Range Not Satisfiable
請求報文所請求的是指定資源的某個範圍，而此範圍無效或無法滿足時，使用此狀態碼；
417：Expectation Failed
請求的Expect請求首部包含了一個期望，但伺服器無法滿足此期望時，使用此狀態碼。
如果代理或其他中間應用程式有確切證據說明源端伺服器會為其請求產生一個失敗的期望，就可以傳送這個響應狀態碼
2.4 500~599--伺服器錯誤狀態碼
500：Internal Server Error
伺服器內部錯誤。
501：Not Implemented
客戶端發起的請求超出了伺服器的能力範圍（比如，使用了伺服器不支援到的請求方法）。
502：Bad Gateway
作為代理或閘道器使用的伺服器從請求相應鏈的下一跳鏈路上收到了一條偽相應（比如，它無法連線到其父閘道器）。
503：Service Unavailable
用來說明伺服器現在無法為請求提供服務，但撿來可以。如果伺服器知道什麼時候資源會變為可用的，可用在響應中包含一個Retry-After首部。
504：Gateway Timout
與狀態碼408類似，只是這裡的響應來自一個閘道器或代理，他們在等待另一個伺服器對其請求的進行響應時超時了。
505：HTTP Version Not Supported
伺服器收到了請求，是它無法或不願支援的協議版本時，使用此狀態碼（有些伺服器應用程式會選擇不支援協議的早期版本）。
Linux公社的RSS地址 ： ofollow,noindex" target="_blank">https://www.linuxidc.com/rssFeed.aspx
本文永久更新連結地址： https://www.linuxidc.com/Linux/2018-12/155656.htm