You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/08/31 18:48:04 UTC
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: Selecting the Handler [was: Time for 2.2?]
Posted by André Malo <nd...@perlig.de>.
* 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?]
Posted by gr...@remulak.net.
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?]
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, September 3, 2003 3:33 PM -0400 Geoffrey Young
<ge...@modperlcookbook.org> 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?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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?
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman
> <st...@stason.org> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Time for 2.2?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, September 02, 2003 13:40:23 -0700 Stas Bekman
<st...@stason.org> 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?
Posted by Stas Bekman <st...@stason.org>.
> 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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Time for 2.2?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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?
Posted by David Reid <da...@jetnet.co.uk>.
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" <ju...@erenkrantz.com>
To: <de...@httpd.apache.org>
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?
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Re: Time for 2.2?
Posted by Astrid Keßler <ke...@kess-net.de>.
>> 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?
Posted by Cliff Woolley <jw...@virginia.edu>.
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?
Posted by Erik Abele <er...@codefaktor.de>.
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?
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:justin@erenkrantz.com]
> 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