httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: 2.0.26?
Date Fri, 31 Aug 2001 05:36:26 GMT
On Thu, Aug 30, 2001 at 11:45:09PM -0500, William A. Rowe, Jr. wrote:
> I suggest we handle this as follows; r->uri becomes NULL.  If a hook fn doesn't
> like it, it needs to decline.  Where we go an reject the URI out of hand, let's
> also test for r->main, and if we have a parent, then let it slide.  If we don't
> (we are the main request) we can cough up a 500 if there was a leading slash
> or asterisk on the original uri, or a 400 if there was not.
> I've had it (for tonight.)  I'll be happy to pick back up anything necessary in
> the morning, and will finish my audit of the overall delta after we pin this
> down.  But I would much rather see non-file requests get r->filename of NULL
> (what about mime filename extensions?  I don't think they should apply to 
> non-files) and r->uri of NULL for truly bogus internal redirects.
> I know this will break some 3rd party modules.  This is 2.0, and we are working
> to _help_ them avoid the bugtrac reports on their modules.  I'd think getting 
> this right (in this day and age of the hourly new exploit) is far perferable to
> inconviencing an author with a set of five new rules.  {Ok ok... this will get
> documented once decisions are reached!}

+1.  Yes, this makes sense to me as I understand it.  

Non-file request should definitely get r->filename of NULL.  What
do they get right now?  Same goes for r->uri.  There are lots of
bogus assumptions throughout the code.

However, I disagree with mime filename extensions though.  I could
create a handler that serves everything from a database instead of
a file-system.  So, the core translate_filename (?) never sets
r->filename.  But, there are extensions on the URI that was passed
in - I would make the case that the proper mime mappings apply
(i.e. content-type et al).  AIUI, the mime types should apply to
the request not the files.  But, I could be 100% wrong here...

I'm thinking of mod_mbox which has a virtual namespace - the
mime mappings should be the *entire* URI not what the r->filename
says it should be - in mod_mbox's case r->filename is the raw mbox
file - the complete URI ends with .html so it should get that as
the content-type.  I think content-type should be R->L and handlers 
should be L->R evaluation (first match wins).

I believe that there are not that many filters that would intercept
non-filebacked requests anyway (mod_include comes to mind, but that's
all I can think of now).  (Lots of handlers though - just not

If I knew the code better and had the time to pitch in and help out
with this, I would.  I'm getting ready to go on "vacation," so I'm
trying to get some things closed out here before I go...  Sorry
I can't be of more help on this...  I'll test and try to review
patches though...  -- justin

View raw message