tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer Jung" <tomcat-...@kippdata.de>
Subject Improving jk_uri_worker_map in mod_jk
Date Sat, 11 Dec 2004 19:59:19 GMT
Hi,

while trying to improve parts of the mod_jk documentation I made some
observations concerning mod_jk's jk/native/common/jk_uri_worker_map.c I
wanted to discuss. I'm willing to provide patches but wanted to get some
opinions first.

I find the JkMount worker map decision code very difficult to understand
and I think there is some clean up needed:

1) JkUnMount

There seems to be no general rule, which JkUnMount wins the decision
process vs. conflicting JkMounts. One policy could be, to let JkUnMount
win in any conflicting case, except an exact match from JkMount.

Using longest context match might not be the best idea, since then there
is no way to just say

JkUnMount /*.gif

At the moment most of the time JkUnMount wins, but e.g. not if there is a
longer JkMount match with multiple '*' in it.

2) Map sort

For implementation it could be very helpful to sort the map not only
depending on context length (as it is done now), but to sort it e.g. like:

- First: positive exact Matches (Match returns immediately positive)
- Second: negative Matches (maybe these sorted in ascending context length
order) (Match returns immediately negative)
- Third: all other positive matches sorted in descending context length
order (Match returns immediatly)

3) Further there is a decision needed, which matches should be done case
sensitive on Win32. At the moment matches are only done case insensitive
in the case, when a suffix match is needed and the suffix starts with a
'.'. Anything special about that case?

4) Repairing JkMount /Context/*/Dir: from looking at the code I have the
impression that that case is buggy, but I did not yet test to prove it.

5) It's strange, that the general suffix case is handled very different
from the case, where the sufix starts with a dot. Also, implementation of
both suffix cases seems to be a little clumsy. It steps throught the uri
to find the character, which with the suffix starts and after that
compares the rest of the uri with the suffix for equality. Why not just
jumping to the correct position, since we already know the length of the
suffix.

6) There is some code for prevention of a security fraud coming from URLs
.../secret.jsp/ or .../secret.jsp. or with a ' ' after the suffix. The
code is called after no match is found. Then the uri is made more secret
and a shortened decision loop is called to make another mapping decision.

This fraud prevention e.g. is never called when JkUnMount matches. It also
seems to be used only in case a suffix pattern is used. What's the idea
behind it? Wouldn't it be more stable to beautify the URI before looping
through the mapping?

What about non-matches /Context//secret.jsp or /Context/./secret.jsp? Are
these URIs already simplified by Apache itself?

7) Concerning the new wildcard matches using multiple "*" or "?": They are
very useful, but they break the idea of "longest context wins", because
they take the whole pattern as the context, whereas the former possible
patterns only used anything up to the first "*" as the context. It makes
understanding the decisions (and correctly documenting the feature)
difficult. Also we should mention, that using more than just one "*" has a
performance penalty (since then the pattern is not split into context and
suffix with relatively easy matching algorithm, but instead the URI is
passed to a more general recursive wildcard matching method).

Any comments?

Rainer



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


Mime
View raw message