HTTP 303是否可用于其他HTTP方法？

鼓励使用将客户端重定向到资源的规范表示形式。它只在

httpget

的上下文中讨论主题

---

这是否也适用于其他HTTP方法？如果客户端尝试将

HTTP PUT

或

DELETE

放入非规范URI，是否可以（和/或建议）返回HTTP 303？最佳实践是什么？为什么？

我在书中发现了一个有趣的部分。根据第378页第302节（“找到”）：

此状态代码是大多数重定向相关混淆的最终来源。它应该像307（“临时重定向”）一样处理。事实上，在HTTP 1.0中，它的名称是 不幸的是，在现实生活中，大多数客户处理302就像 303（“见其他”）。区别取决于客户机在运行时应该做什么 获取302以响应放置、发布或删除请求。参见下面307的条目 如果你对细节感兴趣

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

换句话说，HTTP 302被分为HTTP 303和307。 接下来，在第380页第307节（“临时重定向”）：

对于GET请求，其中唯一被请求的是服务器发送表示，此状态代码与303相同（“请参阅其他”）。一个典型的例子是307 当服务器想要将客户端发送到镜像站点时，GET是一个很好的响应。 但是对于POST、PUT和DELETE请求，，服务器需要执行一些操作 响应请求的操作，此状态代码与303明显不同

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

位置

标题

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

话虽如此，我在这里引用的是这本书，而不是HTTP规范（它对预期行为的沉默令人怀疑）

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

---

来源：

与其说它是为它设计的，不如说PRC模式是由于浏览器处理响应代码的方式而产生的，并且这种行为成为了事实上的标准。@KeithGaughan，我刚刚在书中找到了一个答案，为规范提供了新的解释。请参阅我的更新答案。进一步证明：--IETF明确删除了对

HTTPGET

的引用，以响应

HTTP303

。另见：