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.