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 :
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.
André
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
