浏览器中的302你真的知道吗

前言

在公司小程序内嵌H5相关页面在做收银台区分跳转时，了解到了一些有关浏览器302相关的有趣故事，分享给大家。

地址栏的302

在网页输入一个地址后，如果当前地址返回302,301的状态码。浏览器会自动跳转到Response header中指定的Location指定的地址。如下图：

到这里开始我们进入我们今天要聊的正题:
在地址栏浏览器帮我们自动重定向了，那我们如果通过XHR来发送请求后
1：如果相应是302的话，也会帮我们自动跳转吗？
2：如果自动跳转，我们如何知道已经发生了跳转呢？
3：有没有什么办法可以拦截这种行为？
心急的同学直接看最后两部分即可，中间是一些演示DEMO以及示例。

业务场景

之前的业务再跳转收银台时，会携带大量的参数直接通过window.location交给后端去处理，收银台的页面属于后端PHP页面。在小程序开发过程中，由于后端接口逻辑较多，所以决定通过前端解析后端PHP页面接口来获取订单号然后调用小程序路由跳转函数去走小程序的收银台。所以，前端不能再走window.location的方式去直接扔给后端去处理。具体处理流程见下图：

可以看到，当我们通过XHR请求后端PHP接口时，该接口可能正常情况下返回200状态码，并且返回HTML页面。我们通过正则解析PHP页面可以拿到订单号，通过判断页面存在订单号的数量可以区分出来是否是第一次支付。这里有个业务情况就是可能存在0元课的情况，用户通过选优惠券等等满足不需要支付直接完成订单的情况。所以前端需要主动去调用一次show的接口来判断。而这个show接口就是本文的重点：
无需支付的情况下他会返回302状态码。需要支付的情况下，他会返回200的状态码。我通过判断状态码来选择让路由跳向不同的程序。是吧？很简单的逻辑。基于axios。我写出了如下的代码

  ..... 跳转小程序订单完成页
  return
}
.....跳转小程序收银台

因为代码过于简单，我甚至没有测试，直接上灰度。

然后，发现我的if分支不生效。
然后，我本地开始测试，发现好神奇，一直是200状态码。

故事开始

因为axios在浏览器环境下是基于XHR的。所以我本地写了一个简单的测试DEMO：
服务端：

前端页面：

结果跟我想的一样。302的影子甚至连看都没看到。

这就很离谱。

难道浏览器这也帮我自动重定向了？实际上还真是。XHR会自动帮你重定向。那我们有没有什么办法知道发生了重定向呢？也是可以的：

所以我们的代码应该这么写：

// consfig.url = /api
// responseUrl = http://localhost:3000/cart
if(!request.responseURL.includes(config.url)){
  ..... 跳转小程序订单完成页
  return
}
.....跳转小程序收银台

我们修改一下我们的小Demo让他能判断出来发生了重定向。

我们已经能成功的判断出来是否发生了重定向了。所以我们的需求终于可以搞了。

解决了这个问题，我们应该更深入的思考一下。毕竟我们不是那么肤浅的人。

都21世纪嘞，我们应该试试Fetch，好滴。我们去试试Fetch：

前端页面【这玩意就是用起来比XHR简单，我喜欢】：

跑一下试试

不愧是新一代。通过测试发现，response中有一个redirected 的值，可以让我们直接拿来判断是否发生了重定向。我们查阅一下MDN：https://developer.mozilla.org/zh-CN/docs/Web/API/Response。

仔细查阅文档，

fetch似乎可以让我们手动重定向。我们试试这个特性。


确实帮我们把重定向拦截掉了，但是，查看响应接口。我们似乎也没有办法拿到重定向地址。
大家可以看这个ISSUE：https://github.com/whatwg/fetch/issues/601 。规范的定义本就如此。它的意思是不让浏览器去重定向，阻止重定向。并不是让我们来手动重定向。
所以我们没有办法去手动重定向。这种情况下 我们有没有什么解决方案呢？
通过查阅资料：
https://www.ruanyifeng.com/blog/2020/12/fetch-tutorial.html

大家注意：这里写的不对哈！是错误的实例，大佬也有犯错的时候🤣。
这个大佬的文章：https://github.com/mrlmx/blogs/issues/2。可以参考这篇文章，写的非常好，最后比较完美的诠释了如何手动重定向。需要fetch与XHR来配合完成拦截重定向并获取重定向地址。由于大佬写的过于完美，我就不展示了。核心就是：

总结

1：默认情况下，不论是XHR还是fetch都会自动重定向。
2：fetch提供了属性值来判断是否发生了重定向，XHR可以通过比对responseURL与请求URL是否相同来判断是否发生了重定向。
3：fetch提供了阻止重定向的能力，但是无法获取重定向URL。XHR可以阻止，并且可以拿到被阻止重定向的值，这是比fetch高级一点的地方。

参考资料：

fetch：https://developer.mozilla.org/zh-CN/docs/Web/API/fetch
XHR：https://developer.mozilla.org/zh-CN/docs/Web/API/XMLHttpRequest
Response：https://developer.mozilla.org/zh-CN/docs/Web/API/Response
ISSUE：https://github.com/whatwg/fetch/issues/763
ISSUE：https://github.com/whatwg/fetch/issues/601
BLOG：https://github.com/mrlmx/blogs/issues/2