The Linux and Unix Menagerie

Hey there,

Following up on yesterdays post on 301 redirects , which we realize is a tired subject, today we're going to take look at simple ways you can do regular/subdomain redirection using htaccess and "mod_rewrite" for Apache on Linux or Unix. And, while yesterday's subject matter (and perhaps even today's) may be somewhat generic, we're trying to even the balance here. Now that we're in the 500's on post count, we feel it would be a shame if somebody came here to learn something really cool and then couldn't find some other really basic information. As written previously, if this blog's subject matter were more limited this would be much easier to do. On the bright side, we'll probably never run out of things to write about :)

You can reference the basics of mod_rewrite syntax and rules on the link provided that points back to apache.org. While this page (or pages it links to within the same site), obviously, covers all the aspects of using Apache's "mod_rewrite," the style may not be suited to everyone. It's great information, but assumes some level of comfort that you may or may not already have regarding the subject matter.

In our few examples today (which won't cover much but should be explained with a good amount of detail), we're going to use a file named ".htaccess" (the dot at the beginning of the name is important!) placed in our web server's root folder (or base folder, etc) which contains the "mod_rewrite" rules. Our first example will implement the equivalent of a 3xx redirect using "mod_rewrite" instead of the more conventional methods. In order to implement this, just place the following content in your .htaccess file (assuming, again, that we want visitors to www.myxyz.com to be redirected to www.myotherxyz.com):

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
Redirect 301 / http://www.myotherxyz.com

Looks familiar, yeah? We actually covered that yesterday, as it's one of the most basic rewrites you can do. We just added the "standard recommended" starting lines for your .htaccess file. Those top three lines aren't "always" necessary, which is why we didn't include them in yesterday's example.

Here's another example that shows you how to use "mod_rewrite"'s regular expression functionality to redirect from an htm(l) page on one web server to a page on another web server:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteRule ^(.+)\.htm$ http://www.myotherxyz.com/1ドル.html [R,NC]

This example doesn't do all that much more than the previous, but it "is" a lot more flexible. We'll walk through the RewriteRule, to see what it's doing (and, remember, all of the nitty-gritty can be found on Apache's mod_rewrite page ). The line itself, if you're familiar with basic regular-expression syntax, isn't too hard to decipher. The characters that are special in the line are the following:

^ <-- The caret indicates that the match is anchoring to the start of the request.
. <-- The dot character is representative of "any" alphanumeric character (including spaces, tabs, goofy characters, etc). It matches "anything"
\ <-- The backslash character "escapes" special match characters. In this case, we're using it to represent a "real" dot, rather than the regular-expression dot described above.
+ <-- The plus symbol indicates that the character preceding it must exist one or more times if the match is to be considered a success
$ <-- The dollar sign is the opposite of the caret. It indicates that the match is anchored at the end of the request
() <-- Anything within parentheses (on the left-hand-side, or LHS, of the expression) is considered to be a "captured" part of the match. It can be referenced on the right hand side (or RHS) of the rewrite rule using the dollar sign. This sign, as shown above, means something completely different on the RHS of the equation.
1,ドル 2,ドル 3,ドル etc <-- the dollar-sign-plus-number on the RHS of the expression represents the content of an LHS match (within the parentheses, as written above). The first parentheses match on the LHS is represented by 1,ドル the second by 2,ドル etc.
[] <-- Within the match rule itself, the brackets indicate a range, or "class" (a term that doesn't seem correct, but is used in the mod_rewrite terminology) of characters. For instance [abcd] would match the letter a, b, c or d. At the end of the mod_rewrite rule (as its final component) the characters within it hold special significance and "do not" represent a range. You can use more than one and just separate them with commas. In the example above they say that:
R <-- We're doing a "R"edirect. You can add an equals sign and the proper number if you want to be specific. So, a 301 redirect would look like [R=301] and make our expression's end look like [R=301,NC]
NC <-- Even though N and C both have special meanings of their own (in the final part of the rewrite rule), when used together as a single entity they mean that the matching-rule should be "case insensitive" NC equal "No Case" if that helps ;)

And that's that one line. Explained with only 10 or 12 more ;) Basically, it matches any web server request (for an html page - a bit more than our other rule was looking for) and redirects it, like so:

ORIGINAL REQUEST: http://www.myxyz.com/iNdex.html (Sent to the web server as "/iNdex.html)
MATCHING RULES APPLIED: ^(/iNdex).html ==> http://myotherxyz.com//index.html

The double slashes are squashed into one by default, but you could remove them from the LHS of the match rule and make that "" "^(.+)\.htm$" into "^/(.+)\.htm$" - effectively removing the leading forward slash from the () parentheses match and its extrapolated value (1ドル) on the RHS.

The standard final argument indicators are listed on Apache's mod_rewrite page and below:

[R] Redirect. You can add an =301 or =302, etc, to change the type.
[F] Forces the url to be forbidden. 403 header
[G] Forces the url to be gone. 401 header
[L] Last rule. (You should use this on all your rules that don't link together)
[N] Next round. Rerun the rules again from the start
[C] Chains a rewrite rule together with the next rule.
[T] use T=MIME-type to force the file to be a mime type
[NS] Use if no sub request is requested
[NC] Makes the rule case insensitive
[QSA] Query String Append. Use to add to an existing query string
[NE] Turns off the normal escapes that are the default in the rewrite rule
[PT] Pass through to the handler (together with mod alias)
[S] Skip the next rule. S=2 skips the next 2 rules, etc
[E] E=var sets an enviroment variable that can be called by other rules

In our final example, if you want to redirect all sub-domains of a domain to another site (e.g. redirect home.myxyz.com to www.myxyz.com), you could do it like this:

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteRule %{HTTP_HOST} ^([^.]+)\.myxyz\.com$ http://www.myotherxyz.com [NC,L]

The %{HTTP_HOST} variable is translated from the variable provided by the standard HTTP headers. The L in the final argument means that, if this match is made, it will be considered the last match and no more rules in your .htaccess file will be processed. In our small example this doesn't really make a difference, but it can help with flow control if you have multiple rules and want to quit matching if you match this condition.

Hopefully today's quick run-down has been helpful. Let us know - too much information, not enough, not-enough-of-some-but-too-much-of-another? We're always interested in hearing your thoughts :)

Cheers,

, Mike

Posted by Mike Golvach at 12:31 AM  

301, apache, htaccess, linux, match, redirect, regular expression, unix

Hey there,

Today we're going to look at simple ways you can do site redirection using a few basic methods for Apache on Linux or Unix. I'd presume that the functionality works exactly the same for Apache on Windows, but that would (to misquote a cliche) make a "pres" out of "u" and "me" - yeah, the "assume" version of that plays much nicer ;) Tomorrow, we're going to follow up with more advanced ways to do site and subdomain redirects using "mod rewrite".

