Re: Selecting the Handler [was: Time for 2.2?]
William A. Rowe, Jr. wrote: I recall some discussion that the walk-through-every-registered-hook-provider to resolve the handler is a pretty slowish/crufty way to handle that part of the request processing. Especially if everyone sets up the handler up-front in the various request preprocessing phases The problem with leaving it to be 'snatched' in the handler is that nobody knows this will happen when the evaluate a 'preprocessed' req_rec. And, it's slow. ++1 in concept. This creates a performance problem that is unlikely to show up in profilers because the extra cycles/i-cache misses are spread among all the handlers. Not sure how to implement it, but it shouldn't be too hard. Greg
Re: Selecting the Handler [was: Time for 2.2?]
* William A. Rowe, Jr. wrote: > So perhaps it's time to deprecate req_rec::handler in favor of a handler_fn > or some other sort of hash, and make the handler phase 1:1 on the request? That sounds like a very good idea to me. But how would you handle things like "handler1 returns DECLINED and handler2 takes over"? nd
Re: Selecting the Handler [was: Time for 2.2?]
I recall some discussion that the walk-through-every-registered-hook-provider to resolve the handler is a pretty slowish/crufty way to handle that part of the request processing. Especially if everyone sets up the handler up-front in the various request preprocessing phases. The problem with leaving it to be 'snatched' in the handler is that nobody knows this will happen when the evaluate a 'preprocessed' req_rec. And, it's slow. So perhaps it's time to deprecate req_rec::handler in favor of a handler_fn or some other sort of hash, and make the handler phase 1:1 on the request? Bill
Re: filter_init was Re: Time for 2.2?
I, for one, would appreciate more details to better understand the needs. I'm not clear where the mime type fits in. well, say you have an output filter that should only operate on a particular mime-type - like the mod_blanks that keeps coming up here. ideally, the filter should be able to do at least few things: remove (or weaken) the ETag, alter Last-Modified, and do it's filtering. the first two need to happen in filter_init because of default_handler and its logic, but with an unknown content-type the filter is in a quandry - if it calls update_mtime but doesn't run (not html) then it affected the cache status unnecessarily, but if it doesn't call update_mtime() then default_handler might return 304 before the filter can insert itself. the etag issue is similar. this is a real life scenario, btw - something I've been working on :) > Is it that > filter_init isn't called for AddOutputFilterByType filters? I hadn't tried that, it would be interesting to see what ends up happening on AddOutputFilterByType filters when the content is a cgi script and content-type differs from DefaultType. could be easily solved by moving ap_meets_conditions logic to it's own filter, which was the original proposal before filter_init won. as I use Hmm. Would that filter be a CONTENT_SET (or PROTOCOL?) filter? If it thinks the response shouldn't be sent, would it throw away the response (so far) and send down the 'right' bits for a 304? Might work, but that seems rather late to make that decision. -- justin well, I was thinking something along the lines of the C-L filter (whatever that is :) basically, if everybody calls update_mtime but leaves set_last_modified for the filter then each handler and filter gets the chance to add its criterion to Last-Modified without worrying about another module sending a premature 304. no_local_copy could be used when one participant knows what it is doing negates all caching. granted, yes it seems late in the process if you're taking the time to compress a flat file only to send a 304 after, but as output filters get more complex, the non-content altering deflate model becomes the only circumstance I can think of where you actually desire the current behavior. --Geoff
filter_init was Re: Time for 2.2?
--On Wednesday, September 3, 2003 3:33 PM -0400 Geoffrey Young <[EMAIL PROTECTED]> wrote: other issues that I have found center around 304s. I can go into more detail here if people like, but the overall idea is that filter_init is sometimes too early to make intelligent decisions, especially when you want to operate only on a certain mime type. just about all of these, though, I, for one, would appreciate more details to better understand the needs. I'm not clear where the mime type fits in. Is it that filter_init isn't called for AddOutputFilterByType filters? could be easily solved by moving ap_meets_conditions logic to it's own filter, which was the original proposal before filter_init won. as I use Hmm. Would that filter be a CONTENT_SET (or PROTOCOL?) filter? If it thinks the response shouldn't be sent, would it throw away the response (so far) and send down the 'right' bits for a 304? Might work, but that seems rather late to make that decision. -- justin
Re: Time for 2.2?
Another problem with filters design is the init_filter function. I forgot the details, I hope Geoff can give them, as he has messed with it. the issue is primarily with default_handler. for instance, there is currently a bug in the interaction between mod_include and default_handler: if default_handler decides a 304 is in order, it sets an ETag header, even if mod_include (rightly) stripped it in the original 200 response. I've posted a patch http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105120818606501&w=2 and a bit more explanation, but the patch is really a hack - there probably needs to be an ETag generation API so that modules can work together in generating the ETag. other issues that I have found center around 304s. I can go into more detail here if people like, but the overall idea is that filter_init is sometimes too early to make intelligent decisions, especially when you want to operate only on a certain mime type. just about all of these, though, could be easily solved by moving ap_meets_conditions logic to it's own filter, which was the original proposal before filter_init won. as I use output filters more, I'm finding that I really don't want default_handler (or any content handler, for that matter) making conditional GET decisions when output filters are involved, even if it means that the server is slower when only serving compressed, flat files. HTH --Geoff
Re: Time for 2.2?
Justin Erenkrantz wrote: --On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman <[EMAIL PROTECTED]> wrote: Before 2.2 is even considered shouldn't all the outstanding design issues be fixed first? e.g. there are at least several design problems with filters. Aren't you just talking about the fact that it's not a doubly-linked list? This leads to the oddness when removing the first connection filter, right? I wouldn't call that a design flaw. It's a revert of a prior commit that removed DLLs. -- justin I remember you told me that rbb removed it because it didn't quite work, no? Another problem with filters design is the init_filter function. I forgot the details, I hope Geoff can give them, as he has messed with it. Yet another issue was with the filters in sub-requests. I don't remember if it was completely resolved (copying the stack...) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Time for 2.2?
--On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman <[EMAIL PROTECTED]> wrote: Before 2.2 is even considered shouldn't all the outstanding design issues be fixed first? e.g. there are at least several design problems with filters. Aren't you just talking about the fact that it's not a doubly-linked list? This leads to the oddness when removing the first connection filter, right? I wouldn't call that a design flaw. It's a revert of a prior commit that removed DLLs. -- justin
Re: Time for 2.2?
Well, as Cliff pointed out, we would start issuing releases under the 2.1 moniker. Then, when we're all feeling warm and fuzzy about 2.1, we'll call it 2.2, and open APACHE_2_2_BRANCH. HEAD would then become 2.3. APACHE_2_0_BRANCH would still be open. Before 2.2 is even considered shouldn't all the outstanding design issues be fixed first? e.g. there are at least several design problems with filters. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Time for 2.2?
David Reid wrote: > Seems like a plan. > > Do we then migrate from 2.0 to 2.2 for our *stable* tree? Some extra > clarification might be nice... Well, as Cliff pointed out, we would start issuing releases under the 2.1 moniker. Then, when we're all feeling warm and fuzzy about 2.1, we'll call it 2.2, and open APACHE_2_2_BRANCH. HEAD would then become 2.3. APACHE_2_0_BRANCH would still be open. Ideally, we'd recommend that 2.0 users migrate to 2.2 because it's 'stable' and has more feature, blah, blah, blah. And, to re-iterate, I forsee this process taking a few months. -- justin
Re: Time for 2.2?
>> Just to prevent any misunderstandings: are we talking about a 2.2 >> *alpha* or *beta* release here, or what will it be called? If it's in >> any way marked as *unstable*, then a clear +1 from my side. The recent >> changes are definitely worth to get tested in the wild, IMHO. > The alphas/betas will be called 2.1.x. 2.2.0 wouldn't be released until > 2.1.x releases were declared stable. So, basically, yes. +1 from me Kess
Re: Time for 2.2?
Seems like a plan. Do we then migrate from 2.0 to 2.2 for our *stable* tree? Some extra clarification might be nice... david - Original Message - From: "Justin Erenkrantz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 31, 2003 5:48 PM Subject: Time for 2.2? > Looking at nd's recent mod_rewrite and mod_include changes including the aaa > rewrite (and some other changes and new modules that just weren't backported), > I'm starting to think this is about the 'right feel' for a 2.2 release. 2.1 > has essentially been open since last September. > > So, I think we should start producing 2.1 unstable releases with a goal of > producing a stable 2.2 release in a few months. > > The one issue I'd like resolved before starting a 2.1 release cycle is > figuring out if we can axe ap_*_client_block (as this is a major API change). > I think Sander's mentioned something about changing how authorization hooks > are called, but I don't know if he's prepared to do it 'soon.' > > Thoughts? -- justin >
Re: Time for 2.2?
On Sun, 31 Aug 2003, Erik Abele wrote: > Just to prevent any misunderstandings: are we talking about a 2.2 > *alpha* or *beta* release here, or what will it be called? If it's in > any way marked as *unstable*, then a clear +1 from my side. The recent > changes are definitely worth to get tested in the wild, IMHO. The alphas/betas will be called 2.1.x. 2.2.0 wouldn't be released until 2.1.x releases were declared stable. So, basically, yes.
Re: Time for 2.2?
On 31/08/2003, at 09:21, Sander Striker wrote: Indeed. Since 2.2 is already about the AAA rewrite it would be nice to include the final step on that subject aswell. Thoughts? -- justin What about: I'll do a 2.1 release at the same time as 2.0.48? Just to prevent any misunderstandings: are we talking about a 2.2 *alpha* or *beta* release here, or what will it be called? If it's in any way marked as *unstable*, then a clear +1 from my side. The recent changes are definitely worth to get tested in the wild, IMHO. A X.Y release where X and especially Y > 0 is often perceived as a major bug fix release in my experience (fwiw) and I'd like to ensure that nobody is expecting too much... hmm, but perhaps I'm too fussy about this? Cheers, Erik Sander
RE: Time for 2.2?
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 31, 2003 6:48 PM > Looking at nd's recent mod_rewrite and mod_include changes including the aaa > rewrite (and some other changes and new modules that just weren't backported), > I'm starting to think this is about the 'right feel' for a 2.2 release. 2.1 > has essentially been open since last September. > > So, I think we should start producing 2.1 unstable releases with a goal of > producing a stable 2.2 release in a few months. > > The one issue I'd like resolved before starting a 2.1 release cycle is > figuring out if we can axe ap_*_client_block (as this is a major API change). > I think Sander's mentioned something about changing how authorization hooks > are called, but I don't know if he's prepared to do it 'soon.' Indeed. Since 2.2 is already about the AAA rewrite it would be nice to include the final step on that subject aswell. > Thoughts? -- justin What about: I'll do a 2.1 release at the same time as 2.0.48? Sander
Re: Time for 2.2?
On Sun, 31 Aug 2003, Justin Erenkrantz wrote: > Looking at nd's recent mod_rewrite and mod_include changes including the > aaa rewrite (and some other changes and new modules that just weren't > backported), I'm starting to think this is about the 'right feel' for a > 2.2 release. 2.1 has essentially been open since last September. > > So, I think we should start producing 2.1 unstable releases with a goal > of producing a stable 2.2 release in a few months. +1... have been thinking the same myself. Huge module rewrites are the perfect incentive to push ahead toward 2.2. --Cliff
Time for 2.2?
Looking at nd's recent mod_rewrite and mod_include changes including the aaa rewrite (and some other changes and new modules that just weren't backported), I'm starting to think this is about the 'right feel' for a 2.2 release. 2.1 has essentially been open since last September. So, I think we should start producing 2.1 unstable releases with a goal of producing a stable 2.2 release in a few months. The one issue I'd like resolved before starting a 2.1 release cycle is figuring out if we can axe ap_*_client_block (as this is a major API change). I think Sander's mentioned something about changing how authorization hooks are called, but I don't know if he's prepared to do it 'soon.' Thoughts? -- justin