Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 4/22/14, 5:09 AM, André Warnier wrote:
Christopher,
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
All,
I'm running some load tests in a dev environment, and I'm seeing
acess log messages like these:
::1 - - [21/Apr/2014:14:15:03 +0000] "OPTIONS * HTTP/1.0" 200 -
"-" "Apache/2.4.9 (Amazon) OpenSSL/1.0.1g-fips PHP/5.5.10
mod_jk/1.2.40 (internal dummy connection)"
Paired with mod_jk errors like these:
[Mon Apr 21 14:15:03.359 2014] [23925:3072505728] [warn]
map_uri_to_worker_ext::jk_uri_worker_map.c (1096): Uri * is
invalid. Uri must start with /
This happens to be running Apache httpd 2.4.9 with mod_jk 1.2.40,
but I can see similar messages in an otherwise
identically-configured server running httpd 2.2.23 and mod_jk
1.2.37:
==> access.log <== ::1 - - [21/Apr/2014:14:20:24 +0000] "OPTIONS
* HTTP/1.0" 200 - "-" "Apache/2 (internal dummy connection)"
==> mod_jk.log <== [Mon Apr 21 14:20:24.159 2014]
[12384:3072042880] [warn]
map_uri_to_worker_ext::jk_uri_worker_map.c (1057): Uri * is
invalid. Uri must start with /
In my httpd 2.4 environment, I seem to be seeing them much more
regularly (once every second or two) than in my httpd 2.2
environment (maybe every minute or two). If possible, I'd like to
minimize the amount of stuff that goes into my mod_jk.log file,
and since this is logged at the WARN level, it's tough to justify
disabling it.
Now, I realize that the OPTIONS * messages are httpd's internal
monitoring queries to see if workers are serviceable, so that's
not my question. My question is why mod_jk complains about them.
Perhaps a URI of "*" itself is invalid, but since httpd is known
to issue internal queries like this, why doesn't mod_jk simply
ignore them?
Just to "keep the church in the middle of the village", as they say
in my part of the world :
[OT] I'm not sure I can interpret the meaning of that. What does it mean?
1) "OPTIONS *" is a valid HTTP request. [...]
Yep, I get all this. My real question is why mod_jk is complaining
about the URI. It shouldn't.
Here's what happens in mod_jk:
httpd
- -> mod_jk.c::jk_handler
- -> jk_uri_worker_map.c::map_uri_to_worker_ext
Here's the code for map_uri_to_worker_ext, around the interesting part:
jk_uri_worker_map.c::map_uri_to_worker_ext
1056 if (*uri != '/') {
1057 jk_log(l, JK_LOG_WARNING,
1058 "Uri %s is invalid. Uri must start with /", uri);
1059 JK_TRACE_EXIT(l);
1060 return NULL;
1061 }
When this happens, jk_handler ultimately returns DECLINED. So,
everything works the way it should work (except possibly a bug where
Tomcat can't receive requests for "OPTIONS *")
exactly; that is most probably a bug.
except that mod_jk
complains about a URI that it should not complain about.
I'm wondering if there's a particular reason to complain about this
URI,
Maybe it just simplifies the code after that, which compares the mod_jk URI-mappings to
the received request URI.
especially given that httpd (to which mod_jk is rather tightly
bound) uses these requests internally for legitimate reasons. To me,
it just seems like this message should be suppressed entirely.
The real basic issue here seems to be that mod_jk /misinterprets/
these OPTIONS requests : it takes itself the decision to reject it
and log an error, because it misinterprets the fact that, for
OPTIONS, "*" is a valid "path".
All correct, except that mod_jk returns DECLINED instead of ERROR.
I don't think it should do that.
+1
That it then logs an error is a side-effect of this
misinterpretation. Stopping mod_jk from logging this "error" would
just hide the underlying issue.
No. It would just shut it up and everything would still work fine.
It would be mildly interesting, in comparison, to know how the
mod_proxy_ajp developers handle this case.
(*) For example, if you used a <Location(Match)> section with a
"SetHandler jakarta-servlet", and in that <Location>, excluded the
OPTIONS requests (via a filter?). Or if you used mod_rewrite to set
the "no-jk" httpd env value for OPTIONS requests. Unfortunately, I
think that there is no corresponding "JkUnMount" syntax which
allows to exclude some requests based on the HTTP request Verb.
I believe that to be correct. I exclusively use JkMount, so the
"OPTIONS *" should never have mod_jk explicitly set as a request
handler... httpd is just apparently consulting mod_jk for all
requests. That's a bit unexpected, honestly (I thought mod_jk could
"register" itself as a request handler for certain URIs, but in
retrospect that would be pretty chaotic), but the situation is fairly
clear.
I would simply like to remove the warning, or maybe place it at a
lower logging level. It would be nice if "OPTIONS *" requests could be
forwarded-through to Tomcat, but it appears that it not possible with
the current mod_jk version. "OPTIONS /" would certainly work, but not
"OPTIONS *".
- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
