HTTP 重定向: 你可能不知道的故事 - 上


声明:本文转载自https://my.oschina.net/greenlaw110/blog/1577757,转载目的在于传递更多信息,仅供学习交流之用。如有侵权行为,请联系我,我会及时删除。

插播一条广告→2021 ByteDance字节跳动内推←各城市、各方向的岗位都有,大量招人!


在 Spring 里面我们要重定向的话一般都会这样做:

@Controller final class RedirectTestController {      @RequestMapping(value = "/foo")     String foo() {         return "foo";     }      @RequestMapping(value = "/bar")     String bar() {         return "redirect:/foo";     } } 

应用遇到发送到 /bar/ 的请求被重定向到 /foo. 很简单,不是吗?

现在问题来了, 上面的代码能够在 /bar 上除了能够处理 GET 请求之外, 还能处理其他方法, 比如 POST /bar. 那如果用户发起一个 POST /bar 的请求, 会有什么效果呢? 我们把代码稍微改一下:

@Controller final class RedirectTestController {      @RequestMapping(value = "/foo", method = RequestMethod.GET)     String getFoo() {         return "get:foo";     }      @RequestMapping(value = "/foo", method = RequestMethod.POST)     String postFoo() {         return "post:foo";     }      @RequestMapping(value = "/bar")     String bar() {         return "redirect:/foo";     } } 

然后使用 PostMan 工具来尝试向 /bar 发起一个 POST 请求. 结果发现返回的是 get:foo, 而不是 post:foo. 这是因为 Spring 处理 redirect: 的时候采用了 HTTP 302 Found 返回结果. 读一下 HTTP 标准 会发现重定向居然有 4 中不同的返回值:

  • 301 Moved Permanently
  • 302 Found
  • 303 See Other
  • 307 Temporary Redirect

这究竟是什么鬼, 怎么一个小小的重定向居然会定义出 4 种东东? 那我们下面就来讲讲 HTTP 标准中重定向的故事: 其实最早重定向的返回方式只有 301 Moved Permanently 和 302 Found; 301 的标准定义是请求资源已经有了一个新的 URL,以后对该资源的请求都应该使用新 URL, 这个很容易理解就不多费口舌了. 有趣的故事在 302 上面.

302 是一个业界和标准冲突的典型案例, HTTP 1.0 对 302 的定义是后来的 307 Temporary Redirect, 而几乎所有的浏览器对 302 的实现都是按照后来的 303 See Other 方式实现. 那 307 和 303 之间又有什么差别呢?

不需去看标准里面公文化的描述, 简单地说 307 的语义是当一开始请求资源的方法是 POST 或者 PUT 的时候, 重定向之后重新请求资源还是应该为 POST/PUT, 即保持原有方法. 而 303 的语义则是不管原来的方法是什么, 重新请求资源的方法都是 GET, 而这就是我们文中最初引入的 Spring 重定向例子表现出来的结果.

就是因为业界和标准之间对 302 的定义和实现之间不一致, HTTP 1.1 标准后来干脆明确定义了 303 See Other307 Temporary Redirect, 这样可以很清楚的表达上面两种语义. 而 302 Found 则作为遗留下来的结果一直存在, 可以说 302 是事实上的 303. 这也是为什么 Spring 这样的框架将 redirect 解释为 302 返回的原因了.

那为什么会普遍需要 303 See Other 这种语义呢? 其实一个很常见的做法是当用户使用 POST 请求提交表单之后, 服务器返回一个 302 Found 响应, 重定向到提交结果, 这样在很大程度上可以防止用户重复刷新表单带来的重复提交的问题. 因为当 POST 请求返回之后浏览器已经自动提交了一个 GET 请求到新的结果页面,即使用户再次按 F5 刷新页面,也不会重复提交表单数据了.

现在问题来了,如果项目中真的遇到了需要 307 Temporary Redirect 的情况, 即 POST 请求的 URL 变化了, 需要发起新的 POST 请求, 该怎么处理呢? 还有当 ajax 请求需要被重定向的时候又该如何处理呢? 且听下回分解 ...

本文发表于2017年11月23日 12:25
(c)注:本文转载自https://my.oschina.net/greenlaw110/blog/1577757,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如有侵权行为,请联系我们,我们会及时删除.

阅读 1790 讨论 0 喜欢 0

抢先体验

扫码体验
趣味小程序
文字表情生成器

闪念胶囊

你要过得好哇,这样我才能恨你啊,你要是过得不好,我都不知道该恨你还是拥抱你啊。

直抵黄龙府,与诸君痛饮尔。

那时陪伴我的人啊,你们如今在何方。

不出意外的话,我们再也不会见了,祝你前程似锦。

这世界真好,吃野东西也要留出这条命来看看

快捷链接
网站地图
提交友链
Copyright © 2016 - 2021 Cion.
All Rights Reserved.
京ICP备2021004668号-1