[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [PATCH] AddOutputFilterByType issues.

From: Ryan Bloom <rbb_at_covalent.net>
Date: 2002-04-02 00:05:04 CEST

> I've been partly out of it lately, but I think there is a problem
> with AddOutputFilterByType. Since ap_set_content_type() can
> be called arbitrarily many times, it will try to add each filter
> as directed by AddOutputFilterByType on each call. For certain
> filters, that isn't a terrifically good idea - such as mod_deflate.
> For others (say mod_include), this is okay.
>
> We can't compress a file twice (and is causing problems with
> Subversion right now), but that's what we are doing now -
> mod_deflate is in the chain twice. mod_mime calls
> ap_set_content_type twice in its normal execution (I dunno why,
> but that's sucky).
>
> I'm using the following patch to minimize how often
> ap_add_output_filters_by_type is called. This fixes the symptom,
> but perhaps we should think of a better solution? Perhaps only
> allow AP_FTYPE_RESOURCE filters to be added multiple times, and
> AP_FTYPE_CONTENT_SET or higher can only be added once?
>
> Thoughts? -- justin

I have two conflicting thoughts, so I'll put them both out there for
discussion.

1) I agree (mostly) RESOURCE filters are really the only ones that make
sense to add multiple times. We should ensure that no other filters are
added more than once.

2) It is up to the filter to protect against this case. That can be
done by walking the filter chain to ensure that the same filter isn't in
the list already. Of course, walking the chain could be slow, depending
on how many filters there are.

Regardless, this patch is all good-ness, and should be committed ASAP.

Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 2 00:06:43 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.