功能重定向的 HTTP 状态

发布于 2024-07-08 18:13:39 字数 493 浏览 8 评论 0原文

现在,我们有显示 UI 元素的网页,以及仅处理表单提交,然后重定向回 UI 页面的网页。 他们使用 PHP 的 header() 函数来执行此操作:

header("Location: /other_page.php");

这会导致发送 302 Found 响应; 根据 HTTP 1.1 规范,302 表示“请求的资源暂时驻留在不同的 URI 下”的情况。 [HTTP 1.1 规范]

从功能上来说,这很好,但这似乎不是我们正在做的事情的正确状态代码。 看起来 303(“查看其他”)在这里是合适的状态,所以我想知道是否有任何理由不使用它。 我们必须更加明确地使用 header(),因为我们必须指定状态行而不仅仅是 Location: 字段。 想法?

Right now we've got web pages that show UI elements, and web pages that just process form submissions, and then redirect back to the UI pages. They do this using PHP's header() function:

header("Location: /other_page.php");

This causes a 302 Found response to be sent; according to the HTTP 1.1 spec, 302 is for cases where "The requested resource resides temporarily under a different URI." [HTTP 1.1 spec]

Functionally, this is fine, but it doens't seem like this is the proper status code for what we're doing. It looks like 303 ("See Other") is the appropriate status here, so I'm wondering if there's any reason not to use it. We'd have to be more explicit in our use of header(), since we'd have to specify that status line rather than just a Location: field. Thoughts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

浅沫记忆 2024-07-15 18:13:51

为了扩展 RoBorg 的答案,许多浏览器只能理解众多 HTTP 响应代码中的一小部分。

旁注:如果您非常关心搜索引擎的排名,302 可能(据说)会导致问题。

To expand on RoBorg's answer, many browsers do not understand more than a handful of the many, many HTTP response codes.

A side note: it you are at all concerned about search engine placement, 302s can (supposedly) cause problems.

世态炎凉 2024-07-15 18:13:50

我自己从未使用过它......正如您的链接中所说:

注意:许多 HTTP/1.1 之前的用户代理都这样做
不明白303
地位。 当担心与此类客户端的互操作性时,
可以使用 302 状态代码来代替,因为大多数用户代理都会做出反应
响应 302 响应,如此处所述的 303 响应。

对我来说,这似乎是坚持使用 302 的充分理由。

仅供参考 header( ) 需要额外的参数,您可以在其中设置状态代码:

header('Location: /foo.php', true, 303);

I've never used it myself... as it says in your link:

Note: Many pre-HTTP/1.1 user agents do
not understand the 303
status. When interoperability with such clients is a concern, the
302 status code may be used instead, since most user agents react
to a 302 response as described here for 303.

This seems a good enough reason to me to stick with 302.

FYI header() takes extra parameters in which you can set the status code:

header('Location: /foo.php', true, 303);

你的心境我的脸 2024-07-15 18:13:48

您可以使用其中任何一个,但用于重定向后发布的正确状态代码是 303。

这种混乱有历史解释。 最初,302指定浏览器不得更改重定向请求的方法。 这使得它不适合重定向后,您希望浏览器发出 GET 请求。 然而,所有浏览器似乎都会误解规范并总是发出 GET 请求。 为了消除歧义,HTTP/1.1 指定了两个新代码:303 和 307。303 本质上指定了 302 的事实上的解释,而 307 指定了 302 的原始规范。所以实际上 302 和 303 是可以互换的,并且在理论302和307是​​。

如果您确实关心兼容性,则 302 比 303 更安全,因为 HTTP/1.0 代理可能无法理解 303,但所有现代浏览器都使用 HTTP/1.1,因此这不是一个真正的问题。 我建议使用 303,因为这是最正确的做法。

顺便说一句; Location 字段应该是完整的 URL。 实际上,这并不重要 - 浏览器是宽容的 - 但如果您关心规范,那么这是正确的做法。

You can use either, but the proper statuscode to use for redirect-after-post is 303.

The confusion has a historical explanation. Originally, 302 specified that the browser mustn't change the method of the redirected request. This makes it unfit for redirect-after-post, where you want the browser to issue a GET request. However, all browsers seems to misinterpret the specs and always issue a GET request. In order to clear up the ambiguity HTTP/1.1 specified two new codes: 303 and 307. 303 essentially specifies the de-facto interpretation of 302, while 307 specifies the original specification of 302. So in practice 302 and 303 are interchangeable, and in theory 302 and 307 are.

If you really care about compatibility, 302 is a safer bet than 303, since HTTP/1.0 agents may not understand 303, but all modern browsers speak HTTP/1.1, so it isn't a real issue. I would recommend using 303, since that's the most correct thing to do.

On a side-note; The Location field should be a full URL. In practice it doesn't matter - browsers are forgiving - but if you care about the specs, that's the proper thing to do.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文