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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
