tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: mod_jk warning about "OPTIONS *" requests
Date Tue, 22 Apr 2014 15:32:06 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message