We support two canonical name redirection settings:
off - Our system attempts to avoid the use of a site's canonical name. Redirects issued by the network will use the hostname presented in the HTTP Host: header. From an application standpoint this means that the HTTP_HOST variable will be copied to the SERVER_NAME variable for each request. This setting is particularly suited to sites that vary their content based on which alias is used, such as WordPress multi-site hosting, or if you want to use our per-alias document root feature to host multiple websites using only one site on our system.
on - If anybody accesses your site using an alias other than its canonical name, will automatically, transparently get a "301 Moved Permanently" redirect to the correct name. This setting is particularly appropriate for sites with one correct name, but a number of other aliases that the site owner also wishes to accept.
Your site's canonical name and type settings are visible in the "Config Information" box on the Site Information page for that site. To make changes to your site's canonical name or type settings, use the "Edit" button on the "Canonical URL" line.
If you are running software on your site that lets you designate the official URL for the site (such as WordPress), you'll need to update that information before you enable canonical name redirection to a name that is different from what your software is expecting. If you don't, your software and our system will get into a slap fight over what name is correct, and all visitors to your site will get is a "too many redirects" error.
If that happens, switch the canonical type back to "off" to let your site load and regain access to your software's administration area. (To continue with the WordPress example, the "blog URI" or "WordPress address (URL)" is the software setting in question.)
For more information about canonical names, see this FAQ entry.
(The "on" setting used to be "hard," so if you see any references to "hard canonical," it means enabling canonical name redirection. We also used to have a "soft" setting, which some old sites still have. It's useless and if you see it, you should get rid of it!)
By default, you must create an index file for each directory that you create. This is a security precaution for novice webmasters to protect them from unintentionally exposing files they did not intend to publish.
The index file can have any one of several names:
index.html
index.shtml
index.php
index.htm
default.htm
index.cgi
index.pl
(If more than one of these files exists, the server will use the highest one on the list. These names are case-sensitive. E.g. INDEX.HTML and Index.html will not work.)
If you want the web server to display a list of files in a directory, you add the following line to your .htaccess file for that directory:
Options +Indexes
Note that this directive applies to the directory containing its .htaccess file as well as any and all subdirectories.
Create the forwarding site. If you are going to forward to www.example.com or your-site.some-other-web-host.com, try to give it a short name like examplefwd.
Set up the name you want to forward from as an alias of the examplefwd site.
Create a one-line plain text file on your local computer called htaccess.txt containing the following (replacing www.example.com with the name of the site you want to forward to):
Upload this htaccess.txt file to your examplefwd site hosted here as a text file.
Rename the file from htaccess.txt to .htaccess. (That's "htaccess" with a period in front.)
This approach works for all sorts of URLs, not just the main site. For example, if you use this technique to forward members.example.com visitors to www.example.com/members/ and someone visits http://members.example.com/page.html they will be forwarded to http://www.example.com/members/page.html.
Please note if the target site is hosted here and you merely want to redirect alternative names, setting a hard canonical name is usually faster, easier, and cheaper than this approach. This approach is better suited when the redirection involves two hosts or path manipulation at either or both ends.
The syntax for mod_rewrite rules can be tricky and hard to get just right, especially as they get more complex. The rewrite log can help debug RewriteRules. However, as soon as you debug your rules, it's very important to turn it off.
Because a single rewrite rule can produce several lines of output, the rewrite engine obtains a lock on the rewrite log for each access. This means your site can only process one access at a time, which is a horrible performance penalty.
Worse than that, we have seen Apache occasionally lose this lock if an in-progress request dies during rewrite processing (for example due to a closed connection), which will cause all requests for your site to stall indefinitely until the server won't accept any more.
For these reasons, you absolutely should not run the rewrite log on a production site, or for any longer than absolutely necessary to debug your rewrite rules.
NearlyFreeSpeech.NET provides a basic error page in response to most common types of site errors. Sometimes, you may wish to override these pages and provide your own error messages that fit your site style or provide additional information. In order to do this, add the following line to the .htaccess file in your public directory (you'll need to create this plain-text file first if you don't have one):
ErrorDocument 404 /err404.html
Where 404 is the number of the error you wish to catch and err404.html is the name of the file you want displayed when an error occurs. You may use a PHP or CGI script for an ErrorDocument, but be careful not to use absolute paths to specify the name of your ErrorDocument.
Here are the most common errors:
401 Authorization Required
Indicates that a username and password are required but were not provided or were incorrect too many times.
403 Forbidden
Indicates that security restrictions prevent the requested page from being returned. This is the error returned for brand new sites, because our security prohibits directory indexing without an explicit index file.
404 Not Found
Indicates that the requested page or object was not found, either due to a typo or a broken link.
500 Internal Server Error
Usually indicates that a CGI script encountered an error.
Due to the design of our network, you typically cannot use an ErrorDocument to catch a 503 Service Unavailable error. Such errors do not routinely occur except during system maintenance. They may also occur during some types of partial service interruptions, or if you have a custom server type with improperly-configured daemons or proxies.
It's the name you would use when someone asks you for the address of your web site; the "official" name. This would typically be something like www.example.com, and must be one of the aliases that is associated with your site (this can include the default alias ending in .nfshost.com).
The default canonical name of each site is its nfshost.com alias. If your site's shortname is example, then its default canonical name is example.nfshost.com.
Having a canonical name is especially important when you want to have a bunch of alternative names for the same site. For example, if your website is for Example, LLC, you might want to have www.example.com, www.examplecompany.com, and www.example.biz all point to the same site. You may even want to have www.awesome-widget.com for your awesome widget. Plus all those without the www in front. Knowing and setting one of those names to be the canonical name for your site and enabling canonical redirection can improve your search rankings.
We encourage (but do not require) you to use www.example.com as a canonical name rather than example.com in most cases. See this FAQ entry for an explanation.
Ordinarily, your site's document root (as seen by Apache) is /home/public. If you enable the per-alias document root feature from the site info panel in our member interface, the alias used will be added to the site's document root.
For example, if you have www.example.com configured as an alias for your site, then when someone visits it, Apache will treat /home/public/www.example.com/ as the document root. If you also have the alias other.example.com added to the site, then requests using that alias will be directed to /home/public/other.example.com/.
If no directory exists for a given alias, all requests for that alias will return 404. If a directory exists, but no alias has been added via our UI, it will not be recognized as an alias.
This feature can be very helpful if you have multiple sites that need to share some but not all of their data or if you have several sites with different content that are all based on a common framework. Using this feature can allow you to maintain one copy of the framework.
This feature is not a substitute for creating multiple sites. With this feature, one site is still just one site. There is no additional security, isolation, or protection implied by using this feature. Just as nothing protects https://www.example.com/one/ from the contents of https://www.example.com/two/, there is nothing between https://one.example.com/ and https://two.example.com/ if they are pointed to the same site by this feature.
Due to the internal security requirements for the Apache web server, .htpasswd files must be referred to by an absolute path. To find this path for your site, check the "Apache Site Root" value in the "Config Information" box on the Site Information page for your site.
For example, if you have a site named example and the .htpasswd file is in your site's /home/protected directory and your Apache Site Root value is /fsxx/example, your .htaccess file might read:
Although it should be impossible to retrieve an .htpasswd file using web access*, the Apache documentation recommends that you do not store .htpasswd files inside your document root. This is why we recommend using the protected directory instead. Whatever its location, an .htpasswd file must be world readable (or, at least, readable by group "web").
*Only the specific filename .htpasswd is protected from web access. If you use password files with other names in your public directory, they may be visible from the web, which is bad.
Due to the way our network handles incoming requests, it is not possible to use .htaccess files to block IP addresses from accessing your site; by the time the .htaccess file is considered, the incoming request has already been accepted.
However, we recognize the common desire to restrict accesses in this way. For this reason, we provide the ability to block accesses on a per-site per-IP basis at the edge of our network.
By default, all accesses are allowed. We maintain two lists for each site, an allow list and a deny list, which are processed in the order: allow, deny. Thus, an IP address that appears on both lists will be allowed. Entries to either list can contain either an IP address or a netblock specified in CIDR format (10.20.30.40/24).
You can see and manipulate your site's IP access controls (if any) in the "Config Information" box on the Site Information page.
To see exactly what blocked visitors see, visit blocked.nfshost.com, which blocks all visitors.
Once you have TLS working for your site, visitors to the HTTP version will be redirected to the HTTPS version by default, but you can control this behavior from our control panel.
Go to the Site Information panel for your site.
In the "Config Information" box, select the "Edit" button on the "HTTPS Redirection" line.
Set the Canonical HTTPS value to "on" if you want HTTP visitors redirected to HTTPS and "off" if you do not.
(Don't worry, this setting does not apply to any alias of the site that is not set up for TLS.)
You can also optionally indicate strict transport security. However, we don't recommend doing this unless you understand what it's for and how it works. If you get this wrong, you could potentially lock visitors out of your site for six months. The benefit is that if you do this, it will inform browsers to automatically use HTTPS to access your site, even if someone types in an http:// URL.
If you want to do this, add a line to an .htaccess file in your site's public directory something like:
Header always set Strict-Transport-Security "max-age=3600;" "expr=%{req_novary:X-Forwarded-Proto}=='https'"
Once you are very, very sure everything is working properly, you can change the 3600 to 15552000 and optionally add "includeSubDomains" after the semicolon to improve the rating of your site's security on sites like SSLlabs. However, be very careful in doing so, as this value represents 180 days, and if you make a mistake such as redirecting people to an HTTPS version of an alias that isn't set up for HTTPS, you can potentially lock them out of your site for that length of time.
Yes. Our servers support having more than one alternate name for
your site (such as www.example.com and another.example.org).
If you visit the Sites panel and then select
your site name in the "Short Name" list, you will see the Site Information page, where you can add and remove aliases at any time.
You may also add NearlyFreeSpeech.NET DNS to an alias at any time by visiting the Domains panel and choosing "Add" under the "DNS" column for the relevant alias (domain).
This can be very difficult. We wish we could push a magic button and take care of it for you, but the truth is that the scalability and performance of your site is much more under your control than ours. When sites encounter performance issues (such as 503 errors) under load, we almost always find that it is some problem with the site's programming that is responsible. Based on our extensive experience with such situations, we have prepared some general guidelines to help you design a site that is fast and scalable and remains available under heavy load.
First, if you are running WordPress, this information will not be much help. Basic WordPress installs are hopelessly incapable of surviving traffic surges. It requires extensive, specialized tuning to have a WordPress site that remains available under load. We recommend that you read and follow our Advanced WordPress Configuration guide, but even that is mostly in the nature of a good start.
For applications you are developing yourself, the following information may be helpful.
The basic principle of scalability is that however fast requests come in, they must complete at the same speed. If they do not, a backlog will form, response times will increase, and the site will eventually fail. This is the web's equivalent to the law of gravity: what goes in must come out. You cannot get around it.
Take advantage of our network to cache whatever you can. If you set Cache-Control: or Expires: headers for scripted content, our system can store copies in RAM and serve that content orders of magnitude faster than if you generate the same content over and over from a script for each request. (This is helpful primarily for content that is shared between users. I.e. if you personalize a page for each visitor -- such as by using cookies -- caching is unlikely to help. Keep this in mind when designing your site, and try to avoid using cookies or sessions where they are not needed, especially on top-level or high-traffic pages.)
Consider the availability, response times, and usage limits of any external resources your site depends on, like API's. The 100-requests-per-minute limit on that free message queueing web service (or mapping API, or geo IP lookup service, or whatever) you're using seems like a lot until you wind up on the front page of Reddit. Likewise, if your site depends on an external resource and that resource goes down, it's likely to cause timeouts on your site, and those can take forever, leading to a rapid collapse of the site.
Don't do anything that causes incoming requests to be serialized, as that will cause the site to work fine normally (or in testing), but completely collapse under even trivial load. Nobody intentionally serializes requests; it's generally the side effect of something that seemed like a good idea at the time. Making every request obtain an exclusive lock on the same file, like a log file, is one common way to do this. (N.B. if you use mod_rewrite and enable logging, it does exactly this.)
Your database can also be a source of performance problems. Although SQLite performs extremely well under low concurrency, it uses file locking and can have major scalability problems if any writes are performed. Don't use SQLite for an application you intend to scale unless it is read only, use MySQL instead. MySQL's base performance is slower, but it handles high concurrency much better. However, it is not a magic bullet. You should carefully consider indexing and locking, and monitor slow queries in order to get good performance from MySQL. With MySQL, there are often performance thresholds where exceeding a limit causes a dramatic drop in performance. One example is the use of temporary tables. Small temporary tables are stored in RAM. But large ones are written to disk, causing a dramatic drop in performance the minute a table exceeds the threshold for being stored in RAM.
If your site uses caching or temporary files (including PHP's default file-backed session handling), make sure the files are well-organized and routinely pruned. Directories containing tens of thousands of files that are traversed for every request can saturate your available I/O resulting in extremely poor performance.
If part or all of your application requires very high concurrency, particularly for long lived requests, don't use PHP. PHP's one-process-per-request model is not well suited to large numbers of concurrent requests, especially if they are mostly idle. Something like Node.JS is much more effective for that purpose and can scale to thousands of simultaneous connections, whereas PHP will typically choke at dozens. (Or, if it does not, you will likely choke when you see the bill; Node.JS not only handles high concurrency much better, but it also handles it much more cost effectively.)
Building scalable web sites is a high art, and the tips shared here only scratch the surface. But hopefully they offer a place to start on the long, hard journey to building a site that can handle hundreds of thousands of simultaneous users and dozens of requests per second. (And yes, we host those types of sites.)
If you configure a site type that supports arbitrary daemon processes, the infrastructure that initializes them does not process command line arguments. In the rare case that you don't need any, you can run the daemon executable directly from the 'Command' field of the Daemon management interface. In all other cases, you will need a run script.
A run script is a short shell script that lets you customize the environment for your daemon without worrying about the massive stack of stuff we have to do to make sure your daemon runs in the context of your site. A typical, minimal run script is an executable file that looks like this:
(The above is a fictional example; it is not a valid command. You will have to customize it for however your specific process specifies what port to use and to stay in the foreground.)
Then, you enter the path to the run script as the command in your daemon configuration. This lets you customize the daemon's command line arguments. You can also take other actions if needed, like setting environment variables, removing temporary files from previous runs, running preflight database checks, etc.
When writing run scripts, always make sure the following key elements are present:
The shebang line is the first line of the run script. (#!/bin/sh)
The exec command in front of the daemon executable. (Saves RAM = lower costs, may also avoid problems with signal delivery.)
The daemon process must run in the foreground. (Otherwise it will be repeatedly killed and restarted.)
Starting the daemon is the last line in the run script. (Anything after that will almost never be run.)
Executable permissions on the run script. (chmod a+x myrun.sh)
To set up a custom server process, follow these steps:
Make sure your site's Server Type allows daemon processes.
Create a Run Script that starts your custom process.
On the Site Information panel for your site, in the Daemons box, choose the "Add a Daemon" button.On the Add Daemon panel, enter information about your daemon process:
Tag: A unique (within your site's daemon processes) alphanumeric tag to identify this daemon.
Command Line: The correct path to your run script.
Working Directory: The current directory when the daemon is started. When using a run script, ignore this and include a cd command in your script instead. The correct working directory is dependent on the software you are running.
Run Daemon As: Web servers should always be run as the "web" user and support servers should typically be run as the "me" user.
The "Add Daemon" button will add the new daemon. The system will attempt to start it automatically within about a minute.
Watch the Site Information panel to see if the daemon process starts and use its log file to debug any issues.
If (and only if) your custom process is a web server intended to handle incoming requests, you will also need to create a proxy:
On the Site Information panel, in the Proxies box, use the "Add a Proxy" button.
Enter the correct information required by your daemon process:
Protocol: What protocol the system should use to communicate with your daemon process.
Base Path: Which part of the site should be directed to the daemon process. Must begin and end with a forward slash.
Document Root: What to replace the Base Path with when directing requests to your daemon process. Must begin and end with a forward slash. Some daemons need this to be based on the process's working directory (e.g., "/"). Others, including PHP-FPM, require an absolute path to the directory or routing script (e.g., "/home/protected/my-daemon/routing-script.php/").
Target Port: The TCP port number (in the range 1024 to 65535) where your daemon process listens for requests. The correct port number depends entirely on your daemon process.
Test and debug the proxy.
For additional information about this process and a complete example, please see the Django how-to on our blog.
