Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 35562 invoked by uid 500); 5 Jun 2001 21:45:12 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 35535 invoked from network); 5 Jun 2001 21:45:10 -0000 Message-ID: <3B1D52DD.6A006E14@algroup.co.uk> Date: Tue, 05 Jun 2001 22:45:01 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Cc: httpd-2.0-cvs@apache.org Subject: Re: cvs commit: httpd-2.0/modules/http http_protocol.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N rbb@covalent.net wrote: > > On Tue, 5 Jun 2001, Graham Leggett wrote: > > > sterling wrote: > > > > > reset_filters always removed all filters (including TLS). This is a > > > problem in general - I think the only reason the filters are all removed > > > on error is to prevent infinite recursion (in the case where the error > > > came from one of the filters). Optimally, if I add a filter, it should > > > get called even on error - > > > > In theory though on error we should only be removing the request > > filters, not the connection filters. The TLS filter would be a > > connection filter, and would then not be affected... right? > > That's not the way the code works right now. Right now, we remove all > filters. There is no really good way around this. Basically, we are > trying to get to a position that we know is good, so that we can return as > much information as possible. Return to whom? Clearly if you remove the TLS filter, it won't be the user! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff