-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. . . . Friday evening, no beer, make your own conclusions /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUE5F/AAoJEEFGbsYNeTwt8hoH/RqxqZAMbun1YB5UB2LnjX5i wRfG6SsfezXCEqAOnl8K1kQB9JdynBbA8Uam6zcroP9kybdydKKJdnjSApXpdXNd OV/5l8e5VWm/UnV9I1l2mQRi+9uCfG8H2AfAsj56q9OejvZ4fEGKHhE9y2gP8fQ4 J/8T+isTEri5J6Y8oOeUVjJHDvtT25DB20Dm135VGNFdd/5b+2FJSZe+mcKLh41s zC9hU7qdWtnQ52QYuQzzfd0hsZa4acMp3KkYCRpXJvE7madLeq6Dca6T8Pe1eHOD 0dhxn2Of/mqGkuK0uZ/F78nWN7WSh0fuM4WbkwyoeWIzzigUj3JuaW7B285aQLk= =7nAr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
