Apache configuration

The configuration of the Apache HTTP Server (Apache) can vary between OS distributions; see the documentation specific to your installation of Apache.

1. Locate your system's Apache configuration.

   Common configuration directories include:

   • /etc/httpd/conf/
   • /etc/apache2/
   • /usr/local/apache2/conf/
   • /Applications/XAMPP/etc/

   Within the configuration path, the main Apache configuration file is usually named one of the following:

   • httpd.conf
   • apache2.conf

   A longer discussion on the possible locations and names of Apache configuration files is available here: DistrosDefaultLayout

2. Set up an Apache virtual host (vhost) for your installation.

   If your Apache configuration directory contains the directories sites-available and sites-enabled:

   1. Copy the appropriate virtual host definition below into the file sites-available/swarm.

   2. Enable the P4 Code Review virtual host definition.

      sudo a2ensite swarm

   Otherwise, copy the virtual host definition below into the bottom of the main Apache configuration file, httpd.conf or apache2.conf.

   Virtual host definition example for Apache 2.4:

   <VirtualHost *:80>
       ServerName myswarm.host
       AllowEncodedSlashes NoDecode
       ServerAlias myswarm
       ErrorLog "/path/to/apache/logs/myswarm.error_log"
       CustomLog "/path/to/apache/logs/myswarm.access_log" common
       DocumentRoot "/path/to/swarm/public"
       <Directory "/path/to/swarm/public">
           AllowOverride All
           Require all granted
       </Directory>
   </VirtualHost>

   See Apache's virtual host documentation for details: Apache Virtual Host documentation

   If you have installed P4 Code Review on a host that does not provide other web services, you may wish to disable Apache's default site configuration. Doing so means that regardless of the hostname a user might use to reach the web server hosting P4 Code Review, P4 Code Review would be presented.

   Be aware that disabling Apache's default site configuration could disable existing web services or content.

   Disabling Apache's default site configuration on Ubuntu hosts is easy. Run:

   $ sudo a2dissite 000-default

3. Customize the virtual host definition.
   1. Replace myswarm.host with the hostname for P4 Code Review on your network. This may require adjusting the DNS configuration on your network.

   2. Replace myswarm with the name of the subdomain hosting P4 Code Review. Many administrators choose swarm.

      The string myswarm in the log file paths: this should match the subdomain name and prefix for the log files, to help coordinate the active host with the log files for that host. Doing this is particularly useful when your Apache server hosts multiple instances of P4 Code Review.

   3. Replace /path/to/apache/logs with the path where your Apache stores its log files. Apache's log files are typically named access_log and error_log.
   4. Replace /path/to/swarm with the path to the P4 Code Review directory.

4. Verify that the correct Apache modules are enabled.

   • To query whether the PHP and Rewrite modules are active, use the apachectl utility to list all of the active modules (this may be named apache2ctl on your system):

     apachectl -t -D DUMP_MODULES

   • Simply look for php8_module and rewrite_module in the output. If you see them, skip ahead to step 5.

   • If the Apache utility a2enmod is installed, use it to enable the PHP and Rewrite modules:

     sudo a2enmod php8 rewrite

   • Without the a2enmod utility, edit the Apache configuration file by hand. Locate your Apache configuration file for modules and either uncomment or add the following lines:

     LoadModule  php8_module     libexec/apache2/libphp8.so
     LoadModule  rewrite_module  libexec/apache2/mod_rewrite.so

   • Note that your Apache installation may have different paths for the location of its modules (the .so files).

5. Restart your web server.

   • To ensure that the Apache configuration changes you made become active, restart the web server.

     sudo apachectl restart

   • Query Apache's active virtual hosts and modules to confirm your changes are in effect:

     apachectl -t -D DUMP_VHOSTS
     apachectl -t -D DUMP_MODULES

   Apache must be configured to use the prefork MPM because P4PHP does not support threaded operation.

   The prefork MPM is the default for Linux Apache installations, so you may not have to do anything.

   For more information on Apache MPMs and configuration, see: Multi-Processing Modules (MPMs)

6. Configure PHP, see PHP configuration.

Real-time updates Apache configuration

P4 Code Review real-time updates use a WebSocket gateway that is normally exposed through Apache on the same host and port as the main application. Browsers connect to the /ws path, and Apache proxies that request to the local gateway process.

Packaged DEB and RPM installs should enable the required Apache wiring automatically when the feature is enabled. Tarball and manually customised deployments must confirm that the active virtual host includes the WebSocket proxy configuration.

Required Apache modules

The WebSocket proxy path requires the following Apache modules:

• mod_proxy for reverse proxy support

• mod_proxy_http for HTTP backend proxying.

• mod_proxy_wstunnel for WebSocket upgrade handling.

• mod_headers for request-header controls on the /ws path.

• mod_remoteip when P4 Code Review is behind a load balancer, CDN, or trusted reverse proxy.

On tarball deployments, enable these modules manually according to your operating system and Apache packaging. For example, Debian and Ubuntu based systems commonly use:

 a2enmod proxy proxy_http proxy_wstunnel headers remoteip

Virtual host include

Stock DEB and RPM installations proxy /ws using an inline configuration block in perforce-swarm-site.conf. These deployments do not usually require a separate Include statement.

HTTPS, tarball, and manually customised deployments may instead include a separate proxy configuration file.

The Include statement must apply to the same virtual host that serves the main web application, because browsers connect to the same external origin and use the /ws path.

The proxy configuration should:

• Disable forward-proxy mode with ProxyRequests Off

• Proxy only the WebSocket endpoint, normally /ws

• Use WebSocket upgrade handling for the backend gateway connection.

• Strip client-supplied credential and trust headers such as Authorization, Cookie, X-Real-IP, and X-Forwarded-User on the WebSocket path.

• Avoid exposing the gateway's loopback port directly to users.

Load balancers and client IPs

If Apache receives traffic from a load balancer, CDN, or reverse proxy, configure mod_remoteip with only the trusted proxy CIDR ranges. This lets Apache and the WebSocket gateway apply per-client limits using the real client IP instead of treating all users as the load balancer.

Verification

After changing Apache configuration, reload Apache and verify the WebSocket connection in browser DevTools. A working connection to /ws should show HTTP status 101 and remain open. If the request finishes immediately or never upgrades, check that the active virtual host contains the WebSocket proxy configuration and that the required proxy modules (mod_proxy_wstunnel) are enabled.

For the full setup and troubleshooting flow, see Real-time updates.