Who the f*** is Stephen?

2014-05-31 Thread David Law

Hi Alex,

hope you're thriving.

I got a LinkedIn invitation from a Stephen Everson
who (I think...) I've never heard of.

I see he's one of your connections.
Any idea who he is  why he would be contacting me?

Dave

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: mod_jk warning about OPTIONS * requests

2014-05-31 Thread Rainer Jung
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,
 1058Uri %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 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 

Re: ColdFusion10 custom mod_jk difference

2014-05-31 Thread Rainer Jung
On 08.04.2014 23:44, Doug Strick wrote:
 We're moving from ColdFusion8 to CF10 where I work and ran into a strange
 issue.  We tried using mod_jk-1.2.39 and it compiled fine.  We were able to
 get the communication working, but ran into strange errors like below.
  Adobe provides their own customized version of mod_jk which appears to be
 built from 1.2.32.  When I compiled their version from the source they
 provide our errors went away.  I downloaded the source from here if
 anyone's interested:
 http://helpx.adobe.com/coldfusion/kb/rhel-connector-configuration.html.
 I'd like to avoid using their custom version as I don't know how it will
 play if other non-ColdFusion based apps want to use AJP in the future.
  Does anyone have any recommendations on how I might be able to figure out
 what was changed?  I'm not a developer so I don't know much at the code
 level.
 
 
 
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 ajp_send_request::jk_ajp_common.c (1713): (cfusion) request body to send 0
 - request body to resend 0
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13
 pos=0 len=14 max=65536
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0F 00 0A 2F
 69 6E 64 65 78 2E 68 74 6D 00 00 00  - .../index.htm
 ...
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [error]
 ajp_process_callback::jk_ajp_common.c (2071): Unknown AJP protocol code: 0F
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [info]
 ajp_service::jk_ajp_common.c (2669): (cfusion) sending request to tomcat
 failed (recoverable), because of server error (attempt=2)
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 jk_shutdown_socket::jk_connect.c (840): About to shutdown socket 25 [
 172.16.113.55:49315 - 10.9.49.245:51010]
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 jk_is_input_event::jk_connect.c (1287): timeout during poll on socket 25 [
 172.16.113.55:49315 - 10.9.49.245:51010] (timeout=2)
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 jk_shutdown_socket::jk_connect.c (922): Shutdown socket 25 [
 172.16.113.55:49315 - 10.9.49.245:51010] and read 23848 lingering bytes in
 0 sec.
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [error]
 ajp_service::jk_ajp_common.c (2689): (cfusion) connecting to tomcat failed.
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 ajp_reset_endpoint::jk_ajp_common.c (810): (cfusion) resetting endpoint
 with socket -1 (socket shutdown)
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [debug]
 ajp_done::jk_ajp_common.c (3140): recycling connection pool for worker
 cfusion and socket -1
 [Fri Apr 04 15:22:49 2014] [9753:139964571830064] [info]
 jk_handler::mod_jk.c (2806): Service error=-3 for worker=cfusion

The code changes show that Adobe has decided to not only add a feature
(max reuse count per connection), but also to extend the protocol which
makes standard mod_jk incompatible. The Unknown AJP protocol code: 0F
is due to that addition.

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org