-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cris,
On 10/9/18 11:59, Berneburg, Cris J. - US wrote: > Thanks Chris > > cjb> of TC 8.5.32 on Java 8u181, report output Excel cjb> files > won't load (immediately). An error is cjb> displayed to the user. > [...] cjb> 1. What are the ramifications of disabling the cache? > cjb> IOW, what are the potential side-effects? [...] cjb> 2. Is > there a "better" way to specify the setting? [...] cjb> 3. Is there > a "better" way to solve the problem? [...] > > cs> Long ago, we added something similar to what you cs> are > talking about. Basically, it was a file- cs> upload capability for > images. We waffled about cs> whether to just map the > /uploaded-images/ URL cs> space directly to the disk and have > DefaultServlet cs> serve the bytes or to write our own servlet > [...] > > cs> Re-reading the documentation for <Resources> cs> (specifically, > <PostResources>), it seems that: cs> cs> <PostResources cs> > cachingAllowed="false" cs> base="/base/path/to/image/files/" cs> > className="org.apache.catalina.webresources.DirResourceSet" cs> > webAppMount="/uploaded-images/" /> cs> cs> ... might do the trick, > and it would only disable caching for that portion of the disk. > cs> cs> Perhaps this would be a better solution, because cs> it > only disabled caching for a *portion* of the cs> requests you'll be > handling. > > Yes, exactly! I might experiment with something like that "next". > > cjb> Is it possible to declare only the Excel reports cjb> output > folder as non-cache-able but leave the cjb> (default) context cache > setting as-is so everything cjb> else can be cached in the default > way? That is, cjb> set up the Excel report output folder as a > separate cjb> "resource" with an independent cache setting? cjb> > Right now the Excel folder is embedded in the app cjb> file system: > TC/webapps/app/excel. > > Although I wonder if having the Excel folder embedded in the app > content folder and specifying it in a "PostResources" clause at the > same time would somehow conflict with the default servlet already > serving it. Good thought: the DefaultServlet will use the "resources" as set-up by the context, so "post resources" will fall at the end of the list of things to check. If the "excel documents" folder is actually rooted in the web root of the context, then yes, you'll achieve nothing. On the other hand, you shouldn't put your excel files into a directory rooted in the web root of the context because they will be deleted if you undeploy the web application. (oops) Also, using PreResources is a potential security hazard, as "pre resources" are checked for *classes* before the regular WEB-INF/classes and WEB-INF/lib/*.jar files and so it's easy to inject a rogue class into your application if an attacker can arrange for that kind of things to happen. In your use-case, you are building the document internally (so the user isn't uploading files), but it's worth pointing-out that in an upload-situation, use of "pre resources" to serve uploaded files can get you compromised in a hurry. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+CeUACgkQHPApP6U8 pFi8aA//YhQ5C+aevSfPoYYyooN+M2Kw9PWWhVDkVJs2esOPkSrwNFG7TCHnLn52 cBcgqOSKX6nvlanwyk+3aFlk2OdRrZL2IRqszXuugQr2fZpC18qvHru9xi6JpCDJ kFr+qhp0xQ6WNlG/+DnaOXLg8/x3m0N+iihjNOgxbtvwcag1AksADpRpYnscnen1 bimNvvBatyiSyBUZ3m5FQjF3E3iuB63MXygT3emwWsOrGya7PafoeG9Wbr+nD6dc z4nEp6UOqVk0FSyYgaFDoUYAZIa7PNVaHWs+SCFwm749pSjvg9vgnMBoYsBPN0XH t0jHvSMu5ye5H+sACxgjaY0S/2l78ps1dg9ULlHDJM3zIdqM8TQIMObmUUAk7tUJ LDXf0KJEZa8sLYm9o6PEaUHReLrM8I2WylwW6puTSTvRDDjkcoKUj4Nc8xEsDppb yu79aHG5EiiCJfJ6rdo5OdGRKKHaFa27upxdy4yzr9whzCLG8vqpPUmKGiKHPw9O 9lQ6RVhaGO3NYromew614BaujgJbkIHNYtLNkIzVvAK5EuyiRewLSrIKUaC+R5JO wY41Z37ai6bN4mR2chiqFIyPX871OUYFUWMzIbmKZB8xXugKhhdl3syq4vp+uiIr kgStOuxlaUeMUXWW6q5Tvdq5rUc7mzkkVsixyeqHKqw6zjhtfY0= =TguN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
