Acessing static content - Tomcat 7 vs. Tomcat9

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
Dear fellow Tomcat users,

 recently we migrated our application from Tomcat7 to Tomcat9. Most things
work great so far, but we observed on issue. Basically serving static pages
has stopped for us.

 Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
version.

The mod_jk configuration basically looks like:

<IfModule !mod_jk.c>
  LoadModule jk_module modules/mod_jk.so

  JkWorkersFile "conf/cb2/workers.properties"
  JkShmFile "logs/jk-runtime-status"
  JkLogFile "logs/mod_jk.log"
  JkLogLevel info
  JkWatchdogInterval 60
</IfModule>

And then later inside a virtual host:

#
# CB2 - Portal
#
# Mount the "/cb2" application to worker "cb2"
#
    JkMount /cb2/* cb2
#
# Unmount "/cb2/docs" from worker "cb2" to allow static content
# beeing served by apache. Same for "/cb2/cgi-bin"
#
    JkUnMount /cb2/docs/* cb2

So we JkUnMount the "/cb2/docs" directory from the application base in
order to server the content directly from Apache. "docs" itself is a
symbolic link pointing outside the application base.

With TC7, we observe the following in the apache access_log:

[07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
[07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384

So the POST from the application is redirected to the static content, which
is served OK.

With TC9 we see:

[05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1"
s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384

As said, the major difference between the setups is TC7 vs. TC9. Any ideas
for me to follow? I did not find anything in the migration 7->8 or 8->9
guides.

Kind regards
Martin
--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

markt
On 07/10/2019 12:22, Martin Knoblauch wrote:

> Dear fellow Tomcat users,
>
>  recently we migrated our application from Tomcat7 to Tomcat9. Most things
> work great so far, but we observed on issue. Basically serving static pages
> has stopped for us.
>
>  Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
> mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
> version.
>
> The mod_jk configuration basically looks like:
>
> <IfModule !mod_jk.c>
>   LoadModule jk_module modules/mod_jk.so
>
>   JkWorkersFile "conf/cb2/workers.properties"
>   JkShmFile "logs/jk-runtime-status"
>   JkLogFile "logs/mod_jk.log"
>   JkLogLevel info
>   JkWatchdogInterval 60
> </IfModule>
>
> And then later inside a virtual host:
>
> #
> # CB2 - Portal
> #
> # Mount the "/cb2" application to worker "cb2"
> #
>     JkMount /cb2/* cb2
> #
> # Unmount "/cb2/docs" from worker "cb2" to allow static content
> # beeing served by apache. Same for "/cb2/cgi-bin"
> #
>     JkUnMount /cb2/docs/* cb2
>
> So we JkUnMount the "/cb2/docs" directory from the application base in
> order to server the content directly from Apache. "docs" itself is a
> symbolic link pointing outside the application base.
>
> With TC7, we observe the following in the apache access_log:
>
> [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
> HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
> HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>
> So the POST from the application is redirected to the static content, which
> is served OK.
>
> With TC9 we see:
>
> [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1"
> s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384

Where and how is the redirect generated?

> As said, the major difference between the setups is TC7 vs. TC9. Any ideas
> for me to follow? I did not find anything in the migration 7->8 or 8->9
> guides.

I can't think of anything and a review of the migration guides doesn't
bring anything to mind. I'd be looking more at configuration differences
between the old and new systems at this point.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Konstantin Kolinko
In reply to this post by Martin Knoblauch-4
пн, 7 окт. 2019 г. в 14:23, Martin Knoblauch <[hidden email]>:

>
> Dear fellow Tomcat users,
>
>  recently we migrated our application from Tomcat7 to Tomcat9. Most things
> work great so far, but we observed on issue. Basically serving static pages
> has stopped for us.
>
>  Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
> mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
> version.
>
> The mod_jk configuration basically looks like:
>
> <IfModule !mod_jk.c>
>   LoadModule jk_module modules/mod_jk.so
>
>   JkWorkersFile "conf/cb2/workers.properties"
>   JkShmFile "logs/jk-runtime-status"
>   JkLogFile "logs/mod_jk.log"
>   JkLogLevel info
>   JkWatchdogInterval 60
> </IfModule>
>
> And then later inside a virtual host:
>
> #
> # CB2 - Portal
> #
> # Mount the "/cb2" application to worker "cb2"
> #
>     JkMount /cb2/* cb2
> #
> # Unmount "/cb2/docs" from worker "cb2" to allow static content
> # beeing served by apache. Same for "/cb2/cgi-bin"
> #
>     JkUnMount /cb2/docs/* cb2
>
> So we JkUnMount the "/cb2/docs" directory from the application base in
> order to server the content directly from Apache. "docs" itself is a
> symbolic link pointing outside the application base.
>
> With TC7, we observe the following in the apache access_log:
>
> [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
> HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
> HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>
> So the POST from the application is redirected to the static content, which
> is served OK.

A web server will happily server a static content in response to a
POST request. The redirect happens because you are requesting a
directory and your request URI does not end with a '/'.

> With TC9 we see:
>
> [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1"
> s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>
> As said, the major difference between the setups is TC7 vs. TC9. Any ideas
> for me to follow? I did not find anything in the migration 7->8 or 8->9
> guides.

1. In your access log here I see "GET /docs" instead of "/cb2/docs".
Is it intentional?

2. For Tomcat to issue a redirect, the "docs" directory must be
present in your web application. It can be empty, but it must be
present. (If there is none, Tomcat does not know that the requested
resource is a directory).

3. Starting with some version (January 2016) the default place where
the redirect is issued by Tomcat was moved from Mapper (in earlier
stages of request processing) to the DefaultServlet. This behaviour is
controlled by configuration attributes on a Context (in the file
META-INF/context.xml of your web application). See CVE-2015-5345

http://tomcat.apache.org/security-9.html

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

André Warnier (tomcat)
In reply to this post by markt
On 07.10.2019 13:45, Mark Thomas wrote:

> On 07/10/2019 12:22, Martin Knoblauch wrote:
>> Dear fellow Tomcat users,
>>
>>   recently we migrated our application from Tomcat7 to Tomcat9. Most things
>> work great so far, but we observed on issue. Basically serving static pages
>> has stopped for us.
>>
>>   Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
>> mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
>> version.
>>
>> The mod_jk configuration basically looks like:
>>
>> <IfModule !mod_jk.c>
>>    LoadModule jk_module modules/mod_jk.so
>>
>>    JkWorkersFile "conf/cb2/workers.properties"
>>    JkShmFile "logs/jk-runtime-status"
>>    JkLogFile "logs/mod_jk.log"
>>    JkLogLevel info
>>    JkWatchdogInterval 60
>> </IfModule>
>>
>> And then later inside a virtual host:
>>
>> #
>> # CB2 - Portal
>> #
>> # Mount the "/cb2" application to worker "cb2"
>> #
>>      JkMount /cb2/* cb2
>> #
>> # Unmount "/cb2/docs" from worker "cb2" to allow static content
>> # beeing served by apache. Same for "/cb2/cgi-bin"
>> #
>>      JkUnMount /cb2/docs/* cb2
>>
>> So we JkUnMount the "/cb2/docs" directory from the application base in
>> order to server the content directly from Apache. "docs" itself is a
>> symbolic link pointing outside the application base.
>>
>> With TC7, we observe the following in the apache access_log:
>>
>> [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
>> HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>> [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
>> HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>>
>> So the POST from the application is redirected to the static content, which
>> is served OK.
>>
>> With TC9 we see:
>>
>> [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1"
>> s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
>
> Where and how is the redirect generated?
>
>> As said, the major difference between the setups is TC7 vs. TC9. Any ideas
>> for me to follow? I did not find anything in the migration 7->8 or 8->9
>> guides.
>
> I can't think of anything and a review of the migration guides doesn't
> bring anything to mind. I'd be looking more at configuration differences
> between the old and new systems at this point.
>
> Mark
>

The URLs appear different :

- the first case shows a URL of "/cb2/docs" (with some kind of redirect from POST to a
GET). According to the mod_jk configuration, this is NOT being proxied to Tomcat. Assuming
thus that the httpd DOCUMENT_ROOT is set to (e.g.) /var/www/docs, it would mean that the
file being served is some directory list (or index document) located below
/var/www/docs/cb2/docs/ (on the httpd host).

- the second example shows a URL of "/docs", which according to the mod_jk configuration
above is also NOT being proxied to Tomcat; thus Apache httpd attempts to serve it locally.
But that URL does not match any Apache-httpd-local file (because /var/www/docs/docs does
not exist), and thus results in a 404 status "not found".

To verify this is quite simple :
In the URL bar of a browser, enter the URL "http://yourservername/cb2/docs" directly,
replacing "yourservername" alernatively with the one for tomcat 7 and the one for tomcat9.
The result should be the same, because this URL is not being proxied to Tomcat, and is
served locally by httpd.

(On the other hand, the URL "/docs" should give "404 not found" in both cases too)

What I suspect is :

The above URL "/cb2/docs" is not being entered in the browser URL bar.  Instead, the link
to that URL occurs in a html page previously returned by Tomcat, and the user just clicks
on the link.
Then maybe it is that previous page returned by Tomcat, that is different between Tomcat 7
and Tomcat 9.
(That could be consistent with "the major difference between the setups is TC7 vs. TC9.").

Further speculation under incomplete information (I love this) : could it be that under
Tomcat 7, your application is deployed under ../webapps/cb2, while under tomcat 9, you
have relocated it to ../webapps/ROOT ?


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
In reply to this post by Konstantin Kolinko
Hi Konstantin,

On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <[hidden email]>
wrote:

> пн, 7 окт. 2019 г. в 14:23, Martin Knoblauch <[hidden email]>:
> >
> > Dear fellow Tomcat users,
> >
> >  recently we migrated our application from Tomcat7 to Tomcat9. Most
> things
> > work great so far, but we observed on issue. Basically serving static
> pages
> > has stopped for us.
> >
> >  Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
> > mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
> > version.
> >
> > The mod_jk configuration basically looks like:
> >
> > <IfModule !mod_jk.c>
> >   LoadModule jk_module modules/mod_jk.so
> >
> >   JkWorkersFile "conf/cb2/workers.properties"
> >   JkShmFile "logs/jk-runtime-status"
> >   JkLogFile "logs/mod_jk.log"
> >   JkLogLevel info
> >   JkWatchdogInterval 60
> > </IfModule>
> >
> > And then later inside a virtual host:
> >
> > #
> > # CB2 - Portal
> > #
> > # Mount the "/cb2" application to worker "cb2"
> > #
> >     JkMount /cb2/* cb2
> > #
> > # Unmount "/cb2/docs" from worker "cb2" to allow static content
> > # beeing served by apache. Same for "/cb2/cgi-bin"
> > #
> >     JkUnMount /cb2/docs/* cb2
> >
> > So we JkUnMount the "/cb2/docs" directory from the application base in
> > order to server the content directly from Apache. "docs" itself is a
> > symbolic link pointing outside the application base.
> >
> > With TC7, we observe the following in the apache access_log:
> >
> > [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
> > HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> > [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
> > HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> >
> > So the POST from the application is redirected to the static content,
> which
> > is served OK.
>
> A web server will happily server a static content in response to a
> POST request. The redirect happens because you are requesting a
> directory and your request URI does not end with a '/'.
>
>
OK. Thanks for the explanation.

> With TC9 we see:
> >
> > [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs
> HTTP/1.1"
> > s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> >
> > As said, the major difference between the setups is TC7 vs. TC9. Any
> ideas
> > for me to follow? I did not find anything in the migration 7->8 or 8->9
> > guides.
>
> 1. In your access log here I see "GET /docs" instead of "/cb2/docs".
> Is it intentional?
>
>
No, just to many windows to cut and past from. And not enough caffeine...

2. For Tomcat to issue a redirect, the "docs" directory must be
> present in your web application. It can be empty, but it must be
> present. (If there is none, Tomcat does not know that the requested
> resource is a directory).
>
>
OK. The "docs" directory is actually a symbolic link to a directory
elsewhere.

3. Starting with some version (January 2016) the default place where
> the redirect is issued by Tomcat was moved from Mapper (in earlier
> stages of request processing) to the DefaultServlet. This behaviour is
> controlled by configuration attributes on a Context (in the file
> META-INF/context.xml of your web application). See CVE-2015-5345
>
> http://tomcat.apache.org/security-9.html
>
>
Sounds interesting. Need to look at it.

Thanks
Martin

> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Konstantin Kolinko
пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch <[hidden email]>:

>
> Hi Konstantin,
>
> On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <[hidden email]>
> wrote:
>
>
> 2. For Tomcat to issue a redirect, the "docs" directory must be
> > present in your web application. It can be empty, but it must be
> > present. (If there is none, Tomcat does not know that the requested
> > resource is a directory).
> >
> >
> OK. The "docs" directory is actually a symbolic link to a directory
> elsewhere.

Symbolic links by default are not allowed inside a web application.
The option to allow them differs between Tomcat 7 and 8.0, due to a
different underlying implementation of Web Application resources.

http://tomcat.apache.org/migration-8.html#Web_application_resources

(As a reminders: symbolic links must never be enabled on a
case-insensitive filesystem such as used by Windows, as it disables
the necessary security checks.)

http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
In reply to this post by André Warnier (tomcat)
On Mon, Oct 7, 2019 at 2:37 PM André Warnier (tomcat) <[hidden email]> wrote:

> On 07.10.2019 13:45, Mark Thomas wrote:
> > On 07/10/2019 12:22, Martin Knoblauch wrote:
> >> Dear fellow Tomcat users,
> >>
> >>   recently we migrated our application from Tomcat7 to Tomcat9. Most
> things
> >> work great so far, but we observed on issue. Basically serving static
> pages
> >> has stopped for us.
> >>
> >>   Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41
> using
> >> mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
> >> version.
> >>
> >> The mod_jk configuration basically looks like:
> >>
> >> <IfModule !mod_jk.c>
> >>    LoadModule jk_module modules/mod_jk.so
> >>
> >>    JkWorkersFile "conf/cb2/workers.properties"
> >>    JkShmFile "logs/jk-runtime-status"
> >>    JkLogFile "logs/mod_jk.log"
> >>    JkLogLevel info
> >>    JkWatchdogInterval 60
> >> </IfModule>
> >>
> >> And then later inside a virtual host:
> >>
> >> #
> >> # CB2 - Portal
> >> #
> >> # Mount the "/cb2" application to worker "cb2"
> >> #
> >>      JkMount /cb2/* cb2
> >> #
> >> # Unmount "/cb2/docs" from worker "cb2" to allow static content
> >> # beeing served by apache. Same for "/cb2/cgi-bin"
> >> #
> >>      JkUnMount /cb2/docs/* cb2
> >>
> >> So we JkUnMount the "/cb2/docs" directory from the application base in
> >> order to server the content directly from Apache. "docs" itself is a
> >> symbolic link pointing outside the application base.
> >>
> >> With TC7, we observe the following in the apache access_log:
> >>
> >> [07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
> >> HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> >> [07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
> >> HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> >>
> >> So the POST from the application is redirected to the static content,
> which
> >> is served OK.
> >>
> >> With TC9 we see:
> >>
> >> [05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs
> HTTP/1.1"
> >> s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
> >
> > Where and how is the redirect generated?
> >
> >> As said, the major difference between the setups is TC7 vs. TC9. Any
> ideas
> >> for me to follow? I did not find anything in the migration 7->8 or 8->9
> >> guides.
> >
> > I can't think of anything and a review of the migration guides doesn't
> > bring anything to mind. I'd be looking more at configuration differences
> > between the old and new systems at this point.
> >
> > Mark
> >
>
> The URLs appear different :
>
> - the first case shows a URL of "/cb2/docs" (with some kind of redirect
> from POST to a
> GET). According to the mod_jk configuration, this is NOT being proxied to
> Tomcat. Assuming
> thus that the httpd DOCUMENT_ROOT is set to (e.g.) /var/www/docs, it would
> mean that the
> file being served is some directory list (or index document) located below
> /var/www/docs/cb2/docs/ (on the httpd host).
>
>
Dear Andre,

 unfortunately this was cut/paste foul-up on my side :-(

Martin

> - the second example shows a URL of "/docs", which according to the mod_jk
> configuration
> above is also NOT being proxied to Tomcat; thus Apache httpd attempts to
> serve it locally.
> But that URL does not match any Apache-httpd-local file (because
> /var/www/docs/docs does
> not exist), and thus results in a 404 status "not found".
>
> To verify this is quite simple :
> In the URL bar of a browser, enter the URL "http://yourservername/cb2/docs"
> directly,
> replacing "yourservername" alernatively with the one for tomcat 7 and the
> one for tomcat9.
> The result should be the same, because this URL is not being proxied to
> Tomcat, and is
> served locally by httpd.
>
> (On the other hand, the URL "/docs" should give "404 not found" in both
> cases too)
>
> What I suspect is :
>
> The above URL "/cb2/docs" is not being entered in the browser URL bar.
> Instead, the link
> to that URL occurs in a html page previously returned by Tomcat, and the
> user just clicks
> on the link.
> Then maybe it is that previous page returned by Tomcat, that is different
> between Tomcat 7
> and Tomcat 9.
> (That could be consistent with "the major difference between the setups is
> TC7 vs. TC9.").
>
> Further speculation under incomplete information (I love this) : could it
> be that under
> Tomcat 7, your application is deployed under ../webapps/cb2, while under
> tomcat 9, you
> have relocated it to ../webapps/ROOT ?
>
>
Nope. Application is at ".../webapps/cb2"

Thanks
Martin
--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
In reply to this post by Konstantin Kolinko
On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko <[hidden email]>
wrote:

> пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch <[hidden email]>:
> >
> > Hi Konstantin,
> >
> > On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <
> [hidden email]>
> > wrote:
> >
> >
> > 2. For Tomcat to issue a redirect, the "docs" directory must be
> > > present in your web application. It can be empty, but it must be
> > > present. (If there is none, Tomcat does not know that the requested
> > > resource is a directory).
> > >
> > >
> > OK. The "docs" directory is actually a symbolic link to a directory
> > elsewhere.
>
> Symbolic links by default are not allowed inside a web application.
> The option to allow them differs between Tomcat 7 and 8.0, due to a
> different underlying implementation of Web Application resources.
>
> http://tomcat.apache.org/migration-8.html#Web_application_resources
>
> (As a reminders: symbolic links must never be enabled on a
> case-insensitive filesystem such as used by Windows, as it disables
> the necessary security checks.)
>
> http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>
> Best regards,
> Konstantin Kolinko
>
>
OK, this is interesting. We still had the TC7 style "allowLiniking" in the
Context tag. Now moved to Resources.

I also added the two mapper directives to Context:

      <Context path="/cb2" reloadable="false"

docBase="/opt/cb2/Portals/current/tomcat/webapps/cb2"
                        swallowOutput="true"
                        xmlValidation="false"
                        xmlNamespaceAware="false"
                        mapperContextRootRedirectEnabled="true"
                        mapperDirectoryRedirectEnabled="true"
                        useHttpOnly="false">

.
.
.

    </Context>


What I now get is weird in another way. But maybe it gives a hint:

[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "POST /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"

Then the browser tells me that "The page isn’t redirecting properly".

What one can see above is that the POST is now redirected, but the trailing
"/" is not added as I would have expected using the two mapper directives
...


---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Christopher Schultz-2
In reply to this post by Martin Knoblauch-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Martin,

On 10/7/19 07:22, Martin Knoblauch wrote:
> The mod_jk configuration basically looks like:
>
> <IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so
>
> JkWorkersFile "conf/cb2/workers.properties" JkShmFile
> "logs/jk-runtime-status" JkLogFile "logs/mod_jk.log" JkLogLevel
> info JkWatchdogInterval 60 </IfModule>

So, you only configure mod_jk if it's NOT available? You have a "!" in
your <IfModule> which looks like it's going to never ever work.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVVIACgkQHPApP6U8
pFgbxg//TrWenaqfME8ekEnucExZXaKTcF8w2PhWVOhtrc1sUiDemmjudBjJUth/
LJ61XdgTDd5hOYVUOfHukwIgkEwD92RvD+NXRuSppubzRS9u5vPMjwnLbqL4d6/8
0yksGLeol3Ub4mwvNW7LRSfjev3FrpiVa9YpWrr+HgHHt5dVYOlIRQy3Ur8W9JIV
j11HSX8S4rqlsPCeyB4CLFBtuMdTCSto1MbhmhxWofJZpekz6MzzFebWDiYPS5h9
JGP51Gu8yo4pIwg0EVC/nP/ANilB+TsRN870Ds0wppSY/bcttNt+mBlFEeahwndi
xHrdxcx08ep7iKWLJrCU2GkxWuWaJS6vMjUE3LztR5r/L6bvisYpe8itCWTlPXNO
mtewywyyS4ne9UeviaMn0tyIfa7kFQQcUI0dL2xV1Fl1g9GyYFdUeOKTR3NqoHeq
3KK9XRLd7OCF25NJ71ITLZwV7nUka7VtIP11iJD6K+aOj92F90pwdF9CLlfPaAwW
HZlbZ8DuIClzEVNiPO9p9aHQTWu6QeMB+iM7l/DwbVHQmLlEWOMgvXN6jc781t6M
2NGjxYAG5w2p/QtS0czCKGdPeMY0dKtfj8KeGjwzgCSuw4aDUjXIBxN31PJ5E0wd
7xWeEsp7/ykkggjPSXweSOrXohY/UkglInU7OGAQoJlAn+kUOe0=
=x9Jm
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
On Mon, Oct 7, 2019 at 5:10 PM Christopher Schultz <
[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Martin,
>
> On 10/7/19 07:22, Martin Knoblauch wrote:
> > The mod_jk configuration basically looks like:
> >
> > <IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so
> >
> > JkWorkersFile "conf/cb2/workers.properties" JkShmFile
> > "logs/jk-runtime-status" JkLogFile "logs/mod_jk.log" JkLogLevel
> > info JkWatchdogInterval 60 </IfModule>
>
> So, you only configure mod_jk if it's NOT available? You have a "!" in
> your <IfModule> which looks like it's going to never ever work.
>
>
 For a second you worried me. As far as I understand the documentation the
section above means that I configure mod_jk if it is not yet loaded. And
years of operations indicate my understanding is right :-)

Cheers
Martin
--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

André Warnier (tomcat)
In reply to this post by Martin Knoblauch-4
Hi.
see at end.

On 07.10.2019 16:26, Martin Knoblauch wrote:

> On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko <[hidden email]>
> wrote:
>
>> пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch <[hidden email]>:
>>>
>>> Hi Konstantin,
>>>
>>> On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <
>> [hidden email]>
>>> wrote:
>>>
>>>
>>> 2. For Tomcat to issue a redirect, the "docs" directory must be
>>>> present in your web application. It can be empty, but it must be
>>>> present. (If there is none, Tomcat does not know that the requested
>>>> resource is a directory).
>>>>
>>>>
>>> OK. The "docs" directory is actually a symbolic link to a directory
>>> elsewhere.
>>
>> Symbolic links by default are not allowed inside a web application.
>> The option to allow them differs between Tomcat 7 and 8.0, due to a
>> different underlying implementation of Web Application resources.
>>
>> http://tomcat.apache.org/migration-8.html#Web_application_resources
>>
>> (As a reminders: symbolic links must never be enabled on a
>> case-insensitive filesystem such as used by Windows, as it disables
>> the necessary security checks.)
>>
>> http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>>
>> Best regards,
>> Konstantin Kolinko
>>
>>
> OK, this is interesting. We still had the TC7 style "allowLiniking" in the
> Context tag. Now moved to Resources.
>
> I also added the two mapper directives to Context:
>
>        <Context path="/cb2" reloadable="false"
>
> docBase="/opt/cb2/Portals/current/tomcat/webapps/cb2"
>                          swallowOutput="true"
>                          xmlValidation="false"
>                          xmlNamespaceAware="false"
>                          mapperContextRootRedirectEnabled="true"
>                          mapperDirectoryRedirectEnabled="true"
>                          useHttpOnly="false">
>
> ..
> ..
> ..
>
>      </Context>
>
>
> What I now get is weird in another way. But maybe it gives a hint:
>
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "POST /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
> [07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
> HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
> (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
>
> Then the browser tells me that "The page isn’t redirecting properly".
>
> What one can see above is that the POST is now redirected, but the trailing
> "/" is not added as I would have expected using the two mapper directives
> ...
Not only that, but also all the subsequent browser GET requests for "/cb2/docs", get a 302
response with a HTTP header :
Location: /cb2/docs
So the browser immediately re-issues a request for "/cb2/docs", which receives the same
response, etc.
Until the (smart) browser realises that it is always requesting and receiving the same
thing and calls quits.

>

What you are showing above as log, is only the httpd access log.
Do you have an access log enabled in tomcat, and do you see these same accesses there ?
(And if yes, then forget all the rest below).

Or else, can you modify the "LogLevel" directive in httpd, so that you see (in the httpd
error log) how (or if) these accesses are really being proxied to tomcat ?
(à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)

Based on this, from a previous post :
quote
#
# CB2 - Portal
#
# Mount the "/cb2" application to worker "cb2"
#
      JkMount /cb2/* cb2
#
# Unmount "/cb2/docs" from worker "cb2" to allow static content
# beeing served by apache. Same for "/cb2/cgi-bin"
#
      JkUnMount /cb2/docs/* cb2

So we JkUnMount the "/cb2/docs" directory from the application base in
order to server the content directly from Apache. "docs" itself is a
symbolic link pointing outside the application base.

unquote

, I would indeed tend to say that a request with the URL "/cb2/docs" SHOULD be proxied to
tomcat (and that the redirect should thus be coming from tomcat), but better make
absolutely sure maybe ? (hence the additional logging above)

The thing I'm unsure of myself, is this :
Apache httpd gets the original request first. Initially, it doesn't know if this request
should be proxied to tomcat or not. So, in its "map to storage" phase - which happens
fairly early in the request processing -, it might try to map this URL to its local
filesystem. Because you do indeed have files locally under /cb2/docs/, it would then find
that "/cb2/docs" is indeed a directory (or a link to ditto).
Now two things can happen, depending on the stage at which the mod_jk proxying directives
intervene in httpd :
- either httpd considers that the request, being for a directory, should have a trailing
"/", and *httpd* issues the 302 redirect to the browser, without even getting to the
proxying-to-tomcat stage
- or the proxying directive has insinuated itself somewhere in-between, and httpd does in
fact proxy the original request to tomcat (rather than trying to map it to its own
filesystem first), and it is tomcat (which also would need to find a directory at
../webapps/cb2/docs) which issues that redirect.

I do not know which of the above is true, because I am unsure of the httpd request cycle
stage at which mod_jk inserts its URL mapping logic.
But the logs which you have so far provided do not really *prove* that these requests make
it to tomcat. So, if it was me, before spending time maybe looking in the wrong place, I
would want to make sure of that first.

Another way would be to enable some local debugging console in the browser, and have a
look at what these 302 replies look like. Apart from the "Location:" header, there must be
a header there indicating from which webserver this response is coming (httpd or tomcat).

Again, because of the configuration that you showed, and because the behaviour seems to
change after making a change in the tomcat configuration, I would tend to believe that
these requests are being proxied to tomcat. But let's be 100% sure, rather than 99%..


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
Hi Andre,

thanks for the extensive response. this is really appreciated. See below
for comments

On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) <[hidden email]>
wrote:

> Hi.
> see at end.
>
>
> > Then the browser tells me that "The page isn’t redirecting properly".
> >
> > What one can see above is that the POST is now redirected, but the
> trailing
> > "/" is not added as I would have expected using the two mapper directives
> > ...
> Not only that, but also all the subsequent browser GET requests for
> "/cb2/docs", get a 302
> response with a HTTP header :
> Location: /cb2/docs
> So the browser immediately re-issues a request for "/cb2/docs", which
> receives the same
> response, etc.
> Until the (smart) browser realises that it is always requesting and
> receiving the same
> thing and calls quits.
>
> >
>
> What you are showing above as log, is only the httpd access log.
> Do you have an access log enabled in tomcat, and do you see these same
> accesses there ?
> (And if yes, then forget all the rest below).
>
>
Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO
NOT* see requests for "/cb2/docs" in there.

Looking at the TC7 setup I can find the access and redirect in the Tomcat
access log:

160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1"
302 -


Or else, can you modify the "LogLevel" directive in httpd, so that you see
> (in the httpd
> error log) how (or if) these accesses are really being proxied to tomcat ?
> (à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)
>
>
Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to
see there. So I am still confused here.

Based on this, from a previous post :

> quote
> #
> # CB2 - Portal
> #
> # Mount the "/cb2" application to worker "cb2"
> #
>       JkMount /cb2/* cb2
> #
> # Unmount "/cb2/docs" from worker "cb2" to allow static content
> # beeing served by apache. Same for "/cb2/cgi-bin"
> #
>       JkUnMount /cb2/docs/* cb2
>
> So we JkUnMount the "/cb2/docs" directory from the application base in
> order to server the content directly from Apache. "docs" itself is a
> symbolic link pointing outside the application base.
>
> unquote
>
> , I would indeed tend to say that a request with the URL "/cb2/docs"
> SHOULD be proxied to
> tomcat (and that the redirect should thus be coming from tomcat), but
> better make
> absolutely sure maybe ? (hence the additional logging above)
>
> The thing I'm unsure of myself, is this :
> Apache httpd gets the original request first. Initially, it doesn't know
> if this request
> should be proxied to tomcat or not. So, in its "map to storage" phase -
> which happens
> fairly early in the request processing -, it might try to map this URL to
> its local
> filesystem. Because you do indeed have files locally under /cb2/docs/, it
> would then find
> that "/cb2/docs" is indeed a directory (or a link to ditto).
> Now two things can happen, depending on the stage at which the mod_jk
> proxying directives
> intervene in httpd :
> - either httpd considers that the request, being for a directory, should
> have a trailing
> "/", and *httpd* issues the 302 redirect to the browser, without even
> getting to the
> proxying-to-tomcat stage
> - or the proxying directive has insinuated itself somewhere in-between,
> and httpd does in
> fact proxy the original request to tomcat (rather than trying to map it to
> its own
> filesystem first), and it is tomcat (which also would need to find a
> directory at
> ../webapps/cb2/docs) which issues that redirect.
>
> I do not know which of the above is true, because I am unsure of the httpd
> request cycle
> stage at which mod_jk inserts its URL mapping logic.
> But the logs which you have so far provided do not really *prove* that
> these requests make
> it to tomcat. So, if it was me, before spending time maybe looking in the
> wrong place, I
> would want to make sure of that first.
>
> Another way would be to enable some local debugging console in the
> browser, and have a
> look at what these 302 replies look like. Apart from the "Location:"
> header, there must be
> a header there indicating from which webserver this response is coming
> (httpd or tomcat).
>
> Again, because of the configuration that you showed, and because the
> behaviour seems to
> change after making a change in the tomcat configuration, I would tend to
> believe that
> these requests are being proxied to tomcat. But let's be 100% sure, rather
> than 99%..
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

André Warnier (tomcat)
On 08.10.2019 13:41, Martin Knoblauch wrote:

> Hi Andre,
>
> thanks for the extensive response. this is really appreciated. See below
> for comments
>
> On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) <[hidden email]>
> wrote:
>
>> Hi.
>> see at end.
>>
>>
>>> Then the browser tells me that "The page isn’t redirecting properly".
>>>
>>> What one can see above is that the POST is now redirected, but the
>> trailing
>>> "/" is not added as I would have expected using the two mapper directives
>>> ...
>> Not only that, but also all the subsequent browser GET requests for
>> "/cb2/docs", get a 302
>> response with a HTTP header :
>> Location: /cb2/docs
>> So the browser immediately re-issues a request for "/cb2/docs", which
>> receives the same
>> response, etc.
>> Until the (smart) browser realises that it is always requesting and
>> receiving the same
>> thing and calls quits.
>>
>>>
>>
>> What you are showing above as log, is only the httpd access log.
>> Do you have an access log enabled in tomcat, and do you see these same
>> accesses there ?
>> (And if yes, then forget all the rest below).
>>
>>
> Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO
> NOT* see requests for "/cb2/docs" in there.
>
> Looking at the TC7 setup I can find the access and redirect in the Tomcat
> access log:
>
> 160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1"
> 302 -
>

Aha.  So it looks like, with Tomcat 9 in the back-end, these requests are not even being
proxied to Tomcat, and that it is httpd in that case which returns the 302's.
Why that would be, with everything else being identical, is also a puzzle to me.
But it's still better that looking uselessly in some Tomcat configuration issue.

Maybe this will give someone else on the list an idea ..

In the meantime, a question : considering your JkMount/JkUnmount directives below, you do
have some files locally under Apache httpd's filesystem, which you want to serve directly
from httpd.
Would you have any other configuration sections with <Location(Match)> which cover these
files, and /may/ be interfering/overriding the JkMount/unmount logic ?
(Agreed, this is a long shot, and whatever they are, they should do the same whether it is
t7 or t9 in the back-end, but again, one never knows..)


>
> Or else, can you modify the "LogLevel" directive in httpd, so that you see
>> (in the httpd
>> error log) how (or if) these accesses are really being proxied to tomcat ?
>> (à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)
>>
>>
> Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to
> see there. So I am still confused here.
>
> Based on this, from a previous post :
>> quote
>> #
>> # CB2 - Portal
>> #
>> # Mount the "/cb2" application to worker "cb2"
>> #
>>        JkMount /cb2/* cb2
>> #
>> # Unmount "/cb2/docs" from worker "cb2" to allow static content
>> # beeing served by apache. Same for "/cb2/cgi-bin"
>> #
>>        JkUnMount /cb2/docs/* cb2
>>
>> So we JkUnMount the "/cb2/docs" directory from the application base in
>> order to server the content directly from Apache. "docs" itself is a
>> symbolic link pointing outside the application base.
>>
>> unquote
>>
>> , I would indeed tend to say that a request with the URL "/cb2/docs"
>> SHOULD be proxied to
>> tomcat (and that the redirect should thus be coming from tomcat), but
>> better make
>> absolutely sure maybe ? (hence the additional logging above)
>>
>> The thing I'm unsure of myself, is this :
>> Apache httpd gets the original request first. Initially, it doesn't know
>> if this request
>> should be proxied to tomcat or not. So, in its "map to storage" phase -
>> which happens
>> fairly early in the request processing -, it might try to map this URL to
>> its local
>> filesystem. Because you do indeed have files locally under /cb2/docs/, it
>> would then find
>> that "/cb2/docs" is indeed a directory (or a link to ditto).
>> Now two things can happen, depending on the stage at which the mod_jk
>> proxying directives
>> intervene in httpd :
>> - either httpd considers that the request, being for a directory, should
>> have a trailing
>> "/", and *httpd* issues the 302 redirect to the browser, without even
>> getting to the
>> proxying-to-tomcat stage
>> - or the proxying directive has insinuated itself somewhere in-between,
>> and httpd does in
>> fact proxy the original request to tomcat (rather than trying to map it to
>> its own
>> filesystem first), and it is tomcat (which also would need to find a
>> directory at
>> ../webapps/cb2/docs) which issues that redirect.
>>
>> I do not know which of the above is true, because I am unsure of the httpd
>> request cycle
>> stage at which mod_jk inserts its URL mapping logic.
>> But the logs which you have so far provided do not really *prove* that
>> these requests make
>> it to tomcat. So, if it was me, before spending time maybe looking in the
>> wrong place, I
>> would want to make sure of that first.
>>
>> Another way would be to enable some local debugging console in the
>> browser, and have a
>> look at what these 302 replies look like. Apart from the "Location:"
>> header, there must be
>> a header there indicating from which webserver this response is coming
>> (httpd or tomcat).
>>
>> Again, because of the configuration that you showed, and because the
>> behaviour seems to
>> change after making a change in the tomcat configuration, I would tend to
>> believe that
>> these requests are being proxied to tomcat. But let's be 100% sure, rather
>> than 99%..
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Christopher Schultz-2
In reply to this post by Martin Knoblauch-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Martin,

On 10/7/19 11:45, Martin Knoblauch wrote:

> On Mon, Oct 7, 2019 at 5:10 PM Christopher Schultz <
> [hidden email]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Martin,
>>
>> On 10/7/19 07:22, Martin Knoblauch wrote:
>>> The mod_jk configuration basically looks like:
>>>
>>> <IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so
>>>
>>> JkWorkersFile "conf/cb2/workers.properties" JkShmFile
>>> "logs/jk-runtime-status" JkLogFile "logs/mod_jk.log"
>>> JkLogLevel info JkWatchdogInterval 60 </IfModule>
>>
>> So, you only configure mod_jk if it's NOT available? You have a
>> "!" in your <IfModule> which looks like it's going to never ever
>> work.
>>
>>
> For a second you worried me. As far as I understand the
> documentation the section above means that I configure mod_jk if it
> is not yet loaded. And years of operations indicate my
> understanding is right :-)

Sorry, I actually didn't notice the "LoadModule" in there.

It's strange to see a LoadModule and the other configuration all
together for me. Typically, I load modules in one section and
configure then in another. It's all rather subjective, of course.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2c3ScACgkQHPApP6U8
pFg8+xAAsuyGXzxffPyIOZI/f0gjSm8JkNmE+SvKV2F5XuL5FeZlmxZq2Y2H7ibb
DJLIafutH+4ZzSnrQD5nMwbqLpYLOKUYV4Uc0aw+MH/hnbu2IFsR4f8wuhhck6xy
QDnHPM2Av2jjhkU1abd1z/qYFeRlhtMPp91GZMLr45lT0D9Plyo2awUNGqQz41Kk
mLKmiIuUayzrZSR2AX8FZMMM8jR3scgw0t43EJOuo+u2rwGjshwDhWs/tZUrAWU3
EGZWf/MNwGYg7Ku23uxZ3HgzQRyTOUi+kG9CBfJMGGSWoFQWUXe3oJ9wgNMauK/E
i+yex/l0r840M+C8voxlL2L6ohSr64zIvmVesTyK2HT8xvna+qhxp5V/dlUBtsiv
mbp3lrGga9HxFbQf1cnQxFMP0/KEhdmlS9LZt4GI+KW6iOufdOPpC/egSnXx9yHD
q8C02BLR83inY/da1pBQvPWSqDLV7Lh9i2rjcBL1gZiAJRHXhRHN/TJj85EvrK76
9RsybJil3n4Yt8RzBtNnKDMtm1kBNeUFpdYx6gO0ElYftK4BWHZ7O/qw6NRzuMNX
A/BrcJsbg2osEpjLXsKhbtUBWxGNFgmNVDQmLx9msE28slEgN4OjLFV/tBvCQopo
vUZudKrsnVS3yNr2v/MhsgmEWrNby2gH9jLOmm7n7cU1ERyH/z4=
=uXJX
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Martin Knoblauch-4
On Tue, Oct 8, 2019 at 9:02 PM Christopher Schultz <
[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Martin,
>
>
>
> Sorry, I actually didn't notice the "LoadModule" in there.
>
> It's strange to see a LoadModule and the other configuration all
> together for me. Typically, I load modules in one section and
> configure then in another. It's all rather subjective, of course.
>
>
>
>
Yeah, that one is a bit different. Two reasons. First, the configurations
has been used for years and the guy doing it just preferred it that way.
Second, as "mod_jk" is an "external" module to "httpd", it actually makes
sense to check it that way. We know we want it. And if it cannot be loaded
"httpd" should not come up at all.

And now back to my redirect issue :-)

Cheers
Martin
--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de