-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All,
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 output. I have to imagine that a "parallel" SSI processor configuration could avoid these potentially large buffers without degrading performance: a win-win. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx+wk0ACgkQ9CaO5/Lv0PDzvACgueG+qr7XLHibw05zmGNaSwH9 OvMAnAnQqCdKCWb1h8l3GPhk1k25RJYm =/k06 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