Site redirection, in and of itself, is fairly easy to do with just straight-up HTML or PHP, but it has its limitations. For instance, if you wanted everyone who visited www.myxyz.com to be redirected to www.myotherxyz.com, all you'd have to do would be to add some simple code to your index.htm(l) or index.php file. In HTML, you could just add this line in the <head> section:

<meta http-equiv="refresh" content="30;url=http://myotherxyz.com/">

This would allow for thirty seconds to pass before the redirect was called. You might want to make that shorter or longer, depending upon how much interactivity you wanted your visitor to have before being redirected. You may want to allow them to use the old site if they want and redirect them if they don't click on a link in 30 seconds, or something like that. If you really want them to not have any choice, try setting the time (content) to 0. Although this, technically, redirects immediately, depending on someone's connection, the server hosting the website, etc, slow page load could cause the user to see the original page before it refreshes to the new site. If you're only using a page for this purpose, you should leave the body blank or with just a similar background image as your new site.

PHP is a bit faster, although still subject to the limitations of the interacting components that affect the HTML redirect (although not to the same degree). In PHP, you could do the same thing with this little chunk of code:

<?
Header( "HTTP/1.1 301 Moved Permanently" );
Header( "Location: http://www.myotherxyz.com/" );
?>

The most efficient method (of the three we're going run through here today) is to use htaccess. This point will be expanded upon to a good degree in tomorrow's post, since the combination of htaccess and "mod rewrite" can allow you to do a lot more than just standard redirection. Using htaccess, you could create a file called, strangely enough, .htaccess in your site's main directory (or root or home directory, or base directory or whatever you prefer to call it) that contained the same directions as above, although with yet another syntax. A simple 301 site redirect in .htaccess can be written this simply (the entire file from top to bottom):

redirect 301 / http://www.myotherxyz.com/

It just doesn't get any simpler than that :) For the htaccess method, since there are no double quotes surrounding your arguments (old-site-name new-site-name) you need to double quote any addresses that include spaces. Simple enough:

redirect 301 "/my old index.html" http://myotherxyz.com/

And that's all there is to it! For a little bit of trivia, you may have noted that we ended all of our redirect destinations with a closing / ( www.myotherxyz.com/ as opposed to www.myotherxyz.com ). The reason we do this is actually still standard protocol. You can actually do the test yourself right now to prove it out. When you send a standard web server a URI request for, say, http://www.google.com (for instance), that actually generates a 301 site redirect and plops you at http://www.google.com/, which is the properly formatted address. It happens very quickly and, of course, only counts when you're requesting a directory. If you specify a file, like http://www.google.com/index.html, you'll either get the page you were expecting or some other error (perhaps even a 301), although it should be noted that some web servers don't do this anymore in all instances (http://www.google.com/news, for example). Still, being a dinosaur, I prefer to stick to the way that should always work.

Give it a shot. It might be more fun than pick-up-sticks ;) If you find a site that does it, you can see the redirect in action using simple Telnet. Take this example using http://abc.go.com/daytime (Although this page actually does a 302 redirect - for temporary redirection - right now and takes you to a specific index page) - I grew tired of trying to find sites that use 301 redirection on sub-directories and you can't telnet to any server and not request a page, unless you want that 404 ("GET /" works, but proving the redirect by doing "GET " doesn't ;)

