This section described the syntax of a rule file as supported by the Rule File Filter in libwww. Please read the section on Rule Files for a full description of the rule file API.
The W3C Sample Code Library can use suffixes to discover the content-type, content-encoding and content-language of a file. The Library contains a long list of commonly used file suffix types but the application doesn't have to use this. In any case, the following configuration directives can be used to add new suffix bindings and override existing defaults:
AddType
- Filename suffix mappings to
MIME Content-Types
AddEncoding
- Filename suffix mappings
to MIME Content-Encodings
AddLanguage
- Multi language support,
suffix mappings to different Content-Languages
As well as any mapping lines in the rule file, the rule file may be used to define the data types of files with particular suffixes. The Library has an extensive set of predefined suffixes, but applications do not need to use this. The syntax is:
AddType .suffix representation encoding [quality]
The parameters are as follows:
*.*
matches to all files which have not been matched by any explicit suffixes
but do contain a file suffix delimiter. A file suffix delimiter is often
a dot <.> but it can be defined as an arbitrary character, please see
the Suffix Binding Module for details.
*
by itself matches to any file which does not match any other
suffix.
xxx.*
which differ in their suffix
only, when a link to xxx.multi
is being resolved. User to 1.0.
AddType .html text/html 8bit 1.0 AddType .text text/plain 7bit 0.9 AddType .ps application/postscript 8bit 1.0 AddType *.* application/binary binary 0.1 AddType * text/plain 7bit
Suffixes are also used to determine the Content-Encoding of a file
(.Z
suffix for x-compressed
, for example). Syntax
is:
AddEncoding .suffix encoding
AddEncoding .Z x-compress
Multi language support is also built on using suffixes to determine the language
of a document. Suffix is bound to a language by AddLanguage
rule (.en
suffix for English, for example). Syntax is:
AddLanguage .suffix encoding
AddLanguage .en en AddLanguage .dk dk
In order to expand the set of content types that can be handled by an application, you can specify a set of external viewers which can handle specific content types. This is for example often the case for postscript viewers etc. This is quite similar to a mail cap file, but the Library doesn't have a real Mail cap file parser.
Presentation representation command [quality]
Presentation application/postscript ghostview 0.5
You can also specify proxies and gateway using the Library rule file. You can lao read more about how libwww handles proxies and gateways in the User's Guide.
Proxies can be set up as follows:
Proxy scheme proxy
And the parameters are:
Proxy http http://proxy.foo.com:8000/ Proxy ftp http://proxy.foo.com:8000/ Proxy gopher http://proxy.foo.com:8000/
You can also specify a set of domains where we shouldn't go via a proxy server
even though the rules indicated by the proxy
directive above
indicates that we should. Often you want to be able to handle a few exceptions
from the proxy rule - especially if the remote host is either very close
or on a high bandwidth connection.
NoProxy hostname scheme port
Registers a host name or a domain as a place where no proxy should be contacted
- for example a very fast link. If port
is not indicated then
it applies to all ports.
Gateways can be set much like proxies:
Gateway scheme gateway
Gateway wais http://www.w3.org:8001/
Rules define the mapping between virtual URLs and physical file names. Currently the following rules are understood:
There are three main rules: Map,
Pass
and
Fail.
The server uses the top rule first, then each
successive rule unless told otherwise by a Pass
or
a Fail
rule.
Map
template result
Pass
template
Pass
template result
Fail
template
When matching,
Map
template exactly, the result string
is used instead of the original string and applied to successive rules.
Map
template with wild card,
then the text of the request which matches the wild card is inserted in place
of the wild card in the result string to form the translated request.
If the result string has no wild card, it is used as it is.
Map
substitution takes place, the rule scan continues
with the next rule using the new string in place of the request. This is
not the case if a Pass
or Fail
is matched: they
terminate the rule scan.