Note: We are working on updating our documentation, this page has been identified as still needing improvement. This notice will be removed once these improvements are complete.
SourceForge.net provides project web and developer web services based on a common platform. As follows are the technical details of that platform, provided to help you deploy pages and applications under these services.
SourceForge.net uses a shared environment for the project and developer web services. You should assume that all files uploaded to our servers may be viewed by other users.
Our web servers are configured with the following:
It is the general policy of SourceForge.net that we will install additional software on the servers only when it is available from our software vendors. To request the install of additional software on our servers, please submit a feature request.
Data (i.e. files) served from the web servers may be throttled in order to optimize serving HTML and image content. As result, access to larger files in web space may be orders of magnitude slower than access to smaller files. Large file content belongs in the File Release System.
Keepalive (HTTP 1.1 Pipelining) support is not enabled in our configuration.
Due to past abuse, outbound access to other hosts from the web servers is strictly prohibited, and is blocked by firewall rules. This includes access to other SourceForge.net hosts; the only exceptions to this policy are access to our project database servers and authorized outgoing emails. SCM server access is not available from the project web servers. Any content needed from other SourceForge.net hosts should be retrieved and stored as a file or database entry that may then be accessed from scripts on the project web servers.
While our PHP install (and other languages) include support for things like LDAP, IMAP and Postgres, we do not permit inbound or outbound connectivity using these protocols. These components are included so third-party code may be kept stock when being deployed on SourceForge.net web servers; and to support the testing of project code which requires these functions.
Files for project web and developer web may be managed using the file management service or interactive shell service.
Service usage is not restricted by disk quotas. That said, file releases should be placed in the File Release System (FRS) rather than being placed in web space.
Large files should not be served from the project web service; alternatives are available. Files that are too large to be served from the project web services will generate a HTTP 403 error for the requester, based on a file size cap we have implemented. This cap, which prevents certain types of abuse, is set to reduce legitimate impact while encouraging use of the File Release System.
Files uploaded to the project web servers from MS Windows-based workstations may require adjustments to their line endings. The 'dos2unix' program may be used to correct line feed style for uploaded files.
$ dos2unix filename_to_convert
If you make a file/directory group writable, it is writable by your project's web applications (but not by other projects' apps). You should set as few files/directories as possible to be group-writable, as that helps to protect against security exploits of your project's web apps being able to modify your web files.
You should remove the world-readble bit from a file that contains secrets, such as DB passwords. As long as the file is group-readable, it can be used by your web apps.
You don't need to worry about file ownership between your project's users, because we use a special filesystem that grants all authorized project members the same rights to change your project files. So, feel free to chmod, edit, etc., regardless of the file's owner. See Project Web Filesystem Permissions for full details.
The index page for a website loads on default into a browser when no specific filename is specified (i.e. https://sourceforge.net and https://sourceforge.net/index.php are the same page, the index.php file loads by default). The project web servers support 3 default index pages (in this order of preference): index.php, index.html and index.shtml. No other filenames will load by default; this means that an index.htm file would need to be renamed to index.html to load. If there is an index.php and an index.html file in place at the same time, proper or expected access to the web page may be hindered.
If no index page is found, we will display a default index page with information about the project or the developer.
We allow the use of Option+Indexes in an .htaccess file to display basic directory listings.
However, DirectoryIndex may not be overridden; Users may not add their own index.foo filename, as an example.
The filenames selected for files to be served by the project web servers can make a large difference on how a file is handled. The extension determines how a file is served to the end user and if any processing should be done on the file or if it should be served as-is to the requester. The three major file extensions supported for web files are .html for HTML pages, .php for PHP pages and .shtml for HTML with SSI. SSI will only be applied on files with an .shtml extension.
PHP is a hypertext pre-processor. It takes the contents of a PHP file, processes the code contained within, and generates HTML to be passed on to the client on the other side. This allows for dynamic, interactive web sites. More information about PHP may be found at http://www.php.net or by reading the PHP documentation.
PHP support is provided using Apache's mod_php. Files placed in the htdocs directory structure which have an extension of .php (such as index.php or filename.php) will be considered PHP scripts.
Many third-party applications require sessions support. Sessions are commonly implemented in PHP to track basic preference and authentication information about a user, as they browse pages on your project web site. We encourage you to store session data in your project database. However, file-based session data is also supported.
Our PHP configuration permits applications to use up to 16MB of memory. We strongly encourage you to optimize your application to run within this resource footprint. If your application requires more memory (it will return an out of memory error, stating that additional memory could not be allocated), and you have already optimized the memory usage of your application, contact SourceForge.net staff via Support Request. We may grant you permission to double the memory permitted for use by your application (to 32MB). If granted permission by SourceForge.net staff, you may create a .htaccess file in the directory of the PHP file that needs more memory. The .htaccess file should contain the following:
php_value memory_limit 32M
Alternately (and if granted permission by SourceForge.net staff), you may make the following change to the top of the PHP files that require more memory:
<?php ini_set("memory_limit", "32M"); ?>
In some cases, projects wish to display the contents of PHP files (i.e. their source code) rather than executing the code. PHP files given the .phps extension will be colorized and formatted for display by PHP, rather than being executed.
flock() Is not compatible with NFS. Since SourceForge.net serves project web content using NFS servers for data storage, the flock() function has been disabled.
CGI scripts are served only from the cgi-bin directory for the project; not from the htdocs directory space.
Common Gateway Interface, or CGI, is a method for executing binaries or interpreted scripts which generate HTML output, permitting the creation of dynamic web sites. CGI scripts may be written in a variety of programming languages. SourceForge.net supports the use of CGIs within the scope of our acceptable use policies for the web services.
In UNIX-based systems, CGI scripts must be run as a particular user. On our server, they are run as the user apache, a member of the group apache. Files that must be manipulated by scripts must be set to be group-writable. The shared environment of our web service has significant security implications for file-writing applications; please program your scripts accordingly. You are encouraged to make frequent backups of all project data.
The project web services support the following CGI languages:
Compiled CGI scripts are allowed, but are not supported.
All CGI scripts must be located in the cgi-bin directory provided to the project. This directory is the only one that has the proper permissions to execute scripts for a project (ensuring that the scripts are secure is a must before placing them in the location for execution). The cgi-bin directory for a project is located at /home/project-web/PROJECTNAME/cgi-bin (where PROJECTNAME is the UNIX name of the project, P is the first character in the project UNIX name and PR are the first two characters in the project UNIX name).
Additionally, CGIs need to be world-readable and executable. You may set these permissions by executing the following command on the file:
$ chmod +rx FILENAME
All CGI scripts must return MIME type data as their first line of output (or an "Internal Server Error" will result). A CGI may generate any kind of content, including HTML or images. The MIME type of our output is defined by the Content-type line. Examples of two content type lines are:
Content-type: text/html Content-type: image/jpg
The following are a list of some sites that may be useful for each of the supported languages. Do note that not all of the information contained applies to SourceForge.net, specifically that of how to transfer files to SourceForge.net hosts and file permissions (covered above).
Server-Side Includes, or SSI, are supported on the project web servers. SSI provides another method of producing dynamic web content. SSI commands are put into an HTML comment, which is interpreted by the web server, resulting in dynamically-generated HTML. For help on how to use Server-Side Includes, please read the "Apache Tutorial: Introduction to Server Side Includes".
SourceForge.net project web servers will apply SSI to files ending in the .shtml file extension. The executable permissions bit has no impact on our SSI handling; SSI files must have a .shtml extension.
The following types of service are not currently included in our offering. This list is provided as some popular hosting providers do include one or more of these services:
Projects may elect to install and use Open Source third-party applications, such as content management systems, template engines and discussion boards, within their project web space. SourceForge.net places no restrictions on the types of Open Source applications that may be hosted in project web space, provided they meet our other use requirements.
When using third-party applications, all installation, configuration and maintenance tasks fall to the project; SourceForge.net staff will not provide assistance related to third-party applications in project web space. If questions or concerns arise about deployment of software for your project team, please seek information from the software manual, the existing user community of that software, or the developers of that software.
Projects are responsible for ensuring all security fixes and version upgrades have been applied for software they deploy. It is important to keep in mind that the project web service is a shared environment; failure to apply security updates to your applications may impact the security of the project web service as a whole.
Projects are solely responsible for the backup and restoration of all data and software deployed in project web space.
In the event that we discover a vulnerable version of a third-party application has been deployed in your project web space, we may take this application offline without prior notice as to safeguard the security of the project web service for other users. Please take responsibility for all software you deploy in project web space.