问题标签 [http-status-code-307]

307 Temporary Redirect是否可以从 ASP.NET MVC 中的控制器返回一个？

我有时需要POST将从一个表单提交的值重新提交到另一个 URI。

使用 JavaScript 在客户端进行选择（从而绕过此问题）不是一种选择。

通过 a 重定向GET不是一个选项，因为发布的数据包含一个 8k 字符串，这可能意味着 URI 对于某些（很多？）浏览器来说太长了。

这甚至可能吗？

考虑以下情况：

• Web 服务器正在运行带有 .NET 的 .NET 应用程序<sessionState cookieless="AutoDetect" />。
• HttpWebRequest客户端使用简单的（无 cookie）向其发布数据。

这个看似简单的案例导致了重大失败。

由于 .NET 无法确定请求代理 ( HttpWebRequest) 是否支持 cookie，因此它使用 302 Found 重定向到相同位置来响应 POST 请求：

• AspxAutoDetectCookie响应中命名的 cookie
• AspxAutoDetectCookie在转发位置命名的查询参数

然后，请求代理应该请求新位置，HttpWebRequest确实如此。当 .NET 在查询字符串中看到时，它知道这是一个重新请求，并且它可以通过查看名为 cookie的请求标头中AspxAutoDetectCookie是否存在来确定是否支持 cookie 。AspxAutoDetectCookie

问题是大多数请求代理（Web 浏览器HttpWebRequest）将 302 Found 视为 303 See Other 并将重新请求设为 GET，而不管原始 HTTP 方法如何！在初始 POST 请求中发送的任何数据都不会被转发。

正确的响应应该是 307 临时重定向，它不会改变请求方法。（对位置 X 的POST请求重定向到对位置 Y 的 POST 请求。）

有什么方法可以改变.NET 中的这种行为，所以 POST 请求不会被破坏？

3xx 重定向信息

我有一个使用 MediaPlayer 类的应用程序......它一直在 1.6 和 2.1 设备上运行，但由于我一直在 2.2 设备（和模拟器）上进行测试，我注意到它不会在重定向时流式传输 mp3 文件首先发生...它将返回以下内容：

我想知道是否有人注意到这种行为，如果有的话，是否有人有解决该问题的方法？它可能是一个“AwesomePlayer”，但它的表现并不比它的前任更好:(

我正在尝试跟踪我们发送的特定电子邮件是否已打开，因此在我发送的每封电子邮件中使用散列网址作为图像。目前，当请求该 url 时，我记录了电子邮件已被查看的事实（基于 url 中的哈希）并从 Web 应用程序服务器提供图像（每个人都使用相同的图像）。

在这一点上，我们正在发展到一个小时内收到 10k 多个请求的情况，我认为我可以通过给他们一个 3xx HTTP 响应以及一个更接近他们的图像的 URL 来更好地为我们的客户服务。专用 CDN 而不是我们的应用程序服务器。

哪个代码最好？我认为 302、303 或 307 都是可用的选择。请记住，这种媒体没有 SEO 价值，我唯一关心的是尽快将静态图像交付给客户端，而不会导致旧邮件客户端出现问题。

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

I use Netbeans to generate web service client code, client-style JAX-WS, so i can invoke a web service API.

However, when I invoke the web service API, I get the exception: com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 307: Temporary Redirect

Why do I get this? What is the workaround? I know the problem isn't with the web service itself, because I can get responses fine via soapUI and .Net.

需要一些帮助来理解这两个重定向之间的区别是什么：

或者

在 HTTP 标头的第二种情况下会发生什么？默认情况下是否有任何设置，或者如果我想暂时重定向某些内容，那是错误的吗？

第二个是错的还是两者没有实际区别？如果我只使用“位置”，则找不到任何关于默认发送 HTTP 标头的文档。

提前致谢

我们正在实施一个短网址服务，其中重定向目标每天都会改变。这些 url 将由移动设备访问，并且始终是 GET 请求。我试图了解哪个是最适合这项工作的 300 类型重定向。

AFAIK 大多数网址缩短服务使用 301 重定向（永久移动）。但是，根据规范，303（参见其他）和 307（临时移动）重定向似乎是为我们的案例设计的......

• 303/307 是否与 301 一样受到支持？规范说它们只在 HTTP 1.1 中实现——这意味着什么限制？
• 选择 301 与 303/307 是否有任何实际的缓存或性能影响。
• 对于 GET 请求，是否有任何理由选择 303 和 307？
• 有任何理由使用 302 重定向吗？
• 还有什么需要考虑的吗？

这是Using 301/303/307 redirects for dynamic short urls的后续问题，我尝试在目标 url 频繁更改时确定实现短 url 重定向的最佳方法。

虽然看起来 301 和 307 重定向都以相同的方式执行，但我担心的问题是 301 重定向缓存（如此处所述） - 是避免这种情况的最佳方法，而是使用 307 重定向（我假设 307 重定向永远不会缓存？），还是显式发送无缓存标头（“缓存控制：无缓存，必须重新验证”）？

很明显，在 2010 年，Google 的 Matt Cutts 在一次采访中以及采访后的后续电子邮件交流中透露，如果您使用域到域 HTTP 状态 301 重定向，Google 会降低页面排名。换句话说，如果您有example.com 和购买example.com 并使用HTTP 状态301 重定向到examples.com，Google 已经承认他们通常会为此扣除PR。

好的，剩下的就是 HTTP 状态 302 和 HTTP 状态 307 重定向。他们在 wikipedia 上说 307 是新方法，并且 HTTP 状态 302 是“混蛋”，并不是真正正确的重定向方法。问题是——自 IE6 以来的大多数浏览器都支持 HTTP 状态 307 吗？看，我没有 IE6 浏览器来测试了。

所以问题是——如果我们需要开始使用 HTTP 状态 307 重定向，它会在 IE6 之后发布的浏览器以及 IE6 浏览器中工作吗？

在我的 CMS 中，有一些页面暂时未发布，后来又重新发布。从 SEO 的角度来看，这是处理它们的最佳方式。告诉搜索引擎删除它们，或者它们是临时移动的？

并非所有页面总是被重新发布，在某些情况下返回的状态代码不是最佳选择，但我想以正确的方式处理将要重新发布的页面比那些永远不会重新发布的页面更有意义是。

当用户或搜索引擎尝试浏览此页面时返回哪个状态？302？307？404？或者哪种是处理这种情况的最佳方法？

非常感谢