Ive got a image cache system that im using to generate certain image sizes as require. Im using modrewrite to check for the file and call the image creation system if it doesnt exist. The problem im having is that it is calling the image creation system even if the image does exist!
The modrewrite is simple enough (sites in the images sub directory)
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /images/index.php?id=$1 [L,QSA]
I even tried removing the -d incase the directory check was confusing it. Ive now got it so that it checks the file exists inside the index.php code - which reports that it does.
I use the url images/cache/140x20/Test.JPG in the html - the file exists, so the RewriteCond should not call the index.php code - but it does for some reason?
Im sure its something obvious but i just cant figure it out
the .htaccess is in the images directory. Using R=302 i get the correct path expected www.domain.com/images/index.php?id=cache/140x20/Test.JPG
That's weird. I was testing under a subdirectory and was getting some unexpected values for %{REQUEST_FILENAME}. But I was able to get the check to work correctly by reconstructing from the document root. Maybe my understanding of %{REQUEST_FILENAME} or the underlying mechanism apache uses to make URI-path to file-path is different than what I expected.
Try:
RewriteCond %{DOCUMENT_ROOT}${REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}${REQUEST_URI} !-d
# and maybe for good measure
RewriteCond %{REQUEST_URI} !index.php
EDIT:
If your extensions are in all caps but the image filename extensions are always all lowercase, you can use a RewriteMap and define a map using the tolower function:
(somewhere in your server or vhost config:
RewriteMap lowercase int:tolower
Then in your htaccess file (above your other rules), change the filenames to lowercase:
# first check to make sure request doesn't already have all lowercase image extension
RewriteCond %{REQUEST_URI} !\.(jpe?g|png|bmp|gif)$
RewriteRule ^(.*)\.(jpe?g|png|bmp|gif)$ /$1.${lowercase:$2} [NC,L]
You can also do something similar with the entire filename, or the entire path.
Related
Context
I'm using mod_rewrite to make my links better for SEO. I made the following rule for my page expanded_debate.php:
Options -MultiViews
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^poll/([0-9a-zA-Z_-]+)/([0-9]+) expanded_debate.php?poll_title=$1&pollid=$2 [NC,QSA,L]
When I input this format in the URL (poll/filename/10, for example) I get a 404 error:
Object not found!
The requested URL was not found on this server. If you entered the URL manually please check your spelling and try again.
If you think this is a server error, please contact the webmaster.
Error 404
localhost
Apache/2.4.46 (Unix) OpenSSL/1.1.1h PHP/7.4.12 mod_perl/2.0.11 Perl/v5.32.0
However, when I change the first folder name to certain words, such as "debate" and "expanded_debate" (but not "expandedebate"), the file loads after page refresh. For example:
RewriteRule ^debate/([0-9a-zA-Z_-]+)/([0-9]+) expanded_debate.php?poll_title=$1&pollid=$2 [NC,QSA,L]
works fine.
I have an older .htaccess file, titled ".htaccess11", with the following info, in case it's of any use:
#forbids users from going to forbidden pages
IndexIgnore *
Options -Indexes
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
#404 error directions
ErrorDocument 404 /404.php
Question
Any idea why only certain terms in the first folder position ("^debate" in example above) work when using mod_rewrite?
There are no "poll" folders in my project, if that's of any interest.
Let me know if there are any questions.
The line
RewriteCond %{REQUEST_FILENAME}\.php -f
Means "Take the requested URL, map it to a full local path in the normal way, append .php to the resulting path, and then process the following rewrite rule only if there is an existing regular file at the modified path".
For example, the URL "poll/filename/10" will be rewritten only if there is a file called "poll/filename/10.php" in the relevant location.
Since the value of the AcceptPathInfo directive is evidently set to On, this condition will also be met if there is an existing file called "poll.php" or "poll/filename.php". That is why the rewrite rule works when you change "poll" to "debate" or "expanded_debate" – there are existing files called "debate.php" and "expanded_debate.php".
In any case, it sounds like this behavior is not what was intended. Removing the -f condition should give the desired result. Or, to prevent the rewrite rule from making existing files inaccessible, you could replace it with:
RewriteCond %{REQUEST_FILENAME} !-f
The exclamation point negates the -f test: "continue only if this file does not exist"
If you are using the %{REQUEST_FILENAME} server variable (anywhere), you should be aware of how the AcceptPathInfo directive will affect this, and consider setting that directive explicitly in the same .htaccess file.
If Options +MultiViews is in effect, then %{REQUEST_FILENAME} will match existing files whether or not the extension is included in the request (GET /foo will match an existing file "foo.php", "foo.html", etc.). And GET /foo.php will match in any case. So, omit the string "\.php" from the original rule.
Other configuration may also have an effect, too. The important point is that, unlike %{REQUEST_URI}, %{REQUEST_FILENAME} invokes all the processing that Apache would otherwise do to translate a URL into a local path.
(source)
NB: although I don't think it was the intention here, you actually might want to test for the existence of a local file as part of this rule. You could use a RewriteCond to check whether the back-end data file for a given poll has been manually created, and return 404 by default if it has not. That would be a simple way to prevent users from making up their own poll URLs at will.
This is my .htaccess
RewriteEngine On
# browser requests PHP
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /([^\ ]+)\.php
RewriteRule ^/?(.*)\.php$ /$1 [L,R=301]
# check to see if the request is for a PHP file:
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^/?(.*)$ /$1.php
RewriteCond %{REQUEST_URI} !^/(views|css|js|media|partials|php)
RewriteRule (.*) /views/$1
This is my project structure:
The idea is that all my HTML files are structured in the folder views, but I don't want my URL to be http://example.com/views/index but just http://example.com/index without the views-part.
This is working fine in the following case:
http://example.com/account/
But fails as soon as I try to access a file in the accounts-folder e.g: http://example.com/account/voeg-kind-toe
That results in a 404. Seems like this .htaccess solution only works for one-level directories.
Edit:
Interesting: If I place the bottom two lines on top (so placing the code to rewrite the view-part before the code to remove the php-extension); the php-extension works but the /views//part don't.
Create .htaccess like this
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteCond %{REQUEST_URI} !^/views/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /views/$1
RewriteCond %{HTTP_HOST} ^(www.)?example.com$
RewriteRule ^(/)?$ views/ [L]
As mentioned in my comment above, providing there are no other directives/conflicts then this should still "work" in a roundabout way. However, there is an issue with the following directive in the order you have placed it:
# check to see if the request is for a PHP file:
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^/?(.*)$ /$1.php
You aren't testing for files in the /views subdirectory. But also, REQUEST_FILENAME does not necessarily contain what (I think) you think it does. When you request /account/voeg-kind-toe (an entirely virtual URL path) then REQUEST_FILENAME contains /account (it actually contains an absolute filesystem path, but I've kept it brief). So, the above is testing whether /account.php exists, not /account/voeg-kind-toe.php, or even /views/account/voeg-kind-toe.php - which is presumably the intention.
So, on the first pass, the above condition fails, no rewrite occurs, and processing continues...
The second rule then rewrites the request for /account/voeg-kind-toe to /views/account/voeg-kind-toe. Providing there are no further mod_rewrite directives, the rewrite engine then starts over. This time, /views/account/voeg-kind-toe is the input.
On the second pass, REQUEST_FILENAME is /views/account/voeg-kind-toe (since /views/account is a physical directory) and the request is rewritten to /views/account/voeg-kind-toe.php (since the filesystem check should be successful). Providing you have no other directives then processing should now stop.
This is working fine in the following case: http://example.com/account/
/account/ is simply rewritten to /views/account/ by the last rule.
Edit: Interesting: If I place the bottom two lines on top (so placing the code to rewrite the view-part before the code to remove the php-extension); the php-extension works but the /views//part don't.
The same process as above occurs, EXCEPT this all occurs in a single pass and so is less dependent on other directives that might occur later in the file.
I'm not sure what you mean by "the /views//part don't"?
Assuming you only have .php files within the /views directory and all URLs are intended to target the /views subdirectory and you don't need to reference directories directly then you could do this is a single directive and rewrite everything that does not contain (what looks like) a file extension to /views/<whatever>.php.
For example:
RewriteRule !\.\w{2,4}$ /views%{REQUEST_URI}.php [L]
The L (last) flag is required if you have other mod_rewrite directives that follow - to prevent additional processing.
This does mean you can't rely on the directory index. ie. You need to request /index (as in your example), not simply / to serve /views/index.php.
(You still need your first rule that removes .php from the requested URL - although this is only strictly necessary if you are changing an existing URL structure, where you previously used .php on the URLs.)
I'm trying to figure out how to manage potentially conflicting conditions in .htaccess
My setup is the following:
- I have a CMS running on a server that can be accessed through myCMSdomain.com where myCMSdomain.com would be CMS home page and myCMSdomain.com/admin would be the admin interface.
- Sites using this CMS should be pointing to myCMSdomain.com/sites/index.php
- Images for all sites are available somewhere behind myCMSdomain.com/admin/images/sitename/...
So here is how I tried to tackle this problem:
RewriteCond %{HTTP_HOST} !^(www.)?myCMSdomain.com$ [NC]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . sites/index.php
With this, all incoming requests coming from other domain names are treated correctly by the index.php file but as images are hosted somewhere else, I'd like to use a rule saying that images should be fetched somewhere else like this:
Visible url format for images is: images-[sitename]/[image_path]
Real location of the images is: admin/site/[sitename]/[image_path]
The following rule works but not in combination with the first rule
RewriteRule images-([a-zA-Z0-9]+)/(.*)$ admin/site/$1/images/$2
Images end up calling index.php instead of using the rule I defined for them.
I have tried to excluse the image directory from the conditions but it doesn't work either:
RewriteCond %{REQUEST_URI} !(images-([a-zA-Z0-9]+)/(.*))
I might have similar issues in the future with other exception so I was wondering if there was a way to handle this.
Thanks!
Laurent
UPDATE 1:
If I use the following rule on top of all other
it works only if I'm using myCMSdomain.com domain name
if I use any other domain like anotherdomain.com, the rule leads to a http 500
RewriteRule images-([a-zA-Z0-9]+)/(.*)$ manager/site/$1/images/$2
So http://www.myCMSdomain.com/images-test/test.jpg leads me to the correct image
But http://www.anotherdomain.com/images-test/test.jpg leads me to a 500 http error code while this domain is pointing correctly to sites/index.php
UPDATE 2:
On Justin's request, here is a view on the physical directory structure on the server
/admin/
/admin/site
/admin/site/site_name/
/admin/site/site_name/images/
/sites/
/sites/js
/sites/css
You can rearrange your conditions logic.
# if www.myCMSdomain.com or myCMSdomain.com -> do nothing
RewriteCond %{HTTP_HOST} ^(?:www\.)?myCMSdomain\.com$ [NC]
RewriteRule ^ - [L]
# if we reach here, this means it's a subdomain/another domain
# images rule
RewriteRule ^images-([^/]+)/(.+)$ /admin/site/$1/images/$2 [L]
# not a file/directory -> sites/index.php
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /sites/index.php [L]
It is also possible the way you did but it would be longer to write.
Also, keep in mind that conditions (RewriteCond) are non-cumulative: they are for next rule (RewriteRule) only.
I've been struggling with this issue for some time now but at last I think I have found the issue. It looks like there was something wrong in the domain name configuration, I don't know exactly what but once I had re-saved the mapping of all domains, the htaccess worked the way it should.
In the end I have used Justin's proposition, it looks more future proof than mine.
Thanks for your help and happy new year to all
Laurent
I have an .htaccess file that I'm using to catch when a requested image doesn't exist so I can make one. The file properly detects a missing image when requested from the directory the .htaccess file is in. But, if I request an image from a subdirectory that technically does not exist, .htaccess does not send me to my image handler. Can someone help me match any subdirectory that does not exist?
Here is my htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} .(jpg|jpeg|gif)$
RewriteRule ^(.*)$ missingimage.php?img=$1 [QSA,L]
That .htaccess file is placed in a folder called "uploads". So for example, my uploads folder also has oranges.jpg.
The following url will correctly pass the request to missingimage.php:
http://localhost/uploads/oranges_asdf.jpg
The following url will NOT correctly pass the request to missingimage.php, but instead returns a standard 404 from apache:
http://localhost/uploads/not_a_real_directory/oranges.jpg
How can I modify my htaccess to catch requests to directories that don't exist and still pass them to my image handler? Thank you.
REQUEST_FILENAME doesn't actually contain the full absolutely path if the request doesn't exist. My theory on this without actually digging into httpd core code would be that it's thinking we've come far enough to know that the request isn't actually there so let's stop looking.
i.e. if you request /uploads/fake/test.jpg it'll REQUEST_FILENAME contains /path/to/uploads/fake and won't actually continue to append /test.jpg on there, but does when you do /path/to/uploads/test.jpg because test.jpg is the termination of where it knows the request doesn't exist. Even if this isn't the reason why httpd stops the string there you have plenty of other variables that can help you.
This rewrite condition:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
is ridiculously popular right now for this trick of creating a dispatcher for MVC frameworks and does actually work, since /path/to/uplaods/fake is niether a file nor a directory and will send your request to your image dispatcher.
Here's the real fix for your extension matching condition... you need to get the REQUEST_URI because it will contain what the user actually requested (/uploads/fake/test.jpg) including the file extension and you can us it in your third RewriteCond to match the file extension. Since we're going to use that for the third rule, I cleaned up your first two to match.
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteCond %{REQUEST_URI} ^[A-Za-z0-9\/_-]+\/[A-Za-z0-9_-]+\.(jpg|jpeg|gif)$
RewriteRule ^(.*)$ missingimage.php?img=$1 [QSA,L]
I cleaned up your match on the file name as you were matching all sorts of bullshit with that leading period which is actually (when un-escaped) telling the preg match engine to match anything. So, backslash period will make preg match an actually period.
I also cleaned up the match on the first half to the request uri to include /alpha/num/directories_with/underscores-and-dashes/followed/by/alpha-num_filenames.jpg|jpeg|gif, feel free to remove that if you don't want it.
I have a little problem with my apache2 and .htaccess rules.
for example:
I have a shortened uri like
www.domain.tld/sitemap
which has to be rewritten by a rewriterule, redirected in a php File to display the sitemap.
The problem is, that in the root folder a file named sitemap.xml exists.
My apache automatically calls the sitemap.xml file but i don`t want that.
The file should be only called when uri is
www.domain.tld/sitemap.xml
is there a possibility to avoid the call of this file when the shortened URI is called?
this is just an example. There are some files that are required to be in the root folder and can`t moved from there into a subfolder (which would be the easiest way to fix this problem, but its not possible in my situation). it is required that these files are callable by uri.
Has anyone an idea how to fix this problem?
my current .htaccess file
RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php?urlseg=%1&%{QUERY_STRING} [NC,L]
Thanks a lot!
You likely have MultiViews enabled, which auto-resolves your non-existent resource /sitemap to the existent resource /sitemap.xml. Especially in cases where you're using mod_rewrite, I really see no need for MultiViews, so you can turn it off by adding this to the top of your .htaccess file:
Options -MultiViews
Doing so should hopefully prevent this from happening.