I do not know whether anyone has come across this, but the problem is the following. When I write the site address in the search box, not pressing Enter yet, Chrome already on the background FULLY with html and headers loads the site, I calculated it through a sniffer. And when I press Enter to open the site, Chrome sends the request again, loads it all over again and eventually opens the site. What I see in the logs.

1.1.1.1.1 - - [20/Nov/2018:11:11:57 +0300] "GET / HTTP/1.0" 200 20349 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

1.1.1.1.1 - - [20/Nov/2018:11:12:00 +0300] "GET / HTTP/1.0" 200 18991 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

You can see exactly the same requests, with a difference of 3 seconds, that is, while I clicked on Enter, the old request was still completed, and the new one just started to load because my apache only allows one connection.

The biggest problem is that the first background request, even before pressing the Enter server, has already been worked out, and the cookie that I use to authorize the user is updated by the server, written to the database and sent back to the client in the headers, only when I press Enter, the request is sent- then with the old token, that is, the cookies in the browser have not yet been updated, as a result, the user remains unidentified. And to get new cookies from the browser, you need to press F5 so that everything is synchronized.

In short some nonsense. In other browsers this is not. Found a description of this problem here (recent answers) https://stackoverflow.com/questions/4432378/chrome-sends-a-request-multiple-times

I do not see a solution.

  • Apparently it is necessary to revise the authorization and not to use the constant updating of cookies. You can never be sure that the client has received a formed cookie and will not decide to use the previous one. At any time on the network, anything can happen and the cookie sent out (and stored in the database) may not be received by the client. Most authorization systems issue a cookie once - after checking the password and then do not change it with every call - Mike
  • @Mike they do not change with each treatment. Cookies are updated only if there is no temporary session that is valid until the browser is closed. If I close the browser, I update the token, because the user could not log in for 2 days and this is not safe. - Max_Payne
  • then I do not understand why the first chromium treatment hinders you. Why does the first call update something in the database that interferes with the second call? - Mike
  • one
    It is necessary to store tokens in the database so that they are not removed from there immediately after you send them to the client. With an unstable connection, the client can easily make even 5 requests in a row. And it is not necessary to delete the token from the database when sending the answers never. If you are afraid that the table will be too large, then delete obsolete tokens by some separate procedure, according to their obsolescence time - Mike
  • one
    It may be useful to record in the table the fact of the exchange of the old token with the indication of a new one, so that when you re-apply it just return this newest one - Mike

0