httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: svn commit: r785425 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_dir.c
Date Fri, 19 Jun 2009 04:57:38 GMT
2009/6/18 Rich Bowen <rbowen@rcbowen.com>:
>
> On Jun 16, 2009, at 18:43, William A. Rowe, Jr. wrote:
>
>> William A. Rowe, Jr. wrote:
>>>
>>> This might be NotFoundHandler or for dir-not-file, ListingHandler.
>>
>> Sorry; not ListingHandler, but IndexHandler.
>>
>> But there is no point to a NotFoundHandler; the existing mechanics
>> in ScriptAlias combined with PATH_INFO solve that problem already.
>>
>> I think the interest was in handling the directory resource URI and
>> that would be an IndexHandler, absolutely.
>
> The intent was to call a something (I'd call it a handler) for requests that
> don't correspond to a resource. This is to answer the frequent
> configuration:
>
> RewriteEngine On
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteRule . index.php [PT]
>
> ie - if the request wasn't for a file, send the request directly to
> index.php (or index.pl, or wordpress.php, or whatever)
>
> and variations thereof that occur in every PHP web app I install these days.
> This situation is common enough that it seems like something we aught to
> support out of the box.

Is the intention that the way this new mod_dir directive works is such
that SCRIPT_NAME as added by ap_add_cgi_vars() would equate to the URL
of the directory, or is it still going to end up having index.php on
the URL, like with when using rewrite rules to achieve the same thing?

It is a bit of pain that when using rewrite rules that you have to do
a fiddle to SCRIPT_NAME to avoid the index.php bit appearing if you
base URL reconstruction on SCRIPT_NAME.

Graham

Mime
View raw message