Forum Moderators: phranque

Message Too Old, No Replies

Is there a mistake in this mod_rewrite rule?

         

Markus Klaffke

11:38 am on Sep 10, 2004 (gmt 0)

10+ Year Member



Hi,

the following rule is not my own creation. It is from this page

[movabletype.org...]

and I use Movabletype as a CMS.

This is it:

# Disable fancy indexes, so mtview.php gets a chance...
Options -Indexes
<IfModule mod_rewrite.c>
# The mod_rewrite solution is the preferred way to invoke
# dynamic pages, because of its flexibility.
# Add mtview.php to the list of DirectoryIndex options, listing it last,
# so it is invoked only if the common choices aren't present...
<IfModule mod_dir.c>
DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /mtview.php
</IfModule>
RewriteEngine on
# don't serve mtview.php if the request is for a real directory
# (allows the DirectoryIndex lookup to function)
RewriteCond %{REQUEST_FILENAME}!-d
# don't serve mtview.php if the request is for a real file
# (allows the actual file to be served)
RewriteCond %{REQUEST_FILENAME}!-f
# anything else is handed to mtview.php for resolution
RewriteRule ^(.*)$ /mtview.php [L,QSA]
</IfModule>
<IfModule!mod_rewrite.c>
# if mod_rewrite is unavailable, we forward any missing page
# or unresolved directory index requests to mtview
# if mtview.php can resolve the request, it returns a 200
# result code which prevents any 4xx error code from going
# to the server's access logs. However, an error will be
# reported in the error log file. If this is your only choice,
# and you want to suppress these messages, adding a "LogLevel crit"
# directive within your VirtualHost or root configuration for
# Apache will turn them off.
ErrorDocument 404 /mtview.php
ErrorDocument 403 /mtview.php
</IfModule>

My first problem is this line:

 <IfModule!mod_rewrite.c>

The

!

is wrong - yes?

The second problem is this line:

# anything else is handed to mtview.php for resolution
RewriteRule ^(.*)$ /mtview.php [L,QSA]

If i enable this line i cannot access my /cgi-bin/. If i comment it out, everything goes well.

My apache log gives me this error: Premature end of script headers ...mtview.php.

Is there a mistake in that line?

To understand this: I have installed the CMS in a very simple VHost on my server. I have a line for documentroot and for scriptAlias. Nothing more.

Thanks in advance
Markus

P.S.: I have also posted this in the Movable Support Forum, but without a answer, not even from the owner of the site.

jdMorgan

3:36 pm on Sep 10, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



> The "!" is wrong - yes?

It looks like the use of "!" (meaning NOT) is correct and consistent with the stated purpose in the comments, "if mod_rewrite is unavailable, we forward any missing page... "

However, make sure you have a space preceding this and any other "!" symbols in your code.

> If i enable this line i cannot access my /cgi-bin/. If i comment it out, everything goes well.

You may be having a problem with the "scope" of this code. That is, this code was not designed to work with cgi-bin or any other "extra" features on the server. You may have to modify the code to avoid rewriting to mtview for any cases where you don't want mtview to handle the request.

It might be as simple as adding a single RewriteCond to the rule:


RewriteCond %{REQUEST_FILENAME} !^/cgi-bin/
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /mtview.php [L,QSA]

However, this should not be necessary, since /cgi-bin exists and is a directory, and therefore, the first original RewriteCond should have prevented the rule from being invoked if the request was for /cgi-bin.

Because of this, I suspect that your /cgi-bin directory is aliased and that there is an error in the module loading order on your server that causes mod_rewrite to be processed before mod_alias. This would cause /cgi-bin to fail the test for "exists and is a directory" and therefore the rewriterule would be invoked. It is very common to have server load order misconfigured, and this causes the modules to execute in the wrong order. Added to that is the fact that modules are executed in the reverse order that they are loaded. And then there are hosting companies that add a service - like php - and they just "throw the module into the load list" without any thought as to what order it should go in. We get a lot of threads here at WebmasterWorld as a result.

Jim

Markus Klaffke

8:28 am on Sep 11, 2004 (gmt 0)

10+ Year Member



Thanks for your reply jdMorgan.

I have inserted

RewriteCond %{REQUEST_FILENAME}!^/cgi-bin/

in my VHost and now it works.

<IfModule!mod_rewrite.c>

I have also inserted the missing (!).

Yes, my /cgi-bin/ is aliased.


ScriptAlias /cgi-bin/ /var/www/user1/cgi-bin/
AddHandler cgi-script .cgi .pl

As for the load order: I am running Debian and my httpd.conf came with the Debian package and looks like this:


# LoadModule vhost_alias_module /usr/lib/apache/1.3/mod_vhost_alias.so
# LoadModule env_module /usr/lib/apache/1.3/mod_env.so
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
#LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule info_module /usr/lib/apache/1.3/mod_info.so
LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
# LoadModule asis_module /usr/lib/apache/1.3/mod_asis.so
# LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so
# LoadModule action_module /usr/lib/apache/1.3/mod_actions.so
# LoadModule speling_module /usr/lib/apache/1.3/mod_speling.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
# LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so
# LoadModule dbm_auth_module /usr/lib/apache/1.3/mod_auth_dbm.so
# LoadModule db_auth_module /usr/lib/apache/1.3/mod_auth_db.so
LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so

# LoadModule digest_module /usr/lib/apache/1.3/mod_digest.so
# LoadModule cern_meta_module /usr/lib/apache/1.3/mod_cern_meta.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule headers_module /usr/lib/apache/1.3/mod_headers.so
# LoadModule usertrack_module /usr/lib/apache/1.3/mod_usertrack.so
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
# LoadModule sys_auth_module /usr/lib/apache/1.3/mod_auth_sys.so
LoadModule dav_module /usr/lib/apache/1.3/libdav.so
LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so
# LoadModule put_module /usr/lib/apache/1.3/mod_put.so
LoadModule ssl_module /usr/lib/apache/1.3/mod_ssl.so
# LoadModule throttle_module /usr/lib/apache/1.3/mod_throttle.so
#LoadModule auth_ldap_module /usr/lib/apache/1.3/auth_ldap.so
#LoadModule ldap_auth_module /usr/lib/apache/1.3/mod_auth_ldap.so
# LoadModule allowdev_module /usr/lib/apache/1.3/mod_allowdev.so
# LoadModule eaccess_module /usr/lib/apache/1.3/mod_eaccess.so
LoadModule php4_module /usr/lib/apache/1.3/libphp4.so
# LoadModule roaming_module /usr/lib/apache/1.3/mod_roaming.so
LoadModule python_module /usr/lib/apache/1.3/mod_python.so
LoadModule gzip_module /usr/lib/apache/1.3/mod_gzip.so
#LoadModule jk_module /usr/lib/apache/1.3/mod_jk.so

The load order must be ok. I canīt see something wrong. Or can you see it?

Markus

jdMorgan

2:38 pm on Sep 11, 2004 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



From my reply above:

Added to that is the fact that modules are executed in the reverse order that they are loaded.

Notice that mod_alias is loaded before mod_rewrite, which means that mod_rewrite will execute first. So, as I stated, this could be the cause of your problem.

It also appears that several optional modules were added to the end of the load list without any regard for their interaction with the other modules. For example, if a file is declared as a php or python executable and exists, you won't be able to rewrite a request for it, because and pythion php execute first.

I'm not a server config expert, so I cannot tell you "the exact right order" to load your modules for any given situation. But at least this explains why you had the problem you saw. Maybe someone with a lot more experience with complex server configurations can contribute some useful comments here.

Jim