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

Reply via email to