I use mod_jk 1.2.40, httpd-2.2.15-29.el6.centos.x86_64. I set Hostname property to IPv6 address using JK Status Manager, But error occured. In web browser Firefox, I clicked the link 'E' ('[S|E|R] Worker Status for ajp13w') . and I set Hostname property to IPv6 address(2001:c0a8::1) in Edit worker settings pages, But error occured. -mod_jk.log [Thu Jun 12 11:09:13.029 2014] [4233:140197382711040] [info] commit_member::jk_status.c (3369): Status worker 'jkstatus' setting 'host' for sub worker 'ajp13w' to '2001%3Ac0a8%3A%3A1' [Thu Jun 12 11:09:13.029 2014] [4233:140197382711040] [error] commit_member::jk_status.c (3384): Status worker 'jkstatus' failed resolving address '2001%3Ac0a8%3A%3A1:8009' for sub worker 'ajp13w'. -
Thread on @users: "I can not set Hostname property to IPv6 address using JK Status Manager" http://tomcat.markmail.org/thread/5z54blmnrttwytr6 The problem is that url-encoded parameter value (2001%3Ac0a8%3A%3A1) is passed "as is" to the jk_resolve method. Looking at the code, jk_status.c has its own HTTP query parameters parsing (status_parse_uri() in native/common/jk_status.c), implemented by splitting the query string. The url-decoding of parameters is not performed. There is a comment that it had been planned, but has not been implemented yet. /* XXX Depending on the params values, we might need to trim and decode */
(In reply to Konstantin Kolinko from comment #1) > Looking at the code, jk_status.c has its own HTTP query parameters parsing > (status_parse_uri() in native/common/jk_status.c), implemented by splitting > the query string. > The url-decoding of parameters is not performed. There is a comment that it > had been planned, but has not been implemented yet. > > /* XXX Depending on the params values, we might need to trim and decode */ Yes, jk_status.c:1277 looks like the right place to do this. It seems no parameter-decoding is happening at all, probably because mod_jk never expects to get a parameter value that is encoded in any way. There are several settings that could be affected in this way: hostname, route, redirect-route, cluster-domain, worker-name The last one (worker-name) could be configured properly in workers.properties, but then be unable to send the worker's name via HTTP without encoding, in which case mod_jk would never be able to find the worker.
Created attachment 32339 [details] Initial patch with (possibly) sloppy memory management I have a patch which lifts the whole apr_unescape_url method from APR 1.5 and uses it in jk_status:status_parse_uri and initial testing suggests that it works. However, I have been lazy with my memory allocations because I have not yet understood how jk_map_put deals with memory. I'm attaching my proposed patch with the understanding that it is almost certainly not complete, as it likely contains a memory leak. It also does not decode parameter *names*, but it doesn't seem like the mod_jk status worker really needs that right now.
Created attachment 32340 [details] A better patch without memory leaks
Hi Chris, I have applied your patch with some minor variation in r1648934. I have removed the dependency on APR, because the same code is used when the status worker is called via the ISAPI redirector. Since unescape shortens the URL (at least doesn't make it longer), I have chosen to do the unescaping in place, i.e. not to copy the original string. Thanks! Rainer
(In reply to Rainer Jung from comment #5) > Hi Chris, > > I have applied your patch with some minor variation in r1648934. > > I have removed the dependency on APR, because the same code is used when the > status worker is called via the ISAPI redirector. For httpd-based systems, APR will be there, so I figured we could take advantage of it. > Since unescape shortens the URL (at least doesn't make it longer), I have > chosen to do the unescaping in place, i.e. not to copy the original string. It doesn't save much but its a bit tidier. I did a separate buffer just in case there was a bug there would be less likelihood of trashing the original query string. It also allows us to reject a malformed parameter value without half-decoding it; instead we can use the completely-encoded value in the event of a failure (though we always fail when the value can't be decoded).