-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 9/15/14 11:45 AM, André Warnier wrote: > 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. Because we can't simply drop support for JkMount: it would break basically everybody's configuration but yours ;) > 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. No, but inertia is a tough thing to overcome. > 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 ? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUF00gAAoJEBzwKT+lPKRY084P/1XQjT0w9o7ptqlDiAP4MR1J DWw3erGP8FpnBLQFMtl4M7aOCSBW3Y5TCMxCiJc/FkaUbqb+ooCBTUEmY0gHvBO9 WQpDlfZx+VzMAOrjYHgypD0eKep5ZdaTS5P37sXl49AceJiXOe0aZdnjVhV/H6SI vkczbt2BAolMFmHuv2elvq3F7Au2yoKC2Pls5xO1gOcqgyiY9AV3MAdKaJ5fQjhD 8o0G6m9q3YDEDv18pVus3cCw+sKD3c5Ai8AJxSFfgXwK8oYsIzZh8FxFlfld9F0v CkX3eul3ncQ1Ne4DPcv9DMtuba2do6UEav327sROizM19/1XZfcHNOZZtLPAcEK8 1UcXGI5IuZtIf0wU01594OL1D+L1vHmwSLlQKVqhKdE95azWzbdKv8agkmwBEQ+0 PBta53r4k0IUlv5w6ON9HFARl3Wr28PRb7M3CDrXr7nd01GoKEWnYjEedhtlbCho ANqexEhH/iz+z1QgOy43700BODb8r4Ix72q/82JYXSsL7KYqjpBorAlq2eGgSb9S RScJXp6C5na+/OvmpIhlZaAH9S+qoRNsXNV0Bd9DjHwlfWzRpyMk5xz719HAcRgv Hfs++tJifr8ZnkkX1Sc5D3LhMbGqmElTRzUfnRUKetV32TAIqiv+CU44ELonzbqX uOk5aKvYB9FQdNHnEvuZ =Np6S -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
