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) <a...@ice-sa.com>
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: 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
