date:20191007


On 08.10.2019 00:50, Magosányi Árpád wrote:

On 10/7/19 11:29 PM, André Warnier (tomcat) wrote:


 DirectoryIndex off
 RewriteEngine Off
 AuthType openid-connect
 AllowOverride None
 AuthzDBDQuery "a correct database query"
 Require dbd-group allrepo
 LogLevel debug



Nice. It have solved the problem, thank you very much. By adding the ssl
related directives here I could pass the ssl info as well. So basically
we have put the JkMount in a Location, and the other directives in
another similar directive, as a kind of workaround?


Think of it as follows :
When httpd gets a request,
- step 1 : it first looks only at the request URL, and it applies any directives that it 
finds in  or  sections which match that URL.
- step 2 : then it tries to match the URL, with the filesystem on disk, and IF it finds a 
file that corresponds to that URL

- step 3 : then it applies any  or  that apply 
to that file
- step 4 : httpd serves the file back to the browser

If you have JkMount directives that match the URL, then step 2, 3 and 4 above never 
happen, because the request will be passed to tomcat anyway, so it will never map to a 
file on the httpd filesystem. And if you have JkUnmount directives, that also match the 
URL, then they partially negate the matching JkMount, and they /force/ step 2, 3 and 4.


The combination of JkMount/JkUnmount directives, with the httpd  and 
 sections, is sometimes a bit unclear, specially when they overlap.


There is another syntax applicable to the proxying via mod_jk, which I prefer because I 
find that it makes the httpd URL mapping clearer, in a httpd configuration logic sense.

You can find it here :
http://tomcat.apache.org/connectors-doc/reference/apache.html
section : Using SetHandler and Environment Variables

Using that form, you do NOT use any "JkMount/JkUnmount" directives, you use only 
 blocks, like :



  SetHandler jakarta-servlet
  SetEnv JK_WORKER_NAME worker1
  DirectoryIndex off
  RewriteEngine Off
  AuthType openid-connect
  AllowOverride None
  AuthzDBDQuery "a correct database query"
  Require dbd-group allrepo
  LogLevel debug


The combination of the , SetHandler and SetEnv, does the same as 
a separate "JkMount /servlet* worker1" and (in my view) it makes it clearer in the Apache 
httpd configuration file, to know which URLs get proxied to tomcat and which do not get 
proxied.
Look at the example "" to see how you can have some static documents 
served by the httpd front-end directly (= not proxied to tomcat), and the real calls to 
tomcat servlets being proxied to tomcat.








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




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

Re: [POLL] Who is using CGIServlet, and why?

2019-10-07 Thread Chuck Caldarale

On Mon, Oct 7, 2019 at 10:22 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

I'm interested in what the community is doing with the CGIServlet, if
> anything. Please do NOT reply if you don't use the CGIServlet. Please
> DO reply if you fit into any of these categories:
>
> 1. Using Tomcat as a primary web server without reverse proxy (e.g.
> httpd/nginx/etc), and using CGIServlet to run e.g. Perl, PHP,
> Python... really any common scripting language on the back-end.
>

The above is our use case, mostly for prototyping, usually in Python.

  - Chuck

Re: user and certificate info is not passed to tomcat

On 10/7/19 11:29 PM, André Warnier (tomcat) wrote:
> 
>     DirectoryIndex off
>     RewriteEngine Off
>     AuthType openid-connect
>     AllowOverride None
>     AuthzDBDQuery "a correct database query"
>     Require dbd-group allrepo
>     LogLevel debug
>  

Nice. It have solved the problem, thank you very much. By adding the ssl
related directives here I could pass the ssl info as well. So basically
we have put the JkMount in a Location, and the other directives in
another similar directive, as a kind of workaround?

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

Re: user and certificate info is not passed to tomcat


Adding to my own previous post :

A posteriori, I saw a question here :
https://stackoverflow.com/questions/58240796/pass-username-and-client-certificate-from-apache-to-tomcat-using-mod-jk
that may be related to your question on this list.
Examining the above, you problem may be in the httpd configuration :
As I interpret it, the  section that you mention, will not be taken into 
account for the URLs that you are proxying to tomcat.
That is because  sections only apply if the URL ultimately maps to a local file 
for httpd. In this case, it does not, because you are proxying this request to tomcat. For 
such URLs, you should use a  or  in httpd, not a .

