Description of the problem that Chrome generates 2 requests to the original request when redirecting 302

Ape Tutorial_ - webapi tutorial-webapi tutorial

Ape Tutorial_ - webapi tutorial-Web API overview

Ape Tutorial_ -webapi tutorial - new Web Api project

Ape Tutorial_ - webapi tutorial-testing web API

Ape Tutorial_ - webapi tutorial-Web API Controller

Ape Tutorial_ - webapi tutorial-configure Web API

Ape Tutorial_ - webapi tutorial-Web API routing

Ape Tutorial_ -webapi tutorial - parameter binding

Ape Tutorial_ - webapi tutorial-Action method return type

Ape Tutorial_ - webapi tutorial-Web API Request/Response data format

Ape Tutorial_ - webapi tutorial-media formatter

Ape Tutorial_ - webapi tutorial-Web API filter

Ape Tutorial_ - webapi tutorial - creating a web API interface containing CRUD operations - part 1

Ape Tutorial_ - webapi tutorial-create a Web API interface containing CRUD operations 2: Implement the Get method

Ape Tutorial_ - webapi tutorial-create a Web API interface containing CRUD operations 3: Implement the Post method

Ape Tutorial_ - webapi tutorial-create a Web API interface containing CRUD operations 4: Implement the Put method

Ape Tutorial_ - webapi tutorial-create a Web API interface containing CRUD operations 5: Implement the Delete method

This problem should indeed be a Chrome bug. I found it in my own programming environment and tested it on multiple servers, multiple programming language operating environments, and multiple browsers, and I saw that there are 2 request appears. In order to prove that it is not a problem with my own environment, I also went to some other sites to test with some of the redirected requests in it. For example, the request address http://wenda.golaravel.com/account/openid/qq_login/ is the link address of the golaravel question and answer module for qq login, and it will redirect to the page where qq authorizes the login.

Use fiddler to monitor the site wenda.golaravel.com, then visit the above address in Chrome, and go back to fiddler to view the monitoring results:

image

From this result, we can clearly see that Chrome made two http requests to this address, and both http requests got Responses from the server. From the Statistics column of fiddler, we can compare some information about the two request processes: 
the first one is:

image 
The second is:  from this comparison result, we can see that the two requests are not in a serial relationship, but in a parallel relationship. But the characteristics of this problem are not so simple. Some of the phenomena I have found so far are as follows:
image 

1) This situation does not happen every time. I can only say that this situation occurs in most test operations, but a small number of situations are normal: when accessing the address of 302, only one request is made to the original address, and the second time is The request to the address specified by 302 Location is normal; 
2) These two requests do not always get a response from the server successfully. Sometimes one of them will report an error of 500 or fail. At this point, if you observe the log records of fiddler, you will see the following key information:

3) In most cases, these two requests are initiated first, and then the 302 Location request is redirected; however, in rare cases, the 302 redirect request will be sandwiched between these two requests.

At present, I have not found the cause of this problem. There is too little related information on the Internet, so I can only verify whether it is a problem with Chrome itself from multiple aspects. The final conclusion is also consistent with my conjecture, which is A bug in the newer version of Chrome, I see this phenomenon in the latest version of the Chrome browser at the current point in time:

image

Below I will prove in detail whether it is a bug in Chrome.

1. Discovery of the problem

I used the laravel framework to write a very simple program, just a few pages, for the demo of WeChat login, so the WeChat login button on the page is actually an address that needs to be redirected to the WeChat authorization page. When I access this address in the browser, in the access.log of the apache server under the local windows, I found that this access operation generated three http requests:  it is obvious from this log that there are two requests to /login /weixin request, this is the original request record of the redirection request. After discovering this problem, I don't think it's a server or browser problem, but I first wonder if there is a redirection loop in my code. So the first step is to check your code carefully:
image 

The final redirect method is:

The RedirectResponse in this code is a class provided by the laravel framework. From this code, I don't see any problem, because there is no processing of creating Response multiple times. So I began to wonder if it was a problem with the new version of the laravel framework, because I was using the latest laravel framework. So I tested it again with the company's php environment. The company's php environment used the yii php framework. It turned out that the company's environment still had this problem locally.

In order to rule out the problem of the framework, I wrote two simplest php pages myself:  I deployed demo1 to demo1.com, demo2 to demo2.com, and then visited demo1.com to test. Finally encountered this problem. In this test, I also found two key points:
image 
image 

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. 排查是否为浏览器的问题

I have 360 ​​browsers, firefox, IE11, Edge browser and the latest Chrome browser on my machine. In the final test, it was found that only the Chrome browser had this problem. In other browser tests, I could only see that only one http request was initiated to the original address in fiddler. In each browser, I repeated the visit about ten times. Operation came to this conclusion. In order to further verify the version problem of Chrome, I deliberately deleted the current version and downloaded a Chrome46 browser test, but I did not find this problem. So far, it can basically be considered a problem with the Chrome browser.

5. Further troubleshoot whether it is a problem with the local operating environment

In order to further investigate the problem of my own development environment, I specifically went to the Internet to find the 302 request addresses of some other sites for testing. In addition to the address provided at the beginning of this article, the following address can also be tested:

http://www.toutiao.com/auth/connect/?type=sso&platform=weixin&next=https://sso.toutiao.com/auth/login_success/?service=http://www.toutiao.com/

image

Finally, according to the above investigation, it can be determined that this problem is a bug of Chrome. I have reported it to them. It is not important to reply or not. The most important thing is whether the problem can be solved in the next version. So next, my way of dealing with this problem is: follow up with the version update of chrome and test it in the new version. Hopefully it will be resolved in subsequent releases.

In fact, in the above investigation process, there are still some circumstances to consider, such as the influence of the operating system environment and the network environment. After all, the http request itself is under these two major factors, so they cannot be completely ruled out. Therefore, if interested friends think this issue is worth studying, I very much hope that you can feedback your own test results. If this problem also exists on your machine, it will increase the objectivity and correctness of this article. It can help more people; if many people have not tested this problem, it means that the conclusion of this article is wrong, and this article should be invalidated.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326998631&siteId=291194637