$ telnet abc.go.com 80
Trying 198.105.194.116...
Connected to abc.go.com.
Escape character is '^]'.
GET /daytime HTTP/1.0

HTTP/1.1 302 Found
Connection: close
Date: 2009年2月26日 00:19:27 GMT
Location: /daytime/index?pn=index
Server: Microsoft-IIS/6.0
P3P: CP="CAO DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAi IVDi CONi
 OUR SAMo OTRo BUS PHY ONL UNI PUR COM NAV INT DEM CNT STA PRE"
From: abc07
Set-Cookie: SWID=54AE3DC5-FB42-4F6C-8B10-82E506FFD442; path=/;
 expires=Thu, 26-Feb-2029 00:19:27 GMT; domain=.go.com;
Content-Length: 163
X-UA-Compatible: IE=EmulateIE7

<HTML><HEAD><TITLE>Moved Temporarily</TITLE></HEAD><BODY>This document
 has moved to <A HREF="/daytime/index?pn=index
">/daytime/index?pn=index
</A>.<BODY></HTML>Connection closed by foreign host.

Posted by Mike Golvach at 12:41 AM  

301, apache, htaccess, linux, php, redirect, subdomain, unix

Hey there,

Today we're going to take a look at creating new "types" for use with Veritas Cluster Server (VCS). In a broad sense of the term, almost everything you'll ever define in your main.cf (the main configuration file for VCS) is based on a specific "type," which is actually described in the only standard include file in that configuration file: types.cf - Note that both main.cf and types.cf are located in /etc/VRTSvcs/conf/config. You could move the types.cf to an alternate location fairly easily and only have to modify the "include" line in main.cf, but it's not recommended. VCS has the potential to make your life miserable in many built-in ways ;)

For instance, if you had an entry like this in your main.cf:

Apache httpd_server ( 
 httpdDir = "/usr/local/apache" 
 HostName = www
 User = nobody
 ConfigFile = "/usr/local/apache/conf/httpd.conf" 
 )

type Apache (
 static str ArgList[] = { ResLogLevel, State, IState, httpdDir, SharedObj
Dir, EnvFile, HostName, Port, User, SecondLevelMonitor, SecondLevelTimeout, Conf
igFile, EnableSSL, DirectiveAfter, DirectiveBefore }
 str ResLogLevel = INFO
 str httpdDir
 str SharedObjDir
 str EnvFile
 str HostName
 int Port = 80
 str User
 boolean SecondLevelMonitor = 0
 int SecondLevelTimeout = 30
 str ConfigFile
 boolean EnableSSL = 0
 str DirectiveAfter{}
 str DirectiveBefore{}
)

 Port = 8080

Apache regular_server ( 
 httpdDir = "/usr/local/apache" 
 HostName = www
 User = nobody
 Port = 80
 ConfigFile = "/usr/local/apache/conf/httpd.conf" 
 )
 
Apache alternate_server ( 
 httpdDir = "/usr/local/apache" 
 HostName = www
 User = nobody
 Port = 8080
 ConfigFile = "/usr/local/apache/conf/httpd.conf" 
 )

host # ls /opt/VRTSvcs/bin/Apache
Apache.pm ApacheAgent monitor online
Apache.xml clean offline

