On 02/10/2019 14:51, Mark Thomas wrote: > On 30/09/2019 20:33, Rainer Jung wrote: >> Thanks, eactly what we need. > > +1. I can reproduce this. > >> I will look into it, but it might take two >> or three days. Anyone who can do it more quickly is welcome. I suspect >> these log lines point to the root cause: >> >>> [Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug] >>> jk_servlet_normalize::jk_util.c (2184): URI on entering >>> jk_servlet_normalize: [] >>> [Mon Sep 30 15:04:03 2019][3906:140148297873536] [emerg] >>> jk_servlet_normalize::jk_util.c (2188): [] does not start with '/'. >>> [Mon Sep 30 15:04:03 2019][3906:140148297873536] [debug] > > Also agreed. > >> but we'll need to investigate whether it can be fixed by configuration >> or needs a code change. Our configs are pretty flexible but we need to >> understand a bit better how we can let mod_jk keep out of the SSI >> handling of the internal requests. >> >> As far as I have understood, you do not actually want these SSI requests >> to be forwarded via mod_jk/AJP and instead want all of them being >> handled directly by Apache? > > That is my understanding as well.
I've figured out what is going on here. The SSI includes are using file="..." so they are entirely file system based. Therefore, the URI in the sub-request is set to "". When this is passed to mod_jk, it tries to normalise it, complains because it does not start with "/" and then returns an error. This prevents the processing of the sub-request. mod_jk returns an error since normalisation errors typically mean path traversal attempts and other similar client misbehaviour. There is a work-around. Use virtual="..." in the SSI includes. Meanwhile, I am working on a fix for mod_jk. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
