但是，很多时候，您需要通过POST（例如银行付款）将用户重定向到另一个域。这是一个常见的场景，并且确实是一个要求。有人知道为什么HTTP规范中忽略了这样的通用要求吗？解决方法是发送一个表单（在隐藏字段中带有参数），并将其操作设置为目标位置（Location头字段的值），然后使用
setTimeout将表单提交到目标位置。#1 楼
在HTTP 1.1中，实际上存在状态码（307），该状态码指示应使用相同的方法重复请求并发布数据。正如其他人所说，这里有可能被滥用，这可能就是为什么许多框架在其抽象中坚持使用301和302的原因。但是，有了适当的理解和负责任的使用，您应该能够完成所需的工作。
请注意，根据W3.org规范，当
METHOD不是HEAD或GET时，用户代理应提示用户，然后在新位置重新执行请求。如果旧的用户代理不确定如何使用307，还应该为用户提供注释和后备机制。使用这种形式：并让Test307.aspx只需通过以下位置返回307：http：//google.com、Chrome 13和Fiddler确认确实将“ test = the test”发布到了Google。当然，进一步的响应是405，因为Google不允许POST，但显示了机制。有关更多信息，请参见HTTP状态代码列表和W3.org规范。
307临时重定向（自HTTP / 1.1起）在这种情况下，应使用另一个URI重复请求
，但以后的请求仍可以使用原始URI.2。与303相比，重新发出原始请求时，不应更改request方法。例如，必须使用另一个POST请求重复POST
请求。
评论
@DavidRuttka，野外对浏览器的支持是什么？
–起搏器
2014年5月12日上午9:32
@DavidRuttka，您可能想要更新您的答案以将rfc7231考虑在内（已作废rfc2616）。提示用户是基于rfc2616中的要求。此要求已在rfc7231中删除，并且rfc7231还引入了307重定向不得更改请求方法的要求（您在引用中提到了答案的结尾）。
– nibarius
14-10-22在6:39
请注意，根据tools.ietf.org/id/draft-hunt-http-rest-redirect-00.html“，除非服务提供商知道客户端实际上是用户，否则不应该使用HTTP重定向代码301-306。代理”，因此看来ReSTful服务应使用308而不是301。但这只是草稿。
–布鲁斯·亚当斯（Bruce Adams）
18-11-22在15:37
#2 楼
我在这里的此页上找到了很好的解释。WWW上最简单的情况是“幂等”事务，即可以重复而不会造成任何伤害的事务。这些是
，通常是“ GET”事务，这是因为它们是对
直接URL引用（例如HTML中的href =或src =属性）的检索，或者是因为它们是使用GET的表单提交方法。重定向
这样的事务很简单，没有任何问题：
客户端接收到重定向响应，包括一个Location：
标头，该标头指定了新的URL，客户端对此做出了响应通过
将交易重新发行到新的URL。与这些重定向相关联的不同30x状态代码之间在隐式可缓存性方面存在差异，但在响应GET请求方面，它们基本相似（301和302）。 >
POST事务是不同的，因为按照
原则，它们被定义为非幂等（例如订购比萨饼，进行表决或进行任何操作），并且不得随意
HTTP协议规范旨在考虑这种区别
：GET方法被定义为固有幂等的，而POST方法被定义为：至少有可能，
非幂等；该规范要求客户端代理（例如浏览器）采取多种预防措施，以保护用户
避免因疏忽（重新）提交他们原本不希望的POST事务，或者在他们不想要的环境中提交POST
。
我不喜欢严格限制用户的使用，以防止他们造成不必要的混乱或有害伤害对于他们的应用程序，我可以理解这一点并且很有意义。
评论
大部分的推论都归因于插管缓慢且不可靠的时代（它们仍然在世界上的许多地方）。我清楚地记得当我使用拨号时，每当有人拿起电话时，它就会随机断开。重新加载页面并查看服务器所处的状态比重新提交内容和冒两次执行相同操作的风险要好。
–zzzzBov
2011年8月10日13:55
@Falcon，增加“访客计数器”是否被视为非等幂的？如果是这样，这些天几乎没有网站可以进行幂等GET ...
–起搏器
2014年5月12日上午9:35
@Pacerier：通常将幂等解释为“以一种有意义的方式幂等”，例如，两次购买同一商品，而不是两次造访。否则，您将是正确的。但是实际上，该规范应该要求服务器在必要时具有有意义的幂等性，例如在页面中嵌入ID以防止重复-不需要浏览器向用户询问他们无法准确回答的问题。无论如何，阻止POST重定向都不会影响幂等性。这只是一条消息，说明请求的目标实际上在那儿。
–劳伦斯·多尔（Lawrence Dol）
16年1月28日在23:30
我看不出这种推理有何意义。假设我在大通银行网站上，然后提交了表格。我已经同意/信任他们。因此，如果他们必须将该数据重定向到另一页，我为什么还要再次同意。再举一个例子，假设我是默认情况下关闭JavaScript的人。有一天，我会在线填写抵押贷款应用程序，提交表单时会出错。如果应用程序可以重定向（使用POST）到我刚刚填写的用于预填充数据的页面，那就太好了。
–b01
17年11月26日在13:51
@Flacon，我需要证明用POST限制重定向可以在任何方面防止混乱。由于我首先必须使用我的数据来信任该应用程序，因此一旦获得数据，他们就可以使用该应用程序执行任何操作。而且我认为重定向比POST请求更容易受到攻击。
–b01
17年11月26日在13:57
#3 楼
GET（和其他一些方法）在http规范（RFC 2616）中定义为“ SAFE”：9.1.1安全方法
实现者应请注意，该软件在用户通过Internet进行的互动中代表了用户，并应谨慎操作，以使用户了解他们可能会采取的可能具有意想不到的意义的任何操作。
特别是，已经建立了约定，即GET和
这允许用户代理以特殊方式表示其他方法，例如POST，PUT
和DELETE，以便使用户了解
事实，正在请求可能不安全的操作。
自然，不可能确保服务器不会由于执行GET请求而产生副作用。 ;实际上，一些动态资源认为该功能。重要的区别在这里是用户没有要求副作用，因此不能对它们负责。
这意味着GET请求永远不会给用户带来任何严重的后果，除了看到他们可能不希望看到的内容外，但是POST请求可能会更改对他们来说很重要的资源或对其他人。
尽管JavaScript已经改变了这种情况，但传统上用户界面有所不同-用户可以通过单击链接来触发GET请求，但必须填写表单来触发POST请求。我认为HTTP的设计者渴望维护安全和非安全方法之间的区别。
我也认为没有必要重定向到POST。大概需要执行的任何操作都可以通过在服务器端代码中调用一个函数来完成，或者如果它需要在其他服务器上发生，则可以将包含浏览器URL的重定向发送到该服务器，而不是发送该重定向可以向该服务器本身发出请求，就像用户的代理一样。
评论
您正在寻找状态码307吗？请参阅下面的答案。