Many websites consist of several applications: the website itself, an API, a WebSocket service for live features or a tool for statistics. Until now, this required a proxy on your own server that distributes the requests by path. With path rules, ShieldCache takes over this task: requests whose path starts with a certain beginning go to their own target instead of the origin of the site.
How to create a path rule
- Open the site in the customer area and switch to the Origin tab, sub-tab Path rules.
- Click Add rule. The examples in the dialogue fill in typical values.
- Enter the path, for example
/api/, and the target: address (IP address or host name), port and whether ShieldCache should connect encrypted. - Choose whether the path prefix is removed and whether the cache applies to this path (see below).
- Save and click Apply. Use the lightning icon in the list to test the target from the proxy.
Example
Your website runs on the origin, the API on a separate server. With the rule /api/ → 203.0.113.20:8080 and “Remove path prefix”, calls to www.muster.de/api/users go to the API server as /users - everything else goes to the origin as before.
Which rule applies?
Matching is “starts with”, upper and lower case do not matter. If several rules match, the one with the longest path applies: /api/v2/ comes before /api/. /api/ only matches paths below it, not /api itself; /api matches /api, /api/users and also /apix. The path / alone is the origin of the site.
The settings of a rule
- Target: IP address or host name of a publicly reachable server and the port of your application. Port 80 only works without, port 443 only with encryption. As with the origin, internal and private addresses are not allowed.
- Verify certificate: On by default for encrypted connections. Only switch it off for self-signed certificates.
- Host header: If left empty, the target receives the requested domain. If your application expects a fixed name, enter it - with HTTPS it also applies to the certificate.
- Remove path prefix: Off (default): the target receives the path unchanged, i.e.
/api/users. On: the beginning is removed and the target receives/users; parameters such as?seite=2are kept. This corresponds to a proxy with a slash at the end of the target address. - Cache: Off (default): requests to this path always go directly to the target, never from the cache - right for APIs and live data. On: the cache rules of the site apply.
What still applies to path rules
Firewall, rate limits, IP and country rules, access protection, file protection, custom headers and error pages also apply to paths with a rule. Timeouts and the headers with the visitor IP are taken over from the origin of the site (Origin tab, sub-tabs Server and Advanced). WebSockets are passed through; with “Cache” off also without an idle timeout. The statistics count requests to a target like requests to the origin.
How many rules?
The number applies per site and depends on the plan: Starter 3, Professional 10, Enterprise 25 rules. You can see the current status at the top of the list.
Test the target first
Save the rule and test the target with the lightning icon before you apply. The test requests the path that the target will see later - with the prefix removed, that is /. If your application answers there with 404, this is not an error: what matters is that the target is reachable.
Can a rule distribute to several servers?
No, each rule has exactly one target. Failover with further servers is available for the origin of the site, see Setting up the origin server.
My WebSocket service drops the connection.
Leave “Cache” off for this path and do not set a rate limit on the path of the connection. Check whether your service expects the path with or without the prefix and adjust “Remove path prefix”.
I changed my plan and now have more rules than allowed.
A change to a smaller plan is only possible once every site has at most as many rules as the new plan includes. Remove surplus rules and apply the change.