| back | page: doc.redirect.html, rendered:2003-05-18 11:23 |
Redirection Primer
1 URL Primer
If you are a rookie in HTTP/URL stay tuned. Others may skip this section.1.1 Antonomy of an URL
A HTTP URL is splitted into the following parts (Actually this not quite complete, I know. But this is a primer. If you want to get more information, please consult the IETF RFCs)- a scheme part (either HTTP or HTTPS)
- an authority part ('the server')
- a path part (addressing a file or directory on the server (actually a 'resource' but this is not equal to a Looky resource))
- a query part (adding control parameters)
- a fragment part (a local position in the addressed file)
http://my.server.com/path0/path1/path2?foo=bar&bar=foo#here `---´ `-----------´ `---------------´ `-------------´ `--´ | | | | | scheme authority path query fragment
1.2 Path and Segments
The path part of an URL may be splitted into segments. Each segment is addressed by its position in the path starting with '0':seg-0/seg-1/seg-2/seg-3/seg-4
`---------------´
|
e.g. segment offset 1, length 3
1.3 Query and Parameter
The query part of an URL may be seen as dictionary (key, value) tuples. Each key defines a parameter with a given value.foo=bar&bar=foo&baux=ixi
`-----´ `-----´ `------´
|
e.g. have a parameter 'bar' with value 'foo'
2 Looky Redirector
The Looky balancer clients CGI and Squid are using the
's
Redirectory algo described in this section. It is necessary for
you to understand this section if you want to use Looky in your
organization.
The Looky Redirector algo is a simple URL translation. The URL sent by the consumer is taken as input. The algo computes a redirected URL and returns this URL as output. The algo consists of three steps:
- [A] extract pool and consumer
- [B] contact looky server to allocate a resource
- [C] compute redirect URL
- if an error occures, compute URL with error pattern
- if a resource was allocated, compute URL with redirect pattern
2.1 Extract Pool and Consumer
The pool and the consumer are computed by so called compute-pool / compute-consumer expressions. This 'compute' expressions are functions, that use either the path, the query, the environment or a constant string as input to compute the pool/consumer.- If the path of the original URL is used as input, the
consumer/pool is taken from a path segment. If you do so, you
should choose a segment that is near the first or the last
segment: E.g. segment 0 is used for pool and segement 1 is used
for consumer:
compute.pool:path/0 compute.consumer:path/1
As a result of this the initial application startup URLs have a pool/consumer prefix. You get URLs like this:http://any.server.com/sales/oliver/appl/may/have?strange=urls
This URLs are actually not good for the application. So you need to cut off the pool/consumer prefix. This is done by the transient-path expression.
- If the query path of the input URL is used as input, the
consumer/pool is taken from a parameter. If you do so, you
should choose a parameter that is not used by the
application. E.g. parameter '~pool' and parameter '~consumer'.
compute.pool:query/~pool compute.consumer:query/~consumer
As a result of this you get URLs like this to start the application:http://any.server.com/appl/may/have?strange=urls&~pool=sales\ \&~consumer=oliver
This URLs may be accepted by the application. If not, you may replace this with a transient-query expression.
2.2 Compute Redirect URL
If a resource has been assigned to the consumer, a redirect pattern is evaluated. This redirect pattern is fitted with ctags. The ctags are very powerfull shell like tags with the following features:- %{<ctag>} is replaced by the value of ctag
<ctag>.
- %{<ctag>:<t-clause>} is replaced by the value of ctag <ctag>, if it has a value != ''. If ctag <ctag> is undefined or is equal to an empty string, the ctag is replaced with the result of the evaluation of <t-clause>. The <t-clause> may contain other ctags. Inside a ctag, use single quotes to escape a region or '\' to escape a single character to a literal.
The ctag %{path} and %{query} are filled with so called transient expressions. A transient expression computes those parts of the path/query that are transient for the algo, from the original URL (send by consumer) to the redirect URL (send to consumer).
2.3 Examples
2.3.1 Example 1
Settings:- application start URL is /start/my/appl?time=now
- we have pools admin and sales
- there is no need to distinquish consumers
Recommended redirection rules:
redirect:http://%{resource}/%{path}%{url/query:?%{url/query}}%{url/fra\
\gment:#%{url/fragment}}
compute.pool:path/0
compute.consumer:const/-
transient.path:1
Due to the need to support several pools, the pool is read from segment 0 of the original URL send by consumer (e.g. /sales/start/my/appl?time=now). As a consequence from this, this pools prefix is cut off in transient %{path}.
This setting implies that the locations '/admin/' and '/sales/' on Apache WEB server are run by looky balancer client CGI. However with this approach you are able to assign individual ACL for both locations.
If you have no need to distinquish consumers, the constant expression '-' must be used.
The orignal query and fragment part are passed thru (if they are used).
2.3.2 Example 2
Settings:- application start URL is /start/my/appl
- we have only one pool 'pool'
- consumers are indentified by IP adresses
Recommended redirection rules:
redirect:http://%{resource}/%{url/path}%{url/query:?%{url/query}}%{url\
\/fragment:#%{url/fragment}}
compute.pool:const/pool
compute.consumer:env/REMOTE_ADDR
We just have one pool here, so a const expression to select the pool is the best.
Environment variable REMOTE_ADDR is used to identify the consumer.
The original URL parts are more or less passed through.