I downloaded a website, all files are coded in HTML and files do not have any extension.
My root domain is WordPress based.
I want to open all files as HTML using .htaccess - the files are in a subdomain.
I have tried this, think its for root domain only... I need help for subdomain.
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.+)$ /$1.php [L,QSA]
Your question is a bit vague as you've not given any examples of the URLs and file structure involved. However, if the HTML files do not have file extensions then it's quite probable that the Content-Type HTTP response header being sent from the server is either wrong or entirely absent (and reliant on the browser "content sniffing" - which is going to get mixed results).
We need to make some assumptions:
All the HTML files (that do not have file extensions) do not contain a dot anywhere in the file path.
The CSS and JS files do have appropriate file extensions ie. .css and .js, and are already returning the correct mime-type (Content-Type header).
If these too don't have file extensions, then they would need to be contained in specific directories so we can set the appropriate mime-type accordingly. We would also need to create exceptions with our rules in order to avoid conflicts.
So, in order to get the browser to interpret these files as HTML we need to make sure that we are sending the correct mime-type (ie. text/html) in the Content-Type response header. (I assume this is not the case currently.)
For example, using mod_rewrite in the .htaccess file in your subdomain (which I assume is separate from your main domain):
RewriteEngine On
RewriteRule ^([^.]+)?$ - [T=text/html]
However, as noted above, if your static resources (JS, CSS, images, etc.) are also devoid of file extensions then we'll need to add conditions to the above rule and create additional rules for the different file/mime types.
Aside:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.+)$ /$1.php [L,QSA]
These directives that you posted in the question don't appear to have anything to do with your question, which has only added to the confusion in comments.
Related
After entering the code below, my home page gives a 403 error. The rest of the site works perfectly. All instances of .html were removed.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.html [NC,L]
Any advice?
Thank you!
example.com leads ti the 403 error. If I write example.com/index it works fine.
Something else must have changed for this to result in a 403 error. The code you posted won't actually do anything when you request example.com/ - the same as if that code didn't exist at all. (UPDATE: However, this assumes your .htaccess file is located in the document - it appears this is not the case - see below.)
However, what will trigger a 403 in such cases is when "formatted directory listings" are disabled and the directory index document cannot be found (or has been disabled).
So, try setting the appropriate directory index at the top of your .htaccess file:
DirectoryIndex index.html
It is the DirectoryIndex that serves the appropriate file when requesting your "home page", not your directives in .htaccess.
UPDATE:
It [.htaccess] is located in my root directory. Would it be better to put it in the public_html folder?
Yes, the code you posted should go in the /public_html directory (ie. your document root). If these directives are in a .htaccess file above the document root then the RewriteRule pattern will match the URL-path public_html/ and rewrite the URL to public_html/.html which is possibly where your 403 error is coming from ("dot" files are usually hidden/protected OS files and you may also have a directive in your server config blocking access. However, this behaviour may also be dependent on other factors in the server config/OS). However, with that code in the document root then a request for example.com/ (your home page) won't be processed by these directives (which is good) - mod_dir should then serve the index.html file in this instance.
However, you don't want to process "directories" anyway (public_html is obviously a "directory", not a file). Which is what's happening above. eg. .html shouldn't be appended to public_html/ to begin with (or example.com/path/to/directory/ or any other directory). This can be avoided by adding an additional condition to your rule block to avoid directories (as well as files). For example:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([^.]+)$ $1.html [L]
Simply adding that additional RewriteCond directive might be enough and still allow you to keep your .htaccess file above the document root. (However, you may still need to move the .htaccess file as well, as described above.)
Also, the NC flag is not required here and literal dots don't need to be escaped when used inside a character class.
You could also extend this code to first check the existence of the file (with a .html extension) before rewriting, although this may be unnecessary in your case. For example:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^([^.]+)$ $1.html [L]
This requires an additional "file check" which may be an unnecessary overhead.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(.*)\.(css|js|htc|pdf|jpg|jpeg|gif|png|ico)$ [NC]
RewriteRule ^(.*)$ index.php?path=$1 [QSA,L]
This .htaccess redirects everything to index.php?path=SOMETHING where I can pick it up (SOMETHING path) and show appropriate content (views).
The problem is with including .css/.js files.
If I use www.website.com/something everything works (css path is like /css/style.css and it's searching in the www.website.com/css/style.css). But if I use www.website.com/something/2 everything crashes because it's searching in www.website.com/something/css/style.css folder.
How to set root (?) everytime to www.website.com (whatever path is)? So I should still have acccess to my 'path' variable but everything should point to the website root and not /some/... path when including my files.
The problem is in the way how you write links to css/js/image files.
Instead of including css/js/images using relative URLs to the current page:
href="css/style.css"
you should use URLs relative to the root (notice the leading slash):
href="/css/style.css"
or use absolute URLs (that will include domain name -- much less preferred approach).
This is a typical mistake when designing website (html part) when site uses Nice URLs/URL Rewritting. This is -- it's now that rewrite engine breaks URLs -- it's browser that sends them like that (/something/css/style.css) in first place.
Right now im using .htaccess to hide .htm extentions:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\.]+)$ $1.htm [NC,L]
But i also have php in my site (not to mention javascripts and images, etc..). So how do i change my htaccess to hide all file extentions? (or at least just .htm and .php)
edit: i dont know if it matters, but im on a linux server.
edit2: i tried some of the things i saw on the web and none is worked properly..
Options +MultiViews
should do that trick (replacing your current script). See documentation
(You might need to add some rewrite rules to redirect urls with extension to ones without, to prevent multiple urls pointing to the same resource)
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.
As of now my website has a few static pages, one of which is /portfolio. Among other things, my htaccess hides the .html extension. I'd like to add a portfolio directory, but I do not want to move my existing portfolio page into the portfolio directory as the default index file. My /portfolio page is one of my Google sitelinks and I am afraid if it is moved or if the url changes in someway, Google will consider it to be a brand new page.
My problem is once I add the /portfolio/ directory, whenever I try to visit the original /portfolio page, a trailing slash is automatically added and it links to the directory itself.
I've tried countless options, one being a rewrite of /portfolio/ to /portfolio, however this creates an infinite loop. I also tried "DirectorySlash Off" but that only removed the trailing slash while being inside the directory, it didn't revert access to the original /portfolio page.
Ultimately, I would like to keep my /portfolio page as-is, linking to pages inside the directory like so /portfolio/example and if either /portfolio or /portfolio/ is accessed it will result in showing the same page which is outside of the directory without Google thinking it is duplicate content.
A similar question exists here:
.htaccess rewriting url to page or directory though this still resulted in an infinite loop for me for some reason, I'm guess it has something to do with the hidden extensions.
Here's my htaccess-
RewriteEngine On
# HTML to PHP
RemoveHandler .html .htm
AddType application/x-httpd-php .htm .html
# Hide extension
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html
# Force WWW
RewriteCond %{HTTP_HOST} ^mydomain\.net
RewriteRule ^(.*)$ http://www.mydomain.net/$1 [R=301,L]
# Blog Subdomain
RewriteCond %{HTTP_HOST} ^blog.mydomain.net$
RewriteRule ^(.*)$ http://www.mydomain.net/blog/$1 [R=301,L]
I know it's not a great idea having a directory with the same name as a static page, but I really would rather not alter the existing page and lose the Google sitelink, so a clean and proper way to handle this would be a help.
There are two things going "wrong" here, and two ways to fix it.
The first is that apache "figures out" that there is a directory by the name of "portfolio" before the rewrite conditions are applied. That means that the rewrite conditions are receiving "portfolio/" instead of "portfolio".
Second, the "!-d" rule is specifically avoiding the rewrite that you want to make if there is in fact a directory by that name
Solution 1: Manually re-route requests for the portfolio directory to remove the slash.
# Manually re-route portfolio/ requests to portfolio
RewriteCond %{REQUEST_FILENAME} portfolio/$
RewriteRule ^(.*)/$ $1
# Hide extension
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html
Note the removal of the "!-d" condition.
The downside to this is that you are having to hard-code the "portfolio" edge case directly into the rewrite rules, and will still result in the browser being first redirected to portfolio/
Solution 2: Set DirectorySlash Off and remove directory exists test
# Disable Automatic Directory detection
DirectorySlash Off
# Hide extension
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html
Setting DirectorySlash Off would fix this issue the best, but may break other parts of your site where you actually want the auto DirectorySlash. Best of Luck, and I hope this helps.
Note when testing solution 2, your browser may remember the redirect of "portfolio" to "portfolio/" and perform the redirect before it even sends the request to the server. Be sure to test in a cache-clear, clean environment for best results.