Scripts

As of version 2.4.56 of the Apache web server, an important security fix was implemented for the vulnerability "Apache HTTP Server: HTTP request splitting with mod_rewrite and mod_proxy" (CVE-2023-25690). With this fix, all rewrite requests via .htaccess files that contain spaces or control characters in backreferences, will result in 403 error messages as these characters will not be escaped correctly before being transformed/rewritten. If you use the Live HTTP logs section of the hosting Control Panel to investigate the problem, you will find the full error:AH10411: Rewritten query string contains control characters or spacesThe change causing error AH10411 is considered code-breaking for some software applications like OpenCart and Drupal (see below), when there are space characters in Search Engine Friendly (SEF) URLs, images, or other elements. By default, the software applications display informational messages within the SEF URLs settings or their online documentations that spaces should be avoided and dashes should be used instead; however, that is not always possible. How to fix Apache error AH10411? To resolve problems with applications or custom scripts related to this change, you have two options: Remove all space characters (intervals) from your SEF URLs, page slugs, and file names that are rewritten via an .htaccess file. Add the BCTLS or B flags to your rewrite rules that rely on backreferences and may contain space characters. The second solution is usually preferred as it doesn't require you to modify all elements within your website, and restores the old rewrite behavior. To fix the "Rewritten query string contains control characters or spaces" error with the second solution, you will basically need to modify the rewrite rules with backreferences in your .htaccess file following this example:RewriteRule ^(.*)$ index.php?p=$1to:RewriteRule ^(.*)$ index.php?p=$1 [BCTLS] OpenCart In OpenCart, SEF URLs are generated with dashes instead of spaces by default. If some URLs or other elements of your website that contain space characters in their name return 403 errors while SEO URLs are enabled for OpenCart, the problem is most likely caused by the change implemented by the Apache web server team. To restore the old rewrite behavior for OpenCart search-engine-optimized links, you will need to change the following line in your .htaccess file:RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]to:RewriteRule ^([^?]*) index.php?_route_=$1 [BCTLS,L,QSA]You should repeat the same process (adding the BCTLS tag) for all rewrite rules with backreferences. Drupal Older versions of Drupal may return 403 errors due to intervals in the URL when Clean URLs are enabled. If this happens, you will need to change the following line in your Drupal .htaccess file from:RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]to:RewriteRule ^(.*)$ index.php?q=$1 [BCTLS,L,QSA]This should allow your Drupal application to again use pages, images, and other elements that contain space characters as was the case before the changes implemented in version 2.4.56 of the Apache web server. We would also recommend that you update to a newer version of Drupal where the Clean URLs are handled correctly and space characters are not supported.

The path to the Perl interpreter is: /usr/bin/perl Your Perl scripts need to begin with this line: #!/usr/bin/perl

We run both Python 2.x and Python 3.x on our servers. The path to the default Python 2.x interpreter is: /usr/bin/python If you want to use Python 3.x, the path to the interpreter is: /usr/bin/python3 Your Python 2.x scripts need to begin with this line: #!/usr/bin/python The Python 3.x scripts should start with: #!/usr/bin/python3

The path to the Sendmail binary is: /usr/lib/sendmail

The system path to the Ruby interpreter is: /usr/local/bin/ruby Your Ruby scripts need to begin with this line: #!/usr/local/bin/ruby  

