Files and FilesMatch to target multiple files and using Regular expressions using .htaccess files on Apache.

NOTE: FilesMatch should be used instead of Files when dealing with multiple files.

Adding UTF-8 content-type and and en-US language headers to files with extensions htm, html, css, js, and php

Setting charset in htaccess article

Using the Files Directive

<Files ~ "\.(htm|html|css|js|php)$">
AddDefaultCharset UTF-8
DefaultLanguage en-US
</Files>

Using the FilesMatch Directive (preferred)

<FilesMatch "\.(htm|html|css|js|php)$">
AddDefaultCharset UTF-8
DefaultLanguage en-US
</FilesMatch>

Other Examples using Files and FilesMatch in htaccess

Target a single file admin.php

<Files admin.php>
deny from all
</Files>

Target files that start with admin or staff and end in .php

<FilesMatch "^(admin|staff)\.php$">
AuthName "Dialog prompt"
AuthType Basic
AuthUserFile /web/username/.htpasswd
Require valid-user
</FilesMatch>

Target all files that end in .html or .htm

<FilesMatch "\.(html|htm)$">
AddDefaultCharset utf-8
DefaultLanguage en-us
</FilesMatch>

<FilesMatch> Directive Description: Contains directives that apply to regular-expression matched filenames Syntax: <FilesMatch regex> ... </FilesMatch> Context: server config, virtual host, directory, .htaccess

The <FilesMatch> directive limits the scope of the enclosed directives by filename, just as the <Files> directive does. However, it accepts a regular expression. For example:

<FilesMatch "\.(gif|jpe?g|png)$">

<Files> Directive Description: Contains directives that apply to matched filenames Syntax: <Files filename> ... </Files>

The <Files> directive limits the scope of the enclosed directives by filename. It is comparable to the <directory> and <location> directives. It should be matched with a </Files> directive. The directives given within this section will be applied to any object with a basename (last component of filename) matching the specified filename. <Files> sections are processed in the order they appear in the configuration file, after the <directory> sections and .htaccess files are read, but before <location> sections. Note that <Files> can be nested inside <directory> sections to restrict the portion of the filesystem they apply to.

The filename argument should include a filename, or a wild-card string, where ? matches any single character, and * matches any sequences of characters. Extended regular expressions can also be used, with the addition of the ~ character. For example:

<Files ~ "\.(gif|jpe?g|png)$">

would match most common Internet graphics formats. <FilesMatch> is preferred, however.

Note that unlike <directory> and <location> sections, <Files> sections can be used inside .htaccess files. This allows users to control access to their own files, at a file-by-file level.

The configuration sections are applied in a very particular order. Since this can have important effects on how configuration directives are interpreted, it is important to understand how this works.

The order of merging is:

  1. <directory> (except regular expressions) and .htaccess done simultaneously (with .htaccess, if allowed, overriding <directory>)
  2. <directoryMatch> (and <directory ~>)
  3. <Files> and <FilesMatch> done simultaneously
  4. <location> and <locationMatch> done simultaneously

Apart from <directory>, each group is processed in the order that they appear in the configuration files. <directory> (group 1 above) is processed in the order shortest directory component to longest. So for example, <directory /var/web/dir> will be processed before <directory /var/web/dir/subdir>. If multiple <directory> sections apply to the same directory they are processed in the configuration file order. Configurations included via the Include directive will be treated as if they were inside the including file at the location of the Include directive.

Sections inside <virtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.

Later sections override earlier ones.

Technical Note: There is actually a <location>/<locationMatch> sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed.