We have a page in php, that may take some time to load and the response time can be over 30 seconds, it has a heavy script and it is normal, not open to the public. This page saves a log on our database everytime it is executed, and I noticed that, when the page loads fast, the log is saved once, but if it takes longer to respond, the log is saved twice.
Weird enouph, this was only happening in Chrome, when opening the page on Firefox, even if it took long to load, the log was saved once. Which brought me to the deduction that Chrome was executing the page twice when the response time was long.
After inspecting the network in Chrome I found that in fact Chrome was loading the page twice:
First time it was canceled, then redirected (307) and finally loaded. (in his case it took more than a minute to load, but that is normal)
The redirection is not a 307 Temporary Redirect but a 307 Internal Redirect. After some more digging, it turns out that Chrome in fact has an extension that executes this redirections (see the anser by @Rob W. 307 Redirect when loading analytics.js in Chrome)
The question is:
- Why does Chrome make a 307 Internal Redirect (which do call the server twice)
- and how can I prevent it from the server side? (I don’t want to have to modify the configuration from Chrome because I can’t ask all the users to change their configuration)
Thanks!
Advertisement
Answer
The
307 internal redirect
is not a real redirect. It’s a fake internal redirect done by Chrome and isn’t actually sent to the server. Chrome does it when it sees theHSTS
non-authoritative header on and so it creates a fake request with a307 internal redirect
and then send a real request to the backend/server using the upgradedhttps
URL found in the location header in the first fakeinternal redirect
request. It’s a security feature(http strict transport security
) that allows sites to opt browser to upgrade fromhttp
tohttps
. You can check @Barry’s answer here https://stackoverflow.com/a/34213531/14876907Find the config in the web server where it’s enabled. It’ll be something like
Strict-Transport-Security
as header that it sent to browsers so find where it was set and then remove it. Also, remember to remove the website itself from Chrome’s cache so that Chrome doesn’t automatically upgrade tohttps
. It also could be set on the domain itself that’s preloaded into the browser itself(for example, any domain name with the.dev
or.app
is going to get upgraded to usehttps
; in that case, there is nothing to be done really. check the preloaded domains over here https://hstspreload.org/.