From apache-cvs-return-2496-apmail-apache-cvs-archive=apache.org@apache.org Thu Aug 17 01:45:43 2000 Return-Path: Delivered-To: apmail-apache-cvs-archive@apache.org Received: (qmail 37863 invoked by uid 500); 17 Aug 2000 01:45:40 -0000 Mailing-List: contact apache-cvs-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-cvs@apache.org Received: (qmail 37843 invoked by uid 500); 17 Aug 2000 01:45:40 -0000 Delivered-To: apmail-apache-2.0-cvs@apache.org X-Authentication-Warning: koj.rkbloom.net: rbb owned process doing -bs Date: Wed, 16 Aug 2000 18:49:47 -0700 (PDT) From: rbb@covalent.net X-Sender: rbb@koj.rkbloom.net To: new-httpd@apache.org cc: apache-2.0-cvs@apache.org Subject: Re: cvs commit: apache-2.0/src/main util_filter.c In-Reply-To: <20000816181516.H17689@lyra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Greg, you are missing the design as I wrote it in my initial e-mail. This was a hack to get things working for chunking. The real patch will take more time. Right now, we are completely broken, and it is impossible to add more filters in the middle of processing. On Wed, 16 Aug 2000, Greg Stein wrote: > As I've said, this simply reverses the problem. Now the situation is that > the LIFO makes it easy to insert *some* types of filters and harder for > others. That is exactly where we were before. It doesn't reverse the problem, it begins to solve it. We should be a stack. > > You wanted an example: a PHP filter decides that it will generate SSI text > and wants to add an SSI filter. With the original add_filter, this will come > afterwards. Not, we are a stack. As you run a filter, when you insert the next one, it gets inserted in the correct place. The PHP filter would have been inserted into the chain in the correct spot. Basically, it would have been: default handler --> PHP --> core_filter becomes: default handler --> PHP --> INCLUDE --> core_filter Thie behaviour is seen because we are a stack. Traversing the stack has the effect of popping the filters. This wasn't coded, it was explained in e-mail. I started the work by making things LIFO. > Another: let's say that we create ap_set_content_type() and let it add > filters based on content type. (Ken seems to not like this one because of > the need for magic MIME types, but let's go with it right now) When > mod_mime calls ap_set_content_type() to set the PHP magic type, we grab that > and add a PHP processor. Next, we look in our config to see that all PHP > output should be run though SSI. So we add an SSI processor. All handled in the design. > For the issue that you're seeing with chunking vs core, the filter type was > designed to deal with this problem. The ordering of the hooks is the basis > for simple ordering. It's the wrong solution. It requires that people make a decision about what kind of filter they have. As filter chains become more complex, we need to start adding more types of filters. We had five to begin with. The first three were content filters, and if they were called in the wrong order, the result was wrong. By using a stack, and inserting the filters as they are required, we solve all of these problems. > This LIFO thing? Now the add_filter is COMPLETELY BACKWARDS for the > insert_filter hook. > > ap_hook_insert_filter(my_hook, ..., AP_HOOK_MIDDLE); > ap_hook_insert_filter(my_other_hook, ...., AP_HOOK_LAST); > > Guess what? my_hook will run first, but the filter will go in *after* the > filter installed by my_other_hook. > > Every filter writer would need to compensate with their insert_filter hook > to reverse the sense. This is just too much. > > The chunking filter can be fixed by using the appropriate filter types. Not > by reversing the insertion. It's not too much, because it isn't an issue. There are two ways to insert a filter. 1) It is inserted from the config file. 2) It is inserted from code. The filters inserted from the config file are in the correct order, because that is how the admin wants them. Filters inserted by code are in the correct order because of when they are inserted. The only time this is a problem at all, is if the core filter isn't inserted first. This problem goes away because we can ensure that it is inserted first. Basically what I am saying is that our first step was wrong. The insert filters hook was wrong, and the FIFO is wrong. Roy has been right all along, because its the only way that works into the future. You add filters it is determined that they are necessary, and because of the way the server works, this just works. Relying on using the insert_filters hook is what is causing all of the problems with filter ordering. Most modules won't know if they should be inserting filters during the insert_filters hook. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------