tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Questions about Server Side Includes (SSI) implementation
Date Wed, 01 Sep 2010 21:14:53 GMT
Hash: SHA1


In responding to Marc's recent "Question about SSI" post, I was
wondering a couple of things about the implementation. If anyone who can
provide some illumination, I'd appreciate it.

First, the SSI Filter is implemented as a buffer-then-process filter,
rather than setting up the SSI processor to do pipelined processing. By
that, I mean that the original resource is fetched into a buffer and
then processed start-to-finish, rather than wrapping the response's
output stream and allowing the SSI processor to run /during/ the
generation of content by the original resource.

Was this done for performance reasons? I'd imagine that you might
hold-up content generation of the original resource (that is, the thing
you get by calling chain.doFilter) if the SSI processor stalls doing
something such as executing an external script or including some other
slow resource. On the other hand, the same thread will be doing all the
work, anyway, so the client doesn't get the bytes any faster either way.
The only difference seems to be that the current strategy requires a
potentially large buffer to hold the entire contents of the original
resource, plus a potentially large buffer to hold the post-SSI-processed

I have to imagine that a "parallel" SSI processor configuration could
avoid these potentially large buffers without degrading performance: a

Complications arise, of course, because the content type is not
guaranteed to be set when the first byte of output is sent and because
the response might be reset somewhere along the way. I believe these
issues are not deal-breakers. The SSI filter would also not be able to
set the Content-Length header in this case. I'm not sure if that's a
problem or not.

Second, for configurations where the content type of the original
resource is unimportant, it might be nice to avoid the overhead of a
regular expression pattern match. I'd be happy to provide a simple patch
that avoids the pattern match for patterns like ".*" or "".

These were just some thoughts I had while reading-through the SSI filter
code. Any thoughts?

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message