This list assembles rule examples. It is just a collection of rules and
each rule is explained. In each example, only non-empty fields are listed.
To show variable term that should be replaced by the actual values of your
own server configuration:
server has to be substituted with your servers name, e.g. www.yourserver.com
serverIP has to be substituted with a folders name for a virtual
host
subfolder has to be substituted with a folders name for a virtual
host
In the "How it works" section, I will quote ("")
any rule text I am talking about.
Private Pictures
Shared and protected cgi-bin folder
Multi-Language Index Files
Redirection of outdated Links
Private Pictures [back]
This rule will prevent others to create links on their pages to pictures
on your server. This version restricts access to one virtual host, so you
should duplicate it for any virtual host you like to protect.
Path: /subfolder/*.{gif jpg jpeg}
Referer: http://{server serverIP}/*
Execute Condition: <P0>&<!R0>
Path Result: /subfolder/a_transparent.gif
Jump To: stop
How it works:
The "{gif jpg jpeg}" will match any of the three suffixes. I add
a "." in front of it and to match only paths that ends in ".xxx"I use a "*" to match anything in fron to of it.
The referer field will only match the servers name or ip number.
To create a boolean expression that will say "a match at Path: and
not a match at Referer", I use a "&" to add a AND and
inside the second reference I use "!" as NOT. Note, that using
"<P0>" or "<R0>" or any other reference
with an ending "0" will be very common in the condition field.
Compared to e.g. "<P2>" which will be the reference to the
second placeholder in the Path: field, "<P0>" will be the
boolean result of the question: "Was Welcome able to match all wildcards
in the field?".
The result field will simply change the path (whatever it was before) to
a path that points to a file in the virtual server root. If you create a
transparent 1x1 pixel GIF image and name it "a_transparent.gif"you will have nice results.
Shared and protected cgi-bin folder [back]
This rule is a global rule. It will change all requests to scripts in each
virtual hosts to point to the main cgi-bin folder. WebSTAR for example can
protect the execution of cgi scripts only if you use the root level cgi-bin
folder. To create a workaround, we use this rule to have shared and protected
scripts for all virtual hosts.
Path: /[^/]/cgi\-bin/*
Execute Condition: <P0>
Path Result: /cgi-bin/<P1>
How it works:
Assuming, that you only have 1 level deep subfolders for all virtual hosts,
the path field will first match anything to the second "/" (this
is the "/[^/]" part) and then match the string "cgi-bin/"(we escape the "-" because it is a reserved character) and anything
after it. So only URLs like "/welcome/cgi-bin/lasso.acgi$..."will be matched, but not "/foo/test/cgi-bin/cool.html"
The condition is a typical one. It just executes the rule if the path was
matched.
In the result, we strip the subfolder by not including it in the string.
As you can see, the path starts directly with "/cgi-bin" (note
that escaping is only allowed in the wildcard formulars) and adds the reference
to the "*" ("<P1>"). A reference will put the
text of the wildcard's match in the expression. In this rule, we are just
passing the stuff after the "cgi-bin/" string, so it will not
modify the path beyond "/cgi-bin/".
Multi-Language Index Files [back]
To show you, that you can create a set of rules for solving a problem, I
like to create three rules that will call two different index files - depending
on the language(s) the user has set in his/her browser. This needs to have
two index files in each directory: instead of "index.html", we
use "index-d.html" and "index-e.html". To the outside
world, the index file is always "index.html" and no link and no
bookmark or printed docs will ever contain "index.html" - even
not the html files on the virtual host. The first two rules will detect
the language tokens and then change the name of the index file to reflect
the language. The third rule will act as a default setting. If rule 1 +
2 fail to detect either "de" or "en", it will rename
to index file to your default language (in this example "index-e.html")
Path: /subfolder*/index.html
Language: *en*
Execute Condition: <P0>&<L0>
Path Result: /subfolder<P1>/index-e.html
Path: /subfolder*/index.html
Language: *de*
Execute Condition: <P0>&<L0>
Path Result: /subfolder<P1>/index-d.html
Path: /subfolder*/index.html
Execute Condition: <P0>
Path Result: /subfolder<P1>/index-e.html
How it works:
Rule 1 and 2 are almost the same. They check for a path ending in "/index.html".
This will even work with the root index file as the "*" will also
match an empty string. If the first rule changes the path, the second rule
will not match the "index-e.hml" anymore - this is what we want.
The language field will check if the token string contains either "en"or "de". Because the first rule will check first, a "en"will be prefered if both tokens exist.
Finally, the third rule will only match an unmodified "index.html",
so it is only executed if the first and the second rule didn't match.
Note 1: if you don't like to rename all of your index files, but just keep
"index.html" as the default language, you can modify the rules
to use only a second index file for the other language. This way, you only
have to create a second file fore each existing index file.
Note 2: Working with index files is really easy. Even if the path will not
contain the index file, but will end in a "/", Welcome is smart
enough to add the index file to the path before rules are executed. You
never have to deal with two cases.
Redirection of outdated Links [back]
If you have areas on your server that have changed or moved to another server,
you will get lots of error hits from search engines or bookmarks. Other
tools can redirect a single file, but with Welcome you can redirect any
number of grouped files. To do this, you need to know what these files have
common in their url path. If you know it, you can set up a rule that will
match all files in the group and redirect the request to the right location.
This rule will redirect all HTML requests in three different subfolders
to another server.
Path: /subfolder/{sales people updates}/*
Execute Condition: <P0>
Path Result: http://www.anotherserver.com/new/<P1>/<P2>
Redirection: checked
How it works:
The path field will match all paths that start with one of your virtual
host's subfolder (remember to replace "subfolder" with a real
name). The "{sales people updates}" will match (in this case)
three different folders and finally the "*" at the end will match
anything inside these three folders.
The condition is "<P0>" again - to execute this rule only
if the path has really the structure that will match path wildcard formular.
If the condition results in "true", all fields below the condition
are evaluated. Path Result will then set the path to a full specified URL
including the old folder (one of "sales,"people" or "updates")
and the rest of the path.
Note 1: that "<P1>" and "<P2>" will refer
to the wildcards used in (P)ath and that "<P1>" will refer
to the 1st wildcard ("{sales people updates}") and "<P2>"will refer to the 2nd wildcard ("*") counted from left to right.
The checkbox "Redirection" is used to not modify the path, but
to actually send out a redirect to the requesting client. In this case,
the request never gets to your server. It will be catched by Welcome.
Note 2: Because of the redirect, rule execution will stop with the first
rule that does a redirect. For rules that have the redirection checkbox
checked, you don't need to set the jump to field to "stop".
If you have an example of a good rule, or if you like to have a rule
added for a problem that you cannot solve, please contact me at pardeike@comcon.de. |