httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Kahan <>
Subject [mod_spelling] misuse of AcceptPathInfo?
Date Tue, 25 Sep 2007 15:25:33 GMT

Since Apache 2.2, one has to turn on AcceptPathInfo
in order to correct directory mispelings:

<IfModule mod_speling.c>
   CheckSpelling On
   AcceptPathInfo On

This is because mod_speling has the following code:

    /* we default to reject path info (same as core handler) */
    if ((r->used_path_info != AP_REQ_ACCEPT_PATH_INFO) &&
        r->path_info && *r->path_info) {
        return DECLINED;

Having to turn on the AcceptPathInfo to be able to use
mod_speling seems wrong. When Apache is parsing a URI and
doesn't find an equivalent filename, it is storing the
"extra" information into r->path_info. However, unless
AcceptPathInfo is turned on, mod_speling won't even try
to fix the spelling.

For example, the following URI is a valid one:

If AcceptPathInfo has a value different than On, we will 
get a 404 status on the following (TR spelled as tr):

thus defeating the benefits of using of mod_speling.

On the other hand, if you turn on AcceptPathInfo, you
get mod_speling to work. On the other hand, you
are accepting PathInfo even if you don't want, and even
if it's a bogus.  Any time a file foo.ext exists, requests for 
foo/* are served with 200 OK status. e.g.,

Moreover, this breaks the browser-side resolution of 
relative links.

Our stats show that Apache 1.x didn't accept bogus PathInfo. The
above URIs would return a 404 status, just as if we had 
never enabled AcceptPathInfo in 2.2.

Is there any special reason as to why mod_speling is running
conditional to the value of AcceptPathInfo? I don't see
any benefit to it as you have to enable AcceptPathInfo for your
server and you get side effects.

Does it make sense to remove that check from mod_speling?



View raw message