You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@raleigh.ibm.com> on 2001/01/06 01:14:27 UTC
index.html not served w/mod_autoindex active
Lately in 2.0, if you turn on autoindexes, and the request URL refers to
a directory containing index.html, Apache serves an autoindex directory
listing instead of the index.html contents. The debugger shows that
mod_dir's handler never gets a shot at it - mod_autoindex's handler runs
first and happily does its thing. These handlers must have been invoked
in the opposite order when it was working.
It's easy to fix with a hack if the modules are statically linked: go
into modules.c, (ignore the warning about not hand editing it,) go down
to the ap_prelinked_modules structure and move the &dir_module line down
to after the &autoindex_module line, then make, restart the server, and
voila! - index.html's are back.
Unfortunately, not only is it very complicated to re-order this list at
configure time, it is also pointless because it doesn't deal with the
situation when one or both of these modules is a DSO. If we had
something like the hook sorting mechanism for handlers, it would be
easily solved.
Thoughts?
Greg
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Ames wrote:
>
> just tested this...it's fixed. Thanks much, Ben!
My pleasure.
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
Re: index.html not served w/mod_autoindex active
Posted by Greg Ames <gr...@raleigh.ibm.com>.
just tested this...it's fixed. Thanks much, Ben!
Greg
Greg Ames wrote:
> Lately in 2.0, if you turn on autoindexes, and the request URL refers to
> a directory containing index.html, Apache serves an autoindex directory
> listing instead of the index.html contents.
Re: index.html not served w/mod_autoindex active
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jan 06, 2001 at 03:24:37PM -0800, rbb@covalent.net wrote:
>...
> It bothers me that either in the middle of the 2.0 beta series, or during
> the 2.0 series itself, we are all of a sudden going to change how handlers
> are registered.
If somebody has the time and inclination do get something done The Right
Way, then I think it should be done. Trading off Rightness for a schedule
just never sits well with me.
[ conversely: if nobody is inclined to revamp something to do it better,
then it just gets shipped as-is. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
> Personally, I find calling N handler functions more expensive than the old
> mechanism.
It is. I'm still prepared to bet you can't measure it, though.
> However, I do like the new registration-based system. I'd take it
> a bit further and have an explicit handler system in Apache where the
> modules register a handler->func mapping in an Apache-internal hash table.
> At runtime, we just go BAM! and yank out the func and call it.
Doesn't handle wildcards. Of course, you could make them a fallback.
> Of course, that doesn't have the neato ordering that the hooks has
> introduced.
Precisely!!!
> A possible optimization goes back to something Ryan did with some early hook
> patches: per-request hook registration. Each module would register their
> handler on the *request*, if they think they might apply to that request.
> Apache would then run them, in order. The typical list would be *much*
> shorter.
I can't believe you're even contemplating that! There's _no way_ that
can be anything less than horribly expensive - a topological sort on
every request? Wash your mouth out with soap!
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
Re: index.html not served w/mod_autoindex active
Posted by Doug MacEachern <do...@covalent.net>.
right, r->handler is normally set in the mime-type phase and not used
by anything after the handler is dispatched. so why not re-use that field
and set r->handler to the handler you are now passing with the new
prototype. and then we can have the old prototype back.
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> On Sun, Jan 07, 2001 at 02:03:56PM -0800, Jon Travis wrote:
> > On Sun, Jan 07, 2001 at 02:00:53PM -0800, Greg Stein wrote:
> >...
> > > I'm lost on this thread. Step back, and re-present it with your thoughts.
> > > What exactly is the issue with the current organization?
> >...
> > My beef is not that we are using hook based instead of running through
> > stuff defined in the module_rec. I'm only concerned with the fact that
> > we have changed the prototype for the content generation functions.
>
> Ah, yes. That does seem a bit gratuitous.
>
> Ben? Any particular reason for passing that? It isn't like it is
> disappearing from "r" anytime soon.
It isn't in r. To quote...
if (r->handler) {
handler = r->handler;
handler_len = strlen(handler);
}
else {
handler = r->content_type ? r->content_type :
ap_default_type(r);
if ((p = ap_strchr_c(handler, ';')) != NULL) {
/* MIME type arguments */
while (p > handler && p[-1] == ' ')
--p; /* strip trailing spaces */
handler_len = p - handler;
}
else {
handler_len = strlen(handler);
}
}
what we pass is handler, not r->handler. OTOH, I have introduced a bug,
I need to copy it and do the trailing space and semicolon stripping.
Ooops!
> And I'm not so sure that "well,
> everybody is going to have to deref it" is quite valid... as Jon says, we
> *do* call a bazillion funcs with just "r" as the parameter, knowing that
> everything needed is in there.
That ain't my argument. :-)
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
Re: index.html not served w/mod_autoindex active
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 07, 2001 at 02:03:56PM -0800, Jon Travis wrote:
> On Sun, Jan 07, 2001 at 02:00:53PM -0800, Greg Stein wrote:
>...
> > I'm lost on this thread. Step back, and re-present it with your thoughts.
> > What exactly is the issue with the current organization?
>...
> My beef is not that we are using hook based instead of running through
> stuff defined in the module_rec. I'm only concerned with the fact that
> we have changed the prototype for the content generation functions.
Ah, yes. That does seem a bit gratuitous.
Ben? Any particular reason for passing that? It isn't like it is
disappearing from "r" anytime soon. And I'm not so sure that "well,
everybody is going to have to deref it" is quite valid... as Jon says, we
*do* call a bazillion funcs with just "r" as the parameter, knowing that
everything needed is in there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: index.html not served w/mod_autoindex active
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Jan 07, 2001 at 02:00:53PM -0800, Greg Stein wrote:
> On Sun, Jan 07, 2001 at 01:44:14PM -0800, Jon Travis wrote:
> > On Sun, Jan 07, 2001 at 09:39:29PM +0000, Ben Laurie wrote:
> >...
> > > I could by that. Makes it less clear how you get from A to B, but I'm
> > > not that fussed. OTOH, request_rec _already_ has handler:
> > >
> > > /** The handler string that we use to call a handler function */
> > > const char *handler; /* What we *really* dispatch on */
> > >
> > > the comments are a complete lie, of course. I don't know whether we can
> > > fix them without breaking stuff.
> >
> > I don't know that adding the overhead of an extra function call is that
> > major of a deal here. Some may disagree. It is certainly more clear then
> > adding more stuff to the request_rec, IMO.
>
> Slow down, Tex. Nobody has added anything to request_rec. The "handler"
> field has always been in there.
>
> I'm lost on this thread. Step back, and re-present it with your thoughts.
> What exactly is the issue with the current organization?
>
> Personally, I find calling N handler functions more expensive than the old
> mechanism. However, I do like the new registration-based system. I'd take it
> a bit further and have an explicit handler system in Apache where the
> modules register a handler->func mapping in an Apache-internal hash table.
> At runtime, we just go BAM! and yank out the func and call it.
>
> Of course, that doesn't have the neato ordering that the hooks has
> introduced.
>
> A possible optimization goes back to something Ryan did with some early hook
> patches: per-request hook registration. Each module would register their
> handler on the *request*, if they think they might apply to that request.
> Apache would then run them, in order. The typical list would be *much*
> shorter.
My beef is not that we are using hook based instead of running through
stuff defined in the module_rec. I'm only concerned with the fact that
we have changed the prototype for the content generation functions.
-- Jon
Re: index.html not served w/mod_autoindex active
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jan 07, 2001 at 01:44:14PM -0800, Jon Travis wrote:
> On Sun, Jan 07, 2001 at 09:39:29PM +0000, Ben Laurie wrote:
>...
> > I could by that. Makes it less clear how you get from A to B, but I'm
> > not that fussed. OTOH, request_rec _already_ has handler:
> >
> > /** The handler string that we use to call a handler function */
> > const char *handler; /* What we *really* dispatch on */
> >
> > the comments are a complete lie, of course. I don't know whether we can
> > fix them without breaking stuff.
>
> I don't know that adding the overhead of an extra function call is that
> major of a deal here. Some may disagree. It is certainly more clear then
> adding more stuff to the request_rec, IMO.
Slow down, Tex. Nobody has added anything to request_rec. The "handler"
field has always been in there.
I'm lost on this thread. Step back, and re-present it with your thoughts.
What exactly is the issue with the current organization?
Personally, I find calling N handler functions more expensive than the old
mechanism. However, I do like the new registration-based system. I'd take it
a bit further and have an explicit handler system in Apache where the
modules register a handler->func mapping in an Apache-internal hash table.
At runtime, we just go BAM! and yank out the func and call it.
Of course, that doesn't have the neato ordering that the hooks has
introduced.
A possible optimization goes back to something Ryan did with some early hook
patches: per-request hook registration. Each module would register their
handler on the *request*, if they think they might apply to that request.
Apache would then run them, in order. The typical list would be *much*
shorter.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: index.html not served w/mod_autoindex active
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Jan 07, 2001 at 09:54:03PM +0000, Ben Laurie wrote:
> Jon Travis wrote:
> > > > You are doing it
> > > > everytime in ap_invoke_handler anyway, so the only inneficiency is that
> > > > introduced is an extra function call.
> > >
> > > What?
> >
> > You said that "Because then it has to be done every time, which is inneficient"
> > referring to the work that is done in ap_invoke_handler.
>
> No, I meant if you do it in the hook, you do it in every module.
Ahh. True. Since we've moved all this checking of handlernames into
the handler as well, we could just combine the two (comparing handler
names, and snagging the correct handler information from the request_rec)
into a unified function. I don't see this as a particularly convincing
argument, though.
> > > > And if you wanted, you could add
> > > > another field to the request_rec, and just manipulate that within
> > > > your ap_invoke_handler routine, or whatever. That would save the
> > > > overhead of the function call.
> > >
> > > I could by that. Makes it less clear how you get from A to B, but I'm
> > > not that fussed. OTOH, request_rec _already_ has handler:
> > >
> > > /** The handler string that we use to call a handler function */
> > > const char *handler; /* What we *really* dispatch on */
> > >
> > > the comments are a complete lie, of course. I don't know whether we can
> > > fix them without breaking stuff.
> >
> > I don't know that adding the overhead of an extra function call is that
> > major of a deal here. Some may disagree. It is certainly more clear then
> > adding more stuff to the request_rec, IMO.
>
> Even more clear is passing it in the function call. :-)
Yes, and since an authentication handler is generally going to need the
r->user, why not just pass that in as well? Because that information is
readily available through the request_rec. Just change it back.. Please?.. ;-)
-- Jon
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Jon Travis wrote:
> > > You are doing it
> > > everytime in ap_invoke_handler anyway, so the only inneficiency is that
> > > introduced is an extra function call.
> >
> > What?
>
> You said that "Because then it has to be done every time, which is inneficient"
> referring to the work that is done in ap_invoke_handler.
No, I meant if you do it in the hook, you do it in every module.
> > > And if you wanted, you could add
> > > another field to the request_rec, and just manipulate that within
> > > your ap_invoke_handler routine, or whatever. That would save the
> > > overhead of the function call.
> >
> > I could by that. Makes it less clear how you get from A to B, but I'm
> > not that fussed. OTOH, request_rec _already_ has handler:
> >
> > /** The handler string that we use to call a handler function */
> > const char *handler; /* What we *really* dispatch on */
> >
> > the comments are a complete lie, of course. I don't know whether we can
> > fix them without breaking stuff.
>
> I don't know that adding the overhead of an extra function call is that
> major of a deal here. Some may disagree. It is certainly more clear then
> adding more stuff to the request_rec, IMO.
Even more clear is passing it in the function call. :-)
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
Re: index.html not served w/mod_autoindex active
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Jan 07, 2001 at 09:39:29PM +0000, Ben Laurie wrote:
> Jon Travis wrote:
> >
> > On Sun, Jan 07, 2001 at 09:11:12PM +0000, Ben Laurie wrote:
> > > Jon Travis wrote:
> > > >
> > > > On Sun, Jan 07, 2001 at 05:50:21PM +0000, Ben Laurie wrote:
> > > > > rbb@covalent.net wrote:
> > > > > >
> > > > > > > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > > > > > > that we shouldn't have to call every handler. Please implement whatever
> > > > > > > > solution you like best.
> > > > > > >
> > > > > > > Since no-one else has expressed an opinion, I shall. :-)
> > > > > >
> > > > > > Cool. I look forward to seeing it. :-) I am sorry that I held things up
> > > > > > this long. I didn't realize that I was the bottleneck. If I had, I would
> > > > > > have gotten out of the way much sooner. :-)
> > > > >
> > > > > Don't sweat it - I didn't have time to do it any sooner, anyway!
> > > >
> > > > I hope this is the correct thread to respond on this to, so here goes:
> > > >
> > > > I just saw the commits which were made to hookize the handlers. I have
> > > > a few comments:
> > > >
> > > > 1 - AP_DECLARE_HOOK for the handler should probably not be in http_config.h
> > > > It should probably be in http_request.h
> > >
> > > Probably correct.
> > >
> > > > 2 - A new hook prototype has been made. One that takes the handlername, and
> > > > the request. This sucks. Since the handler information is gleaned
> > > > from the request anyway, why not keep the old prototype for the
> > > > handler, and make the registered hook use some function to grab the
> > > > handler from the request_rec?
> > >
> > > Because then it has to be done every time, which is inefficient. Why
> > > does it suck?
> >
> > Because it makes me have to write more code.. ;-) mod_snake handles all
> > the request_rec based handlers in a same generic way. By changing the
> > prototype of this function you kinda break that.. :-(
>
> Ah.
>
> > You are doing it
> > everytime in ap_invoke_handler anyway, so the only inneficiency is that
> > introduced is an extra function call.
>
> What?
You said that "Because then it has to be done every time, which is inneficient"
referring to the work that is done in ap_invoke_handler.
>
> > And if you wanted, you could add
> > another field to the request_rec, and just manipulate that within
> > your ap_invoke_handler routine, or whatever. That would save the
> > overhead of the function call.
>
> I could by that. Makes it less clear how you get from A to B, but I'm
> not that fussed. OTOH, request_rec _already_ has handler:
>
> /** The handler string that we use to call a handler function */
> const char *handler; /* What we *really* dispatch on */
>
> the comments are a complete lie, of course. I don't know whether we can
> fix them without breaking stuff.
I don't know that adding the overhead of an extra function call is that
major of a deal here. Some may disagree. It is certainly more clear then
adding more stuff to the request_rec, IMO.
-- Jon
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Jon Travis wrote:
>
> On Sun, Jan 07, 2001 at 09:11:12PM +0000, Ben Laurie wrote:
> > Jon Travis wrote:
> > >
> > > On Sun, Jan 07, 2001 at 05:50:21PM +0000, Ben Laurie wrote:
> > > > rbb@covalent.net wrote:
> > > > >
> > > > > > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > > > > > that we shouldn't have to call every handler. Please implement whatever
> > > > > > > solution you like best.
> > > > > >
> > > > > > Since no-one else has expressed an opinion, I shall. :-)
> > > > >
> > > > > Cool. I look forward to seeing it. :-) I am sorry that I held things up
> > > > > this long. I didn't realize that I was the bottleneck. If I had, I would
> > > > > have gotten out of the way much sooner. :-)
> > > >
> > > > Don't sweat it - I didn't have time to do it any sooner, anyway!
> > >
> > > I hope this is the correct thread to respond on this to, so here goes:
> > >
> > > I just saw the commits which were made to hookize the handlers. I have
> > > a few comments:
> > >
> > > 1 - AP_DECLARE_HOOK for the handler should probably not be in http_config.h
> > > It should probably be in http_request.h
> >
> > Probably correct.
> >
> > > 2 - A new hook prototype has been made. One that takes the handlername, and
> > > the request. This sucks. Since the handler information is gleaned
> > > from the request anyway, why not keep the old prototype for the
> > > handler, and make the registered hook use some function to grab the
> > > handler from the request_rec?
> >
> > Because then it has to be done every time, which is inefficient. Why
> > does it suck?
>
> Because it makes me have to write more code.. ;-) mod_snake handles all
> the request_rec based handlers in a same generic way. By changing the
> prototype of this function you kinda break that.. :-(
Ah.
> You are doing it
> everytime in ap_invoke_handler anyway, so the only inneficiency is that
> introduced is an extra function call.
What?
> And if you wanted, you could add
> another field to the request_rec, and just manipulate that within
> your ap_invoke_handler routine, or whatever. That would save the
> overhead of the function call.
I could by that. Makes it less clear how you get from A to B, but I'm
not that fussed. OTOH, request_rec _already_ has handler:
/** The handler string that we use to call a handler function */
const char *handler; /* What we *really* dispatch on */
the comments are a complete lie, of course. I don't know whether we can
fix them without breaking stuff.
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
Re: index.html not served w/mod_autoindex active
Posted by Doug MacEachern <do...@covalent.net>.
> Because it makes me have to write more code.. ;-) mod_snake handles all
> the request_rec based handlers in a same generic way. By changing the
> prototype of this function you kinda break that.. :-( You are doing it
> everytime in ap_invoke_handler anyway, so the only inneficiency is that
> introduced is an extra function call. And if you wanted, you could add
> another field to the request_rec, and just manipulate that within
> your ap_invoke_handler routine, or whatever. That would save the
> overhead of the function call.
ugh. same for mod_perl. big +1 on keeping the old handler
(request_rec *) prototype. if the prototype is changed, please at least
keep request_rec as the first argument.
Re: index.html not served w/mod_autoindex active
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Jan 07, 2001 at 09:11:12PM +0000, Ben Laurie wrote:
> Jon Travis wrote:
> >
> > On Sun, Jan 07, 2001 at 05:50:21PM +0000, Ben Laurie wrote:
> > > rbb@covalent.net wrote:
> > > >
> > > > > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > > > > that we shouldn't have to call every handler. Please implement whatever
> > > > > > solution you like best.
> > > > >
> > > > > Since no-one else has expressed an opinion, I shall. :-)
> > > >
> > > > Cool. I look forward to seeing it. :-) I am sorry that I held things up
> > > > this long. I didn't realize that I was the bottleneck. If I had, I would
> > > > have gotten out of the way much sooner. :-)
> > >
> > > Don't sweat it - I didn't have time to do it any sooner, anyway!
> >
> > I hope this is the correct thread to respond on this to, so here goes:
> >
> > I just saw the commits which were made to hookize the handlers. I have
> > a few comments:
> >
> > 1 - AP_DECLARE_HOOK for the handler should probably not be in http_config.h
> > It should probably be in http_request.h
>
> Probably correct.
>
> > 2 - A new hook prototype has been made. One that takes the handlername, and
> > the request. This sucks. Since the handler information is gleaned
> > from the request anyway, why not keep the old prototype for the
> > handler, and make the registered hook use some function to grab the
> > handler from the request_rec?
>
> Because then it has to be done every time, which is inefficient. Why
> does it suck?
Because it makes me have to write more code.. ;-) mod_snake handles all
the request_rec based handlers in a same generic way. By changing the
prototype of this function you kinda break that.. :-( You are doing it
everytime in ap_invoke_handler anyway, so the only inneficiency is that
introduced is an extra function call. And if you wanted, you could add
another field to the request_rec, and just manipulate that within
your ap_invoke_handler routine, or whatever. That would save the
overhead of the function call.
-- Jon
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
Jon Travis wrote:
>
> On Sun, Jan 07, 2001 at 05:50:21PM +0000, Ben Laurie wrote:
> > rbb@covalent.net wrote:
> > >
> > > > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > > > that we shouldn't have to call every handler. Please implement whatever
> > > > > solution you like best.
> > > >
> > > > Since no-one else has expressed an opinion, I shall. :-)
> > >
> > > Cool. I look forward to seeing it. :-) I am sorry that I held things up
> > > this long. I didn't realize that I was the bottleneck. If I had, I would
> > > have gotten out of the way much sooner. :-)
> >
> > Don't sweat it - I didn't have time to do it any sooner, anyway!
>
> I hope this is the correct thread to respond on this to, so here goes:
>
> I just saw the commits which were made to hookize the handlers. I have
> a few comments:
>
> 1 - AP_DECLARE_HOOK for the handler should probably not be in http_config.h
> It should probably be in http_request.h
Probably correct.
> 2 - A new hook prototype has been made. One that takes the handlername, and
> the request. This sucks. Since the handler information is gleaned
> from the request anyway, why not keep the old prototype for the
> handler, and make the registered hook use some function to grab the
> handler from the request_rec?
Because then it has to be done every time, which is inefficient. Why
does it suck?
> 3 - Given #2, ap_invoke_handler should be split up. handler_len isn't
> even used in that function ATM. There should be another routine to
> grab the handler info (i.e. content_type, or handler, etc.)
handler_len is a leftover. Hmm. Doesn't -Wall catch unused variables?
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
Re: index.html not served w/mod_autoindex active
Posted by Jon Travis <jt...@covalent.net>.
On Sun, Jan 07, 2001 at 05:50:21PM +0000, Ben Laurie wrote:
> rbb@covalent.net wrote:
> >
> > > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > > that we shouldn't have to call every handler. Please implement whatever
> > > > solution you like best.
> > >
> > > Since no-one else has expressed an opinion, I shall. :-)
> >
> > Cool. I look forward to seeing it. :-) I am sorry that I held things up
> > this long. I didn't realize that I was the bottleneck. If I had, I would
> > have gotten out of the way much sooner. :-)
>
> Don't sweat it - I didn't have time to do it any sooner, anyway!
I hope this is the correct thread to respond on this to, so here goes:
I just saw the commits which were made to hookize the handlers. I have
a few comments:
1 - AP_DECLARE_HOOK for the handler should probably not be in http_config.h
It should probably be in http_request.h
2 - A new hook prototype has been made. One that takes the handlername, and
the request. This sucks. Since the handler information is gleaned
from the request anyway, why not keep the old prototype for the
handler, and make the registered hook use some function to grab the
handler from the request_rec?
3 - Given #2, ap_invoke_handler should be split up. handler_len isn't
even used in that function ATM. There should be another routine to
grab the handler info (i.e. content_type, or handler, etc.)
-- Jon
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > Do not consider this a veto in any way shape or form, this is an opinion,
> > > that we shouldn't have to call every handler. Please implement whatever
> > > solution you like best.
> >
> > Since no-one else has expressed an opinion, I shall. :-)
>
> Cool. I look forward to seeing it. :-) I am sorry that I held things up
> this long. I didn't realize that I was the bottleneck. If I had, I would
> have gotten out of the way much sooner. :-)
Don't sweat it - I didn't have time to do it any sooner, anyway!
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
Re: index.html not served w/mod_autoindex active
Posted by rb...@covalent.net.
> > Do not consider this a veto in any way shape or form, this is an opinion,
> > that we shouldn't have to call every handler. Please implement whatever
> > solution you like best.
>
> Since no-one else has expressed an opinion, I shall. :-)
Cool. I look forward to seeing it. :-) I am sorry that I held things up
this long. I didn't realize that I was the bottleneck. If I had, I would
have gotten out of the way much sooner. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
> It bothers me that either in the middle of the 2.0 beta series, or during
> the 2.0 series itself, we are all of a sudden going to change how handlers
> are registered. At least, that's the impression I get from the later
> messages. Basically, it sounds to me like we are going to move the check
> into the handler, just to move it back out later once we decide to make
> the optimization.
You are presupposing that we will decide to make the optimisation. It
isn't clear to me that we would.
> I would much rather get the API correct, even if we
> don't implement all of it immediately. That way, we don't break every
> single handler when we get around to implementing the optimzation. All I
> am asking, is that we get the API to the point that we can implement the
> optimization without changing the API again. For right now, I really
> don't care that the core actually does everything, but I do care that we
> get the API correct for the advancement in the future.
Again, you are assuming that this is an enhancement we actually want.
I'm inclined to argue that all it gets us is one less function call in a
small number of cases at the cost of considerable obfuscation - it isn't
clear to me that this enhancement would be even measurable. And the
point of doing this is to remain allegedly compatible with the existing
system, though, of course, registering hook functions can only be
compatible in the most eccentric sense of the word.
> Other people suggested that being able to specify the order in the config
> file, because it makes debugging modules easier, but that was it. I
> really don't care that much about the hinting mechanism for the config
> file.
Actually, the idea was to permit people to define order of hooking _in
general_, which could clearly be useful.
> I care that modules can specify the the "char *" when they register the
> handler, even if the core doesn't DO anything with it immediately. If we
> don't have that option, then we will always have to call every handler.
If the core does nothing with it, then it _won't work_. And we always
have to call every other hook, even though they usually decline, but
that's never worried you before... and there's _far_ more of them.
> Do not consider this a veto in any way shape or form, this is an opinion,
> that we shouldn't have to call every handler. Please implement whatever
> solution you like best.
Since no-one else has expressed an opinion, I shall. :-)
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
Re: index.html not served w/mod_autoindex active
Posted by rb...@covalent.net.
> OTOH, the only reason I'm considering doing this _at this stage_ is
> because Ryan objected that not doing so would require a code change in
> handlers. This code change is a one-liner, that checks the handler type
> against a string (not a strcmp, coz it uses wildcards) so I can't say
> that it actually worries me greatly, given the rather large amount of
> other changes that are already required for modules, and also given that
> failure to do the check will be _really obvious_ (the handler will
> handle stuff it shouldn't), and also given that the string you have to
> check against will otherwise have no place to live, which should be a
> large clue for even the dimmest programmer.
>
> So, I do kinda hope that Ryan will relent and say that its OK to move
> the check into the hook, instead of adding this complex hinting
> mechanism right now.
I wasn't trying to stop ANYTHING. I expressed a single concern, and the
conversation stopped. I didn't veto the change, or say not to do it. I
said I disliked having to call every handler function, but that's all I
said. I tried suggesting a different solution, which you obviously
dislike, but feel free to implement whatever solution you like best. I
just wanted to get my only concern in the open, so that we all agreed that
the issue was there.
It bothers me that either in the middle of the 2.0 beta series, or during
the 2.0 series itself, we are all of a sudden going to change how handlers
are registered. At least, that's the impression I get from the later
messages. Basically, it sounds to me like we are going to move the check
into the handler, just to move it back out later once we decide to make
the optimization. I would much rather get the API correct, even if we
don't implement all of it immediately. That way, we don't break every
single handler when we get around to implementing the optimzation. All I
am asking, is that we get the API to the point that we can implement the
optimization without changing the API again. For right now, I really
don't care that the core actually does everything, but I do care that we
get the API correct for the advancement in the future.
Other people suggested that being able to specify the order in the config
file, because it makes debugging modules easier, but that was it. I
really don't care that much about the hinting mechanism for the config
file.
I care that modules can specify the the "char *" when they register the
handler, even if the core doesn't DO anything with it immediately. If we
don't have that option, then we will always have to call every handler.
Do not consider this a veto in any way shape or form, this is an opinion,
that we shouldn't have to call every handler. Please implement whatever
solution you like best.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: index.html not served w/mod_autoindex active
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > It's easy to fix with a hack if the modules are statically linked: go
> > into modules.c, (ignore the warning about not hand editing it,) go down
> > to the ap_prelinked_modules structure and move the &dir_module line down
> > to after the &autoindex_module line, then make, restart the server, and
> > voila! - index.html's are back.
> >
> > Unfortunately, not only is it very complicated to re-order this list at
> > configure time, it is also pointless because it doesn't deal with the
> > situation when one or both of these modules is a DSO. If we had
> > something like the hook sorting mechanism for handlers, it would be
> > easily solved.
>
> Re-order the modules with the AddModule command for now. Ben Laurie has
> started to work on a project to order the handlers the same way the other
> hooks are ordered.
What I actually want to do (and I may work on this tomorrow) is to add a
hinting mechanism for all hooks, which will then mean that handlers can
be cleanly linked into the hooking mechanism.
OTOH, the only reason I'm considering doing this _at this stage_ is
because Ryan objected that not doing so would require a code change in
handlers. This code change is a one-liner, that checks the handler type
against a string (not a strcmp, coz it uses wildcards) so I can't say
that it actually worries me greatly, given the rather large amount of
other changes that are already required for modules, and also given that
failure to do the check will be _really obvious_ (the handler will
handle stuff it shouldn't), and also given that the string you have to
check against will otherwise have no place to live, which should be a
large clue for even the dimmest programmer.
So, I do kinda hope that Ryan will relent and say that its OK to move
the check into the hook, instead of adding this complex hinting
mechanism right now.
BTW, I'm really totally opposed to doing a special for handlers: that's
BS, IMO.
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
Re: index.html not served w/mod_autoindex active
Posted by rb...@covalent.net.
> It's easy to fix with a hack if the modules are statically linked: go
> into modules.c, (ignore the warning about not hand editing it,) go down
> to the ap_prelinked_modules structure and move the &dir_module line down
> to after the &autoindex_module line, then make, restart the server, and
> voila! - index.html's are back.
>
> Unfortunately, not only is it very complicated to re-order this list at
> configure time, it is also pointless because it doesn't deal with the
> situation when one or both of these modules is a DSO. If we had
> something like the hook sorting mechanism for handlers, it would be
> easily solved.
Re-order the modules with the AddModule command for now. Ben Laurie has
started to work on a project to order the handlers the same way the other
hooks are ordered.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------