Hi.
see at end.
On 07.10.2019 16:26, Martin Knoblauch wrote:
On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko <knst.koli...@gmail.com>
wrote:
пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch <kn...@knobisoft.de>:
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:
<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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
