Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 9/12/14 11:14 AM, Mark Eggers wrote:
Chris,
On 9/12/2014 7:13 AM, Christopher Schultz wrote:
Daniel,
On 9/11/14 4:15 PM, Daniel Pfeiffer wrote:
On 2014-09-10 22:12, Mark Eggers wrote:
I don't think that the trailing /* is valid for a simple
Location directive. If you want regular expressions you'll
have to use either LocationMatch or Location ~ (Location
followed by the ~)
This was the decisive hint! JkMount needs /*, but Location
doesn't seem to handle it well. This makes the
one-argument-form of JkMount quite useless. The solution was
using the two-argument-form isolated with /* and Location
without.
Still doesn't explain why it sometimes works, but I'll leave
that as an exercise for mod_jk fans.
Would you please log a bug in Tomcat's Bugzilla for this? At the
very least, it warrants a documentation fix, and possibly a
review of how mappings for <Location>s are expressed/evaluated.
-chris
- From the documentation:
Inside Location, one omits the first argument (path), which gets
inherited from the Location.
That's where I took my clue. In Tomcat documentation fashion, the
density of information is quite high.
I personally don't have a problem with this, even though it's not
normally my style (obviously :-p).
The problem is that most people would write:
<Location "/foo">
JkMount worker
</Location>
The "/foo" in location will handle any URL beginning with "/foo" while
mod_jk will handle a URL with /exactly/ that path "/foo". Basically,
<Location "/foo"> behaves like <Location "/foo/*"> without actually
saying it,
nitpick : more like "/foo*"
and mod_jk will stupidly do exactly as requested, which is
not always what might be expected.
That's why the above doesn't work as expected, but using Set-Handler
does: when Location/JkMount is used, we get a bad JkMount result
(mod_jk maps only /foo, not /foo/*). If you use Set-Handler, then
/httpd/ makes the decision that the URL matches the <Location> amd
then sets the handler for it.
I really do think this warrants at least a documentation update.
Clearly explained, thanks.
As an addendum, I would venture that the situation gets even more complicated (or
downright nonsensical) with <LocationMatch regexp>, because there is no way JkMount can
possibly match that.
And as a bit more than an addendum :
When you think about it, it would probably greatly simplify mod_jk itself, if it just
assumed that any request passed to it was for it, period, and not have his own match
evaluation. And let the front-end entirely decide whether mod_jk is the appropriate
content-generating handler for this request.(*)
Right now, basically, 2 consecutive evaluations are taking place (or at least
seem to) :
- first httpd, going through all its <Location>, <LocationMatch> and <File> sections, and
then if mod_jk is called, it re-does its own evaluation in function of its own separate
URI-mapping table.
And one has to hope that the results match, which they don't always, as per
above.
(**)
I would guess this is a design left over from a time when maybe Apache httpd's
URL-matching was not entirely able to match Tomcat's (***), and nobody thought of
questioning it ever after.
At the very least, one possibility would be for mod_jk, when it sees a JkMount inside any
<Location*> section, to turn its own uri-mapping off entirely, and just accept the request
as it is. In other words, such a JkMount would just become an alias to "SetHandler
myself". (Unless no-jk is set of course).
Oh do those things get complicated..
(*) because from the httpd point of view, the content generator is mod_jk. And httpd
doesn't know, and doesn't give a damn, that there is a cluster of 16 Tomcats behind mod_jk.
(**) and then there is Tomcat of course, doing its own URI-to-webapp mapping.
And then the webapp itself doing its own URI-to-servlet mapping.
It all looks kind of redundant, doesn't it ?
(***) or maybe there was no way then, for Apache httpd to change its content-handler
on-the-fly, and mod_jk had to sneak its way in there to set itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
