DO NOT REPLY [Bug 18500] Host aliases to match by regular expression

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=18500

--- Comment #5 from Christopher Schultz <ch...@christopherschultz.net> 2011-09-20 21:33:24 UTC ---
Unfortunately for this enhancement, the Mapper is written to use a relatively
high-performance binary search algorithm to find a matching <Host> given all
the <Host> and <Alias> definitions (where <Alias>es are basically treated as if
they were additional <Host> definitions with shared configuration information).

Such an algorithm can't work with regular expressions because they can't be
sorted in any sane way. Thus, a linear search would have to be performed which
will degrade performance (along with the execution of all those regular
expression matches).

If we're going to do this, I would recommend that we add another layer of
abstraction near the insertMap/find/findIgnoreCase mechanism. Something along
these lines:

1. The Mapper works exactly as it currently does under "normal" operations.
2. When a Host (or Alias) is added with special markings (say, leading and
trailing "/" marks which are easily recognizable and otherwise illegal in a
hostname), we switch into "regex mode".
3. Entering into regex mode creates another List/Map/whatever of metadata that
will need to be maintained: existing <Hosts> are processed-into this data
structure.
4. Hosts (and Aliases) added after going into regex mode will of course have
this metadata updated as appropriate
5. In internalMap, modify the call to findIgnoreCase depending upon the current
mode: if we're in "normal" mode, just call findIgnoreCase and move-on; if we're
in "regex" mode, make a different call that uses the aforementioned metadata to
find the proper index into the <Host> array

This could be done by re-factoring the Mapper to use a pair of new private
inner classes: one that behaves like the current implementation, and one that
works with regular expressions. Switching from one mode to the other could be
done by replacing the currently-effective Mapper with one of the other type.
You could even go back if you really wanted to.

We will need a policy of conflict resolution: more than one <Host> could match.
We can't use a policy like "longest match wins" because it's tough to tell
which regex is "longer" due to their complexities. I would favor a linear
search where the first-defined <Host> wins. The Digester should give us all
<Host> elements in XML-order, so the user can specify the order of preference
just by ordering server.xml to their liking.

Thoughts?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org