On 22.04.2014 17:32, André Warnier wrote:
> 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 +] "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 +] "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
>> 1056if (*uri != '/') {
>> 1057jk_log(l, JK_LOG_WARNING,
>> 1058"Uri %s is invalid. Uri must start with /", uri);
>> 1059JK_TRACE_EXIT(l);
>> 1060return 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 section with a
>>> "SetHandler jakarta-servlet", and in that , 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
