Neil, > I think it's a bad idea to design a solution based on the file type. A > webapp can contain all kinds of files.
Why is that in this instance when the focus is on deploying to these specific folders as defined by Tomcat? Taken from the Tomcat documentation... - WEB-INF/classes/ - This directory contains any Java class files (and associated resources) required for your application, including both servlet and non-servlet classes, that are not combined into JAR files. If your classes are organized into Java packages, you must reflect this in the directory hierarchy under WEB-INF/classes/. For example, a Java class named com.mycompany.mypackage.MyServlet would need to be stored in a file named WEB-INF/classes/com/mycompany/mypackage/MyServlet.class. - WEB-INF/lib/ - This directory contains JAR files that contain Java class files (and associated resources) required for your application, such as third party class libraries or JDBC drivers. So, while there may be additional resources I would have thought that it would be safe to assume that .war, .jar & .class suffixes contained Java classes / resources, raw (.class) or zipped (.war, .jar). Regarding checking the validity of a .war / .jar, there looks to be a good way of checking validity in the standard java.util.zip.ZipFile class which opens a file for reading and will return an exception if there is a ZIP format error. Of course, if we might expect someone to deploy a file with one of the "reserved" suffixes that does not conform then the file will never pass validation and so either would need to give up after a period of time and let the reload continue or raise an exception reporting that the file did not contain the expected type (i.e. a recognised zip file structure). Given that Tomcat is pretty well defined about what those two folders are for, I would have thought that we should be able to expect that users would confirm to only use the recognised suffixes for the purpose they are intended for and the benefits of a safe deployment outway the outside risk of users abusing the meaning of the suffixes. Of course, only those files with those two suffixes (jar / war) would have the additional validation applied, the rest would simply be subject to the timeout for non activity having expired. John Neil,> I think it's a bad idea to design a solution based on the file type. A webapp can contain all kinds of files.Why is that in this instance when the focus is on deploying to these specific folders as defined by Tomcat? WEB-INF/classes/ - This directory contains any Java class files (and associated resources) required for your application, including both servlet and non-servlet classes, that are not combined into JAR files. If your classes are organized into Java packages, you must reflect this in the directory hierarchy under WEB-INF/classes/. For example, a Java class named com.mycompany.mypackage.MyServlet would need to be stored in a file named WEB-INF/classes/com/mycompany/mypackage/MyServlet.class.WEB-INF/lib/ - This directory contains JAR files that contain Java class files (and associated resources) required for your application, such as third party class libraries or JDBC drivers.So, while there may be additional resources I would have thought that it would be safe to assume that .war, .jar & .class suffixes contained Java classes / resourses, raw (.class) or zipped (.war, .jar).Regarding checking the validity of a .war / .jar, there looks to be a good way of checking validity in the standard java.util.zip.ZipFile class which opens a file for reading and will return an exception if there is a ZIP format error.Of course, if we might expect someone to deploy a file with one of the "reserved" suffixes that does not conform then the file will never pass validation and so either would need to give up after a period of time and let the reload continue or raise an exception reporting that the file did not contain the expected type (i.e. a recognised zip file structure). Given that Tomcat is pretty well defined about what those two folders are for, I would have thought that we should be able to expect that users would confirm to only use the recognised suffixes for the purpose they are intended for and the benefits of a safe deployment outway the outside risk of users abusing the meaning of the suffixes.Of course, only those files with those two suffixes (jar / war) would have the additional validation applied, the rest would simply be subject to the timeout for non activity having expired.John -------- Original message -------- From: Neil Aggarwal <n...@propfinancing.com> Date: 20/02/2022 18:29 (GMT+00:00) To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: is too quick to respond I think it's a bad idea to design a solution based on the file type. A webapp can contain all kinds of files. On Sun, Feb 20, 2022, 12:16 PM Simon Matter <simon.mat...@invoca.ch> wrote: > > I may be wrong but I thought .war files are zip files. Wouldn't it be > possible to just wait until the file has a consistent content and then > extract it? > -------- Original message --------From: Neil Aggarwal <n...@propfinancing.com> Date: 20/02/2022 18:29 (GMT+00:00) To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: is too quick to respond I think it's a bad idea to design a solution based on the file type. Awebapp can contain all kinds of files.On Sun, Feb 20, 2022, 12:16 PM Simon Matter <simon.mat...@invoca.ch> wrote:>> I may be wrong but I thought .war files are zip files. Wouldn't it be> possible to just wait until the file has a consistent content and then> extract it?> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
