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 +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 *".
I have now reduced the level of the log message for "OPTIONS *" from
warning to debug in r1598864. So those internal dummy connections will
no longer trigger mod_jk logging for normal production JkLogLevel.
And yes, we can't currently use JkMount to forward "OPTIONS *", which is
not a problem in this specific case but could be for others. I haven't
investigated how much would break if we allowed non-slash prefixed URIs
in JkMount (and how to circumvent that "*" already has another meaning
in JkMount).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
