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>

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

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

Reply via email to