URL does not resolve using Firefox but does using Chrome
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
People
(Reporter: ken.good, Unassigned)
References
Details
(Whiteboard: [necko-triaged][necko-priority-next])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Steps to reproduce:
Entering http://keep.education takes us to http://keep.education/cgi-sys/defaultwebpage.cgi if the new domain registered has not propagated completely.
Actual results:
Using Firefox we can not get back to http://keep.education, even when propagation has fully taken place, even days later. Firefox always goes to http://keep.education/cgi-sys/defaultwebpage.cgi however this does not happen on Google Chrome.
Expected results:
http://keep.education should be displayed, showing our default page. Yes, it is said that we can clear the cookies, but it should not be necessary to clear all cookies because this has wider implications, and I'm not sure this would work anyway. Besides, we don't want to have to ask our clients to clear their cookies either every time they end up with a page like http://keep.education/cgi-sys/defaultwebpage.cgi which shows " SORRY!
If you are the owner of this website, please contact your hosting provider: webmaster@keep.education
It is possible you have reached this page because:". It is not our system that is at fault, Firefox changes the URL to display this page instead of the http://keep.education page.
This problem has existed with Firefox, our preferred browser, for a long time - years I would like to say. As developers if we make a mistake in the .htaccess file (usually from a copy and paste), and redirect the site to another domain, then we have the same problem - but it is more serious in this case because the client wants to see the website we are working on - so we direct them to use Google Chrome.
Hello, thank you for the bug report!
Unfortunately I could not reproduce your issue. Would you be so kind as to answer a few questions so we can investigate this further?
- Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
- Does this issue happen with latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
- Does this issue happen when Firefox is in Troubleshoot Mode? Here’s a link on how to enable it: https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-troubleshoot-mode
Setting the Component to ‘General’. Please change if there’s a better fit, thank you.
|
||
Comment 3•2 years ago
•
|
||
it should not be necessary to clear all cookies because this has wider implications
There is another workaround:
- Press ctrl+h (or alternatively go to the hamburger menu at the top right, select history, then Manage History at the bottom)
- search for
keep.education - right click on a history entry
- click on "Forget about this site"
Besides, we don't want to have to ask our clients to clear their cookies either every time they end up with a page
FYI: The problem is, that the website told the browser on a previous visit that there is a (permanent) redirect to another URL. If you have never visited the website with Firefox when that redirect was in place (for example if your clients didn't visit the website at that time), then they just load the current website from the webserver as expected.
AFAIK Chrome has the same behavior: If you would have visited the website before with Chrome, you would also see the misleading cached redirect behavior.
We're planning to take a look at the caching behavior in Bug 968273, to make redirects received over the insecure http (as opposed to https) not permanently cached. That will help with situations like this.
If you need to create temporary redirects during development, you can use the status code 307 Temporary redirect [1]. That one wouldn't get cached and the browser validates it on every visit.
Clearing needinfo and triaging, because this is known behavior. Could potentially be closed as duplicate.
(In reply to Manuel Bucher [:manuel] from comment #3)
it should not be necessary to clear all cookies because this has wider implications
There is another workaround:
- Press ctrl+h (or alternatively go to the hamburger menu at the top right, select history, then Manage History at the bottom)
- search for
keep.education- right click on a history entry
- click on "Forget about this site"
Besides, we don't want to have to ask our clients to clear their cookies either every time they end up with a page
FYI: The problem is, that the website told the browser on a previous visit that there is a (permanent) redirect to another URL. If you have never visited the website with Firefox when that redirect was in place (for example if your clients didn't visit the website at that time), then they just load the current website from the webserver as expected.
AFAIK Chrome has the same behavior: If you would have visited the website before with Chrome, you would also see the misleading cached redirect behavior.
We're planning to take a look at the caching behavior in Bug 968273, to make redirects received over the insecure http (as opposed to https) not permanently cached. That will help with situations like this.
If you need to create temporary redirects during development, you can use the status code
307 Temporary redirect[1]. That one wouldn't get cached and the browser validates it on every visit.
Thank you for addressing this issue Manuel Bucher, you clearly understand the issue. Sorry for my delay in response, I have been ill with the bad cold/flu going around.
Just one point about Google Chrome, we have had the situation of going to a website using Chrome and getting re-directed but then later after fixing the .htaccess redirect error or when propagation has fully taken effect as in the case that happened with keep.education, going back to Chrome and entering the website address (keep.education or other) and Chrome shows the right website, does not maintain the "permanent" redirection. But at the same time Firefox does not and Firefox will continue re-directing literally for days at a time. Some how Chrome knows the redirection is not applicable anymore.
If we or anyone else were trying to get a clients website live and they couldn't access it using Firefox we have no alternative but to tell them to use Chrome or some other browser. This is not good for Firefox, and we would much rather not have to tell them to do this because we like and support Firefox and have done for many years.
I am sure that many other developers have this problem but haven't raised it with you, because many of us copy a website from a website we have developed previously - and many of us register new domains often.
Many thanks for your help.
Don't worry, take care.
Could you setup a redirect in Apache to help debug what specifically goes on here? I don't yet know which status code Apache is returning and which Headers. It would be really helpful if you can setup an endpoint on your server for debugging the issue. I'm especially interested in the output of curl -I http://keep.education/your-redirect-endpoint. I'm also interested in how the Apache .htaccess line for the redirect looks like to be able replicate the setup.
That would also help me verify the difference to Chrome.
(In reply to Manuel Bucher [:manuel] from comment #6)
Don't worry, take care.
Could you setup a redirect in Apache to help debug what specifically goes on here? I don't yet know which status code Apache is returning and which Headers. It would be really helpful if you can setup an endpoint on your server for debugging the issue. I'm especially interested in the output of
curl -I http://keep.education/your-redirect-endpoint. I'm also interested in how the Apache.htaccessline for the redirect looks like to be able replicate the setup.That would also help me verify the difference to Chrome.
We use shared hosting as a re-seller so we have no access to the server other then through cPanel or FTP. However, the re-direct has to be set up, then you have to go to the website using Firefox, then the re-direct has to be removed, then you have to try to get to the original URL before the re-direct was set up.
Do you have an example for an URL with this specific redirect currently set? And how does the .htaccess line looks like? From https://www.redhat.com/sysadmin/beginners-guide-redirects-htaccess I see that the line would look like this:
Redirect 301 "/service" "https://newdomain.com/service"
I don't have an apache server at hand right now, but could set one up especially if I know which kinds of redirects exactly we are talking about.
|
Reporter | |
Comment 10•2 years ago
|
||
(In reply to Manuel Bucher [:manuel] from comment #9)
Do you have an example for an URL with this specific redirect currently set? And how does the
.htaccessline looks like? From https://www.redhat.com/sysadmin/beginners-guide-redirects-htaccess I see that the line would look like this:Redirect 301 "/service" "https://newdomain.com/service"I don't have an apache server at hand right now, but could set one up especially if I know which kinds of redirects exactly we are talking about.
Hi Manuel, I think if you have a domain say "aaaaa.com" and you set up the .htaccess in that root folder with the following:
Options +FollowSymLinks -Indexes
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://www.yourotherdomain.com/$1 [R=301,L]
Then when you go to https://aaaaa.com you should end up at https://www.yourotherdomain.com using Firefox and this will trigger Firefox to remember the redirect. Then remove the above code in .htaccess and try and go to https://aaaaa.com you will always end up at https://www.yourotherdomain.com
If at the same time you also try the same using Google Chrome, or Edge, you won't be stuck with never being able to get to https://aaaaa.com
Thanks for providing the info. This will be enough to investigate. (I somehow missed the comment two months ago).
|
||
Updated•2 years ago
|
|
|
||
Comment 12•1 year ago
|
||
Kershaw - since Bug 968273 landed a year ago (after this bug was discussed), perhaps this can be closed?
|
||
Comment 13•1 year ago
|
||
(In reply to Randell Jesup [:jesup] (needinfo me) from comment #12)
Kershaw - since Bug 968273 landed a year ago (after this bug was discussed), perhaps this can be closed?
Yes, I think we can close this bug.
Thanks.
Description
•