host # cp -pr /opt/VRTSvcs/bin/Apache /opt/VRTSvcs/bin/ApachE8080
host # ls /opt/VRTSvcs/bin/ApachE8080
Apache.pm ApacheAgent monitor online
Apache.xml clean offline
host # diff -r /opt/VRTSvcs/bin/Apache /opt/VRTSvcs/bin/ApachE8080
host # <-- In this case, no news is good news :)

type ApachE8080 (
 static str ArgList[] = { ResLogLevel, State, IState, httpdDir, SharedObj
Dir, EnvFile, HostName, Port, User, SecondLevelMonitor, SecondLevelTimeout, Conf
igFile, EnableSSL, DirectiveAfter, DirectiveBefore }
 str ResLogLevel = INFO
 str httpdDir
 str SharedObjDir
 str EnvFile
 str HostName
 int Port = 8080
 str User
 boolean SecondLevelMonitor = 0
 int SecondLevelTimeout = 30
 str ConfigFile
 boolean EnableSSL = 0
 str DirectiveAfter{}
 str DirectiveBefore{}
)

Apache regular_server ( 
 httpdDir = "/usr/local/apache" 
 HostName = www
 User = nobody
 ConfigFile = "/usr/local/apache/conf/httpd.conf" 
 )
 
ApachE8080 alternate_server ( 
 httpdDir = "/usr/local/apache2" 
 HostName = www
 User = nobody
 ConfigFile = "/usr/local/apache2/conf/httpd.conf" 
 )

Posted by Mike Golvach at 12:26 AM  

apache, cluster, linux, main.cf, server, types.cf, unix, veritas

Hey there,

In an older post, we went into some small detail about ignoring HTTP headers when using bash to access the network. Today we're going to look at that from another angle and consider how you can, at least somewhat, protect yourself from a clearly defined outside attack by mocking up your HTTP headers using Apache.

For this simple test, we used the 3 latest versions of the three separate build trees of the Apache HTTPD Server: versions 1.3.41, 2.0.63 and 2.2.8. All three versions were compiled on RedHat Linux, SUSE Linux and Solaris Unix.

While all of these versions provide for some measure of protection within the httpd.conf file (such as turning the server signature on or off, allowing you to fake your hostname, letting you fool with server tokens, etc), if you want to truly utilize security-through-obscurity with Apache, your starting point should be at the source code level. Of course, if you use a pre-packaged binary, you might no be able to do any of this, short of recompiling a vendor package, which might cause more harm than good...

As a quick note to source-code builders who run Apache with mod_ssl, please keep in mind that mod_ssl generally checks the Apache include files to determine whether or not the version of Apache it's being compiled against is the correct one. If you "do" use this sort of setup, be sure to compile mod_ssl first, make these changes and then compile Apache. Or you could compile Apache this way, change the include back to the way it was, compile mod_ssl and go from there. Whatever suits your particular style is OK :)

The main (and by main, I mean "only" ;) trick here is to change what the Apache HTTPD server thinks it is (The version that it spits out of the httpd binary). All of the configuration file mangling you do won't stop Apache from reporting its true version given a particular set of circumstances.

Luckily, this modification is very easily achieved, and can be set in one file (before running configure and make). Depending on how crazy you want to get, you can mislead attackers so that they attempt to use outdated exploits against your site or (if you get too creative) let them know that they can't be sure what version of Apache you're running... if you're running Apache at all. The biggest trick in all this, after a while, might just be remembering what version you really "are" running ;)

For Apache 1.3.x, you can change these fields in the source_dir (wherever you untar the source files) under the src/include directory in the httpd.h file:

#define SERVER_BASEVENDOR "Apache Group"
#define SERVER_BASEPRODUCT "Apache"
#define SERVER_BASEREVISION "1.3.41"

If you want, you could make this:

#define SERVER_BASEVENDOR "HTTPD Consortium Group"
#define SERVER_BASEPRODUCT "SpyGlass"
#define SERVER_BASEREVISION "3.2"

And, instead of a user seeing this when they hit the right error page (or nail your server directly):

Server: Apache/2.2.4 (Unix)

They'd see this:

Server: SpyGlass/3.2 (Unix)

And that's just from a telnet to port 80. The other information could be gotten other ways. In any event, whoever gets it will be misinformed :)

For both the 2.0.x and 2.2.x strains of Apache's HTTPD server, the file you'll need to modify is in the source_dir, in the include directory, in the file ap_release.h.

