I have logging enabled in my httpd conf file as follows...
RewriteLog "/var/log/httpd/rewrite.log"
RewriteLogLevel 3
This works fine. I don't want to impact the server whilst debugging though, or create extra info than needed.
Is there any way to only log rewrites only for a specific IP address (or narrow via some other criteria if not)?
One solution I've found so far is the pipe operator, so I've added the following...
RewriteLog "|/bin/grep '<myIpAddress>' > /var/log/httpd/debugrewrite.log"
RewriteLogLevel 5
Not sure how efficient that is, as it calls grep each time, so I'm not a fan of it, but for the moment its helping cut down the logging, and I turn it off as soon as finished.
Related
Is there some command to retrieve the Apache settings applicable to a certain directory in other words the command should take into account the cascade of .htaccess files as well as the global configuration of the Apache server.
The command should do something like:
$ command .
AddType text/html html
...
Such command can be useful to debug why a certain page generates a 500 (or other) error. Since several configuration files can play their part in this.
Short answer NO, but you can see what rewrite rules are being applied to requests, that's assuming you have access to the servers httpd.conf and the ability to restart the web server. Simply add the following to your virtual host definition / included rewrite file e.g.
RewriteLog "/tmp/tmp_rewrite.log"
RewriteLogLevel 9
Remember to remove / comment out the entry, or to set the RewriteLogLevel to 0 once you've finished playing.
I can't get mod_rewrite to log anything about what it's doing. You can imagine that this makes debugging mod_rewrite... challenging. I've followed the "instructions" at http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html (I'm running 2.2.22 on a Mac), except that they're missing critical details like... which of the config files to put the configuration in, and in which level of XML elements.
RewriteLog "/tmp/rewrite.log"
RewriteLogLevel 8
Where do I put these directives so that I actually get logging about what mod_rewrite is doing? /tmp/rewrite.log is created, so Apache has some clue about what I want, but it logs nothing at all to this file.
I was trying out the Apache Rewrite Engine, but was having problems because it cached it's responses. Now if I change the file, it does not do what the file says, but does what it did when I tried the same url before.
For example, I tried to type in
localhost/api
but I had not yet set a rule that would match that. The server gave me a 404 error. I tried to add a rule that would work with this url:
RewriteRule api/? api.php [L]
but it still gave me the same error. If I try an address like localhost/lapi which I didn't enter before I added the rule, it works. Is there a way to clear this cache and restart? I tried restarting apache using apachectl -k restart and apachectl -k graceful but I still had the same problem. Does anyone know how to fix this problem?
First of all, depending on the context of your rule, you may need a leading slash as in:
RewriteRule api/? /api.php [L]
Regarding the caching, do you have mod_cache enabled? If so, disable it and restart your server. mod_rewrite does not do any caching on its own. Also be sure to completely clear your browser cache and be aware that if you are not accessing your server over the same local network, there may be other caching taking place along the way.
This problem can also be caused by the MultiViews option, see Apache doc. Try omitting Option MultiViews from httpd.conf or add Options -MultiViews to .htaccess.
(The MultiViews option enables Apache to choose automaticaly between several versions of the file based on the file name extension and content preferences present in the HTTP request (i.e. something you probably don't want to happen). It can lead to this kind of bizzare failure when a rewrite rule just removes the script's extension.)
I am trying to fix this whole day without success, so I hope someone might be able to help me. I have an app at http://localhost/, and it uses Pylons for the app I am hosting. In addition to that, I need to host a PHP/MySQL site, so I had to use Apache too.
My current setup is that I use haproxy with this config for the Apache backend:
backend apache
mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin
server app02-8002 localhost:8002 maxconn 1000
This is triggered by this:
acl image url_sub images
use_backend apache if image
So, when I open my IP/images, it will trigger that and open Apache then, with port 8002.
For Apache, I created virtual hosts, and this is the "image" one:
<VirtualHost *:8002>
ServerAdmin my#email.com
ServerName image
ServerAlias image
DocumentRoot /srv/www/image/public_html/
ErrorLog /srv/www/image/logs/error.log
CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>
So, that all works nicely, when I type IP/images it open the /srv/www/image/public_html. But then the issues come. As I am using the image uploading script, it involves a lot of rewriting, so I had to enable that mod. This is the .htaccess which is located in the public_html/images folder (I somehow had to make this subfolder too, to "match" the URL with the actual location in the public_html.
SetEnv PHP_VER 5_3
RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/
RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]
So, basically, this is somethow not working. I suppose there is a conflict between this virtual host, subdirectory, rewriting or something, but I can't seem to isolate it.
It is a bit confusing that when I open the IP/images/xxxx.jpg it opens the image, which is located in the public_html/images/upload/original folder, so the rewrite is working. The the other rules seem not to be working. All of the thumbnails and smaller versions are not rendering properly (with the icon, small, medium, square), so that makes the site quite unsusable.
Here is the link of the development server: http://localhost/images/
Thanks in advance for your time and help!
The first thing you should do is determine whether mod_rewrite is in fact part of the problem by accessing one of the failing URLs directly via its rewritten form and verifying that you get the expected result.
Indeed, the problem might simply be that the PHP script for the smaller resolutions "doesn't work" while it does for the original size ones. The first of the following URLs nicely served me an image; the second one is supposed to give me a smaller version of the same image, but served me an HTTP 500:
http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png
I got the same result (HTTP 500) for any of the smaller-size format names mentioned in your post, which matches your problem description.
Once you've verified that the script works as expected, it's likely that the problem is with mod_rewrite. If so, enable rewrite logging: use the RewriteLog directive to activate it, and RewriteLogLevel to control its verbosity. Especially at the higher log levels, it can give you very detailed information about exactly what it's doing. This should make the problem readily apparent from the logs.
Also, if possible, try to avoid configuring mod_rewrite rules in .htaccess files -- move them into your main server config file instead. The reason is explained on Apache mod_rewrite Technical Details, section "API phases":
Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.
Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.
In general, not using .htaccess at all has the added advantage that you can tell Apache to not even bother and disable the functionality all together, which save Apache from having to scan each directory level it serves from for the .htaccess files.
I'm getting a "webpage has a redirect loop" error. Most likely this is due to my Apache rewrite configuration. I've had these issues before, and find them hard to debug. Is there some sort of log that allows me to see what the request is being redirected to?
If not, how do you debug Apache rewrites in an efficient way?
If you are using newer Apache version (I'm testing it with 2.4), the RewriteLog directive has been replaced by the new per-module logging configuration (see apache doc).
Now you want to put the following line in your configuration:
LogLevel alert rewrite:trace3
and check your error log for the rewrite module messages.
tail -f error_log|fgrep '[rewrite:'
You can configure mod_rewrite's log file via the "RewriteLog" directive.
For example:
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
For more information, see: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewritelog
One other link I find myself going back to is "crazy advanced mod_rewrite" -- lots of info there which you may want to stash away for future reference. It's at: http://www.askapache.com/htaccess/crazy-advanced-mod_rewrite-tutorial.html
See RewriteLog and RewriteLogLevel directives.