Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 9/12/14 8:36 PM, Mark Eggers wrote:
Here was my naive thought. haven't tested this yet (may be a
project for this weekend).
Outside of a <Location> or <LocatioMatch> directive, the JkMount
directive parses the configured URL prefix. If requested URL
passes the rules, then mod_jk gets to handle the request.
Inside of <Location> or <LocationMatch>, things are a bit
different. Apache HTTPD parses the incoming request. If the
requested URL passes, then it's sent along to whatever is inside of
the directive.
So you can think of a JkMount wrapped in a <Location> or
<LocationMatch> directive as a 'dynamic' JkMount. It gets
rewritten with whatever passes the <Location> or <LocationMatch>
directives.
mod_jk must modify its own internal map of URL (patterns) -> workers
when it finds a one-argument JkMount within a <Location>. Simply using
Set-Handler is not quite enough: you have to use JkMount (or set
JK_WORKER_NAME - or whatever you set with JkWorkerIndicator),
otherwise mod_jk will have no idea how to route the request.
So, if mod_jk were to skip the URL-matching and rely on httpd's
<Location> (or whatever construct) and Set-Handler, it would also
require that JkMount [workerName] (or SetEnv JK_WORKER_NAME
[workerName)] also be present.
I would imagine that, at configuration time, it would be difficult to
determine if all of these things requirements have been met. At
request-time, it would be easy to tell if things were okay, but then
you may have a bit of confusion by users who haven't quite configured
things properly and get a different default behavior then they were
expecting.
Something like:
JkMount [i-made-it-inside] worker
At least that was my understanding. And yes, the documentation is
not so clear.
It doesn't seem to me that obvious that JkMount would somehow read
the parameter from <Location> or <LocationMatch> and use that in a
configuration such as:
JkMount /*faddle.jsp$ worker
Especially since that regular expression would make no since to
JkMount.
Correct. It's perfectly reasonable to do something like this:
<Location "~/.*/abc/*.exe">
JkMount workerX
</Location>
... and have a URL pattern that mod_jk has no idea how to handle.
It's starting to sound more and more like mod_jk should just not try
to over-think things and re-evaluate URLs, etc: it needs a mode where
it will take the worker name from JkMount (or Set-Handler) and just
use it without checking the URL. On the other hand, I'm not sure how
mod_jk can detect (during a request) when it's being called from
"within a <Location>". You may have to set some other environment
variable to disable mod_jk's URL (re)evaluation logic.
Under Apache httpd, why does mod_jk even need to know where it is called from ? It could
just assume that httpd is calling it when appropriate and not otherwise.
If you want a "universal" JkMount-equivalent to "JkMount /*", then do
<Location />
SetHandler jakarta-servlet
</Location>
, and it will be inherited by all sub-Locations (aka "handle all URI's") unless overridden
by another SetHandler (like "SetHandler None").
If you need it more focused or conditional, use the very powerful and flexible Apache
<Location*> sections, and don't second-guess them.
All the other Jk* directives can be emulated by the setting (or lack of setting) of Apache
variables such as no_jk, JK_WORKER_NAME et al.
This may sound counter-intuitive (if not anathema) to Tomcat-focused people.
But don't forget that from a httpd point of view, mod_jk (and the possible umpteen Tomcats
behind it) is just one way of generating a HTTP response for some request URI's, among
many others.
Sometimes you need to think out of the box. Or maybe in the box in this case; because
after all, we are talking here of a configuration file which belongs to httpd. So it
sounds rather logical to me that the directives in it, would have an Apache httpd look and
feel; which Jk* directives do not.
After all also, when you use either mod_proxy_http or mod_proxy_ajp as a connector, you do
use only httpd-style directives.
Finally, all this is - in my view - a rather strong argument for using the "SetHandler
jakarta-servlet" in Apache, rather than JkMount/JkUnMount.
I originally thought that it was more a matter of preference only, but as a result of this
discussion and the pittfalls that it showed, it seems rather more than that : it is much
less error-prone. And it would allow mod_jk to avoid its own URI-mapping logic entirely,
thus removing a probably sizeable chunk of code, and making it even more efficient.
(This becomes rather evident if you turn on mod_jk logging high enough that it shows its
efforts at matching every URI it is given).
mod_jk 2.x anyone ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
