On 02/20/2011 12:37 PM, Igor GaliÄ wrote:
Why?
>> I'm trying to learn how to use the Apache rewrite module > (http://bash.org/?866112)As a matter of fact, I *do* know how to operate a jackhammer. Do you need your demons let out? ;-)
Also, I have attempted to enable the rewrite log and set the target directory mode to 0777, but no log file is written (?).http://blag.esotericsystems.at/igor/says/no
Oh, isn't he cute!
You do not, NEVER EVER chmod something 0777. There is no place for 0777 on any server. Not even a test server. There is a place for 1777 and that place is /tmp and /var/tmp.
I was expecting Apache to run as www-data:
2011-02-20 13:35:44 dpchrist@p43400e ~/bluefish
$ sudo grep -r APACHE_RUN_USER /etc
/etc/apache2/envvars:export APACHE_RUN_USER=www-data
/etc/apache2/apache2.conf:User ${APACHE_RUN_USER}
But, Apache seems to be running as root:
2011-02-20 14:00:57 dpchrist@p43400e ~/bluefish
$ chmod 0755 log
2011-02-20 14:06:11 dpchrist@p43400e ~/bluefish
$ sudo rm log/rewrite.log
2011-02-20 14:06:18 dpchrist@p43400e ~/bluefish
$ sudo apache2ctl graceful
2011-02-20 14:06:25 dpchrist@p43400e ~/bluefish
$ ll log/rewrite.log
-rw-r--r-- 1 root root 0 Feb 20 14:06 log/rewrite.log
So, you're right -- mode 0777 wasn't necessary in this case.
(Perhaps a Debian bug report is in order...)
Generally, mod_rewrite is debugged using RewriteLog. http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritelog But see below. Aha.. might want to check out: http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritelog later on...
>> RewriteLog /home/dpchrist/bluefish/log/rewrite.log Unfortunately, it's empty. (Another Debian bug report?)
How many people, I wonder, have mod_authz_groupfile loaded without using it?
587,243, give or take. ;-)
Why when you have full access to the config do you put your rewrite rules in .htaccess?
Because I don't have full access to the config file on shared hosting servers.
Please their documentation for what they are good for: http://httpd.apache.org/docs/current/howto/htaccess.html
Yes, I've read that: past, present, and future. :-)
Finally, I fail to see why you're even using rewrite for that thing? You could just name your files .html, make them executable.
So, if I want HTML pages to be generated by Perl scripts named *.html, then should I write HTML pages named *.pl to generate my Perl scripts? Do I then pipe the output of wget to perl -e? But, how do I feed that into Apache to generate the HTML page? Perhaps I should really use *.html for Bash scripts? ;-)
Options +ExecCGI would only pick up those that are exectuable. Of course that's not "transparent" but if you're looking for transparency, why not just *drop* .html *and* .pl from the *Request* and have Options +MultiViews take care of serving the right file?
http://httpd.apache.org/docs/2.2/mod/core.html#options http://httpd.apache.org/docs/2.2/content-negotiation.html http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html Interesting.
See my last mail to users@ which, too, suggests avoiding mod_rewrite:) http://www.mail-archive.com/users@xxxxxxxxxxxxxxxx/msg46255.html
http://wiki.apache.org/httpd/WhenNotToUseRewrite"These examples assume the RewriteRules are not placed in a directory context (i.e., not in a .htaccess file nor in a <Directory> section)."
For this test, the rewrite rules are in .htaccess. http://httpd.apache.org/docs/trunk/rewrite/avoid.html"The most common situation in which mod_rewrite is the right tool is when the very best solution requires access to the server configuration files, and you don't have that access. Some configuration directives are only available in the server configuration file. So if you are in a hosting situation where you only have .htaccess files to work with, you may need to resort to mod_rewrite."
Shared hosting without access to the server configuration files is the use-case I am testing.
David --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|