Since built 0.175 this is the place to specify the ports (and their settings) the servers listens at for new connections. It's a global setting and won't have any effect when used in a virtual server block. The entries have this scheme:

The mode is not in use yet. Later it will mark a port considered secure (behind stunnel for example) or being normal. It's mainly interesting for CGI and other gateway interfaces that need to know if the connection is safe.
The address is either a "*" or an address like the one shown in the above example. It is not possible to use a name here as the function doesn't support this feature.
The port or socket the server listens to. What else to say?
The listen-queue-length is the number of pending connections before the system starts to reject new incoming ones automatically. Actually this number is not a setting but only an upper limit of the systems max setting for that. It is usually 128-256 (1024 in SuSE 9.3) unless you change it in your OS manually.
The values in [] are optional. "nagle" will enable nagle. However, this setting is not inherited by the working connections, it's just used by the listener and therefore pretty useless. "defer_accept" will activate the defer_accept mode of the listener socket. This was default until 211c, now you have to enable it here. If it increases speed or not you have to test yourself. In my experience, it will increase overall speed only on multi processor/core systems. On single core systems it tends to increase keep-alive request handling but slows down non-keep-alive ones.

There is no default to fall back if no listener is specified, so a missing entry will be a critical error and the server process won't start but give an according error message instead. BACK

It is possible, based on the referer host of a request header, to limit access to the files on a per virtual server basis. For that the system compares the requests one with the ones in the list. The list is considered a special setting and is not inherited as a default setting, so if no list is defined for a virtual server he doesn't perform this test. To make things a bit easier a simple wildcard is possible. Example list:

With this list, requests with a referer from "forum.yourserver.com" (exact match) and all requests with a referer host ending with ".mys.com" (e.g. www.mys.com, ww2.mys.com, forum.mys.com, pics.mys.com, 2005.dezember.mys.com, ...) will be allowed/denied based on the referer_policy. BACK

This block is considered a default value and the content of the server block will be inherited by all virtual servers unless they have an own block specified. An empty block (no lines, but it exists) will also work to disable the settings. The server takes the complete line, adds the required "\r\n" at it's end (so don't include that!) and place those at the end of all response headers coming from that virtual server. However, the program makes no test if the lines are syntactically sound, nor if the content is in direct conflict with a header line created automatically. The space in the response header buffer is limited. In case the additional lines don't fit into it the server will create a 500 error with the text "server error: response header too big for buffer". So test your settings before you deploy them. There should usually be space for around 1000-1500 Bytes though. A typical use could be to set a cookie, to specify an expiration date/value or this often demanded P3P header line. BACK

These are often refered to as mime-types. The browser needs some information what kind of file it is receiving in order to display it as intended. Like most other servers hssTVS uses the file extension to get this information. If it encounters an unknown type it will use the one set with default_mime, which might be just fine. A file type with an empty mime-type (php in the example below) will block that file with either an 403 (default) or an 404 (if set so with unknown_mime_handler). Such empty entries only make sense if the default_mime contains a non-empty string...

There are a couple of pages in the web where you can find the definitions. Currently the list is not processed in an optimised way, just gone through linear, so you shouldn't put in more than you really need. Until I have time to change that you can tune your server up by sorting the entries from most likely to most unlikely. The comparission is made case insensitive, so you need to include every type only once.(HTML, html, Html and so on is the same) BACK

In order to protect the files you don't want to share you have to tell hssTVS which directories the user is allowed to use. Those directories are always relative paths based on the content_root entry. You may not start the entry with a '/'. The server takes this away internally for the incoming request and it will never get a match then. The '*' is the only allowed wildcard and it has 2 purposes. The first is to allow the content_root directory and the second is to allow a whole subtree. So '**' allows all directories, including the content_root up. A 'content*' will allow all paths starting with "content". However, in case you use the '*' the path is additionally checked for things that might enable the user to look elsewhere, like "../" and so on to prevent the user to gain access to other directories. BACK

hssTVS supports virtual servers. Modern browsers always include the "Host:" header field and the content of that is compared to the names you have defined here. If it is an unknown name the server will use the default entry. In case you wonder, if you register a host name like "myserver.com" only the last two part strings are compared to find out the targets ip-address (as long as you don't explicitely define subdomains in the DNS entry). So "www.myserver.com", "home.myserver.com" as well as "my.home.myserver.com" will result in the browser getting the right address. You can use this to define basically a whole bunch of virtual servers. The entries are a name followed by a marker that defines the entry name of the config file to use to find the right settings:

The name is followed either by '-', by '*' or by a string. A '-' tells the server to use the default settings for this name. A '*' tells the server to look for an entry starting with the given name while a string acts as an alias to look under. For the examples above the server will do the following. "myserver.com" will get the defaults. For "forum.myserver.com" the server will look for an entry of "[forum.myserver.com-Configuration]" and take the values found there. For "dpftvs.myserver.com" it will take the values found under "[mine-Configuration]". The space between the name and the definition can be regular spaces as well as tabulators or a combination of them. "*.myserver.net" is a special case. It is a mass virtual server definition. These have to be followed by an alias string. BACK