The client browser uses the CDN API endpoint to run Zephr rules. The way in which you configure this endpoint defines the domain from which the script runs; for example, Staging or Production.
The endpoint can be configured in the following ways:
- Preserve the explicit cdnAPI endpoint
- Reverse proxy
Preserve the Explicit cdnAPI Endpoint
You can set the endpoint to a pre-determined Zephr CDN. All GET and POST calls must be forwarded to /blaize* and /zephr* API endpoints.
This approach ensures that the browser runs the correct version for the site; for example, staging or production.
To preserve the explicit cdnAPI endpoint, you must set a subdomain. A Canonical Name (CNAME) record points to the Zephr CDN API endpoint from this subdomain. You must use the subdomain to ensure that the cookie is a first-party cookie.
run() method as follows:
<subdomain>.<site>.com canonical name = <subdomain>.<site>.cdn.zephr.com
Note: You must configure separate subdomains for each site in the same format. For further information, see Sites.
To use reverse proxy, you must remove the explicit
run() method. This means that the API calls use the origin URL.
The resulting feature decision URLs are constructed as follows:
- Rule retrieval: https://<site>/zephr/feature
- Rule decisions and outcome retrieval: https://<site>>/zephr/feature-decisions
You must configure a rule on your server to change the origin domain to the actual Zephr endpoint and preserve the path. The proxy rule must include /blaize* and /zephr* URLs. Both GET and POST methods must be forwarded.
Note: This method allows you to deploy multiple sites on the same web service distribution without support from your technical team each time a new site is deployed.
For further information on reverse proxy, including sequence diagrams, see the Use Zephr Functionality with Third-Party CDNs topic.