For example, *add* this to your httpd configuration :

DirectoryIndex off
RewriteEngine Off
AuthType openid-connect
AllowOverride None
AuthzDBDQuery "a correct database query"
Require dbd-group allrepo
LogLevel debug


Note: the above is very rough, and you may need to tune the regex a bit better.

On 08.10.2019 00:11, André Warnier (tomcat) wrote:

On 07.10.2019 23:24, Magosányi Árpád wrote:

On 10/7/19 8:20 PM, André Warnier (tomcat) wrote:


Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



Yes, I did, however adding it back did not improve the situation.


Ok. I just mentioned that, because it is one piece of the puzzle, and you might 
have
forgotten it.
What this piece really does is :
- IF the front-end Apache httpd authenticates the HTTP request which it later 
passes on to
tomcat
- IF the protocol used between Apache httpd and tomcat is AJP
- IF the AJP Connector in tomcat has the attribute set as above
- THEN tomcat will retrieve the user-id of the httpd-authenticated user, and 
save it
internally as the tomcat-authenticated user-id for this request

So now you have the two last IF's answered positively.
What about the first IF ?

Info : in the default format of the Apache httpd access log, it will show the
authenticated user (if any) for each request, for example like this :

127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET 
/starwebtt-internal/esearch...
(where "THEUSER" is the httpd-authenticated user)

while if the request is not authenticated by httpd, it will show a "-" instead 
of the
user-id, like this :
127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch...

(and, of course, if httpd has not authenticated the request which it later 
passes on to
tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot 
retrieve
this user-id, and thus the request, at the tomcat level, is not authenticated).


Next comes the question of how the tomcat application retrieves this user-id, 
from tomcat
itself. I suppose that this would be a question for the developers of the
"com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your 
configuration below.
(if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses 
some other
method, then you are out of luck for this front-end/back-end combination)(or 
you may need
to do something additional at the front-end httpd level).




My server.xml now:



   
   
   
   
   

   
 
   

   

 


 

   
 
   

   

 

   
 
   


and my web.xml until mime mappings:

http://xmlns.jcp.org/xml/ns/javaee";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
   version="4.0">


 
 default

org.apache.catalina.servlets.DefaultServlet
 
 debug
 0
 
 
 listings
 false
 
 1
 


 
 jsp
 org.apache.jasper.servlet.JspServlet
 
 fork
 false
 
 
 xpoweredBy
 false
 
 3
 


 
 default
 /
 

 
 jsp
 *.jsp
 *.jspx
 

   
 KKAuthorizationFilter

