.htaccessaccess-log

RewriteRule creates 404 in SSL access log


I'm trying to get some nice URLs. I want to use
https://sub.domain.edu/fs/7356
for
https://sub.domain.edu/fs/index.php?ind=7356

My .htaccess for this directory is:
RewriteEngine On RewriteBase /fs/ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?ind=$1 [L,QSA]

The page works fine in the browser. The PHP script works. It all looks great. But the ssl_access_log shows every page access as a 404.

"GET /fs/7356 HTTP/1.1" 404 9241

This would only be mildly annoying except logwatch flags all these 404s as possibly malicious probes. Every morning I get an email saying dozens of IPs tried to probe the site. I have tried adding R=301 to the RewriteRule but it does a full redirect to the full URL I am trying to avoid.


Solution

  • I had to make a custom log format. In /etc/httpd/conf.d/ssl.conf, I commented out the entry that created the ssl_acess-log file and replaced it with LogFormat and Customlog directives.

    #TransferLog logs/ssl_access_log LogFormat "%h %l %u %t \"%r\" %s %b" logwatchfix CustomLog logs/ssl_access_log logwatchfix

    http://httpd.apache.org/docs/current/mod/mod_log_config.html

    This resulted in a near-identical output as the original with the only exception being the "%>s" replaced with "%s" It works opposite the way I understand the documentation.

    "%s Status. For requests that have been internally redirected, this is the status of the original request. Use %>s for the final status."

    I would have thought the "status of the original request" would have been "404" and the "final status" after .htaccess redirection would be "200" In practice, in my case, it worked the opposite. I also placed similar .htaccess files in the other directories that worked the same way. I set the directory index to index.php instead of index.html in the httpd.conf file, but it seemed to make no difference.