-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/12/2014 5:36 PM, Mark Eggers wrote: > On 9/12/2014 3:07 PM, André Warnier wrote: >> 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. > > Folks, > > Ah, now I see. > > 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. > > 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. >
err . . . sense . . . > . . . Friday evening, no beer, make your own conclusions /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUE5JBAAoJEEFGbsYNeTwtoKIH/205oiXP7g19E/iQOmIe0MKd 34CVn1evNm6h0IoTzGU+pMlT5QIv+OIypHlfRmaFncQEH588+mBknuOH85wMrQZg EGbT4J/qnAQmjeh0lV4hMktUeeCoWrRb12q+VfN5gBP7CaXd1fNVyCAJsxoLT7Ka hgxGzVI0Keq90hll8xrAPlAXLJLuPj4e2SEWIPOIUUg3cmztrerR7gF35K/pabQU AjnMWGcSmTo14/SYp1Z+airEFpPF/Fd1N9aBA5Ki3ngtgxdbWueNQdFvB7E1Kpk+ IfDjnyPMeHmoDRTl7nv0Jarji3StpczeKlG5ymmZlrU3UrrRgOJ/VH+qa/EpTZg= =xXyt -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
