Redirection Primer
 | Table Of Content | |
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/fragment:#%{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.
|
|
redirection