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

Question

RESTful Web Services 鼓励使用HTTP 303 将客户端重定向到资源的规范表示。它只讨论HTTP GET 上下文中的主题。

这是否也适用于其他 HTTP 方法？如果客户端尝试将 HTTP PUT 或 DELETE 发送到非规范 URI，是否可以接受（和/或推荐）返回 HTTP 303？最佳做法是什么？为什么？

Answer 1

我刚刚在书中发现了一个有趣的部分。根据第378页302 ("Found")：

此状态码是大多数重定向相关混淆的最终来源。它应该像 307（“临时重定向”）一样处理。事实上，在 HTTP 1.0 中它的名字 是“临时搬家”。不幸的是，在现实生活中，大多数客户处理 302 就像 303（“见其他”）。不同之处在于客户应该做什么 收到 302 响应 PUT、POST 或 DELETE 请求。请参阅下面的 307 条目 如果您对细节感兴趣。

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

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

对于 GET 请求，请求的唯一内容是服务器发送表示，此状态代码与 303 相同（“查看其他”）。 307的典型案例 对 GET 的一个很好的响应是当服务器想要将客户端发送到镜像站点时。 但是对于 POST、PUT 和 DELETE 请求，服务器预计会占用一些 响应请求的动作，这个状态码与303明显不同。

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

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

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

Answer 2

此状态码通常适用于任何 HTTP 方法。它主要用于允许 POST 操作的输出以将用户代理重定向到选定的资源，因为这样做可以提供与 POST 响应相对应的信息，该信息可以独立于原始的形式单独识别、添加书签和缓存请求。

来源：https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p2-semantics-21#section-7.4.4