Quick Mod Rewrite question

"if image not found" ...

[zoltan]

My problem should be simple for somebody with experience:
I have

http://server01.example.com/images/12345/a.jpg
http://server01.example.com/images/12345/b.jpg
http://server01.example.com/images/12346/a.jpg
etc.

Now, if the image exists, simply serve the image as it is, if not then rewrite it to something like:
http://server02.example.com/images/12345/a.jpg

So, basically, the image is on server02 if it is not on server01.

How do I do this?

Thanks in advance for your help!

[edited by: jdMorgan at 4:41 pm (utc) on Sep. 17, 2008]
[edit reason] example.com [/edit]

[jdMorgan]

This is highly-inefficient, since every image will have to be checked, calling the operating system to go to disk and look for it.

But basically, use a RewriteCond to check REQUEST_FILENAME and act on the "!-f" token which means, "does not exist as a file." The RewriteRule pattern should be as specific as possible, so that only image filetype URLs are matched. If possible to restrict them to a certain directory path, then include that in the pattern as well. This will prevent unnecessary OS filesystem calls.

Jim

[edited by: jdMorgan at 4:40 pm (utc) on Sep. 17, 2008]

[zoltan]

Thanks Jim. Can you give me an example?

All the images are stored on one server (server02) and rsynced to server01 once an hour. But images are changing and new images are added every hour by members so if I want to serve the images from server01 they will not be available until the new ones are already rsynced.

So, basically, images are stored on one server and I want to rsync them to another server and serve them from there without too many errors. What other options do I have?

[jdMorgan]

Many examples already posted in threads here -- The file exists check is part of every WordPress install out there, and so appears in dozens of threads here.

As explained in our charter, we discuss Apache stuff here, and we can help you debug your code, but this forum, with the few contributors that it has, cannot serve as a "free code-writing service" -- There are simply not enough people to post answers here to support that kind of "second full-time job." :(

Jim

[zoltan]

Thank you. Would that work?

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(/.*) http://server02.example.com%{REQUEST_URI} [L]

[edited by: jdMorgan at 10:37 pm (utc) on Sep. 17, 2008]
[edit reason] example.com [/edit]

[jdMorgan]

This would be much more efficient:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+\.(gif¦jp[eg]¦jpeg¦png))$ http://server02.example.com/$1 [R=302,L]

That is coded for use in .htaccess. For use in httpd.conf, add a slash to the beginning of the RewriteRule pattern, so it starts with "^/". Also, replace the broken pipe "¦" characters in that pattern with solid pipe characters before use; Posting on this forum modifies the pipe characters.

Jim

[g1smd]

It's a start, but (.*) should not have a / in it, and needs to be more specific. It needs to check that the request was for an image, not for an HTML file or robots.txt or anything else that isn't an image, as jd just explained.

Ooops. that's what happens when you leave a tab open for two hours before replying.

[zoltan]

Thanks. Will try them. :)

[zoltan]

Just a quick update. I resolved the issue with a 404 error page going to a redirect.php file. Thanks for all your contributions.

[jdMorgan]

That's a potentially-bad solution, if you mean that literally... *If* you care about image search, be aware that robots will see only the 404 response, and dump that image.

Using a 404 page as a basis for redirection is a very old 'trick' that came into use before "mere users" were allowed to use mod_rewrite and other Apache modules on inexpensive/free servers. It was used, for example, on GeoCities back in the mid-90's. Since it was the *only* way to accomplish the goal, it was used.

But of course, no-one paid much attention to search engines back in those days; They were just on the rise, and most people used directories and bookmarks.

I can't say what other problems you might run into. But do be aware that returning a 404 followed by a redirect is a functional violation of the HTTP protocol. So be warned...

Jim

[zoltan]

Thanks Jim. I will try another solution.

[jdMorgan]

You've never said if there was a problem with the code posted above. That is what you need, and it should work, assuming you've given us the correct URL-paths and server filepaths, that mod_rewrite is installed and working on your server, and that you heeded the warning about replacing the broken pipe characters in the code...

What happened when you tried that code?

Jim

[zoltan]

I had one problem with it, this is why I came up with this one. Let me try it one more time and will get back to you.

[zoltan]

OK, found what I was doing wrong, it is working now. Is this safe for bots?

[jdMorgan]

Yes, it should be: The 302 redirect says, "That image is not here at the URL you requested. Try again at this alternate URL. But keep the current URL, because this alternate URL is temporary."

That's what you want, because the image will be present at the current URL as soon as your servers "re-sync."

Jim

[zoltan]

You are absolutely right.
Just FYI, this was the PHP code I used on redirect.php:

<?php
header('HTTP/1.1 302 Found');
header('Location: [server02.example.com'.$_SERVER['REQUEST_URI'])...]
?>

[jdMorgan]

Yes, the problem is not the response code served by the redirect.php page, the problem is *how* you get to the redirect.php page. If you use ErrorDocument 404 /redirect.php to get there, then the server detects the missing image, sends a 404 response to the client, and uses the contents of /redirectpage.php as the page-body for that response. So, the 404 response is immediately followed by the 302-redirect, but there is still that 404 response... Which is not good.

Using mod_rewrite to test for file-exists and immediately sending a 302 redirect, or using mod_rewrite to detect the missing image and *internally rewrite* the request to /redirect.php (which then sends the 302 response) are acceptable solutions which both avoid the 404 response.

Jim

[edited by: jdMorgan at 8:00 pm (utc) on Sep. 20, 2008]