I have adapted the .htaccess on my WordPress site and made additions such as the activation of GZIP.
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>
Then I put a rule in the subfolder that should prohibit access to certain pages.
<FilesMatch "connection\.php|data\.php|protection\.php">
order allow,deny
deny from all
</FilesMatch>
Of course, I wanted the rules created in the root folder to also apply to the additional rules in the subfolders (of course only in the respective folders). Today I read a article that made me suspicious in which I read that a .htaccess file in a subfolder completely overwrites a .htaccess file from a parent folder and not adds the new specific points and only when a new point is added to a point from the higher-level folders which is suppose it gets overwritten. So I tried it out and in my opinion it is not true because, according to GZIP Tester, the files are also got zipped in the folder where I don't add this
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
</IfModule>
Here is a diagram from the page where I found this article.
It's German, but I think you will understand that. (Verzeichnis = Root folder, Unterverzeichnis = subfolder)
The question is what's right, did I make a mistake and have to re-list the rules every time I want to extend the root folder in each .htaccess file (in sub-folders) or was the text on the website just wrong?
From the official Apache docs (https://httpd.apache.org/docs/current/howto/htaccess.html#how):
The configuration directives found in a .htaccess file are applied to the directory in which the .htaccess file is found, and to all subdirectories thereof. However, it is important to also remember that there may have been .htaccess files in directories higher up. Directives are applied in the order that they are found. Therefore, a .htaccess file in a particular directory may override directives found in .htaccess files found higher up in the directory tree. And those, in turn, may have overridden directives found yet higher up, or in the main server configuration file itself.
I know how to force all jpg files to download using .htaccess, like below:
AddType application/octet-stream jpg
But now I want to force all files (no matter what format) under the specific path to download using .htaccess
For example:
Force all files under the path /home/user/public_html/files/attachments to download and not open in browser directly.
How can I do?
You can probably use RewriteRule to reach your goal, no need to use AddType:
RewriteCond %{REQUEST_URI} ^/home/user/public_html/files/attachments/(.*)$ [NC]
RewriteRule ".+\..+" "-" [T=application/octet-stream,L]
This will force any kinds of formats to download in the browser only when the path matches /home/user/public_html/files/attachments.
You can add all the possible extensions which are in the folder to AddType. like,
AddType application/octet-stream .jpg .doc .mov .avi .pdf .xls .mp4
I came across similar situation and couln't able to find a better way of doing it so posting this as answer.
Force a Content-Disposition header.
Header always set Content-Disposition "attachment"
Was wondering is this possible in .htaccess?
I'm currently caching .js, .css and all image files via PHP (and providing the cached only if the file has not been modified by checking the filemtime()).
However someone suggested it's possible via .htaccess and much faster, so was hoping maybe someone can shed some light...I've looked around and found various snippets but none which cover what I'm after.
If you've got mod_expires installed on your apache server you can put something like this in your .htaccess file. This example is PHP orientated (actually grabbed from the Drupal 7 .htaccess file) but should serve as a good starting point.
FileETag MTime Size
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
<FilesMatch \.php$>
# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior.
ExpiresActive Off
</FilesMatch>
</IfModule>
Can someone explain what the difference is between AddType and AddHandler in htaccess files? I want to make the settings such that I can have a javascript file (.js) be run through the server as though it were a php file (application/x-httpd-php5) but then sent to the user's browser as a (text/javascript) file. How might i configure this?
AddHandler http://httpd.apache.org/docs/2.0/mod/mod_mime.html#addhandler tells the server how to handle the file type. AddType http://httpd.apache.org/docs/2.0/mod/mod_mime.html#addtype tells the server what MIME type to give the client.
I doesn't sound like a great idea to parse all .js files as php. I would suggest using a .htaccess Rewrite directive to map the .js files in question, to your php script.
RewriteRule /phpjs/.* /phpjs/js.php
Then add
header("Content-Type: text/javascript");
to your php output.
What mime type should WOFF fonts be served as?
I am serving truetype (ttf) fonts as font/truetype and opentype (otf) as font/opentype, but I cannot find the correct format for WOFF fonts.
I have tried font/woff, font/webopen, and font/webopentype, but Chrome still complains:
"Resource interpreted as font but transferred with MIME type application/octet-stream."
Anybody know?
Update from Keith Shaw's comment on Jun 22, 2017:
As of February 2017, RFC8081 is the proposed standard. It defines a top-level media type for fonts, therefore the standard media type for WOFF and WOFF2 are as follows:
font/woff
font/woff2
In January 2011 it was announced that in the meantime Chromium will recognize
application/x-font-woff
as the mime-type for WOFF. I know this change is now in Chrome beta and if not in stable yet, it shouldn't be too far away.
For me, the next has beeen working in an .htaccess file.
AddType font/ttf .ttf
AddType font/eot .eot
AddType font/otf .otf
AddType font/woff .woff
AddType font/woff2 .woff2
It will be application/font-woff.
see http://www.w3.org/TR/WOFF/#appendix-b (W3C Candidate Recommendation 04 August 2011)
and http://www.w3.org/2002/06/registering-mediatype.html
From Mozilla css font-face notes
In Gecko, web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.
Note: Because there are no defined MIME types for TrueType, OpenType, and WOFF fonts, the MIME type of the file specified is not considered.
source: https://developer.mozilla.org/en/CSS/#font-face#Notes
Reference for adding font mime types to .NET/IIS
via web.config
<system.webServer>
<staticContent>
<!-- remove first in case they are defined in IIS already, which would cause a runtime error -->
<remove fileExtension=".woff" />
<remove fileExtension=".woff2" />
<mimeMap fileExtension=".woff" mimeType="font/woff" />
<mimeMap fileExtension=".woff2" mimeType="font/woff2" />
</staticContent>
</system.webServer>
via IIS Manager
NGINX SOLUTION
file
/etc/nginx/mime.types
or
/usr/local/nginx/conf/mime.types
add
font/ttf ttf;
font/opentype otf;
font/woff woff;
font/woff2 woff2;
application/vnd.ms-fontobject eot;
remove
application/octet-stream eot;
REFERENCES
RFC #02.2017
https://www.rfc-editor.org/rfc/rfc8081#page-15
https://www.iana.org/assignments/media-types/media-types.xhtml
Thanks to Mike Fulcher
http://drawingablank.me/blog/font-mime-types-in-nginx.html
As of February 2017, RFC8081 is the proposed standard. It defines a top-level media type for fonts, therefore the standard media type for WOFF and WOFF2 are as follows:
font/woff
font/woff2
Note: This answer was correct at it's time but became outdated in 2017 when RFC 8081 was released
There is no font MIME type! Thus, font/xxx is ALWAYS wrong.
Add the following to your .htaccess
AddType font/woff woff
good luck
Thing that did it for me was to add this to my mime_types.rb initializer:
Rack::Mime::MIME_TYPES['.woff'] = 'font/woff'
and wipe out the cache
rake tmp:cache:clear
before restarting the server.
Source: https://github.com/sstephenson/sprockets/issues/366#issuecomment-9085509
#Nico,
Currently there is no defined standard for the woff font mime type. I use a font delivery cdn service and it uses font/woff and I get the same warning in chrome.
Reference: The Internet Assigned Numbers Authority
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types
This is a helpful list of mimetypes
I know this post is kind of old but after spending many hours on trying to make the fonts work on my nginx local machine and trying a tons of solutions i finally got the one that worked for me like a charm.
location ~* \.(eot|otf|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
Inside the parenthesis you can put the extensions of your fonts or generally the files that you want to load. For example i used it for fonts and for images(png,jpg etc etc) as well so don't get confused that this solution applies only for fonts.
Just put it into your nginx config file, restart and i hope it works also for you!
Maybe this will help someone. I saw that on IIS 7 .ttf is already a known mime-type. It's configured as:
application/octet-stream
So I just added that for all the CSS font types (.oet, .svg, .ttf, .woff) and IIS started serving them. Chrome dev tools also do not complain about re-interpreting the type.
Cheers,
Michael
For all Solution index.php remove form url and woff file allowed. for write below code in .htaccess file and and make this alternation to your application/config/config.php file:
$config['index_page'] = '';
For only Linux hosting server.
.htaccess file details
AddType font/ttf .ttf
AddType font/eot .eot
AddType font/otf .otf
AddType font/woff .woff
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#Removes access to the system folder by users.
#Additionally this will allow you to create a System.php controller,
#previously this would not have been possible.
#'system' can be replaced if you have renamed your system folder.
RewriteCond %{REQUEST_URI} ^system.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#When your application folder isn't in the system folder
#This snippet prevents user access to the application folder
#Submitted by: Fabdrol
#Rename 'application' to your applications folder name.
RewriteCond %{REQUEST_URI} ^application.*
RewriteRule ^(.*)$ /index.php?/$1 [L]
#Checks to see if the user is attempting to access a valid file,
#such as an image or css document, if this isn't true it sends the
#request to index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>
<IfModule !mod_rewrite.c>
# If we don't have mod_rewrite installed, all 404's
# can be sent to index.php, and everything works as normal.
# Submitted by: ElliotHaughin
ErrorDocument 404 /index.php
</IfModule>
IIS automatically defined .ttf as application/octet-stream which seems to work fine and fontshop recommends .woff to be defined as application/octet-stream
WOFF:
Web Open Font Format
It can be compiled with either TrueType or PostScript (CFF) outlines
It is currently supported by FireFox 3.6+
Try to add that:
AddType application/vnd.ms-fontobject .eot
AddType application/octet-stream .otf .ttf
Mime type might not be your only problem. If the font file is hosted on S3 or other domain, you may additionally have the issue that Firefox will not load fonts from different domains. It's an easy fix with Apache, but in Nginx, I've read that you may need to encode your font files in base-64 and embed them directly in your font css file.