Can IIRF do this? (Rewrite based on existence of a file)

Topics: User Forum
Dec 2, 2009 at 1:23 AM

I'm trying to write rules to support the Drupal Boost module. Essentially the following:

On encountering

/page/intro?t=about

check if the file cache\normal\host\page\intro_t=about.html exists. If if it does, rewrite the URL to serve that static (cached) html file.

The cache directory should be under the document root, and the _ is a delimiter for the query_string.

 

Coordinator
Dec 2, 2009 at 4:42 PM

There's a way in IIRF to test for the existence of a filesystem file, and apply a rewrite (or redirect or...)  depending on the outcome of that test.

Look into the RewriteCond directive and use the -f  "special pattern".  http://cheeso.members.winisp.net/Iirf20Help/html/39dbb30e-2afd-4cb1-aaff-45497fe2cbe6.htm#Section3 

I don't know what you mean by "_ is a delimiter for the query_string" but I guess you'll figure it out. 

 

Dec 3, 2009 at 12:41 AM

Thanks for the reply!

I guess what I'm asking is how to do the translation from

/page/intro?t=about to something like c:\inetpub\wwwroot\content\host\page\intro_t=about.html

All my efforts so far has rendered something like

c:\inetpub\wwwroot\content\host/page/intro_t=about.html, which always fails the -f special pattern.

Coordinator
Dec 3, 2009 at 5:18 PM

If I were doing that, I would use something like this:

RewriteCond %{REQUEST_FILENAME}_$1   -f
RewriteRule ^/page/intro\?(.+)$             /page/intro_$1   [L]

What this does is ... applies the pattern ^/page/intro\?(.+)$ to the incoming request. The (.+) captures the query string that follows the question mark. (If there's no question mark, this rule doesn't apply). It then rewrites that incoming request to a new URL determined by appending the captured query string to /page/intro_ .

But, there is a RewriteCond that applies. It evaluates to true, only if the string given by %{REQUEST_FILENAME}_$1 is a file that exists in the filesystem. The $1 is a reference to the captured querystring in the rule. And REQUEST_FILENAME evaluates to the actual filesystem file associated to the incoming URL, which in this case is probably c:\inetpub\wwwroot\content\host\page\intro . So the concatenation there will probably result in something like c:\inetpub\wwwroot\content\host\page\intro_t=about .

I haven't tested this. If not this, then something similar. Check your IIRF log file for the incoming requests to get some better visibility into what's going on. (During testing you will want IIRF Log level to be 4 or higher.)

Dec 3, 2009 at 5:46 PM

Hi, I got it working a couple hours back, but your solution seems more elegant.

I'm not sure if %{REQUEST_FILENAME} would work as I forgot to mention that the cached file is actually in

c:\inetpub\wwwroot\content\host\cache\normal\servername\page\intro_.html

Right now I'm doing something like:

RewriteCond c:/inetpub/wwwroot/content/host/cache/normal/%{SERVER_NAME}%{URL}_%{QUERY_STRING}.html -f

RewriteRule .* /cache/normal/%{SERVER_NAME}%{URL}_%{QUERY_STRING}.html [I,L]

I've listed /page/intro as an example, but in practice this could be any URL. There are other rules to prevent the ones that matter from being cached.

Due to the way Drupal (and Drupal Clean URLs) work, /page/intro is almost guaranteed not to exist as a physical file, and has to be mapped into /index.php?q=page/intro.

The above caching rule works by checking if the intro_.html file already exists in the appropriate directory, and therefore bypasses index.php completely (thereby bypassing the PHP subsystem and saving time). If it does not exist, index.php?q=page/intro is loaded as usual, and the caching subsystem automatically creates the intro_.html, so that future accesses will hit the cache instead. I attempted to use -s instead of -f, but it keeps failing on IIRF 1.2.15R3.

Thanks for the help! I'm sure anyone out there attempting to use IIRF with Drupal and Boost would appreciate it!

 

Coordinator
Dec 3, 2009 at 7:17 PM

Glad you got it working!

Thanks for posting your solution - it will be helpful for other people.

I will look into the -s issue you mentioned. 

 

 

 

Coordinator
Dec 3, 2009 at 7:18 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Dec 5, 2009 at 12:32 PM

kint, thanks for notifying me of that -s problem.

That was due to a basic bug in the filter. It's been fixed now.  You need IIRF v2.1 to get the fix.

 

Dec 6, 2009 at 3:00 PM

My pleasure.