I don't understand why this Url:
www.hortadascanas.com
and this Url:
http://hortadascanas.com
are not pointing to the same page. If you look the content, you can see that icons don't show up at the 2nd adress...Actually It seems to me that the 2nd Url links to an older version of the page.
I thought the "www" was a shortcut of "/public_html".
If I try with this address http://hortadascanas.com/location it is redirected to http://www.hortadascanas.com/location but the home page is not redirected.
What is happening ?
EDIT
This is what I have in my .htaccess file:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
I guess I have to remove some lines because the site crashes if I add the lines you gave me....I have redirections loops...
EDIT 2
Should I delete this red line and recreate one pointing to the alias www.hortadascanas.com ?
This can be done by adding the following lines at the beginning of the .htaccess file in your public_html folder:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.hortadascanas.com [NC]
RewriteRule ^(.*)$ http://hortadascanas.com/$1 [L,R=301]
if you want to redirect both HTTP and HTTPS non-www Urls to www, you can combine rules as follows:
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [L,R=301]
For more information please read following :
https://www.siteground.com/kb/how_to_redirect_www_urls_to_nonwww/
Edit
In your case its because of CNAME in your cloudflare,please check complete guide for this,
https://help.ghost.org/hc/en-us/articles/223210747-Root-Domain-Setup-Using-CloudFlare
www.hortadascanas.com and hortadascanas.com are simply different hostnames.
They don't have identical DNS resolution:
[ ~ ]
[ user ][ user#workstation.local ] % host hortadascanas.com
hortadascanas.com has address 69.195.124.135
hortadascanas.com mail is handled by 0 mail.hortadascanas.com.
[ ~ ]
[ user ][ user#workstation.local ] % host www.hortadascanas.com
www.hortadascanas.com has address 104.27.134.235
www.hortadascanas.com has address 104.27.135.235
www.hortadascanas.com has IPv6 address 2400:cb00:2048:1::681b:86eb
www.hortadascanas.com has IPv6 address 2400:cb00:2048:1::681b:87eb
You end up talking to two different computers depending on which hostname you use.
Running the IP addresses through whois we can see that www.hortadascanas.com is handled by Cloudflare, who provide a CDN and caching service.
Actually It seems to me that the 2nd Url links to an older version of the page.
Presumably Cloudflare is loading the data from 69.195.124.135 and caching it … so it is an older version of the page.
Even if the two hostnames' DNS resolved to the same computer, you could still get different content. Name based virtual hosting allows multiple websites to share a single IP address. The Hostname is included in the HTTP request header so the server can determine which site to return.
Related
When we enter example.com in browser address bar it will redirecting to https://example.com and also inner pages working (redirecting to https site),
Issue 1:
When we enter www.example.com in browser address bar it is not redirecting to https://www.example.com and Site loading without https, but inner pages are redirecting to https
Issue 2:
https://example.com/file.php shows current content, but http://www.example.com/file.php shows old content, We checked in Incognito mode and clearing the caches
Issue 3: (this may be the root cause of the issues)
When we are seeing the $_SERVER parameters by accessing the url http://www.example.com/server.php shows HTTPS value as on
We print_r the $_SERVER in server.php file
Environment:
Godaddy VPS Server
Apache 2.3.1 (mod_rewrite enabled)
PHP 5.4.45
Wordpress
Valid SSL Certificate Configured - Required Ports are opened (80, 443)
In Wordpress Settings,
we placed https address for both Site url and Home page url as https://example.com
we used the below code in .htaccess for redirection
RewriteCond %{HTTPS} !on [OR]
RewriteCond %{HTTP_HOST} ^www\.example.com$
RewriteRule ^(.*)$ https://example.com%{REQUEST_URI} [L,R=301]
And we also checked in below sites and they are showing positive response for SSL
https://www.sslshopper.com, whynopadlock.com
Everytime We checked by clearing cache and cookies
DNS Records:
A (Host)
Host # Points To xx.xx.xx.xx with TTL 600 Seconds
CName (Alias)
Host www Points To # with TTL 1 Hour
Please suggest how can i resolve this issue with www.example.com to https
I am using below code in .htaccess file to redirect http request to https.
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{HTTP_USER_AGENT} !MSIE/[1-8]\. [NC]
RewriteCond %{HTTP_HOST} www.example.com
RewriteRule ^.*$ https://www.example.com%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} ^www.%{HTTP_HOST} is an invaild condition and it never returns true because you can not use server variable in RewriteCond's pattern. You can use Regex based pattern like the following :
RewriteCond %{HTTP_HOST} ^www\.example.com$
So i had a wordpress blog in wordpress.com. I mapped the domain name to it through godaddy.
The domain name was https://domain.com/ when it was active on wordpress.com however i moved my site to a self hosted site and adjusted the domain accordingly to point to fatcow subdirectory.
After mapping the site i noticed that in firefox i was able to see my self hosted website but in other browsers like chrome and IE i could not i would get the message below.
Your connection is not private
Attackers might be trying to steal your information from pogosmart.com
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID"
I also noticed that the site was going to Https not http, i have not purchased an SSL cert so i don't understand why i had access to https when i was hosted in wordpress.com... now that i am not, the domain still uses https.
How can i make my website http://domain.com/ instead of https://domain.com/ https is causing a "your connection is not private" error.
If this is not enough information let me know
You'll need to check two places.
One is the WordPress setting for the site's URL. If you can log into the dashboard, you can find it under general settings. Just take the 's' out of 'https' in the URL.
If you can't log into WordPress, you'll need direct access to the database, probably through phpMyAdmin. Browse the wp_options table, and locate options named 'siteurl' and 'home' and change both to remove the same 's'.
Next, check for a file in the root of your WordPress site called .htaccess. This may contain some code that redirects incoming traffic to the secure version of your URL.
Remove anything like:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://domain.com/$1 [R,L]
Your .htaccess should only contain something like:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase //
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . //index.php [L]
</IfModule>
# END WordPress
... and maybe some extra stuff from any security plugins you may use.
Initially used a 301 to redirect www.example.com/ → www.example.com/wp
Unfortunately, I didn't read all the 'don't use 301 unless your 100% sure it's permanent' and now I need to revert back to the original domain.
At first, I tried to do a regular site url/wordpress url change in Setting/General in the admin dash. Saved over the old .htaccess on the root that had the original 301 redirect. Didn't work.
I moved everything to the root directory because I was getting a 'This webpage is a redirect loop' error page. Cleared cache on all browsers. Still getting the redirect loop error page.
Checked my url redirection here: http://www.digitalcoding.com/tools/url-redirect-check.html
I have two prompts, the first is going through fine, the second is a big fat X in red:
301 Moved Permanently: www.example.com/ → www.example.com301 Another Redirect Detected: www.example.com
.htaccess looks like this:
#Use PHP 5.4
AddType application/x-httpd-php54 .php
<IfModule mod_suphp.c>
suPHP_ConfigPath /opt/php54/lib/php.ini
</IfModule>
ErrorDocument 401 default
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Any insight?
Redirect 301 / http://www.example.com/
You get an endless loop because there is nothing in that code to tell it not to redirect www.example.com to itself.
You are correct that you cannot use the Redirect directive, and this is the reason; It is unconditional, and will cause a loop in the scenario you describe.
In order to prevent the loop, you must find a way to tell the code not to redirect www.example.com to itself. This can be done by using mod_rewrite, and specifically, the RewriteCond directive in mod_rewrite, to test the requested hostname and act accordingly:
Options +FollowSymLinks -MultiViews
RewriteEngine on
#
# if requested hostname is non-blank
RewriteCond %{HTTP_HOST} .
# and if requested hostname is NOT "www.example.com"
RewriteCond %{HTTP_HOST} !^www\.example\.com
# redirect to same object in correct domain
RewriteRule (.*) http://www.example.com/$1 [R=301,L]
The first directive, Options, may or may not be required on your server. If it is not required, it may in fact not be allowed. Comment it out of you have trouble.
The second directive, RewriteEngine, is required once (and only once) at the top of your mod_rewrite code.
The third directive, the first RewriteCond, is only required if you do not use a name-based virtual (shared) server. It prevents an infinite loop if the client does not send a "Host" header with its request. Since it is impossible to access a name-based virtual server without a "Host" header, this line is not required on a name-based virtual server. No harm will come from leaving it in, except that it takes a little time to process it.
Note that this code will also redirect "example.com" to "www.example.com", and so serves to canonicalize your main domain name as well, preventing ranking dilution from having duplicate content on two variations of the domain.
We have become the victim of a vicious DDOS attack on a WordPress site.
Thankfully, they should be easily removed as they are GET requests with the string ?ptrxcz appended to the end of the URL.
With this in mind we have set up rules to give 403 permission error pages to requests that fulfill this using .htacess. The trouble is these don't appear to work with permalinks installed also.
Here is my full .htaccess file as it is.
RewriteEngine On
RewriteCond %{QUERY_STRING} .*ptrxcz.*
RewriteRule (.*) - [F]
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
The beginning part is redirecting users with ptrxcz to the 403 page. This works perfectly if I remove the WordPress rules underneath it, but with them included it just never works.
Frustratingly using a negative regex with the QUERY_STRING search works in reverse correctly (blocking everything except request with the query string, as so:
RewriteCond %{QUERY_STRING} !.*ptrxcz.*
(Note the added !)
Does anyone have any idea:
Why it doesnt work with permalinks
How I can make it work with permalinks
Why a negative regex on the query string works but not a positive one.
I had the same problem, but it was severe enough that I brought up a small web server to act as a front end and filter out these requests. The relevant iptables rule is:
iptables -A INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'ptrxcz_' -j DROP
It instructs the system to examine up to the first 70 characters of the request and if it finds 'ptrxcz_ ', to silently drop the request. I tried returning an error message, but the bandwidth consumed by the error code was not worth it considering there would never be a user on the other end of the connection to read the error.
I created a blog post describing the steps I took:
http://web.htcomp.net/?pageid=85&blogid=2
Larry
If you replace QUERY_STRING in the code above with THE_REQUEST then this works fine and does exactly as required within WordPress.
I am using .htaccess to accelerate a site with the following redirects:
request for http://example.com/images/name.jpg routed to http://i.example.com/name.jpg
request for http://example.com/css/name.css routed to http://c.example.com/name.css
From listening to the Stack Overflow podcast, I learned that this could make a site faster, since the browser can download more files simultaneously (apparently two streams per domain, although this is unconfirmed).
Indeed, the difference is dramatic; the page loads about five times as fast!
I have not touched the original folders and images -- I am just using mod_rewrite to change the addresses from example.com/images/ to i.example.com/:
rewritecond %{HTTP_HOST} !^i\.example\.com [NC]
rewriterule ^images/([^/]+)$ http://i.example.com/$1 [L]
rewritecond %{HTTP_HOST} !^c\.example\.com [NC]
rewriterule ^css/([^/]+)$ http://c.example.com/$1 [L]
The problem I have is that this technique works perfectly for image tags included in html, but doesn't work for images included via stylesheets:
img src=/images/logo.jpg works perfectly
background:url(/images/logo.jpg); does not work
The server error log contains the following entry:
File does not exist: /var/www/html/css/images, referer: http://example.com/page.html
This seems to imply that the rewrite rule is being applied incorrectly.
The stylesheets work if I use:
background:url(http://i.example.com/logo.jpg);
However, in order to avoid rewriting all the style sheets, I'd like to know: why doesn't url rewriting apply to stylesheets the way it does to html img tags.
[update1] This problem exists in Safari 4 Beta, Firefox 3.0.3, and Chrome, but the page works perfectly in IE6.
[update2] Adding [L,R=301] and [L,R=302] did not help.
[update3] I tried the following based on Gumbo's suggestion below:
Redirect externally if path doesn’t match host name:
rewritecond %{HTTP_HOST} !^i\.domain\.com$
rewriterule ^images/([^/]+)$ http://i.domain.com/$1 [L,R=301]
rewritecond %{HTTP_HOST} !^c\.domain\.com$
rewriterule ^css/([^/]+)$ http://c.domain.com/$1 [L,R=301]
Redirect internally; if there's an unnecessary folder name remove it (see server error above):
rewritecond %{HTTP_HOST} ^i\.domain\.com$
rewriterule ^images/([^/]+)$ $1 [L]
rewritecond %{HTTP_HOST} ^c\.domain\.com$
rewriterule ^css/([^/]+)$ $1 [L]
It still didn't work. Bizarrely, the server error is:
File does not exist: /var/www/html/css/var, referer: http://domain.com/page.html
I was able to resolve this by not trying to incorporate directories into the subdomains:
request for domain.com/images/ routed to i.domain.com/images/
request for domain.com/css/ routed to c.domain.com/css/
It works perfectly and is still extremely fast.
There seems to be a bug in modern browsers where a css request that is redirected will apply only the new domain, leaving the original directories as part of the request:
If a css image at url(domain.com/images/name.jpg) is redirected to i.domain.com/name.jpg, the browser will mistakenly request i.domain.com/images/name.jpg.
I found a way to solve this problem if all host names use the same virtual host:
# redirect externally if path doesn’t match host name
RewriteCond %{HTTP_HOST} !^i\.example\.com$
RewriteRule ^images/([^/]+)$ http://i.example.com/$1 [L,R=301]
RewriteCond %{HTTP_HOST} !^c\.example\.com$
RewriteRule ^css/([^/]+)$ http://c.example.com/$1 [L,R=301]
# redirect internally to the file
RewriteCond %{HTTP_HOST} ^i\.example\.com$
RewriteRule !^images/ images%{REQUEST_URI} [L]
RewriteCond %{HTTP_HOST} ^c\.example\.com$
RewriteRule !^css/ css%{REQUEST_URI} [L]
This will do the following:
http://example.com/css/foo externally to http://c.example.com/foo
http://c.example.com/foo internally to /css/foo
http://example.com/images/bar externally to http://i.example.com/bar
http://i.example.com/bar internally to /images/bar
As well as correcting mismatching paths and host names:
http://i.example.com/css/foo externally to http://c.example.com/foo
http://c.example.com/images/bar externally to http://i.example.com/bar
A mismatch occurs when the requested stylesheet http://example.com/css/foo is redirected to http://c.example.com/foo and an image URI reference like /images/bar inside the stylesheet is resolved from this new base URI and thus leading to http://c.example.com/images/bar instead of the initial http://example.com/images/bar.