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 - 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
