Waittingforyou 2016-12-30
猿教程_-webapi教程-Web API Controller
猿教程_-webapi教程-Web API Request/Response 数据格式
猿教程_-webapi教程-创建包含CRUD操作的Web API接口-第一部分
猿教程_-webapi教程-创建包含CRUD操作的Web API接口2:实现Get方法
猿教程_-webapi教程-创建包含CRUD操作的Web API接口3:实现Post方法
猿教程_-webapi教程-创建包含CRUD操作的Web API接口4:实现Put方法
猿教程_-webapi教程-创建包含CRUD操作的Web API接口5:实现Delete方法
这个问题应该确确实实是一个Chrome的BUG,我在自己的编程环境中发现,并在多个服务器,多个编程语言的运行环境,以及多个浏览器下都测试过,都看到有2次请求出现。为了证明不是自己环境的问题,我也特意去找了一些其他站点,用它里面的一些会产生重定向的请求来测试。比如这个请求地址http://wenda.golaravel.com/account/openid/qq_login/,这是golaravel问答模块进行qq登录的链接地址,它会重定向到qq授权登录的页面。
使用fiddler监控wenda.golaravel.com这个站点,然后在Chrome里面访问以上地址,回到fiddler查看监控结果:
从这个结果可以明确地看到,Chrome对这个地址发出了2次http请求,并且这两次http请求都从服务器拿到了Response。从fiddler的Statistics栏里面,可以对比看出这两个请求过程的一些信息:
第一个是:
第二个是:
从这个对比结果可以看到,这两个请求并不是一种串行的关系,而是并行的关系。但是这个问题的特性还不止这么简单,目前我发现的一些现象如下:
1)不是每次都会出现这个情况,我只能说大部分测试操作都出现这种情况,但是少部分情况是正常的:访问302的地址,对原地址只发起了一次请求,第二次是对302 Location指定的地址的请求,这是正常的;
2)这两个请求并不是每次都能成功从服务器拿到响应,有的时候其中的一个会报500的错误,或者是显示failed,此时如果观察fiddler的log记录,会看到有下面的一些关键信息:
3)大部分情况下,都是这两个请求先发起,然后再对302 Location重定向请求;但是极少的情况会遇到302重定向请求夹在这两个请求中间。
目前我并没有找到这个问题产生的原因,网上相关的资料太少了,所以我只能从多个方面来验证是否是Chrome本身的问题,最后得出的结论也跟我的猜想一致,这就是Chrome较新版本的一个BUG,我在当前时间点的最新版本的Chrome浏览器里面看到这个现象的:
下面我会详细地证明它是否为Chrome的一个BUG。
1. 问题的发现
我使用laravel框架写了一个很简单的程序,就几个页面,做微信登录的demo用的,所以页面里的微信登录按钮,实际上就是一个需要重定向到微信授权页面的地址。我在浏览器里面访问这个地址的时候,在本地windows下的apache服务器的access.log里面,发现这一个访问操作产生了三次http请求:
从这个日志里很明显地看到有2次对/login/weixin的请求,这个就是重定向请求的原请求记录。发现这个问题之后,我并不认为是服务器或者浏览器的问题,而是首先怀疑是否是自己代码里面有重定向loop的情况。所以第一步就去仔细地检查自己的代码:
最后的redirect方法是:
这个代码里的RedirectResponse是laravel框架提供的类。从这个代码,我并没有看出什么问题,因为没有多次创建Response的处理。所以开始怀疑是否是新版的laravel框架的问题,因为我用的是最新的laravel框架。所以我又用公司的php环境测试了一下,公司的php环境用的yii这个php框架,结果发现,公司的环境在本地依然存在这个问题。
为了排除是框架的问题,我又自己写了两个最简单的php页面:
我把demo1部署到demo1.com,demo2部署到demo2.com,然后访问demo1.com来测试。最后也还是遇到了这个问题。在这一次测试里面,我还发现了有两个关键点:
1)如果把302改成301重定向,那么chrome就不会产生两次请求。但是实际上301用在这里是不对的,因为它的含义是原地址的资源已经永久转移到别的位置了。
2)这个问题导致的两次对原地址的请求,大部分情况下,服务器都能收到并进行处理。(demo1里面的打印信息,在这个问题出现的时候,每次都打印两个时间信息,说明服务器响应了2次)。这意味着用户的一次访问操作,浏览器发出了2个请求,服务器对同一个用户操作进行了2次处理。这并不是个没有影响的事,比如当这个请求对某个资源的状态做了一些持续性的改变时,如数据累计,那就意味着用户一次操作,就会累计2次,这样这些数据结果可能就有问题了。这也是我把这个问题详细记录说明的主要原因,我觉得开发中应该注意到这个问题的存在,以便在排除一些疑难的数据问题的时候,可以思考到这个层面上来。
到此为止,基本上已经排除是php框架的问题了。接下来考虑的问题产生对象主要是编程语言,服务器以及浏览器。
2. 排查是否为编程语言的问题
为了验证是否为php语言本身的问题,我又用express框架写了以下简单代码,并运行在node的环境里面来测试:
最后测试发现这个问题,在Nodejs里面同样存在。所以也可以排除是php语言的问题了。
3. 排查是否为服务器的问题
因为这个问题本身是在本地windows服务器里面发现的,所以我怀疑是否为本机apache的问题,所以我又把相关的代码部署到远程的nginx服务器上,最后同样测试到这个问题的存在。
加上上一步在nodejs里面测试的时候,实际上是用本机的node服务器运行的,综合这两个服务器测试结果,也能证明并不是apache服务器的问题。
4. 排查是否为浏览器的问题
我的机子上有360浏览器,firefox,IE11,Edge浏览器和最新的Chrome浏览器的。最后测试发现只有Chrome浏览器里面有这个问题,其它浏览器测试,在fiddler里面都只能看到对原地址仅发起了一次http请求,在每个浏览器我都重复做了大概十多次访问操作才得出这个结论。为了进一步验证Chrome的版本问题,我又特意删了当前版本,下载了一个Chrome46的浏览器测试,结果没有发现这个问题。到此为止,也就基本上可以认为是Chrome浏览器的问题。
5. 进一步排查是否为本机运行环境的问题
为了进一步排查是自己开发环境的问题,我专门到网上找了一些其他站点的302请求地址做测试。除了本文开头提供的地址,下面这个地址也可以测试:
最后,根据以上的排查内容,可以认定这个问题是Chrome的一个BUG,我已经report给他们了,回不回复不重要,最重要的是下一个版本这个问题是否能够解决。所以接下来这个问题,我的处理方式是:跟进chrome的版本更新情况,并在新版本中进行测试。希望它能在后续的版本中得到解决。
其实在以上排查过程中,还有一些情况值的考虑,比如操作系统环境,网络环境的影响,毕竟http请求本身处于这两个大的因素之下,所以也不能完全排除它们的原因。所以,要是感兴趣的朋友,觉得这个问题值得研究的话,非常希望你能把自己的测试结果反馈过来,如果这个问题在你的机器上也存在,那么就能增加本文的客观性和正确性,就能帮助更多的人;如果很多人都没有测试出这个问题,就说明本文的结论有误,这篇文章应该作废才行。