HTTP 303是否可以接受其他HTTP方法？

Question

RESTful Web服务鼓励使用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 中，它的名称是“临时移动”。不幸的是，在现实生活中，大多数客户端处理 302 就像 303（“查看其他”）。区别取决于客户端在响应PUT、POST 或 DELETE请求时收到 302 时应该做什么。如果您对详细信息感兴趣，请参阅下面的 307 条目。

为了解决这个歧义，在 HTTP 1.1 中，这个响应代码被重命名为“Found”，并创建了响应代码 307。

换句话说，HTTP 302 被拆分为 HTTP 303 和 307。接下来，在第 380 页部分307 ("Temporary Redirect")：

对于 GET 请求，唯一被请求的是服务器发送一个表示，此状态代码与 303（“See Other”）相同。307 是对 GET 的良好响应的典型情况是服务器想要将客户端发送到镜像站点。但是对于POST、PUT 和 DELETE 请求，服务器预计会采取一些动作来响应请求，此状态码与 303 有很大不同。

响应POST、PUT 或 DELETE的 303表示操作已成功，但响应实体正文未与此请求一起发送。如果客户端想要响应实体主体，则需要向另一个 URI 发出 GET 请求。响应 POST、PUT 或 DELETE 的 307 意味着服务器甚至没有尝试执行操作。客户端需要将整个请求重新提交到Location标头中的 URI 。

换句话说，HTTP POST、PUT、DELETE 在 HTTP 303、307 上是合法的。上一段解释了预期的行为。

话虽如此，我在这里引用的是这本书，而不是 HTTP 规范（它对预期的行为可疑地保持沉默）。