On Wed, Dec 08, 2004 at 08:22:49AM -0800, Justin Erenkrantz wrote:
> --On Wednesday, December 8, 2004 9:33 AM +0000 Joe Orton
> <jorton@redhat.com> wrote:
>
> >On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
> >> OK, now that you have enabled upgrades for anything other than
> >>OPTIONS, I see the problem. Even though there is a content-length
> >>included in the header, you are saying that the header is being sent
> >>encrypted but the content is not, correct? And the reason for this is
> >>because there is more than one filter stack that needs to be modified?
> >
> >Yes. I think this fixes it, it's a bit of a hack though:
>
> Isn't this the issue Stas keeps bringing up about the filters? See STATUS
> - in particular "the edge connection filter cannot be removed" - I believe
> it's listed as a showstopper currently.
>
> Should we invest time to just fix this the 'right' way?
>
> IIRC, the only real way to fix it is to go back to a doubly-linked list of
> some sort. But, there might be some other clever ways of dealing with this.
Ah very interesting, yes, it's essentially the same issue. It looks
like using a doubly-linked list would solve this case as well.
I can't convince myself it would solve the general case, though: if both
r-> and c->output_filters to happen point to the *same* filter,
modifying the filter chain without knowledge of r-> (which is the
problem) will still break if the filter must be inserted in the ->prev
position?
joe
|