HTTP 303可以被其他HTTP方法接受嗎？

Question

RESTful Web Services鼓勵使用HTTP 303將客戶重定向到資源的規範表示形式。它僅在HTTP GET的背景下討論主題。

這是否也適用於其他HTTP方法？如果客戶端嘗試將HTTP PUT或DELETE添加到非規範URI中，是否可以接受（和/或推薦）返回HTTP 303？最佳做法是什麼？爲什麼？

Answer 1

此狀態碼通常適用於任何HTTP方法。它主要用於允許POST操作的輸出將用戶代理重定向到選定的資源，因爲這樣可以提供與POST響應相對應的信息，其形式可以獨立於原始文件單獨標識，加書籤和緩存請求。

來源：http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-7.4.4

Answer 2

我剛在書中發現了一個有趣的部分。根據頁378部分302 ("Found")：

此狀態碼是大多數重定向相關混淆的最終來源。它應該像307一樣處理（「臨時重定向」）。事實上，在HTTP 1.0中，它的名字 是「Moved Temporarily」。不幸的是，在現實生活中，大多數客戶處理302就像 303（「See Other」）。區別取決於當客戶端 獲得302響應於PUT，POST或DELETE請求時應該執行的操作。如果您對細節感興趣，請參閱下方的條目 。

要解決這種歧義問題，在HTTP 1.1中，此響應代碼被重命名爲「找到」，並且創建了響應代碼307。

換句話說，HTTP 302分成HTTP 303和307 接下來，頁380節307 ("Temporary Redirect")：

對於GET請求，在被請求的唯一的事情就是服務器發送表示形式，此狀態代碼與303（「See Other」）相同。一種典型的情況是，當服務器想要將客戶端發送到鏡像站點時，對GET的響應很好。 但對於POST，PUT和DELETE請求，其中，服務器預計將採取一些行動 響應該請求，這個狀態代碼是303

A 303顯著不同的響應POST ，PUT或DELETE表示操作已成功 ，但響應實體主體未與此請求一起發送。如果客戶端 想要響應實體主體，它需要對另一個URI發出GET請求。 響應POST，PUT或DELETE的307表示服務器甚至沒有嘗試 來執行操作。客戶端需要將整個請求重新提交到 的Location標頭中的URI。

換句話說，HTTP POST，PUT，DELETE上HTTP 303,307法律。以上段落解釋了預期的行爲。這就是說，我在這裏引用這本書，而不是HTTP規範（對於預期的行爲可疑地保持沉默）。