tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)
Date Mon, 28 Oct 2019 13:58:55 GMT
Hash: SHA256


On 10/28/19 09:51, Rémy Maucherat wrote:
> On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz 
> <
> <>> wrote:
> All,
> Note: this was not a vote.
> The consensus seems to be that SSIs should be moved into a
> separate JAR file.
> I've done a *very* short investigation, and I have discovered the 
> following:
> 1. Tomcat builds fine after removing the entire 
> org.apache.catalina.ssi source package, so it's completely
> isolated from the rest of Tomcat (which was entirely expected).
> This suggests that releasing Tomcat without any of the SSI
> components is practical and relatively easy.
> The stock conf/web.xml contains a sample configuration for the SSI 
> servlet. We will have to decide what to do with that. I can think
> of at least two options:
> a. Remove it from the stock conf/web.xml entirely b. Add comments
> to conf/web.xml indicating that the SSI component is a separate
> download
> I think I like #2 better.
> 2. Separating the packaging should be easy. Note that I haven't 
> actually done this:
> i.  Modify files.catalina in build.xml to <exclude> the 
> org.apache.catalina.ssi package ii. Modify the "package" target in
> build.xml to <jarIt jarfile="catalina-ssi.jar" .../> with the
> appropriate classes
> I think this is super simple to do and we should go ahead and do
> this, /now/. For embedded clients who don't care about SSI, this
> gives them a JAR today that they can simply remove from their
> bundled clients to save a little space.
> 3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina 
> APIs. This may complicate fully-extracting the SSI component and 
> making it a standalone product (e.g. cross-container):
> org.apache.catalina.connector.Connector; 
> org.apache.catalina.connector.Request; 
> org.apache.catalina.util.IOTools; 
> org.apache.catalina.util.Strftime; 
> org.apache.catalina.util.URLEncoder; org.apache.coyote.Constants; 
> org.apache.tomcat.util.buf.B2CConverter; 
> org.apache.tomcat.util.buf.UDecoder; 
> org.apache.tomcat.util.http.FastHttpDateFormat; 
> org.apache.tomcat.util.http.RequestUtil; 
> org.apache.tomcat.util.res.StringManager; 
> Some of them are simply for convenience -- e.g. UDecoder, 
> FastHttpDateFormat, etc. Those could easily be replaced with 
> alternatives or re-implementations. I haven't yet looked at how
> much the org.apache.catalina.connector.Connector and 
> org.apache.catalina.connector.Request classes are used. It's
> possible that these could be replaced with the generic versions of
> themselves (e.g. HttpServletRequest and ... I'm not sure what we
> get from the Connector but of course there is no direct replacement
> for that in the public API).
> So I'd like to move-forward with the separation of the SSI
> component into a separate JAR file and then see what can be
> re-factored within SSI itself to divorce it from internal Tomcat
> APIs.
>> Personally I am in favor of a separate JAR, but maintain
>> everything else unchanged. The use of utility classes reduces
>> code duplication. If it becomes cross container then I think SSI
>> should be moved elsewhere. Maybe something like the taglibs
>> subproject. It's a rather significant effort to test and maintain
>> compatibility with everything out there IMO.

Thanks for the feedback. I wouldn't bother replacing the uses of
utility classes unless we were expecting to spin the project off into
a subproject as you say.

If we did that, I would say that anyone wanting to run the
SSIServlet/Filter on another container would be caveat downloader and
that patches were always welcome; the subproject would only promise
compatibility with Tomcat, at least at first.

Who knows? Maybe there is a nascent community out there who wants to
support CGI forever on all servlet containers and they'll get behind
such a project. *shrug*

- -chris

> On 10/7/19 10:46, Christopher Schultz wrote:
>> All,
>> I recently gave a presentation on locking-down Apache Tomcat[1]
>> and I briefly discussed the "sharp edges" present in Tomcat. Some
>> of them are unnecessarily sharp and may be actually unnecessary.
>> I'm going to make a few proposals to remove functions from
>> Tomcat.
>> Proposal: Remove Server-Side Includes
>> Justification:
>> The SSI module is a remote-code execution (RCE) vulnerability as
>> a feature. My sense is that SSI is a little-used feature. A few 
>> years ago, markt[2] asked if anyone was using SSI. The only
>> replies were from other Tomcat devs commenting on what to do with
>> SSI if it's no longer in the main Tomcat distribution; there were
>> no community members who responded saying that SSI was important
>> to them.
>> If the packaging of Tomcat could be tweaked a bit to move the
>> SSI components into a separate JAR file (e.g. move 
>> org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI 
>> components don't rely on any Tomcat specific capabilities or 
>> internals, then the cattalina-ssi.jar file could be used between 
>> Tomcat versions. For example, a user of Tomcat 10 who still
>> needs SSI could get the SSI module from a distribution of Tomcat
>> 8.5.x or 9.x.
>> -chris
>> [1] 
> at
>> [2] 
> <
> <>%3E
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> <> For additional commands,
> e-mail: 
> <>
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message