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中它的名字   “暂时感动。”不幸的是，在现实生活中，大多数客户处理302就像   303（“见其他”）。差异取决于客户应该做什么   获得302以响应 PUT，POST或DELETE 请求。请参阅下面的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意味着服务器甚至没有尝试过   执行操作。客户端需要将整个请求重新提交给URI   Location标题。

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

话虽如此，我在这里引用了这本书，而不是HTTP规范（对预期的行为持怀疑态度）。