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.


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

Reply via email to