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-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)