A badly-written (or malicious) script intentionally or otherwise using HTTP/1.0 to send requests received by an IP-based server (i.e. one having a unique IP address which therefore *can* be reached with an HTTP “Host” header) will lead to an infinite redirection loop. Since this violates his own stated preference “to minimize redirects,” it seems a no-brainer to support/properly-handle HTTP/1.0 requests by excluding blank hostnames from being redirected.

The same can be said for the uppercase domains: Sure, the *server* is case-insensitive, but do you want to rely on the “kindness of others” not go and create a bunch of mis-cased links to your site? Google and the other majors may sort this in their back-end processing, but what if they drop the ball? What about other search engines, are they that smart, too? I say, delete the [NC] and get on with it.

On the Web, one cannot discount the fact that many access requests come from incompetent and/or malicious scripters. I want my server’s function and my page’s SERP rankings under *my* control, thank you very much.

Please also note that the quotes around “.ht*” in the “<Files “.ht*”>” directive are “smart quotes” or “high-bit-set character-code quotes” and will either crater the server with a HTTP 500 Error, or just not work — and I haven’t got time to test which one right now.

For myself, I’d follow the Apache recommendation here, and use

<FilesMatch “^\.ht”>
Deny from all
</FilesMatch>

instead.
.

That’s the problem with .htaccess. It’s very compact, very powerful server configuration code. There’s often many ways to apparently achieve the same thing, but some might have flaws that have catastrophic consequences for rankings and traffic even though the code ‘appears’ to work. In addition there are many other ways to try to do some jobs that are totally inappropriate. I look back at code I wrote several years ago, and now change it in several ways using the various things I have learned since then.

RewriteCond %{HTTP_HOST} !^(www\.canonical-server-name\.com)?$ [NC]

In the interests of fixing all non-canonical incoming links, the proposed replacement does fix ALL of those problems. I prefer to redirect all non-canonical requests (incorrect protocol, sub-domain, domain, TLD, trailing period, port number, or combination of those) to the canonical form.

As for HTTP/1.0, it is so easy to add support for that, that it seems pointless to not do so. I know that most so-called HTTP/1.0 requests DO include a valid host header, but it only takes one request to arrive without and you potentially have a self-DOS problem on your hands.

Server names aren’t case sensitive. wWw.ExamplE.COM == www.example.com. Since URIs with just uppercase/lowercase differences in the server name part aren’t different at all, there’s no point in redirecting for cosmetic reasons. All uppercase server names may look pretty ugly, but technically that’s not an issue. Also, avoiding redirects when possible is a good idea.

I consider requests with a port number faulty, or even abusive, hence I redirect them. That works both for :80 (http) and :443 (https). We don’t deal with crappy AOL proxies from the last century any more.

As for HTTP/1.0 requests, those are rare nowadays, and mostly faked, that is they tell HTTP/1.0 but provide an HTTP/1.1 host header. True HTTP/1.0 requests are dead, those ancient user agents can’t even handle virtual hosts (many domains sharing one IP). So when there’s no point for anybody in performing HTTP/1.0 requests at all, why should I still support them?

Agree?

This line in particular:

RewriteCond %{HTTP_HOST} !^www\.canonical-server-name\.com [NC]

It fails to redirect www with port number or trailing period; also fails for wrong casing.

It also crates an infinite loop for HTTP/1.0 requests because host header is blank for HTTP/1.0 requests.

Simple solution, replace [NC] with $, and add ( ) and ?:

RewriteCond %{HTTP_HOST} !^(www\.canonical-server-name\.com)?$

There’s a nice tool to build .htaccess file directly on web with a simple form:

www . htaccesseditor . com /en.shtml [Delinked, the first .htaccess code generation I’ve tried produces utterly bullshit. If you use the code for www vs. non-www canonicalization from this page you create an exploit enabling negative SEO.]

Best regards, Riccardo Giuntoli.