while trying out AliasMatch I found a curious behaviour of it.
Let's say you have rules like this in the httpd.conf:
AliasMatch "/goinfinite/" "C:/test/"
<Directory "C:/test">
Require all granted
</Directory>
The directory contains an index.php. However, said php file is not used as directory index. Instead, a 301 redirect is created to http://localhost/goinfinite/index.php/. From that page a redirect is created to http://localhost/goinfinite/index.php/index.php/ and so on.
My goal was to just forward any URL that contains /goinfinite in its path to C:/test and use its index.php file, however I created an infinity loop of 301 redirects. I am unsure what causes these explicit redirects which then trigger the AliasMatch rule again.
I have read the Apache documentation. This is what would be needed for AliasMatch to work like Alias:
AliasMatch "^/image/(.*)$" "/ftp/pub/image/$1"
In my case, I could do something like
AliasMatch "/goinfinite/(.*)" "C:/test/$1"
However, if the path is simply /goinfinite/ $1 would not contain anything. So why would it work in this case?
My question is an academic one, I would like to understand why the directory index is not used, but a redirect triggered instead.
Related
I'm going mad over Apache .htaccess
I'm trying to setting as protected my subfolders using relative address, but it seems impossible.
The path of Apache folder is structured like this:
/var/www/apachedir
now I want to protect
/var/www/apachedir/subfolder/*
What I tryied is putting in /var/www/apachedir/ an .htaccess file like this
<FilesMatch "subfolder\/.*">
Order Allow,Deny
Deny from all
</FilesMatch>
but it seems not woking good.
I don't want to use ModRewrite and I want to make this .htaccess reusable.
So, listen, if I put the site over an other server that has a direcory structure like /var/www/zzz it has to protect files in /var/www/zzz/subfolder/*.
Also the file .htaccess has to stay in the root folder /var/www/apachedir.
There's a way to do it?
Edit:
I don't want to use ModRewrite but also I don't want to use Redirectmatch.
I want to know if there's a way to set it up with FilesMatch without ModRewrite or Redirectmatch.
I don't want to use ModRewrite.
You can use RedirectMatch to block access to a known path:
Redirectmatch 403 ^/subfolder/
I want to know if there's a way to set it up with FilesMatch
No, because the FilesMatch (and the non-regex Files) directive(s) literally match against files only, not directories. eg. <Files "*.jpg"> matches all .jpg files in any subdirectory.
There are various methods to block access to that subdirectory...
Use a <Directory> section in the server config
If you have access to the server (virtual host) config then you can use the <Directory> (and <DirectoryMatch>) directive(s) to target specific directories. But this is not permitted in .htaccess. For example:
<Directory "/var/www/apachedir/subfolder">
Require all denied
</Directory>
Create an additional .htaccess file in that subdirectory
The equivalent userland .htaccess way of doing this is to create an additional .htaccess file in that subdirectory (ie. at /subfolder/.htaccess) with a single Require all denied directive. The .htaccess file itself is equivalent to the <Directory> directive in the server config.
Aside: Order, Deny and Allow are Apache 2.2 directives and formerly deprecated on Apache 2.4 (which you are far more likely to be using). You should be using the equivalent Require (mod_authz_core) directives instead, as used above.
Use Redirect 403 (mod_alias) - not a "redirect"
I don't want to use ModRewrite but also I don't want to use Redirectmatch
RedirectMatch (and Redirect) are part of mod_alias - this is a base module and compiled into Apache by default (unlike mod_rewrite), so using the prefix-matching Redirect directive (no need for the regex variant RedirectMatch) is a reasonable solution as #anubhava suggests in his answer, depending on the scenario and existing directives. For example:
Redirect 403 /subfolder/
Despite the use of the Redirect directive, this is not an external (HTTP) redirect. The 403 response is served via an internal subrequest.
Set an environment variable and check with mod_authz_....
Alternatively, you can set an environment variable when the /subfolder is requested (using SetEnvIf) and check for this using the Require directive. This allows you to keep the condition separate from the directives that actually permit access. For example (using Apache 2.4 mod_authz_core):
SetEnvIf Request_URI "^/subfolder/" BLOCK_ACCESS
<RequireAll>
Require all granted
Require not env BLOCK_ACCESS
</RequireAll>
NB: If you are doing any URL-rewriting with mod_rewrite then you might need to check for REDIRECT_BLOCK_ACCESS instead in the above Require directive.
<If> expression (Apache 2.4)
On Apache 2.4 you can also use an <If> expression to target that specific subfolder with a containing mod_authz_core directive. For example:
<If "%{REQUEST_URI} =~ m#^/subfolder/#">
Require all denied
</If>
Although, strictly speaking, these methods target the URL-path, not the file-path.
Been trying to play with mod_rewrite through .htaccess in one Xampp virtualhost, but I am not getting the results that I am looking for.
What I am tring to do is to rewrite the following: www.example.com/name/billy.html to: www.example.com/billy
Without trying to rewrite the URLs the virtualhost is working fine, I have access to all pages. However, when I add the .htaccess with the corresponding rewrite rule I get a 404 page not found. The regex is working as expected though. I see that the request to www.example.com/name/billy.html it's been rewritten to www.example.com/billy, but the page doesn't load.
The name folder exists in the file structure and the .htaccess is inside the example folder.
Currently, my vh configuration looks like this:
<VirtualHost *:80>
DocumentRoot "/Applications/XAMPP/xamppfiles/htdocs/example"
ServerName www.example.com
<Directory "/Applications/XAMPP/xamppfiles/htdocs/example">
Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
And this is the content of the .htaccess file:
RewriteEngine On
RewriteRule ^name\/([a-z]+).html$ /$1 [L,NC,R]
What is missing?
What I am tring to do is to rewrite the following: www.example.com/name/billy.html to: www.example.com/billy
You seem to have the process the wrong way round and possibly mixing up "rewrites" and "redirects"?
You should be internally rewriting from the visible "friendly" URL to the underlying file-path that actually handles the request. You are trying to do the opposite here. How is your system expected to handle a request for /billy? (It doesn't, and generates a 404.)
You may be thinking you can change the URL using .htaccess (mod_rewrite) alone? But no, that is not how this works.
RewriteRule ^name\/([a-z]+).html$ /$1 [L,NC,R]
You mention "rewrite", but this directive is in fact a "redirect" (as indicated by the R flag). Specifically, a 302 (temporary) redirect in this instance.
(You might actually want to implement a redirect like this, if you are changing an existing URL structure, but more on that later*1)
A URL "rewrite" is entirely internal to the server. The user only sees the public URL, they do not see the URL that it might be rewritten to. You (the user) can't "see" a rewrite.
A "redirect" on the other hand, usually refers to an external redirect, ie. a 3xx response sent back to the client with an instruction to make a new request to a different URL. The URL being redirected to is visible to the user. This is used when content has moved to a different URL.
So, following your example, you should be requesting/linking to (in your HTML source) the short/friendly URL /billy and internally rewriting the request to /name/billy.html that actually handles the request.
For example:
RewriteEngine On
# Rewrite from "billy" to "name/billy.html"
RewriteRule ^[a-z]+$ name/$0.html [NC,L]
The $0 backreference contains the entire URL-path that is matched by the RewriteRule pattern.
Only use the NC flag if you do need to match uppercase letters as well. But a request for /Billy won't serve /name/billy.html on a case-sensitive OS.
And that's really it, with regards to the URL-rewritting, you can stop reading here.
*1 Redirect from old to new
Regarding the external "redirect" mentioned above. You might choose to implement a redirect (in the opposite direction) if you are changing an existing URL structure and the old URLs have been indexed by search engines and/or linked (or bookmarked) to by external third parties - in order to preserve SEO and keep users happy.
For example, say your original URLs were of the form /name/billy.html and you later decided to change your URLs to /billy instead. You first change the URLs in the HTML source and implement the "rewrite" as mentioned above so the new URLs now work. You then might implement an external redirect from the old /name/billy.html URL to the new /billy URL.
For this, you would use a directive like you had initially, except you have to be careful of redirect-loops because you are already rewriting the request in the opposite directive. You only want to redirect "direct/initial" requests and not rewritten requests by the earlier rewrite (that is actually later in the file). An easy way to check for "direct" requests is to check against the REDIRECT_STATUS environment variable, which is empty on the initial request and set to 200 (as in 200 OK status) when the request is rewritten.
For example, the following "redirect" would go before the above "rewrite", immediately after the RewriteEngine directive:
# Redirect from "name/billy.html" to "/billy"
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^name/([a-z]+)\.html$ /$1 [R=301,NC,L]
This should ultimately be a 301 (permanent) redirect since the URL has presumably changed permanently. However, always test with 302 (temporary) redirects to avoid potential caching issues.
Further reading:
Reference: mod_rewrite, URL rewriting and "pretty links" explained
I want exampleapp.com/clientapp/ to execute the index.php in /usr/local/apache/htdocs/clientapp.
This stackoverflow question outlines something similar to what I want to do: https://stackoverflow.com/a/8454/173630
I'm having some trouble getting this working. Here's the start of my VirtualHost setup:
<VirtualHost exampleapp.com:80>
DocumentRoot /home/platform/src/serverapp/public
RewriteEngine On
Alias /clientapp/ "/usr/local/apache/htdocs/clientapp"
<Directory "/usr/local/apache/htdocs/clientapp">
FallbackResource index.php
<IfModule mod_suphp.c>
suPHP_UserGroup nobody nobody
</IfModule>
</Directory>
RewriteRule ^/clientapp/(.*)$ /clientapp/$1 [PT]
I'm using Apache 2.2.22. I know this is kind of a confusing setup -- the reason I'm doing this is to avoid cross-domain AJAX requests from clientapp to serverapp.
With this configuration I'm not getting any errors, it's just falling through to the server app.
Update
The problem was that I had a BasicAuth set up on /usr/local/apache/htdocs/clientapp, and the password wasn't being prompted for when visiting exampleapp.com/clientapp/ and it was just silently failing. I took off the BasicAuth for now, which gets it to work.
After trying a few things out, it looks like this is just mod_alias being retarded and either blindly mashing together file-path and URI-path or mistaking the file-path (/usr/local/apache/htdocs/clientapp) for a URI-path (not sure how). Either way, you can do one of two things, it looks like.
Add a trailing slash to your file-path:
Alias /clientapp/ "/usr/local/apache/htdocs/clientapp/"
Remove the trailing slash from your URI-path:
Alias /clientapp "/usr/local/apache/htdocs/clientapp"
Both seems to do the trick, but I would suggest doing the second option, as it would match requests for exampleapp.com/clientapp (no trailing slash), and mod_dir will properly recognize it as a directory and redirect you to exampleapp.com/clientapp/. Whereas if you go with first option, going to exampleapp.com/clientapp would just give you a 404 (or something in the document root ends up handling it).
Change <Directory ...>...</Directory> to <Location /clientapp>...</Location> and keep everything inside it.
I had mod_rewrite set on my server to rewrite a url like the following
http://www.example.com/1
to
http://www.example.com/index.php?show=1
In order words a URL shortern. Everything was working fine when the system was running under a sub-domain on my development site, but now it just generates a Not Found error, although if I manually enter the url /index.php?show=1 it works fine.
So the only changes is the urls switching from
http://www.site.example.com
to
http://www.site.com
however it's still running on the same server and the same sub-folder inside public_html on the server just the new domain name has been pointed to that folder.
The folder it's stored in is /public_html/paste
The full .htaccess file running in the directory is
# Set Default File
DirectoryIndex index.php
# Turn ReWrite Engine On
RewriteEngine on
# Create Rule To Write URLs To Shorter Versions
RewriteRule /([a-z0-9]+) /index.php?show=$1
I can't enable RewriteLog as the hosting doesn't allow it for some reason.
It sounds like the AllowOverride directive is not properly set for that folder. In your Apache configuration, you should make sure that the Directory or Vhost you're using for the primary domain has the AllowOverride set to All
http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride
You probably need to specify the RewriteBase directive.
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase
I'll also note that Options +FollowSymlinks would be good to have in there too in case you ever turn it off further up the config chain (rewrite wont work without it).
My sites root access is managed by htaccess: it redirects various aliases to their own home files /en/home for english /de/home for Deutsch etcettera. Previously, I used index.php to route and redirect all that, and hence the DirectoryIndex had something like this:
DirectoryIndex /index.php
Now, however, there is no index.php file, so I commented it
# DirectoryIndex /index.php
Would it be better to uncomment is and set it to the default /en/home (with or without .php because in this case? I have set up rules sohat my pages in browser also work when no extension is given)
DirectoryIndex /en/home
In all the above cases, my websites work fine and I don't see ANY change when I set either of the three instances as above. but ... "there's gotta be one best ain't it?"
Thanks!
If you have the rules written in .htaccess it is best not to repeat the rules in whatever php config and routing functions you are using. Routing through apache (your .htaccess) is much faster than subverting routes through php, though you will not realize the gains without a pretty high volume of traffic.