Re: Acessing static content - Tomcat 7 vs. Tomcat9
On Tue, Oct 8, 2019 at 9:02 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Martin, > > > > Sorry, I actually didn't notice the "LoadModule" in there. > > It's strange to see a LoadModule and the other configuration all > together for me. Typically, I load modules in one section and > configure then in another. It's all rather subjective, of course. > > > > Yeah, that one is a bit different. Two reasons. First, the configurations has been used for years and the guy doing it just preferred it that way. Second, as "mod_jk" is an "external" module to "httpd", it actually makes sense to check it that way. We know we want it. And if it cannot be loaded "httpd" should not come up at all. And now back to my redirect issue :-) Cheers 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 10/7/19 11:45, Martin Knoblauch wrote: > 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 :-) Sorry, I actually didn't notice the "LoadModule" in there. It's strange to see a LoadModule and the other configuration all together for me. Typically, I load modules in one section and configure then in another. It's all rather subjective, of course. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2c3ScACgkQHPApP6U8 pFg8+xAAsuyGXzxffPyIOZI/f0gjSm8JkNmE+SvKV2F5XuL5FeZlmxZq2Y2H7ibb DJLIafutH+4ZzSnrQD5nMwbqLpYLOKUYV4Uc0aw+MH/hnbu2IFsR4f8wuhhck6xy QDnHPM2Av2jjhkU1abd1z/qYFeRlhtMPp91GZMLr45lT0D9Plyo2awUNGqQz41Kk mLKmiIuUayzrZSR2AX8FZMMM8jR3scgw0t43EJOuo+u2rwGjshwDhWs/tZUrAWU3 EGZWf/MNwGYg7Ku23uxZ3HgzQRyTOUi+kG9CBfJMGGSWoFQWUXe3oJ9wgNMauK/E i+yex/l0r840M+C8voxlL2L6ohSr64zIvmVesTyK2HT8xvna+qhxp5V/dlUBtsiv mbp3lrGga9HxFbQf1cnQxFMP0/KEhdmlS9LZt4GI+KW6iOufdOPpC/egSnXx9yHD q8C02BLR83inY/da1pBQvPWSqDLV7Lh9i2rjcBL1gZiAJRHXhRHN/TJj85EvrK76 9RsybJil3n4Yt8RzBtNnKDMtm1kBNeUFpdYx6gO0ElYftK4BWHZ7O/qw6NRzuMNX A/BrcJsbg2osEpjLXsKhbtUBWxGNFgmNVDQmLx9msE28slEgN4OjLFV/tBvCQopo vUZudKrsnVS3yNr2v/MhsgmEWrNby2gH9jLOmm7n7cU1ERyH/z4= =uXJX -END PGP SIGNATURE- - 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 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) 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 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
Re: Acessing static content - Tomcat 7 vs. Tomcat9
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) 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
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;
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: 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: 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
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
пн, 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
пн, 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
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
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 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. Kind regards Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
