cFos PNet evaluates configuration files, called AccessFiles. By default they are named .htaccess. So called directives therein control the behaviour of cFos PNet for the particular folder (and all subfolder thereof) where they are located. The first .htaccess file is located in the private folder and contains all initial settings. If the a client requests a certain url, say /test/x/file1.txt, all .htaccess files are evaluated for all folders the url mentions. In this example first .htaccess of the private folder is evaluated, then .htaccess of folder pub, then of folder test, then .htaccess of folder x.
All directives are cumulative, ie. they are added or overwritten, but not deleted.
The idea behind this cumulative configuration is, that you provide a basic configuration and then give users access to folders below the pub folder. For example, you could create a folder limited under pub and give some limited user access to that folder, so he/she can publish files there. That user can then create his/her own .htaccess file, but will be limited to the basic settings you previously configured in private and/or pub.
On the web you can find a lot of good tutorials on .htaccess files, so we will be brief here.
The following directives are supported:
|AllowOverride||Enables/disables certain groups of directives in .htaccess.|
All all directives can be changed
Indexes enable DirectoryIndex
FileInfo enable ErrorDocument, AddType, AddHandler, RemoveType, RemoveHandler, DefaultType, Redirect, RedirectPermanent, RedirectTemp
AuthConfig enable AuthUserFile, Require, AuthGroupFile, AuthName, AuthType
UserInfo enable User
The following directives can only be overwritten if AllowOverride is All:
AllowOverride, AccessFileName, SSIStartTag, SSIEndTag, PNet_UserPwd.
|AccessFileName||The <name> of the AccessFile, default: .htaccess.|
|DirectoryIndex||<file> which is served, if the clients specifies a folder, like /. Many configurations use index.htm/index.html here.|
If HTTP error <num> is encountered, which error document is served. If <num> is ommited the document is used for all errors.
|AddType||Add a <MIME type>, see mime.types in the private folder.|
|RemoveType||Remove a <MIME type>|
|DefaultType||What <MIME type> should be used, after searching the MIME types added with AddType and then searching the mime.types file in vain.|
|ForceType||Forces the mime type to <MIME type>, regardless of the file extension.|
|AddHandler||mode <ext> if a files with extension <ext> is requested, what should cFos PNet do with it. Values for mode are:|
type-map / default-handler this is the default. Files are simply send to the client. The type is determined by the MIME type.
server-parsed this is a server-side include file. cFos PNet parses the file before sending and supports the following SSI (shtml) directives: echo, include. For an example see the all_errors.shtml file in the private folder. cFos PNet also supports nested includes and script invokation by the SSI include directive.
cgi-script CGI script. An external program in started and the process environment is set appropriately. Also this process runs under the user impersonation configured previously. So you can run your favourite scripting languages (Perl, PHP, etc.) in a secure context.
fast-cgi Use a FastCGI script. The FastCGI script is started on first use and ended when the server is stopped.
php-file Like cgi-script, but use the key "php_interpreter" in the [param] section of GLOBAL.INI to start the (PHP-)interpreter with the PHP script file as command-line parameter. Use the full path and optional command line options of PHP-CGI.EXE here.
|RemoveHandler||Remove a previously added <handler>.|
|Redirect||Redirect a certain <url> to another.|
|RedirectPermanent||Redirect a certain <url> to another.|
|RedirectTemp||Redirect a certain <url> to another.|
|RedirectMatch||Redirect a certain <url> to another.|
|PNet_redirect_host <status> <regex> <dest>||redirect according to the host part in a HTTP request (e.g. in http://www.cfos.de/dl the host part is www.cfos.de). <status> is either an HTTP response code or permanent (301), temp (302), seeother (303) or gone (410). <regex> is a regular expression as in the RedirectMatch directive. <dest> is the destination host. The redirect location is the HTTP protocol + <dest> + original URL + original query string. This directive allows easy mapping to a canonical host, e.g. redirect all requests to cfos.de to www.cfos.de.|
|SSIStartTag||How server side include directives start, default <!--#|
|SSIEndTag||How server side include directives start, default -->|
|AuthType||Type of authorization to access the current folder and all its sub-folders:|
basic Username and Password are transmitted as clear-text.
digest Instead of a clear-text password, a digest value is calculated and transmitted. Thereby an attacker cannot read the password. This method is also secure against re-play attacks, because one digest values cannot be used twice.
|Require||Which authorization entity is required:|
user <x> The user named <x> must be authorized to access content in the folder.
group <x> The user must be in group <x> to access the content.
valid-user Any valid user can access the content.
actual-user A valid user, where the last path part matches the user name (e.g. /private/test/index.htm matches user name test).
all granted Always allow access all denied Always deny access, answer the HTTP request with a 403 Forbidden response. method <method-list>method-list is a space-separated list of HTTP methods. Only allow access if the current HTTP methods is one of the methods specified in the method list, e.g. GET, POST, PUT, etc. env <environment-var-list>environment-var-list is a space-separated list of environment variables. Only allow access if one of the listed environment variables is defined and not empty.
|AuthName||The <name> of the authorization realm. This is the name, the browser displays in the password window. It is also evaluated by the browser to re-use the username/password for subsequent authorization requests. By choosing a common name, you can allow the browser to authorize the user automatically for different urls / content locations within your site.|
|AuthUserFile||<file or folder location> of user information. If it is a file, the format is (Apache compatible) as follows:|
If it is a folder, cFos PNet assumes there is a sub-folder for each individual user, which contains a file profile.txt.
profile.txt is actually a hash list (see hash list description below). The idea is to allow more profile information be stored for an individual user, for example access control lists, etc.
|AuthGroupFile||<file location> of the file with (Apache compatible) group information. The group file has the following format:|
group1: member1 member2 member3...
group2: member4 member5 ...
|PNet_lock <on/off>||if on use a named lock to prevent several concurrent HTTP requests from accessing resources in this directory or its subdirectories. This is useful for WEBDAV/CALDAV requests to prevent users from overwriting data with concurrent requests. You could also use it in directories, where simultaneous write access (e.g. HTTP PUT) can occur.|
|User||Impersonate a certain <user>. Thereby you can enforce certain user rights (restricted or extented) for certain folders.|
You can (and should) create at least one limited windows users, so that cFos PNet won't run under admin rights. Store the password of the limited user(s) in the file pwd.txt in the private folder, like this:
assuming the user name is PNet_user and the password is pass.
|PNet_UserPwd||<file location> where cFos PNet gets the passwords to impersonate users with the User directive. See User directive above.|
|<Files exp>||The directives in the <Files> ... </Files> are only used for files matching exp. exp can either be a filename including wildcards the * and ? or a regular expression, preceeded by ~ and enclosed in quotes, like <Files ~ "\.(gif|jpe?g|png|bmp)$">.|
|</Files>||End of <Files> block.|
|<FilesMatch regexp>||Like <Files> directive, regular expression only version.|
|</FilesMatch>||End of <FilesMatch> block.|
|<Location exp>||The directives between <Location exp> and </Location> are only used for a URL which matches exp. The location directive matches the whole URL beginning with / of the request and is not tied to particular files or directories in your file system. The <Location> and <LocationMatch> directives are useful if you want to keep out .htaccess files from certain directories. In this case you can place your needed .htaccess directives in the .htaccess file of the upper directory in a <Location> or <LocationMatch> block.|
|<LocationMatch regexp>||Like <Location> directive, regular expression only version.|
|<Limit method-list>||method-list is a space-separated list of HTTP methods. Directives between <Limit method-lst>...</Limit> are only used if the current HTTP request uses one of the methods specified in the method list, e.g. GET, POST, PUT, etc.|
|</Limit>||End of <Limit> block.|
See rewrite_doc.txt for a detailed documentation.
|Cross-domain scripting support:|
|PNet_accesscontrolalloworigin||<list> can either be * or a space separated list of domains (which may contain the wildcards * and ?).|
When cFos PNet receives an Origin HTTP header it checks it against <list>. If the Origin matches one of the list elements it sends back an Access-Control-Allow-Origin HTTP header. It tells the browser to allow cross site scripting with this server, see https://developer.mozilla.org/en/HTTP_access_control for a detailed explanation.
|common.js module support:|
This directive allows setting a list of space separated search paths. They are used to load modules with the require function, see http://www.commonjs.org/specs/modules/1.0/ for a detailed explanation of this kind of module handling.
|Data compression:||cFos PNet supports gzip and deflate data compression.|
Since compression may cause CPU load and/or memory consumption you should prefer smaller compression levels / memory levels and window sizes. Higher values may only gain you another few percent of extra compression at the cost of CPU and memory usage. Experiment until you find a reasonable compromise.
|SetOutputFilter||deflate enable gzip and deflate compression, off = disable|
|DeflateCompressionLevel||val> set compression level from 1 .. 9 (1 = less compression, 9 max. compression).|
|DeflateMemLevel||<val> set compression memory level from 1 .. 9 (1 = less memory, 9 max memory usage).|
|DeflateWindowSize||<val> set compression window size from 1 .. 15 (1 = min. window, 15 = max. window).|
|PNet_DeflateMinimumSize||<size> disable compression for files below size.|
|Expiry:||Controls the sending of HTTP expire headers. Using expire headers gives you control how long browsers may cache files, before requesting them again from the web server.|
A good general rule is to cache images for one day and versioned scripts and CSS files (like jquery.1.6.2.min.js) "indefinitly", because when they change, they get a new version number in the filename. html files should not use an expire header, ie. they are controlled by the last-modified header by the browser.
|ExpiresActive||on = enable expires headers, off = disable|
|FileETag||all = send Etag header, none = disable|
|ExpiresDefault||<exp> default expiry duration|
<exp> has the following format:
<start> [plus] <number> <unit>, where <start> is either access, now or modification.
If <start> is modification, the last modified time/date of the file is used, otherwise the the time of access (ie. when it is requested).
plus is optional.
<number> is any valid number for <unit>. <unit> is one of the following time units years, months, weeks, days, hours, minutes or seconds.
<exp> can have the following alternative format:
An or Mn, where A means "access" and M means modification. n is the number of seconds added to the <start> time.
Expiration times should not exceed 1 year.
|ExpiresByType||<mime-type> <exp> set expiry for a certain mime-type|