r-Tune

BoostEdge's HTTP service has a very high adaptation capacity. It supports highly detailed configuration of HTTP request processing. Discrimination rules can be based on the host name, the path or any other part of the HTTP request header, and even on the browser's IP address.

Requests can therefore be processed differently depending on whether they are HTML pages, dynamic content (PHP for example) or graphic components.

If we take this example to the next stage, requests relating to dynamic content will be handled by the original server, while requests relating to static content will be served from the cache. In addition, the cache revalidation rules can be different for HTML pages and images.

Various methods can be used to compare the host name or path for the request with test values. An exact comparison is possible, or comparison with wildcard characters or even regular expressions (the so-called regexp) for more complex cases.

Specific selection criteria are required for the host name. For example, you can specify a plain name, an IP address in numerical format and so on.

In the case of the path, it can detect a virtual path, an extension (.jpg), a directory name (ending with "/") and more.

Extended selection criteria

If the processing selection criteria described above are not sufficient, you can use very general selection expressions. These are written in the form of logical expressions (Boolean) that can include terms representing any part of the request.

For example, to consider the browser type, you can use an expression in the following format: match (query.header.UserAgent, "*Mozilla*"). This example shows that the fields in the HTTP header are represented by factors in the format query.header.. All standard fields can be used in this way. It is also possible to test non-standard fields. For example, the presence of a X-my-own-field field can be tested by an expression in the format !query.header.field["X-my-own-field"].empty.