Michael,
On 6/7/24 10:18, Michael Osipov wrote:
On 2024/06/07 12:54:44 Christopher Schultz wrote:
Michael,
On 6/7/24 08:01, Michael Osipov wrote:
On 2024/06/07 08:05:34 Mark Thomas wrote:
On 06/06/2024 16:30, Christopher Schultz wrote:
All,
Resurrecting this thread from 2019.
I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.
Are there any objections?
None here.
Do we want to go further and consider removing it entirely for Tomcat 12
onwards. Maybe a question for the users list?
I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents
dependening whether it is QA or prod. I didn't want to generate multiple sets
of documents (reduce complexity). Now some lines of SSI display a proper QA
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is
almost impossible.
It's entirely possible to separate SSI into a different project. I
didn't do it because it uses helper-classes in Tomcat for certain things.
But if SSI is desirable, it can be packaged separately at the cost of
some additional support classes/methods being copied outside of Tomcat.
I don't want to support it anymore, but it should be easy *for someone
else* to extract and bundle separately :)
What is the pain having it off by default, but have the necessary classes still
provided in the JARs? They do not require any maintenance. They just work,
don't they?
They do "just work" but it's basically RCE as a feature which is just
bad. The idea that Tomcat should be a Java-based replacement for httpd
with all its features is never something I liked. CGI, SSI,
RewriteValve, etc. are all vestiges of that idea. If you want CGI and
SSI and rewrite, then use the right tool for that job which is a
reverse-proxying web server. Let Tomcat deal with all the Java-related
stuff and shed all that extra cruft.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org