For 2.0.x - Modify these lines to suit your taste:

#define AP_SERVER_BASEVENDOR "Apache Software Foundation"
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_MAJORVERSION_NUMBER 2
#define AP_SERVER_MINORVERSION_NUMBER 0
#define AP_SERVER_PATCHLEVEL_NUMBER 63
#define AP_SERVER_ADD_STRING ""

For 2.2.x, the file name and location are the same, and there is only one additional line added that you can/should manipulate:

#define AP_SERVER_BASEVENDOR "Apache Software Foundation"
#define AP_SERVER_BASEPROJECT "Apache HTTP Server"
#define AP_SERVER_BASEPRODUCT "Apache"
#define AP_SERVER_MAJORVERSION_NUMBER 2
#define AP_SERVER_MINORVERSION_NUMBER 2
#define AP_SERVER_PATCHLEVEL_NUMBER 8
#define AP_SERVER_DEVBUILD_BOOLEAN 0

For the AP_SERVER_DEVUILD_BOOLEAN, you can change the value to 1 and the string "-dev" will be added. This is essentially the same as the AP_SERVER_ADD_STRING variable in 2.0.x, but slightly less flexible.

Here's to having fun making up server names or (even better) resurrecting old ones that haven't been around since I was a teenager :)

Cheers,

, Mike

linux unix internet technology

Posted by Mike Golvach at 12:09 AM  

ap_release.h, apache, headers, httpd, httpd.h, include, linux, mod_ssl, server, unix, version

Howdy, Late nighters :)

Here's a tip if you're looking to capture any old error message with apache and want to do something creative with it.

The default server action is usually good enough, but, sometimes you might want to do something extra (like redirect to a script that does a little something extra on your backend, redirect to internal or external links that will show up in reports or just make your error messages fun ...Is that possible?)

The "ErrorDocument" keyword is used for exactly this purpose. Here are a few examples below (all scripts, sites, paths, etc, are purely made up and probaby don't reflect your server configuration)

The syntax is: ErrorDocument ErrorNumber Action(First is plain text, next two are internal redirects, last is external)
ErrorDocument 301 "You got an error 301. Awesome!"
ErrorDocument 301 /public_html/errors/error_301.html
ErrorDocument 301 /cgi-bin/someErrorHandlingProgram.pl
ErrorDocument 301 http://www.errrors.com/error301.html

If there's interest, there might be something to doing some real custom whiz-work in a perl/cgi script to really "handle" errors :P

, Mike

linux unix internet technology


affiliate program

Posted by Mike Golvach at 10:56 PM  

administration, advice, apache, capture, capturing errors, errors, internal handler, linux, scripting, technology, tips, unix

If you need to replace a number of characters, and don't know how many times they're going to show up in a URL, here's how to make sure they get replaced using Apaches mod_rewrite.

The key here isn't really to do the substitution, but to do it any number of times (undetermined) and only redirect the client once!

RewriteRule ^/(.*)A(.*)$ /1ドルa2ドル [N,E=redir:yes]
RewriteRule ^/(.*)B(.*)$ /1ドルb2ドル [N,E=redir:yes]
RewriteCond %{ENV:redir} ^yes$

The RewriteRule lines can be as many as you like. The important thing is that, in the third part of the rule, N instructs mod rewrite only to redirect internally (rewrite without notifying the user browser) and set the environment variable redir to yes.

Then the RewriteCond line sends the redirect to the user browser once your URL is completely rewritten.

Enjoy :)

, MIke

linux unix internet technology


affiliate program

Posted by Mike Golvach at 4:47 PM  

administration, advice, apache, linux, mod_rewrite, muliple urls, scripting, single redirect, technology, tips, unix

• ▼ 2011 (1)
  • ▼ January (1)
    • Updated Post: Arbsorption Of Knowledge In The Com...

• ► 2010 (2)
  • ► December (1)
  • ► January (1)

• ► 2009 (179)
  • ► June (28)
  • ► May (31)
  • ► April (30)
  • ► March (31)
  • ► February (28)
  • ► January (31)

• ► 2008 (366)
  • ► December (31)
  • ► November (30)
  • ► October (31)
  • ► September (30)
  • ► August (31)
  • ► July (31)
  • ► June (30)
  • ► May (31)
  • ► April (30)
  • ► March (31)
  • ► February (29)
  • ► January (31)

• ► 2007 (101)
  • ► December (36)
  • ► November (36)
  • ► October (25)
  • ► September (4)