-----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 *") 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, 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTVnqcAAoJEBzwKT+lPKRYopIQALS77B6mPjTzauy09gZgvrCb
608p9S/yXCdaSCINsGpIzvApBszJ4XVkhcdEbP6Vbilxr+r+lM6iWp6lm17DNDmD
ANIwyGNcvzIK8jvUUFBOkT29XXrzbPgx9hzFKjc+go4YQTDcJ0ZcERckc4noRAiL
d0BHKxOFf/tFOGOgehDPTVPdiPkWtJoQisPxBpazBACAv5pdIkkocrJqqPWESkI6
mkU9qV7GAh9PbsqRiBWyC3CXnjJt2/rDqGHePk7urII3xFmM9MPXxLczVY/hJCBF
rmapD8rPd/qDtL2eIV2+2Ka8t5sImSQTRkZUkwFtCyvfmYw4rVjlIbhB/zKJHTMu
3haX5x0NvAwTylnmH5OGNHujJ/2FbTEluLwT53UrctLruFUGGA9CQNo1vOlTviF+
mO/ndvDPr1DxcHoieze3GgFaicYIoeee2pALm7CaPDZkbOE/DY1tVO3Qd+MoTBYP
bD7l/c1YUuAGB110QQZhJzEtKjMV5FZafdSXHZaLXT+onp3S4NCoa9JtVnVZ248S
6rAuu8uaYqtItFI0f0+ON1Jp4Yfz5eZhjIIU6Cs1YqUDxvo1nR62/v2a/BBHh+z6
OpKh17NmY5S6MC965OsjxRVrJG6zYYFYC8WzJmrvp4IgJ3H3mmF9+BuyK7TFfcA+
42NBhv8KrgI3uWodKfTl
=e4cg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
