I used the following code in the htaccess to put my site under maintenance and show the visitors maintenance.html.
#Options +FollowSymlinks
#RewriteEngine on
#RewriteCond %{REQUEST_URI} !/maintenance.html$
#RewriteRule $ /maintenance.html [R=302,L]
My site is now back online but now I see that all those browsers that tried to go on my site during the maintenance, they are still getting the maintenance.html.
It works if I clear the browser cache and I sort of understand why it is happening. I think the browser caches the redirect and is still doing it.
How can I clear this issue?
You should be able to use mod_header to tell browsers not to cache your maintenance page.
Header merge Cache-Control no-cache
Header merge Cache-Control no-store
Related
I have a website that has in the homepage a forums (created with Xenforo). I have recently put HTTPS with Let's encrypt (I have enabled it server-side with cPanel). The website worked fine with HTTP.
Now that I have HTTPS I am having issues because some people can access the website as always but others cannot. The ones who can't open my website have to use a proxy and then the website loads.
This error has started happening after I have edited a line in my .htaccess file:
# Mod_security can interfere with uploading of content such as attachments. If you
# cannot attach files, remove the "#" from the lines below.
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
ErrorDocument 401 default
ErrorDocument 403 default
ErrorDocument 404 default
ErrorDocument 405 default
ErrorDocument 406 default
ErrorDocument 500 default
ErrorDocument 501 default
ErrorDocument 503 default
<IfModule mod_rewrite.c>
RewriteEngine On
# I HAVE ADDED THESE 2 NEW LINES
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://forums.example.com/$1 [R,L]
# If you are having problems with the rewrite rules, remove the "#" from the
# line that begins "RewriteBase" below. You will also have to change the path
# of the rewrite to reflect the path to your XenForo installation.
#RewriteBase /xenforo
# This line may be needed to enable WebDAV editing with PHP as a CGI.
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^(data/|js/|styles/|install/|favicon\.ico|crossdomain\.xml|robots\.txt) - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]
</IfModule>
I have added these 2 lines:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://forums.example.com/$1 [R,L]
And now I have this weird issue: some people can access my website, others cannot and they have to use a proxy!
I have added those rules because I need to redirect all http to https so http://forums.example.com/ must become https://forums.example.com/. I have never had this issue before. Any idea?
First
What's the specific error message that these people are getting?
When I was building Greenlock I encountered a similar problem and it turned out to be that that certificate was not being loaded correctly, so I'm assuming that this is a TLS "privacy error" from the browsers, not a DNS or HTTP issue.
Next
I'm not familiar with cPanel, but I am very familiar with the ACME standard and clients.
Greenlock, certbot, and many other Let's Encrypt clients use a convention of naming the certificate files like this:
privkey.pem
cert.pem
chain.pem
fullchain.pem (cert.pem + chain.pem)
Some also have bundle.pem (fullchain.pem + privkey.pem).
Many web servers call for CRT and KEY in their documentation. Intuitively you might think that CRT would be cert.pem and KEY is privkey.pem.
This is usually incorrect.
CRT is fullchain.pem
If your site is configured to use cert.pem as the CRT instead of fullchain.pem you will have the issue you describe.
The reason is that anyone who has visited any site that properly uses the same intermediate authority as you will see the page as intended - the necessary chain.pem will already exist in the browser's cache.
However, anyone with a browser that doesn't have that missing piece already in a cache will get a security error.
Why would it work through a proxy?
It depends on the type of "proxy" - because that can mean different things to different people.
My guess is that the proxy is being used for more sites than the person's browser is (particularly a lot of small hobbyist sites that are using that same chain) and perhaps the proxy is actually downloading the site, decrypting it, and then relaying it, or perhaps the proxy is somehow supplementing the certificate chain with its own cache.
Possible Solution for Browser Privacy Error
Your problem may be completely different from the problem that I've had. It may be coincidence that the symptoms sound so similar.
I don't want to lead you down a rabbit hole that won't get you anywhere, but I think that checking your settings to make sure that you're using fullchain.pem and not cert.pem is an important first step.
Possible Solution for .htaccess Redirects
The issue with the redirects sounds coincidental to me. I doubt it's related.
Most likely once your site forced https, more visitors with the browsers that didn't have Let's Encrypt intermediate certificates in their caches suddenly started to notice the problem because they were now affected.
However, if you can back out those changes and confirm that HTTPS (SSL-enabled) works for those users, then I'd suggest that instead of doing redirects that you try adding headers that will do the same:
Upgrade-Insecure-Requests: 1
Strict-Transport-Security: max-age=86400
I have a site which is configured to run on https:
https://www.domain.com.au/
I added the following to htaccess right at the top to redirect all non-https queries:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
But, when I access http://www.domain.com.au/ it doesn't redirect as expected an instead I get a 302 redirect to a page that says:
Found
The document has moved here.
Additionally, a 302 Found error was encountered while trying to use an
ErrorDocument to handle the request.
"here" is just a link to the same http URL in the address bar
I was using cloudflare so I have grey clouded the domain to remove
additional confusion and it's been switched off for a day now.
It's a WordPress site and I have W3TC installed which I have also deactivated to remove confusion
I don't know where to look or how to debug? Any advice on where to start looking would be appreciated.
I think you might need to add the [L,R=301] flags to your rule?
Also - you can achieve this within CloudFlare automatically by enabling "Always use HTTPS" (if you have an active CloudFlare SSL certificate) and the 'orange cloud' enabled.
I'm going to enable mod_rewrite (modsecurity ) in Cpanel and here is my htaccess, please advice me how to enable it.
RewriteEngine on
RewriteCond $1 !^(index\.php|images|public|assets|uploads|themes|install|updates|asset|mob|robots\.txt)
RewriteRule ^(.*)$ index.php?/$1 [QSA,L]
<FilesMatch "\.(jpg|jpeg|png|gif|swf|css)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
Thanks in advance
As per your provided .HTACCESS code, mod_rewrite is already enabled..
RewriteEngine on
While Mod_security can not be enabled/disabled from cPanel end. If you have access to server OR WHM panel then you can do it and make sure you have compiled APACHE to enabl mod_security, otherwise contact your hosting provider to do it for you.
You can find APACHE compile for mod_security details from here...
mod_rewrite is not the same thing as mod_security. The first allows you to create custom rewrite rules in an .htaccess file like the ones you have mentioned. Mod_security is a security module for apache (protects your website against php sql injection attacks, xss etc).
mod_rewrite is enabled by default on a fresh cPanel/WHM install.
What is exactly not working on your actual config/setup?
I stupidly did a 301 redirect on websiteA.com to websiteB.com. After removing it from the .htaccess file the redirect is still in operation. I tried from outside the local network and it is still redirecting. I have cleared my cache and tried a different browser.
Does anybody have any suggestions?
UPDATE:
If I add a 302 redirect to this .htaccess file the site honours it. When I remove it, the old 301 redirect still happens.
.htaccess file for websiteA.com:
# -- concrete5 urls start --
Options -Indexes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end --
#RewriteCond %{HTTP_HOST} ^.*$
#RewriteRule ^/?$ "http\:\/\/www\.websiteB\.co\.uk\/" [R=301,L]
Try to visit the website with Developers Console open (F12)
Make sure you check "Disable cache" under "Network" tab
This will bypass 301 redirect cache on browser-side.
The browser caches the 301 Moved Permanently, until told otherwise. It is default behavior: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2.
To fix it in IE9:
Open IE9 and press Ctrl+Shift+P for private browsing
Navigate to the problem URL
Then go back to normal browsing and all should be fine again
Just delete the line about the Redirect.
And also everyone who has Google Chrome, do the following steps:
Press CTRL + SHIFT + DELETE from your keyboard.
Only check -> "Files and images stored in cache"
Select in "Elements stored in cache since: Past week"
That will clear all your cache and you'll be fine.
The permanent redirect cache is probably in the browser
and in most browsers it is tricky to remove it.
But first, try using a different browser to see if this is the case.
In case the problem is in the browser:
This happened to me before and cleaning the browser data for that website was not enough.
I also realized that there is a trick for each browser.
In Safari (for Mac), I needed to select "Reset Safari..." (No panic, with this option neither bookmarks neither extensions are deleted).
I cannot recall how I did it for Chrome but was less traumatic.
The lesson
When playing with redirects use [302] first.
After everything was tested ok, change the code to [301]
I know this is an old post but i spent some time on the Web and my server to find the answer.
If you created an .htaccess file with a permanent redirection, the server will copy this redirection in the following file : "/var/.htaccess".
You have to edit this file to remove the redirection before cleaning the cache of your browser.
It worked on my Debian Jessie.
Try giving Apache a restart
(on Ubuntu servers: service apache restart or /etc/init.d/apache2 restart)
I have to put a site down for about half an hour while we put a second server in place. Using .htaccess, how can I redirect ANY request to domain.com to domain.com/holding_page.php?
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !/holding_page.php$
RewriteRule $ /holding_page.php$l [R=307,L]
Use 307 (thanks Piskvor!) rather than 302 - 307 means:
The requested resource resides
temporarily under a different URI.
Since the redirection MAY be altered
on occasion, the client SHOULD
continue to use the Request-URI for
future requests.
As I came across this problem, here is the solution I used (brief explanations in the comments):
RewriteEngine On
RewriteBase /
# do not redirect when using your IP if necessary
# edit to match your IP
RewriteCond %{REMOTE_ADDR} !^1\.1\.1\.1
# do not redirect certain file types if necessary
# edit to match the file types needed
RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif|css)
# this holding page that will be shown while offline
RewriteCond %{REQUEST_URI} !^/offline\.html$
# use 503 redirect code during the maintenance job
RewriteRule ^(.*)$ /offline.html [R=503,L]
ErrorDocument 503 /offline.html
# bots should retry accessing your page after x seconds
# edit to match your maintenance window
Header always set Retry-After "3600"
# disable caching
Header Set Cache-Control "max-age=0, no-cache, no-store"
Besides the additional conditions and headers, the main idea is to use a 503 status code when you are doing a maintenance job.
The 503 code stands for Service Unavailable, which is exactly the case during the maintenance. Using this will also be SEO friendly as the bots won't index the 503 pages, and they will come back later-on after the specified Retry-After to look for the actual content.
Read more details here:
Use a 503 HTTP status code (from a person who worked at Google) - https://plus.google.com/+PierreFar/posts/Gas8vjZ5fmB
Redirect Site to Maintenance Page using Apache and HTAccess - http://www.shellhacks.com/en/Redirect-Site-to-Maintenance-Page-using-Apache-and-HTAccess
HTTP 503: Handling site maintenance correctly for SEO - https://yoast.com/http-503-site-maintenance-seo/
This works better...
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !/holding_page.php$
RewriteRule $ /holding_page.php [R=307,L]