The full system path to your hosting account's top folder (home directory) is: /home/user_name The system path to your main domain's directory is: /home/user_name/www/www/ That is where you need to keep the files for your main www subdomain (the contents of your site http://www.your_domain.com). The full system path to your private directory is: /home/user_name/private/ You can learn more on your private directory and its usage in our Private directory article. Note: You should change user_name with your actual username, e.g. /home/jane/www/www/.

CGI stands for Common Gateway Interface. The CGI programs run on the server and are usually used to process data received from a web form or to generate a web page with dynamic content. The CGI scripts may be written in a web programming language, such as Perl, Python, Ruby, and TCL. On our servers, you can store your CGI scripts anywhere within your disk space. They do not need to be in a particular folder. Be sure to include executable permissions for the script files. Permissions such as 775 and 755 will work fine. You can find more information on file permissions in the File and folder permissions section from our online documentation.  

Up-to-date information about the installed software packages that are available on our servers can be found on the System Information page of the Control Panel. Next to PHP and Perl, there are links that read more info; they will display the installed modules for the particular interpreter. If a module that you want to use is not listed there, let us know, and we will check if it is possible to install it for you.

The ionCube Loader PHP extension is available on our servers. You can enable it for a specific domain/subdomain via the Control Panel -> PHP Settings section by following these steps: Click on the Manage button next to the domain/subdomain. Check the box next to the ionCube extension from the Extensions section. Click on the Save changes button. You can also enable the ionCube Loader manually by adding the respective extension directive to a PHP configuration file (php.ini). Since there is a separate ionCube binary compiled for each PHP version, you should enable the PHP extension that matches the PHP version used by your script(s) from the following table: PHP version php.ini directive PHP 8.1   zend_extension=/usr/local/ioncube/ioncube_loader_lin_8.1.so PHP 7.4   zend_extension=/usr/local/ioncube/ioncube_loader_lin_7.4.so PHP 7.3   zend_extension=/usr/local/ioncube/ioncube_loader_lin_7.3.so PHP 7.2   zend_extension=/usr/local/ioncube/ioncube_loader_lin_7.2.so PHP 7.1   zend_extension=/usr/local/ioncube/ioncube_loader_lin_7.1.so PHP 5.6   zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.6.so PHP 5.3   zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.3.so Note: ionCube Loader does not support PHP 8.0. You can learn more about editing your PHP settings in our PHP Settings article. ionCube "Failed loading" errors If you encounter any ionCube loading errors similar to the one listed below: Failed loading /usr/local/ioncube/ioncube_loader_lin_7.2.so: /usr/local/ioncube/ioncube_loader_lin_7.2.so: undefined symbol: zend_ce_countable it is possible that there is a discrepancy between the PHP version used by your script and the PHP version used for compiling the ionCube extension. (Example: You are executing a script in a subdomain working with PHP version 7.4, but the ionCube module for PHP version 7.2 is loaded in the subdomain's php.ini file.) To fix this error, make sure that you have enabled the ionCube Loader extension compiled for the PHP version that is used by your script.

Zend Guard Loader is available on our servers. Please note that it supports only PHP 5.6 and PHP 5.3 which are in end-of-life status. You cannot use Zend Guard Loader for PHP 7. To enable Zend Guard Loader for PHP 5.6, you need to add the following line of code to a PHP configuration file (php.ini) in your account: zend_extension = /usr/local/Zend/ZendGuardLoader.so If you are using PHP 5.3, you need to load the following extension in a PHP configuration file (php.ini) in your account to enable Zend Guard Loader: zend_extension = /usr/local/Zend/ZendGuardLoader-5.3.so You can learn more on how to change your PHP settings in our Changing PHP settings article.

You can manipulate images with your scripts by using GD, ImageMagick(Imagick), and NetPBM. GD PHP is compiled with GD support on all our servers. You can use it directly with your PHP scripts. ImageMagick (Imagick) You can enable the ImageMagick PHP extension for a domain/subdomain via the Control Panel -> PHP Settings section by following these steps: Click on the Manage button next to the domain/subdomain where you want to use ImageMagick. Check the box next to the ImageMagick extension from the Extensions section. Click on the Save changes button. It can also be activated by manually adding the following line to a PHP configuration file (php.ini) in your account: extension = imagick.so Instructions on how to change PHP settings for your account are available in our Changing PHP settings article. You can also use the ImageMagick binaries directly. They are located in this directory: /usr/local/bin/ For example, the full paths to the convert and mogrify ImageMagick binaries are: /usr/local/bin/convert /usr/local/bin/mogrify NetPBM The path to the NetPBM binaries is: /usr/local/netpbm/bin

You can use custom PHP extensions on our hosting servers. The only requirement is that the extension should be compatible with the operating system of the server (Linux 64-bit) and the PHP version configured for your domain/subdomain. To use a custom PHP extension, you should upload it to the Private directory of your hosting account and add the absolute path to the extension file in your PHP configuration (php.ini) for your domain/subdomain as follows: extension = /home/your_username/private/custom.extension Note: You should replace your_username with your hosting Control Panel's username and custom.extension with the exact file name and location of the custom extension in your account. You can edit the main PHP configuration file for your domain/subdomain via the PHP Settings section of the hosting Control Panel. If you would like to learn more about the PHP configuration files supported on our servers, please check our article on PHP configuration files and priority. Installing SourceGuardian If you wish to load PHP files encrypted with SourceGuardian, you need to install SourceGuardian Loader. Step-by-step instructions on the installation process are available below: Create a PHP file (e.g. phpinformation.php) with the following content in the domain/subdomain where you wish to use the SourceGuardian Loader:<?php    phpinfo();?>You can create the file using the File Manager interface of the hosting Control Panel. You can get the SourceGuardian Loader compatible with the PHP version set for your domain using the SourceGuardian Loader Assistant. In the Loader Assistant page, you should enter the URL of the PHP file created in the previous step (e.g. http://your_domain.com/phpinformation.php) and click on the Detect button. Download the provided SourceGuardian Loader file to your computer, then upload it to the Private directory of your hosting account. You can upload the file using the File Manager interface of the hosting Control Panel. Add the following line to the PHP configuration file (php.ini) for your domain/subdomain: extension = /home/your_username/private/custom_extensionNote: You should replace your_username with your hosting Control Panel username and custom_extension with the exact name of the SourceGuardian Loader file you downloaded (e.g. the name of the SourceGuardian Loader extension for PHP 7.4 is ixed.7.4.lin).The main PHP configuration files for your domains/subdomains can be edited via the PHP Settings section of the hosting Control Panel. You can find more information about PHP configuration files in our PHP configuration files and priority article. If FPM is the PHP handler for your domain/subdomain, you should reload the FPM Master process for the new extension to be loaded correctly. To verify that the SourceGuardian Loader is installed successfully, open the SourceGuardian Loader Assistant page again, enter the URL of the PHP file created in the first step (e.g. http://your_domain.com/info.php), and click on the Detect button. The following message should be displayed:The latest version of SourceGuardian loader is already installed in your system and it is ready to run protected scripts.

Server Side Includes (SSI) is a simple to use server-side scripting language, whose primary use is including the contents of one file into another one dynamically or executing of CGI scripts. A couple of important guidelines you need to follow: 1) SSI commands always begin with <!--# and end with --> just like: <!--#directive parameter="value"--> There have to be quotes or space in front of -->2) The web page that adds the SSI instruction to include another page or program MUST end with .shtml or .sht rather than .html or .htm. Some examples of SSI: 1) If you want to insert a file into another one, you can use the include virtual command. The URL to the page you want to insert must be relative to the current web page rather than a full URL. For example: <!--#include virtual="file.txt"--> Тhis command includes the contents of file.txt in your file. file.txt and the SSI file must reside in the same folder - notice how this SSI instruction uses a *relative* URL instead of a FULL URL. This is very important to keep in mind when using SSI. And if your file.txt is in a subfolder named my_ssi, you have to add it following way: <!--#include virtual="my_ssi/file.txt"--> 2) If you want to execute a CGI script (in this case it is a Perl script) and include its output to your web page, use the following code: <!--#exec cgi="name_of_your_cgi_script.pl"--> 3) Printing the size of a file named file.html residing in a subdirectory called directory is very easy: <!--#fsize file="directory/file.html"--> 4) To print the last modification date of a specific file, you can use: <!--#flastmod file="directory/file.html"--> 5) Useful command for debugging: <!--#printenv --> It prints out a listing of all existing variables and their values. 6) Variables: You can easily define and use variables in your SSI scripts. For example, the following command defines the variable PI and assigns a value of 3,14159265 to it: <!--#set var="PI" value="3,14159265"--> Use the following command in case you want to print out the value of PI: <!--#echo var="PI"--> In addition to the variables in the standard CGI environment, these are available for the echo command, for if and elif, and to any program invoked by the document. DATE_GMT - The current date in Greenwich Mean TimeDATE_LOCAL - The current date in the local time zoneDOCUMENT_NAME - The filename (excluding directories) of the document requested by the userDOCUMENT_URI - The (%-decoded) URL path of the document requested by the userLAST_MODIFIED - The last modification date of the document requested by the userQUERY_STRING - The information which follows the ? in the URL which referenced this script. This is the query information. For example, the command below prints the last modification date of the current file: <!--#echo var="LAST_MODIFIED"--> 7) Flow Control Elements The basic flow control elements are: <!--#if expr="test_condition"--><!--#elif expr="test_condition"--><!--#else --><!--#endif --> The endif element ends the if element and is required.

You can use JavaScript with our service. JavaScript is not server-dependent; it is browser-dependent, and it can be used with any hosting service.

UPDATE as of December 2020: All our servers are currently running Debian Buster. To have the current/working directory as a module load path, you can use only Method 2 described below. --- Dated: 15 February 2019 This article is to explain an upcoming change in the configuration of Perl. It may affect scripts which load modules from the current working directory (cwd). General Back in 2016, Debian developers announced that they will be gradually removing cwd (.) from the module load path (@INC), as this practice is potentially dangerous, and can allow running malicious code under certain circumstances. More information can be found in the Debian lists.Following this announcement, the inclusion of (.) in the load path has been made configurable in Debian Stretch - this is the current Debian version on our servers.With the next major Debian release, the option to leave '.' in the @INC array server-wide will become unavailable. This means that the only way to keep this behavior would be to set it in the user scripts. That's why we are warning our Perl users - to make sure that their scripts do not rely on the inclusion of the current directory in the module load path.If you have Perl scripts on your site, and especially if they are custom-made, we advise you to revise them or consult their developers, to make sure that your scripts are not affected by the removal of (.) from @INC. Current configuration On February 9th 2019, the current working directory (.) was removed from the search path (@INC) on all servers. Re-enabling the old behavior If you would like to re-enable the behavior as it was before the configuration change, you can use one of the following methods: Method 1: Create in the private folder of your account an empty file named PERL_USE_UNSAFE_INC (/home/$your_CP_username/private/PERL_USE_UNSAFE_INC) With this file in place, all your Perl scripts will load modules from the current directory, with the lowest precedence. Note that this will be possible ONLY until the upgrade to Debian 10 Buster. Method 2: Add this line at the beginning of your Perl script/s:use lib '.'; This line adds the current directory to the beginning of Perl's search path  (@INC). Your scripts will continue to load modules from the current directory even after the upgrade to Debian 10 Buster. The deadline Although we cannot specify an exact deadline, as we cannot state when the next major Debian upgrade would be, we advise our users to pay attention to this matter and make sure that their scripts are compatible.