.htaccess/404: A better way?

One that doesn't present enigmas . . .

[rocknbil]

If this method is way out of line someone please sound off. It was recommended by a previous system admin.

Task: Redirect requests of a member's URL or a listing ID

http://www.example.com/JohnDoe
http://www.example.com/1234567
To their page, or appropriate listing.

The way we're doing it is using an .htaccess file:

ErrorDocument 404 search_script?d=1

And the query string, still in %ENV, is parsed out to produce the page.

This has worked for years for 99.99% of the visitors. But that .001%, almost ALWAYS AOL users, get "Page cannot be displayed." (They also scream the loudest.) Unfortunately all I can get out of them is the bottom of the page, "Cannot find server or DNS error."

Is there a better way to do this that will fix this once and for all?

Thank you so much for looking. :-)

[jdMorgan]

The problem may be that you are confusing their browser or the AOL caching system with the 404-Not Found server response.

If so, then the following method using mod_rewrite might work better:

# IF requested URL does not resolve to an existing directory
RewriteCond %{REQUEST_FILENAME} !-d
# AND IF requested URL does not resolve to an existing file
RewriteCond %{REQUEST_FILENAME} !-f
# THEN internally rewrite the request to the search script
RewriteRule ^/(.+)$ /search_script?d=1 [L]

This is a code fragment intended for use in httpd.conf. Other server config changes and mod_rewrite setup directives may be needed to make it work on your server. Paths may need to be adjusted as well.

This is not the most efficient way to do things, because every request will result in at least one filesystem check. Anything you can do to constrain these checks would help. For example, if you could require them to prepend "/user/" or "/~" or anything similar onto their requests, then only those URLs starting with "/user/" or "/~" would need to be checked. Or you could move the usernames into subdomains, and then check only that the requested subdomain is not www or blank, avoiding the filesystem check altogether. But if this is an existing system, then you're probably stuck with inefficient methods to support legacy users. It should still be faster than using the 404 ErrorDocument method, though.

404 ErrorDocuments and server responses should be used for only one purpose, and that is to inform the user that the URL he/she requested cannot be found on the server for reasons that could not be determined. If a page is removed intentionally, it should return a 410-Gone response. Any use of these handlers and server response codes for non-error-handling purposes eventually backfires, either in technical difficulties (such as the inefficiency noted above) or in problems with search engine rankings. If it also 'breaks' AOL, then that's a third argument against 'stretching' the HTTP protocol [w3.org].

Jim

[rocknbil]

Jim thank you so much! I always knew there was something wonky about using a 404 this way, but it worked, and no one offered a better solution. I'm off to roust out my admin from his cave and give this a try . . . bringing offerings in the form of doughnuts, they often bite this early in the day. . . . :-)

Thank you again.