يقوم برنامج cFos PNet بتخمين و تحديد ملفات التعريف و الضبط, و التي تعرف بإسم AccessFiles. بشكل إفتراضي فإن هذه الملفات تعرف بالإسم .htaccess. أما بالنسبة للتوجيهات (التعليمات) الموجودة هنالك و المعروفة بالإسم directives, فإنها تقوم بالتحكم في سلوك عمل برنامج cFos PNet و ذلك فيما يتعلق بالمجلد المستحسن إستخدامه على وجه التحديد (و جميع المجلدات الفرعية من هناك) حيث يكون مكان تواجد هذه التوجيهات. إن أول ملف من ملفات .htaccess يكون موقعه في المجلد private folder و الذي يحتوي على جميع الإعدادات الإبتدائية (initial settings). في حال قام متلقي الخدمة (client) بطلب عنوان URL معين (Certain URL), لنقل مثلاً العنوان /test/x/file1.txt, عندها, فإن جميع ملفات .htaccess يتم تخمينها و تحديدها لجميع المجلدات الُمشار لها و المذكورة من قبل عنوان URL. في هذا المثال, فإنه سيتم أولاً تحديد ملفات .htaccess بالنسبة للمجلد private folder, ثم بعد ذلك ملفات .htaccess بالنسبة للمجلد pub, ثم بعد ذلك بالنسبة للمجلد test, ثم بعد ذلك ملفات .htaccess بالنسبة للمجلد x.
إن جميع التوجيهات (directives) تكون تراكمية (cumulative), وبمعنى آخر أنها مضافة (added) أو مكتوبة على ما قبلها (overwritten), إلا أنها لا يتم حذفها أو مسحها (not deleted).
إن الفكرة من وراء هذا الضبط و التعريف التراكمي (cumulative configuration) هو أن تقوم أنت بنفسك بإعداد و توفير تعريف و ضبط أساسي (basic configuration) و من ثم تمنح المستخدمين (users) الإذن بالدخول و الوصول إلى المجلدات المندرجة تحت المجلد pub folder. على سبيل المثال, يمكنك أن تقوم بإنشاء مجلد بإسم limited بحيث يكون مندرجاً تحت المجلد pub و من ثم تقوم بمنح مستخدماً ما برتبة مستخدم محدود (limited user) الإذن بالدخول و الوصول إلى ذلك المجلد, و عليه فإن هذا المستخدم سواءً هو/هي يمكنه أن يقوم بنشر (publish) ملفات هناك. أن ذلك المستخدم (user) يمكنه عندئذٍ أن يقوم بإنشاء ملف .htaccess الخصوصي خاصته/خاصتها, إلا أنه سيكون محدوداً و مقيداً بالإعدادات الأساسية (basic settings) التي قمت أنت بضبطها و تحديدها و تعريفها فيما سبق في المجلد private و/أو المجلد pub.
يمكنك أن تجد العديد من الشروح التعليمية الجيدة على شبكة الإنترنت فيما يتعلق بإستخدام ملفات .htaccess و لذلك سنكتفي هنا بتقديم شرح موجز و مختصر عنها.
جميع التوجيهات (directives) التالية مدعومة و متوافقة من الناحية الوظيفية مع البرنامج:
| AllowOverride | Enables/disables certain groups of directives in .htaccess. Values are: 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. |
| ErrorDocument | [<num>] document 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. java-script Built-in Javascript. cFos PNet offers some extensions and a webserver object to allow seamless integration of Javascript and the webserver. See the scripting documentation below. 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. <script language name> cFos PNet uses the windows scripting host for script execution. Therefore you can use any scripting language which supports the scripting host. Use the language name as registered with the scripting host for <script language name>, e.g. "Jscript" for Javascript or "VBScript" for Visual Basic Script. |
| 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. Note: cFos PNet can also use HTTP authorization from Javascript. This may eliminate the need for session tracking / session cookies in many cases. See below for more information. |
| 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: user1:password1 user2:password2 ... 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: "PNet_user", "!pass" 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. |
| Rewrite engine: | |
| RewriteScript | <script-file> Rewrite engines are used to modify parts of the HTTP request before the actual request is executed by the server. cFos PNet has a Javascript based rewrite engine, which is so powerful, you could even implement a whole http server in Javascript on your own. You can modify every part of the HTTP request or even handle the whole request by your Javascript. 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: | |
| PNet_add_module_path | <list> cFos PNet supports the common.js module specification. This allows structuring Javascript code / libraries into modules. 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 |