我需要使用 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

5 年后...请注意，307 的行为已在 2014 年 6 月由 RFC-7231#6.4.7 更新，现在与 302 有很大不同，因为方法可能不会改变：

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

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

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

Google's documentation 似乎表明 302 和 307 被同等对待，并且“Googlebot 将继续抓取原始位置并将其编入索引。”

但面对模棱两可的情况，您不妨深入研究 RFC 并尝试做正确的事情，并天真地希望爬虫也会这样做。在这种情况下，RFC 2616 § 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 4

我感觉到你的痛苦。至于解决方案，很难说搜索引擎会做什么。似乎每个人都有自己处理重定向的方式。 This link 建议 302 将索引重定向页面的内容，但仍使用主页链接，但尚不清楚 307 将做什么。

您可以考虑进行的另一种方法是使用 javascript 重定向和 <noscript> 标记来解释正在发生的事情。这也会破坏非javascript浏览器，您必须谨慎行事以避免Google's sneaky-site detection routine，但我怀疑只要您的noscript包含与新URL匹配的超链接，您就可以了。

无论哪种方式，如果可能的话，我仍然会追求纯粹的服务器端请求。哎呀，如果您的预期流量很轻，您可以在没有查询字符串的情况下将您的主页视为代理。让它使用后台线程通过查询字符串请求自己并输出结果。 :-)

edit 刚刚看到您使用的是 .NET。也许可以考虑来自 SO：C# Can i modify Request.Form's variables? 的这个答案。