-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 9/12/14 6: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*" +1 > 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.(*) See below. > 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. No, it's because Java web-application people would probably think in terms of the servlet spec's rules for URL pattern matching, where full regexes aren't supported. Instead, you get exact-matching, path-prefix-matching, and extension-matching only. These can all be done by mod_jk (via JkMount) without using regular expressions for the matching, which significantly improves performance. If you want to emulate <url-pattern>*.jsp</url-pattern> with <Location>, I believe you must use <LocationMatch> which will use full regular expression matching (for all requests!). > 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.. +1 It probably *does* make sense for mod_jk to examine the value of the "handler" to see if it has been explicitly set. I don't know enough about http pipeline processing to know whether or not mod_jk can find out whether Set-Handler has already ... umm .. "executed"? That's a question for one of the devs more seasoned in httpd/apr. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUFusvAAoJEBzwKT+lPKRYQfUQAJQw7PXMgduk13FYz1JmtjXN gTlZdwYD8QtF7hZn9sHj8SItrgxhTOd/+YWCR3AoVmW7Mb7rdc04Uj5SmpCsArot Icu7ezSXMPX1/XXMFGvDHDAwd09lfhED/MG8CrYk5rLLCe8t9n3ZSjQfF50kJa3j 3m0Snuhag0Ox51W/5a6AxG+rK5A13Vjvl3D0/cJvTzHZbTzQxiaP4qj0i5HspCM5 XRkkLPnwM4dyJF2ylPuwbYOflojfPIvLrWr//zsWOcPmSiHg5avqIhTRJ2M7azMe CLE7vHs476Ps4ZHKkSIooFExwUjzqpoX0Uq7IYRT/fTe0mdhxSk6u7VzFWmWEf95 6LMowMCfsOm3iA3v6Jwn+3CzxS4gId+zBEkgA0HCcd56lhkjRL24wxbrtsrTfOTg 6ksWBy/xCcijLeilDeGgjp2gdqf1VMFZrlXuB8+w+UzeO0hRtzxoaXjeFSg6yO7N OaCBdM9v7PYGYMdOKc4BG4n+91oGlfor9FO59zxeycIMeXwdK7lp4tHBNfR14K08 2O4IsV+dY5S36bIk1RAD4/Vv5xqQFKDQXgttyfLWLEZuc/CgWMOUlURTtfZsKYt0 4eMHHU5e0f/Lc3EdNn1ChGa/BhQkEs5SnA439tIRHLqA72QFXrs9kRsuQe6eDuh5 jhqDbdCeCTvWqOdKI1b1 =rirN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
