我需要使用http重定向代码302或307吗？

Question

假设我的网站上有一个页面显示当月的媒体发布
http://www.mysite.com/mediareleases.aspx

由于进入*的原因很简单,因此必须为此页面提供一个查询字符串,其中包含当月的当前日期,以便生成此列表:
http://www.mysite.com/mediareleases.aspx?prevDays=18

因此我需要重定向客户端请求http://www.mysite.com/mediareleases.aspx到http://www.mysite.com/mediareleases.aspx?prevDays=whateverDayOfTheMonthItIs

我的问题是,如果我想谷歌索引没有查询参数的页面,我应该使用状态代码302或307来执行重定向吗？

两者都表明页面已经"暂时"移动 - 这就是我想要的,因为如果你理解我的话,页面每天都会"移动".

[*]我正在使用闭源.NET CMS的一个功能,所以我的双手并列.

Answer 1

谷歌的文档似乎表明302和307都被等同地对待,并且"Googlebot将继续抓取并索引原始位置".

但是面对模棱两可的情况,你不妨深入研究RFC,并尝试做正确的事情,天真的希望爬行者会做同样的事情.在这种情况下,RFC2616§10.3包含每个响应代码几乎相同的定义,但有一个例外:

302:由于重定向有时可能会改变,因此客户端应该继续使用Request-URI来处理将来的请求.

307:由于重定向有时可能会被更改,因此客户端应该继续使用Request-URI来处理将来的请求.

这并不是一个重要的区别.我的阅读是302指示客户网站管理员不值得信任,307明确告诉网站管理员客户不会信任他们,因此他们可以自由地改变重定向.

我认为更有说服力的一点是302的定义中的注释:

注意:RFC 1945和RFC 2068指定不允许客户端更改重定向请求的方法.但是,大多数现有的用户代理实现将302视为303响应,对Location字段值执行GET,而不管原始请求方法如何.已经为希望明确清楚客户端期望哪种反应的服务器添加了状态代码303和307.

对我来说,这表示302和307大致相同,但HTTP/1.0客户端第一次无法正确实现302.

Answer 2

简答:既不是.在大多数情况下,您真正​​想要使用的代码是303.

对于长期答案,首先我们需要一些背景知识.

获取重定向代码时,客户端可以(A)使用相同的请求类型加载新位置,或者(B)它可以覆盖它并使用GET.

HTTP 1.0规范没有303和307,它只有302,它强制执行(A)行为.但在实践中发现(A)导致提交表格的问题.

假设你有一个联系表格,访问者填写并提交,客户得到一个302页面说"谢谢,我们会回复你".表单是使用POST发送的,因此感谢页面也使用POST加载.现在假设访问者重新加载; 请求的重新发送方式与第一次获取的方式相同,即使用POST(以及正文中的相同负载).最终结果:表单提交两次(每次重新加载一次).即使客户在执行此操作之前要求用户进行确认,但在大多数情况下仍然令人讨厌.

此问题变得非常普遍,客户端生产者决定覆盖规范并发出重定向位置的GET请求.基本上,它是HTTP 1.0规范中的疏忽.客户最需要的是303(和上面的行为(B)),但他们只得到302(和(A)).

如果HTTP 1.0同时提供302和303,则没有问题.但它没有,所以它导致了302没人正确使用.所以HTTP 1.1增加了303(非常需要),但也决定添加307,这在技术上与302相同,但是是一种"显式302"; 它说"是的,我知道302周围的问题,我知道我在做什么,给我行为(A)".

现在,回到我们的问题.你现在看到为什么在大多数情况下你会想要303.

您希望保留请求类型的情况非常罕见.如果你发现自己就是这种情况,答案很简单:使用302.客户端说HTTP 1.0,在这种情况下它无法理解307; 或者它说HTTP 1.1,这意味着它没有理由保留旧客户的叛逆行为,即.它正确实现302,所以使用它!

Answer 3

5 年过去了……请注意，307 的行为已在 2014 年 6 月由RFC-7231#6.4.7更新，现在与 302 显着不同，因为方法可能不会改变：

307（临时重定向）状态码表示目标资源临时驻留在不同的 URI 下，如果用户代理执行自动重定向到该 URI，则用户代理不得更改请求方法。

可能不是原始问题的问题，但可能与遇到此问题的其他人有关，只是寻找差异。