簡述HTTP報文請求方法和狀態響應碼
1. Method
請求方法，表明客戶端希望服務器對資源執行的動作；
1.1. GET
向服務器請求資源。
1.2 HEAD
和GET方法的行為類似，但服務器在響應中只返回首部，不會返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。
可以做到：
- 不獲取資源的情況下了解資源的情況(比如，判斷器類型)
- 通過查看響應中的狀態碼，看看某個對象是否存在；
- 通過查看首部，測試資源是否被修改了；
1.3. PUT
與GET從服務器讀取文件相反，PUT方法回向服務器寫入文件。有些發布系統允許用戶創建WEB頁面，並用PUT直接將其安裝到WEB服務器上；
PUT方法的語義就是讓服務器用請求的主體部分來創建一個由所請求的URL命令的新文檔，或者如果那個URL已經存在的話，就用這個主體來代替它；
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
服務器收到了請求，是它無法或不願支持的協議版本時，使用此狀態碼（有些服務器應用程序會選擇不支持協議的早期版本）。
簡述HTTP報文請求方法和狀態響應碼