class rewrite_system_id :Rewrites the URL's according to the list of pairs. The left component is the pattern, the right component is the substitute. For example,?forward_unmatching_urls:bool -> (string * string) list -> resolver ->
resolver
new rewrite_system_id
[ "http://host/foo/", "file:///dir/" ]
r
rewrites all URLs beginning with http://host/foo/
to file:///dir/
,
e.g. http://host/foo/x
becomes file:///dir/x
.
If the pattern ends with a slash (as in the example), a prefix match is performed, i.e. the whole directory hierarchy is rewritten. If the pattern does not end with a slash, an exact match is performed, i.e. only a single URL is rewritten.
The class normalizes URLs as norm_system_id
does, before the match
is tried.
By default, URLs that do not match any pattern are rejected
(Not_competent
).
The rewritten URL is only visible within the passed subresolver.
If the opened entity accesses other entities by relative URLs,
these will be resolved relative to the original URL as it was before
rewriting it. This gives some protection against unwanted accesses.
For example, if you map http://host/contents
to file:///data/contents
,
it will not be possible to access files outside this directory,
even if tricks are used like opening ../../etc/passwd
relative to
http://host/contents
. Of course, this protection works only if
the resolver opening the file is a subresolver of rewrite_system_id
.
Another application of this class is to use the identity as rewriting rule. This resolver
new rewrite_system_id
[ "file:///data/", "file:///data/" ]
( new resolve_as_file() )
has the effect that only files under /data
can be accessed, and
other such as /etc/passwd
cannot.
Option forward_unmatching_urls
: If true, URLs that do not match any
pattern are forwarded to the inner resolver. These URLs are not
rewritten. Note that the mentioned access restrictions do not
work anymore if this option is turned on.