On 01/09/2010 22:14, Christopher Schultz wrote: > Was this done for performance reasons? Not to my knowledge.
> I have to imagine that a "parallel" SSI processor configuration could > avoid these potentially large buffers without degrading performance: a > win-win. +1 > 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. No different to a normal servlet. Once the response has been committed, headers can't change. > 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. Shouldn't be. Chunked encoding will handle that. > 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 "". I use an explicit pattern of "" to skip the match. > These were just some thoughts I had while reading-through the SSI filter > code. Any thoughts? Patches welcome :) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
