tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: mod_jk warning about "OPTIONS *" requests
Date Tue, 22 Apr 2014 09:09:54 GMT

Christopher Schultz wrote:
> 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

1) "OPTIONS *" is a valid HTTP request.  It is often used in the DAV context, by DAV 
clients, to figure out at the beginning of an interaction, if the server supports DAV.
(granted, here it does not seem to be such a context, but I mean in general)

2) Tomcat (with the appropriat application) supports DAV, and probably even without DAV, I

would guess that it supports the OPTIONS request, including "OPTIONS *".

3) To generate the response to any given request, Apache httpd works as follows (in 
general terms) :
- there is a "stack" of possible "response handlers", of which the "default handler" is 
the last in the stack.
- given a request, httpd calls each of the stacked handlers in turn, passing it the 
request, and (kind of) asking it : "do you want to handle this ?".  The called handler 
then responds with one of the following status codes :
- "ERROR", meaning "I did try to handle the response to this request, but I encountered an

error in doing so".  Given that response code, httpd skips the rest of the request 
handling phases, and goes straight to the logging phase.
- "OK", meaning : "I did handle that request, produced a response, and everything was 
fine".  Given that response code, httpd does not call any further stacked response 
handlers, and proceeds to the next request handling phase.
- "DECLINED", meaning : "No, that request was not for me, ask someone else".  Given that 
response, httpd calls the next stacked response handler, passing it the same request.
(and keeps doing so until one of the handlers returns something else than DECLINED.
And the last (default) handler will never return DECLINED).

4) mod_jk, for Apache httpd, is just one of these stacked response handlers.  httpd passes

the request to mod_jk, and it is up to mod_jk to accept or decline that request.  If 
mod_jk accepts it, it forwards it to Tomcat, and whatever response Tomcat returns, it 
returns it to httpd.
httpd itself doesn't even know that behind mod_jk there is one (or several) Tomcats.  It 
just sees mod_jk as another stacked response handler, among several.

All of this to say that it is perfectly normal for mod_jk to receive this OPTIONS request

from httpd, and to respond "OK", "ERROR" or "DECLINED" as a return status.
Furthermore, there might be cases where there is an Apache httpd in front which does not 
handle these OPTIONS requests, but there is a back-end Tomcat with DAV which does.  So 
httpd would /have to/ pass this kind of request to mod_jk (just in case), unless it is 
specifically configured to do otherwise (which you could do (*)).

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".
I don't think it should do that.
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.

It would be mildly interesting, in comparison, to know how the mod_proxy_ajp developpers 
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message