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 Stein <gs...@lyra.org> on 2001/08/24 23:07:02 UTC
Re: cvs commit: httpd-2.0/include http_core.h
On Fri, Aug 24, 2001 at 06:12:02PM -0000, wrowe@apache.org wrote:
> wrowe 01/08/24 11:12:02
>
> Modified: server core.c request.c
> include http_core.h
> Log:
> sec, sec, who's got a sec? This gave me a headache, but I had to clear
> out the last patch before I rearranged this to be _readable_.
>
> Next step for everyone's sanity, provide <Proxy > directives ;)
*THANK YOU*
I ran into that crap when I was doing the "ap_conf_vector_t" work. Took a
lot of duct tape to repair my head. Just never got a chance to go back and
fix the stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/include http_core.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
Sent: Friday, August 24, 2001 4:51 PM
> On Fri, Aug 24, 2001 at 04:24:35PM -0500, William A. Rowe, Jr. wrote:
> >...
> > I'm not approaching this again until I've slept on it. I have the patch
> > essentially finished, adding a per-'dir' (proxy location, really) pattern
> > of p, with a isregex flag of r. That's about as complicated as it gets.
>
> I'm not sure that I follow what the pattern thing is all about.
Regex expressions, instead of strcmp matching. (E.g. <ProxyMatch >)
> >...
> > There will be no more 'faux' filenames. It's either an absolute path, or
> > undefined (and irrelevant.) A few modules will get to deal with in anyways
> > (such as mod_mime.)
> >
> > I'll start tommorow and wrap up tommorow, so everyone can take a look at what
> > else this impacts. But getting rid of 'specials' is the only way to clean out
> > directory_walk of all it's very heavy cruft.
>
> Note that r->filename and friends (finfo, canonical_filename, etc) are all
> related to the filesystem. As such, they are all completely bogus when
> you're talking about purely virtual resources (such as /server-status or
> content coming from a database). Thus, they should not be part of the
> request_rec, but instead part of a private structure to something like
> mod_filesystem. That mod_filesystem would implement the various translation
> and other fs-related items that occur.
No argument here ;) This should work out pretty darned well, but I would argue
everyone needs to be able to access the r->filename if their module works with
'files'. That doesn't mean every request needs an fs_request_rec member :)
> And no... I'm not suggesting this happen any time soon :-) But it will one
> day, if I can figure out how to tackle it and can set aside the time.
Re: cvs commit: httpd-2.0/include http_core.h
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 04:24:35PM -0500, William A. Rowe, Jr. wrote:
>...
> I'm not approaching this again until I've slept on it. I have the patch
> essentially finished, adding a per-'dir' (proxy location, really) pattern
> of p, with a isregex flag of r. That's about as complicated as it gets.
I'm not sure that I follow what the pattern thing is all about.
>...
> There will be no more 'faux' filenames. It's either an absolute path, or
> undefined (and irrelevant.) A few modules will get to deal with in anyways
> (such as mod_mime.)
>
> I'll start tommorow and wrap up tommorow, so everyone can take a look at what
> else this impacts. But getting rid of 'specials' is the only way to clean out
> directory_walk of all it's very heavy cruft.
Note that r->filename and friends (finfo, canonical_filename, etc) are all
related to the filesystem. As such, they are all completely bogus when
you're talking about purely virtual resources (such as /server-status or
content coming from a database). Thus, they should not be part of the
request_rec, but instead part of a private structure to something like
mod_filesystem. That mod_filesystem would implement the various translation
and other fs-related items that occur.
And no... I'm not suggesting this happen any time soon :-) But it will one
day, if I can figure out how to tackle it and can set aside the time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/include http_core.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
Sent: Friday, August 24, 2001 4:07 PM
> On Fri, Aug 24, 2001 at 06:12:02PM -0000, wrowe@apache.org wrote:
> > wrowe 01/08/24 11:12:02
> >
> > Modified: server core.c request.c
> > include http_core.h
> > Log:
> > sec, sec, who's got a sec? This gave me a headache, but I had to clear
> > out the last patch before I rearranged this to be _readable_.
> >
> > Next step for everyone's sanity, provide <Proxy > directives ;)
>
> *THANK YOU*
>
> I ran into that crap when I was doing the "ap_conf_vector_t" work. Took a
> lot of duct tape to repair my head. Just never got a chance to go back and
> fix the stuff.
You are welcome :)
I'm not approaching this again until I've slept on it. I have the patch
essentially finished, adding a per-'dir' (proxy location, really) pattern
of p, with a isregex flag of r. That's about as complicated as it gets.
I'll commit the patch to Proxy in the morning, it will break any module that
'fakes' a filename. Essentially, a new hook, ap_walk_hook or some such, will
run for an OK. Proxy will grab that hook, so all is well. Anybody else who
munges a 'fake' request, with a non-absolute path, will have to do the same.
There will be no more 'faux' filenames. It's either an absolute path, or
undefined (and irrelevant.) A few modules will get to deal with in anyways
(such as mod_mime.)
I'll start tommorow and wrap up tommorow, so everyone can take a look at what
else this impacts. But getting rid of 'specials' is the only way to clean out
directory_walk of all it's very heavy cruft.
Bill