On Wed, Dec 08, 2004 at 08:22:49AM -0800, Justin Erenkrantz wrote: > --On Wednesday, December 8, 2004 9:33 AM +0000 Joe Orton > <[EMAIL PROTECTED]> 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
