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
filters...)
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
