【问题标题】:Correct HTTP 1.1 header response code after form submission提交表单后更正 HTTP 1.1 标头响应代码
【发布时间】:2012-07-22 03:49:44
【问题描述】:

在我的 MVC 框架中,我有时会在提交表单后重定向。假设您将表单发布到 /example/input。

我想在 PHP 中添加正确的标头代码和解释性文本,例如header('HTTP/1.1 404 Not Found');

1) 您的输入包含错误。您停留在 /example/input 页面上并再次获取表单,并标记有错误等。HTTP 1.1。使用此重定向指令发送代码和文本是否合适?

2) 你的输入没问题,元素被保存,你通过Header('Location: ...')重定向到/example/success。哪个 HTTP 1.1。代码和文本在这里是正确的吗?

3) PHP 代码由于配置错误、缺少包含文件、损坏的数据库连接或其他原因有时会引发错误。哪个 HTTP 1.1。代码和文本在这里是正确的吗?

我在这里查看了代码:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 数字 200 代表 1),数字 301/302 代表 2),数字 500 代表 3)。但是在这三种情况下,我发现上面链接代码后面的标题/解释并不完全符合我上面描述的场景。我应该选择其他代码/文本吗?

【问题讨论】:

  • 您最好将表格提交至/example/input

标签: php header http-1.1


【解决方案1】:

案例一和二描述了相同情况的变体:您通过 POST 提交表单,服务器处理它并将客户端重定向到成功页面或返回表单。对于这两种情况,“303 See Other”都是正确的响应。这是在服务器正确处理 POST 请求后使用 GET 方法将客户端重定向到资源的正确方法。根据规范:

此方法的存在主要是为了允许 POST 激活的输出 将用户代理重定向到选定资源的脚本。

对于案例 3,500 代码通常适用于最严重的错误。

【讨论】:

  • 实际上情况 1 不会重定向,因为您发布到与显示错误的 URL 相同的 URL。只有案例二实际执行重定向(到成功页面)。
  • 理想情况下,将数据发布到表单实际上会导致重定向。见这里:en.wikipedia.org/wiki/Post/Redirect/Get
  • 在所有提交都严格执行PRG概念的情况下,我已经接受了您的回答。但是,我不相信这是必要的,因为如果表单有错误,那么 POST 将不会生成数据库条目并使用包含错误表单的页面进行响应。但是,如果表单没问题,则根据链接的 PRG 概念使用重定向,以避免重复输入。
【解决方案2】:

据我了解,如果您的 PHP 成功执行,那么 200 代码是正确的。所以这应该照顾1和2。

对于 3,如果发生致命错误,PHP 已经发送 500 代码。

再解释一下 2,300s 用于资源不再位于请求的 URL 时。因此,您会将它们重定向到新的或正确的位置。在您的情况下,资源就在那里,因此您不需要 300 代码。

【讨论】:

  • 这不一定是正确的。 300 个代码处理所有类型的重定向,虽然您对致命错误的看法是正确的,但并非 OP 描述的每种情况都会导致致命错误。
  • 你是对的。我错过了 300 个错误的标记。谢谢。
猜你喜欢
  • 2014-10-10
  • 2020-10-29
  • 1970-01-01
  • 1970-01-01
  • 2014-10-12
  • 1970-01-01
  • 1970-01-01
  • 2017-05-10
  • 1970-01-01
相关资源
最近更新 更多