com.kodekonveyor.realm.KKAuthorizationFilter
   

   
 KKAuthorizationFilter
 /*
 REQUEST
   

 
 30
 










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




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

Re: user and certificate info is not passed to tomcat


On 07.10.2019 23:24, Magosányi Árpád wrote:

On 10/7/19 8:20 PM, André Warnier (tomcat) wrote:


Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



Yes, I did, however adding it back did not improve the situation.


Ok. I just mentioned that, because it is one piece of the puzzle, and you might have 
forgotten it.

What this piece really does is :
- IF the front-end Apache httpd authenticates the HTTP request which it later passes on to 
tomcat

- IF the protocol used between Apache httpd and tomcat is AJP
- IF the AJP Connector in tomcat has the attribute set as above
- THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it 
internally as the tomcat-authenticated user-id for this request


So now you have the two last IF's answered positively.
What about the first IF ?

Info : in the default format of the Apache httpd access log, it will show the 
authenticated user (if any) for each request, for example like this :


127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET 
/starwebtt-internal/esearch...
(where "THEUSER" is the httpd-authenticated user)

while if the request is not authenticated by httpd, it will show a "-" instead of the 
user-id, like this :

127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch...

(and, of course, if httpd has not authenticated the request which it later passes on to 
tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve 
this user-id, and thus the request, at the tomcat level, is not authenticated).



Next comes the question of how the tomcat application retrieves this user-id, from tomcat 
itself. I suppose that this would be a question for the developers of the 
"com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below.
(if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other 
method, then you are out of luck for this front-end/back-end combination)(or you may need 
to do something additional at the front-end httpd level).





My server.xml now:



   
   
   
   
   

   
 
   

   

 


 

   
 
   

   

 

   
 
   


and my web.xml until mime mappings:

http://xmlns.jcp.org/xml/ns/javaee";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
   version="4.0">


 
 default

org.apache.catalina.servlets.DefaultServlet
 
 debug
 0
 
 
 listings
 false
 
 1
 


 
 jsp
 org.apache.jasper.servlet.JspServlet
 
 fork
 false
 
 
 xpoweredBy
 false
 
 3
 


 
 default
 /
 

 
 jsp
 *.jsp
 *.jspx
 

   
 KKAuthorizationFilter

com.kodekonveyor.realm.KKAuthorizationFilter
   

   
 KKAuthorizationFilter
 /*
 REQUEST
   

 
 30
 










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

Re: user and certificate info is not passed to tomcat

On 10/7/19 8:20 PM, André Warnier (tomcat) wrote:
>
> Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?
>

Yes, I did, however adding it back did not improve the situation.


My server.xml now:



  
  
  
  
  

  
    
  

  

    


    

  
    
  

  

    

  
    
  


and my web.xml until mime mappings:

http://xmlns.jcp.org/xml/ns/javaee";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
  version="4.0">


    
    default
   
org.apache.catalina.servlets.DefaultServlet
    
    debug
    0
    
    
    listings
    false
    
    1
    


    
    jsp
    org.apache.jasper.servlet.JspServlet
    
    fork
    false
    
    
    xpoweredBy
    false
    
    3
    


    
    default
    /
    

    
    jsp
    *.jsp
    *.jspx
    

  
    KKAuthorizationFilter
   
com.kodekonveyor.realm.KKAuthorizationFilter
  
 
  
    KKAuthorizationFilter
    /*
    REQUEST
  

    
    30
    




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


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

Re: Acessing static content - Tomcat 7 vs. Tomcat9


Hi.
see at end.

On 07.10.2019 16:26, Martin Knoblauch wrote:

On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko 
wrote:


пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch :


Hi Konstantin,

On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <

knst.koli...@gmail.com>

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:

   

..
..
..

 


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

Re: user and certificate info is not passed to tomcat


On 07.10.2019 17:36, Magosányi Árpád wrote:

Magosányi,


How are you getting the attributes from the request?



This is the filter code:




String user = httpRequest.getRemoteUser(); Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
this.context.log("user:"+user);


This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?


I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.

The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.




To get the certificate chain, I think you also need this in your httpd
configuration:

 JkOptions +ForwardSSLCertChain


I have added this now, though as I understand this is only needed if I
want to get the full chain.

Unfortunately this did not improve the situation in any way.



Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



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

Re: Acessing static content - Tomcat 7 vs. Tomcat9

On Mon, Oct 7, 2019 at 5:10 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 10/7/19 07:22, Martin Knoblauch wrote:
> > The mod_jk configuration basically looks like:
> >
> >  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 
>
> So, you only configure mod_jk if it's NOT available? You have a "!" in
> your  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

Re: user and certificate info is not passed to tomcat

> Magosányi,
>
> >> How are you getting the attributes from the request?
>
> > This is the filter code:
>
>
> > String user = httpRequest.getRemoteUser(); Object cert =
> > httpRequest.getAttribute("javax.servlet.request.X509Certificate");
> > this.context.log("user:"+user);
>
> This won't show any username unless the user has logged-in using HTTP
> Basic/Digest authentication. Are you using those?

I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.

The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.


>
> To get the certificate chain, I think you also need this in your httpd
> configuration:
>
>     JkOptions +ForwardSSLCertChain
>
I have added this now, though as I understand this is only needed if I
want to get the full chain.

Unfortunately this did not improve the situation in any way.



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

Re: user and certificate info is not passed to tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Magosányi,

On 10/7/19 11:16, Magosányi Árpád wrote:
>> Magosányi,
>>
>> On 10/7/19 10:37, Magosányi Árpád wrote:
>>> I intend to use the user and certificate info in a Filter.
>>
>>> I think I have configured everything to do that, but the
>>> information does not get passed along. Based on various
>>> documentations and howtos, SSLVerifyClient require, SSLOptions
>>> +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On
>>> should be enough to pass certificate data, and Require
>>> valid-user should be enough to pass the authenticated
>>> username.
>>
>>> I see the following debug output (also contains the various
>>> info logged by the filter), which clearly lacks the information
>>> needed.
>> How are you getting the attributes from the request?
>
> This is the filter code:
>
>
> String user = httpRequest.getRemoteUser(); Object cert =
> httpRequest.getAttribute("javax.servlet.request.X509Certificate");
> this.context.log("user:"+user);

This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?

To get the certificate chain, I think you also need this in your httpd
configuration:

JkOptions +ForwardSSLCertChain

>> Is the CGI being executed by Tomcat or is it being executed by
>> httpd?
>
> Executed by Apache httpd.

Okay.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bWSkACgkQHPApP6U8
pFgkdQ/+O3c3y8QZaBSyQk0do9nCyVl1os/GBGnBTmPYio7C3L/DHQ78LaERjJwl
DHvElopUxA5T7Jcbrg8mAN41lv3oLkoZqBv1htXxL/6JliRGG5DkH8ZCXbIBIH36
a2kVIJ2B4fbPryZ0kjZ+dmiHfJUYRr41NNZ0Ejrs93VEsV4+A8JZna74z4Wh0nRN
AwctTF/PTZuPrgEAVx7s9zxGFAasHWv5h3UIHXUmHKCmFQxY8bP8GUWXyAZ0pdtg
PiDJf3xAZeG2joB7n2M44VohGyFhG0i+x4fKYn212n8zq7bs++TbWiknrUAUQqMS
LFc6qXw85CxeKoJva4Q1F228HmtXJXLYw/6esjQHWdKqChU2IPUutrTFwxeb2hlf
ZBWHby77FyDQtErakxyVlv9Qi4bwmPeH4bR86ovarxhFYQ7bEcEyEAxdsY6HPnpj
we/pvHXWhb1Rs6MAthZyXzyhmGHu4nZyHbedQnsgX9hBAXerSqs0u8AQaAkmQLtd
dYDNQZ2jL5scN8jB951BMTlgskpxuWGyxG6xbBPM6/YdGTN9Qfgem7TRPzhDImO8
C53AheJwAK/RQGAoNaXIHK66p1bTR33IH3ycvmzsDhBxdtQcCRSpABL6Xm8LGxzS
PU2zKywcD5dqKu9Btd1+PECVy1MIPUkvl++Qv9TwTdqxwGoas3s=
=PCeu
-END PGP SIGNATURE-

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

[POLL] Who is using CGIServlet, and why?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm interested in what the community is doing with the CGIServlet, if
anything. Please do NOT reply if you don't use the CGIServlet. Please
DO reply if you fit into any of these categories:

1. Using Tomcat as a primary web server without reverse proxy (e.g.
httpd/nginx/etc), and using CGIServlet to run e.g. Perl, PHP,
Python... really any common scripting language on the back-end.

2. Using Tomcat for mostly Java code, but you use the heck out of
something very specific (e.g. ImageMagick) via CGI

3. Using Tomcat with mostly Java code, except you've got that one
script that was written back in 1997 by the guy who never talks and
nobody knows how it works, only that your business depends upon it, so
the CGIServlet lets you continue to do that.

If you can fit yourself into one of the buckets above, please do so.
If you can't, please provide a short explanation of why you (a) still
need the CGIServlet and (b) don't fit into one of the above buckets.
Basically, I'm trying to limit the discussion to what people actually
NEED and avoid devolving into endless group-discussions of why some
company operates the way that it does.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bWA8ACgkQHPApP6U8
pFhaaQ//bUQnlJXM+thuLM3kyGPHLurmOis5mZ5DnvL+G4ij/TNxI5ECcLjtEQmi
kRCGij0xiWiG8Iz9I3s87PN9FBiADXbythjPKP7A5GkaC7/sg+O2eH55ut8Y4/A6
0ju+tAvm4adhMFYvl2sA71TPeXfUR/aamgP57W/KGM4jXcP7pN4Qz4giC/zUcwkD
SpActx3PSWc9hFLskxnq50H0Mq0LNYij5iWsuUjSwCCNeKL5XlTvLrb4JIRH7efk
hdeeDFnpZ/kaEZrlTVwRptGJj4cUV+bccke4T4xdEgZOM7F8Ujx90B2HotnDcWZW
OvoDBOMB2+TzWnWTDrU9b/u0MAb8tervPiHL9QcMeIvZCJX5h8hFP81i8yyBViD+
vTyfnwPP0CvQ8bIYNPTE4MVd5mirTJbDICnADmxbQvKFACZU0ZsAYZgzyGcUjhg3
vzYoXn4/DMZKdcwy25cjoHan8GdYOVXGChioppUqA8Kiek/VV6xJ+omm8oV7TvLd
PDE9OZ9xbrSGtA/Yg7s9L+4prOTIkZppiYg9HXyV2R6IeaWtLqnHJ8EXoB7h3hNA
GRqXFLeeqXECeleUgCdrTxDSex0Yq5GIXJozRW5LiNmU37rfQxIF34NFDFX8/UvM
IIxJhRjy25lsk4wvMuYY5XvPZEttI+wLCBQrtnBHxTXkICou0Pw=
=hzhH
-END PGP SIGNATURE-

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

Re: user and certificate info is not passed to tomcat

> Magosányi,
>
> On 10/7/19 10:37, Magosányi Árpád wrote:
> > I intend to use the user and certificate info in a Filter.
>
> > I think I have configured everything to do that, but the
> > information does not get passed along. Based on various
> > documentations and howtos, SSLVerifyClient require, SSLOptions
> > +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On
> > should be enough to pass certificate data, and Require valid-user
> > should be enough to pass the authenticated username.
>
> > I see the following debug output (also contains the various info
> > logged by the filter), which clearly lacks the information needed.
> How are you getting the attributes from the request?

This is the filter code:


package com.kodekonveyor.realm;

import java.io.IOException;
import java.util.Collections;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

public class KKAuthorizationFilter implements Filter {

    private ServletContext context;

    @Override
    public void init(FilterConfig fConfig) throws ServletException {
        this.context = fConfig.getServletContext();
        this.context.log("KKAuthorizationFilter initialized");
    }
   
    @Override
    public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        String user = httpRequest.getRemoteUser();
        String authType = httpRequest.getAuthType();
        for ( String attributeName:
Collections.list(httpRequest.getAttributeNames())) {
            this.context.log("attr
"+attributeName+"="+httpRequest.getAttribute(attributeName));
        }
        for ( String name:
Collections.list(httpRequest.getParameterNames())) {
            this.context.log("param
"+name+"="+httpRequest.getParameterValues(name));
        }
        for ( String headerName:
Collections.list(httpRequest.getHeaderNames())) {
            for (String value:
Collections.list(httpRequest.getHeaders(headerName)))
            this.context.log("header "+headerName+":"+value);
        }
        HttpSession session = httpRequest.getSession();
        this.context.log("session:"+session);
        if(null != session)
            for (String sessionAttName:
Collections.list(session.getAttributeNames())) {
                this.context.log("session attribute
"+sessionAttName+":"+session.getAttribute(sessionAttName));           
            }
        for ( String attributeName:
Collections.list(context.getAttributeNames())) {
            this.context.log("context attr
"+attributeName+"="+context.getAttribute(attributeName));
        }
        Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
        this.context.log("user:"+user);
        this.context.log("cert:"+cert);
        this.context.log("authType:"+authType);
        this.context.log("getContextPath:"+httpRequest.getContextPath());
        this.context.log("getProtocol:"+httpRequest.getProtocol());
        this.context.log("getRemoteHost:"+httpRequest.getRemoteHost());
        this.context.log("getServerInfo:"+context.getServerInfo());
       
this.context.log("getServletContextName:"+context.getServletContextName());
        this.context.log("getRemoteHost:"+httpRequest.getRequestURI());
        chain.doFilter(request, response);
    }

}


>
> > I have a cgi in the cgi-bin directory, which prints out the
> > environment, and I see both REMOTE_USER and all relevant
> > certificate related information there.
> Is the CGI being executed by Tomcat or is it being executed by httpd?


Executed by Apache httpd. As you can see in the logs, mod_jk does not
pass any of that information through to tomcat, which is exactly my problem.

For reference, here is the code of the CGI (not my code, copied from the
internet):

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "\n";

foreach $key (sort keys(%ENV)) {
  print "$key = $ENV{$key}";
}
print "\n";

and relevant parts of the output:

REMOTE_USER = github|756...@kode-konveyor.eu.auth0.com/
SSL_CLIENT_S_DN = emailAddress=m...@kodekonveyor.com,CN=mag


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

Re: Acessing static content - Tomcat 7 vs. Tomcat9

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 10/7/19 07:22, Martin Knoblauch wrote:
> The mod_jk configuration basically looks like:
>
>  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 

So, you only configure mod_jk if it's NOT available? You have a "!" in
your  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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: user and certificate info is not passed to tomcat

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Magosányi,

On 10/7/19 10:37, Magosányi Árpád wrote:
> I intend to use the user and certificate info in a Filter.
>
> I think I have configured everything to do that, but the
> information does not get passed along. Based on various
> documentations and howtos, SSLVerifyClient require, SSLOptions
> +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL On
> should be enough to pass certificate data, and Require valid-user
> should be enough to pass the authenticated username.
>
> I see the following debug output (also contains the various info
> logged by the filter), which clearly lacks the information needed.
How are you getting the attributes from the request?

> I have a cgi in the cgi-bin directory, which prints out the
> environment, and I see both REMOTE_USER and all relevant
> certificate related information there.
Is the CGI being executed by Tomcat or is it being executed by httpd?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVNYACgkQHPApP6U8
pFj/EBAAxOTOVnx/BoxXCtzkCTk4VH5WUrGi1iwwJODJ6h8d4jEz6Jm241gdNA4Q
m6+x1vFHxjnvgdmVxo7RxrIjx0StLECRGk/dNbiRTKbx6uA4PpR+4DWB1X9HJ+pE
NIkURRM33h/ywcwLEw0I3ar2qGJQuXPBktaYxyjdRQUgZHzKRdcZP9wLRCIkRskN
qMkLGia7v4lIpmBN4EVTISJmFzFRwmgkxruFh8XG/1vecFbxuKr8N8U3fuW8ATnf
9zHWXbrjrqzWDBZGkNgFRNql0s6TS08CWivO6yeSk4BaiIqVvAuozrQzgKXPvDrS
MeYa8X6G1L7XPxTKM563dFza6ohoaWDNZ7ylFYuGGlB3CYCZDPns22sXedfYWjrg
FHbRuz+qdh5/+aWOtRKOniBT5HctOU14LTNBehX6TBwHimicLQ+nLd0wR1YMbO4Q
W8C7XglralnGRzissW9/u+qAanXGW2jEILlLiubgTxNYWvSg4AJ5Dy4xeiUuYva/
WHGBWxTLoGc3gPYOKXbpk9m3d4kRejEiNrHtaYux3zOnjpjvSBjEalavhyN57J28
Wvs7JfCgOlzbEQXj6xaBUpoOxdZiiK3+jSByETXWd8n445xab59uC7RRcjD2g3L7
bVFlrQnxo4dUbM2Wf2+2Wrgm80+5wxgB/+YsfTXoHIZmLTX/tBY=
=ejIn
-END PGP SIGNATURE-

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

user and certificate info is not passed to tomcat

I intend to use the user and certificate info in a Filter.
I think I have configured everything to do that, but the information does not 
get passed along. Based on various documentations and howtos, SSLVerifyClient 
require, SSLOptions +StdEnvVars and SSLOptions +ExportCertData and JkExtractSSL 
On should be enough to pass certificate data, and Require valid-user should be 
enough to pass the authenticated username.
I see the following debug output (also contains the various info logged by the 
filter), which clearly lacks the information needed.
I have a cgi in the cgi-bin directory, which prints out the environment, and I 
see both REMOTE_USER and all relevant certificate related information there.

debug log:
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.554 2019] 
[7885:139750518257408] [debug] map_uri_to_worker_ext::jk_uri_worker_map.c 
(1185): Attempting to map URI '/servlet/servlet' from 1 maps
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.555 2019] 
[7885:139750518257408] [debug] find_match::jk_uri_worker_map.c (980): 
Attempting to map context URI '/servlet*=worker1' source 'JkMount'
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.555 2019] 
[7885:139750518257408] [debug] find_match::jk_uri_worker_map.c (993): Found a 
wildchar match '/servlet*=worker1'
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.556 2019] 
[7885:139750518257408] [debug] jk_handler::mod_jk.c (2823): Into handler 
jakarta-servlet worker=worker1 r->proxyreq=0
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.556 2019] 
[7885:139750518257408] [debug] wc_get_worker_for_name::jk_worker.c (120): found 
a worker worker1
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.557 2019] 
[7885:139750518257408] [debug] wc_get_name_for_type::jk_worker.c (304): Found 
worker type 'ajp13'
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.557 2019] 
[7885:139750518257408] [debug] init_ws_service::mod_jk.c (1196): Service 
protocol=HTTP/1.1 method=GET ssl=true host=(null) addr=94.62.142.229 
name=repository.kodekonveyor.com port=443 auth=(null) user=(null) 
laddr=217.61.105.99 raddr=94.62.142.229 uaddr=94.62.142.229 uri=/servlet/servlet
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.558 2019] 
[7885:139750518257408] [debug] ajp_get_endpoint::jk_ajp_common.c (3356): 
(worker1) acquired connection pool slot=0 after 0 retries
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.559 2019] 
[7885:139750518257408] [debug] ajp_marshal_into_msgb::jk_ajp_common.c (684): 
(worker1) ajp marshaling done
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.559 2019] 
[7885:139750518257408] [debug] ajp_service::jk_ajp_common.c (2591): processing 
worker1 with 2 retries
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.560 2019] 
[7885:139750518257408] [debug] ajp_send_request::jk_ajp_common.c (1722): 
(worker1) no usable connection found, will create a new one.
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.561 2019] 
[7885:139750518257408] [debug] jk_open_socket::jk_connect.c (675): socket 
TCP_NODELAY set to On
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.561 2019] 
[7885:139750518257408] [debug] jk_open_socket::jk_connect.c (799): trying to 
connect socket 24 to ::1:8009
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.565 2019] 
[7885:139750518257408] [debug] jk_open_socket::jk_connect.c (825): socket 24 
[:::51520 -> ::a00:c940:0:0:8009] connected
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.566 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): sending to ajp13 pos=4 len=620 max=8192
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.566 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): 12 34 02 68 02 02 00 08 48 54 54 50 2F 31 2E 31  - 
.4.hHTTP/1.1
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): 001000 00 10 2F 73 65 72 76 6C 65 74 2F 73 65 72 76  - 
.../servlet/serv
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): 00206C 65 74 00 00 0D 39 34 2E 36 32 2E 31 34 32 2E  - 
let...94.62.142.
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): 003032 32 39 00 FF FF 00 1B 72 65 70 6F 73 69 74 6F  - 
229.reposito
Oct  5 19:46:13 s_src@repo apache-jk[7881]: [Sat Oct 05 19:46:13.567 2019] 
[7885:139750518257408] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c 
(1267): 004072 79 2E 6B 6F 64 65 6B 6F 6E 76 65 79 6F 72 2E  - 
ry.kodekonvey

Re: Acessing static content - Tomcat 7 vs. Tomcat9

On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko 
wrote:

> пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch :
> >
> > Hi Konstantin,
> >
> > On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <
> knst.koli...@gmail.com>
> > 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:

  

.
.
.




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 #"Mozil

Re: Acessing static content - Tomcat 7 vs. Tomcat9

On Mon, Oct 7, 2019 at 2:37 PM André Warnier (tomcat)  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:
> >>
> >> 
> >>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
> >> 
> >>
> >> 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

Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-07 Thread Konstantin Kolinko

пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch :
>
> Hi Konstantin,
>
> On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko 
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Acessing static content - Tomcat 7 vs. Tomcat9

Hi Konstantin,

On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko 
wrote:

> пн, 7 окт. 2019 г. в 14:23, Martin Knoblauch :
> >
> > 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:
> >
> > 
> >   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
> > 
> >
> > 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Acessing static content - Tomcat 7 vs. Tomcat9

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:

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

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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-07 Thread Konstantin Kolinko

пн, 7 окт. 2019 г. в 14:23, Martin Knoblauch :
>
> 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:
>
> 
>   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
> 
>
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-07 Thread Mark Thomas

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:
> 
> 
>   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
> 
> 
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Acessing static content - Tomcat 7 vs. Tomcat9