Backends

Backend Monitoring

The Web Accelerator constantly monitors the state of the backends, checking that requests for a specific URL return 200.

When monitoring reports an error, the Web Accelerator stops sending requests to that backend. If there are no other functioning backends, it will continue to respond with the objects still in cache even after their expiration, and then with a courtesy page. This way, short outages or maintenance of a cacheable site can remain unseen by visitors.

Usually, Seeweb staff installs a ping.php file in the site, or in a new ad hoc domain in case the backend server manages multiple sites. In the case of sites managed with Wordpress, the file also automatically monitors the operation of the database server. In any case, the customer can provide a monitoring URL suitable for their needs.

Courtesy Page

If all backends are unreachable and there is no usable response in the cache, the Web Accelerator responds with a courtesy page.

If desired, it is possible to customize it with your own graphics.

Since the courtesy page must also work when the backend is not available, our staff will inline any CSS and images. We recommend that it does not exceed a size of approximately 10 kB.

Backends Load Balancing

Redundancy and scalability of backends can be managed with a load balancing mechanism: the Web Accelerator can forward traffic to multiple backends and ignore non-functioning ones.

Multiple Backends

In the case of complex sites where different parts of the same domain are managed by different backends, the Web Accelerator can manage the routing of requests to the appropriate backend based on the URL or other characteristics.

Visitors IP Management

The backend receives all requests from the Web Accelerator's IP and can use the standard X-Forwarded-For header to get the visitor's real IP.

If the backend uses Apache, our staff will configure mod_rpaf or mod_remoteip to handle this transparently.

For backends with IIS this can be used:

Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' ↩
  -filter "system.applicationHost/sites/siteDefaults/logFile/↩
  customFields" -name "." -value @{logFieldName='X-Forwarded-For';↩
  sourceName='X-Forwarded-For';sourceType='RequestHeader'}

HTTPS Request Management

The Web Accelerator also performs as the TLS terminator, so requests originally made with HTTPS always arrive at the backend with HTTP and can be distinguished by an X-Forwarded-Proto: https header.

In the default configuration, the Web Accelerator performs the redirect from HTTP to HTTPS, so the backend can be configured with just HTTP and with no need to directly manage the redirect logic.

If the CMS wants to distinguish HTTP requests from HTTPS requests, it can be integrated with this Apache directive, which our staff usually has already installed in the server's general configuration:

SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on

If nginx is used instead, it is possible to configure, for example in /etc/nginx/fastcgi.conf:

fastcgi_param X_FORWARDED_PROTO $http_x_forwarded_proto if_not_empty;

Rarely, some Wordpress plugins require inserting code like this directly into wp-config.php:

/* Per la gestione di HTTPS tramite il Web Accelerator --Seeweb */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
       && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS'] = 'on';

Timeouts

The Web Accelerator implements timeouts at different levels to terminate requests that take too long. We recommend not increasing them in a generalized way to avoid making the service more vulnerable to denial of service attacks.

Our staff is available to investigate any timeouts that are too short, but usually in the most common case it is triggered the one related to the first byte of the response sent by the server. It is possible to increase it, but this often indicates that the application is poorly written and buffers a large response instead of sending it as it is generated.