Content-Switch Fallback and Case-Sensitive API Path
An e-commerce team uses a content-switching vserver cs_storefront on 443 with SSL termination. Three policies are bound: priority 100 pol_static matches HTTP.REQ.URL.STARTSWITH("/static") and targets lb_static; priority 110 pol_api matches HTTP.REQ.URL.STARTSWITH("/api") and targets lb_api; priority 120 pol_img matches HTTP.REQ.URL.STARTSWITH("/img") and targets lb_img. The CS vserver has lb_web configured as the default LB vserver. A new mobile client calls /API/v3/catalog and gets the generic web 404 page instead of JSON. Separately, a request to /static/api/config.json is served by lb_static even though the team expected lb_api because the path contains /api. The team also wants any unmatched request to go to lb_web, and if lb_web is down, to return a branded maintenance page from lb_maint rather than a generic 503. They cannot change the mobile client code.
1. Why does /API/v3/catalog reach lb_web, and what exact policy change would fix it? Discuss the cost of case-insensitive matching.
Read the worked answer
STARTSWITH in a Citrix ADC policy expression is case-sensitive. /API/v3/catalog does not match HTTP.REQ.URL.STARTSWITH("/api"), and none of the other policies match, so the CS vserver uses its default LB vserver lb_web, which returns the web 404. The precise fix is to evaluate the path case-insensitively, for example HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH("/api"), or HTTP.REQ.URL.PATH.TO_LOWER.STARTSWITH("/api"). Use .PATH rather than the full URL so a query string cannot affect the match. A regex such as (?i)^/api also works but is more expensive to evaluate. The trade-off is that ignore-case also matches /Api and /API variants; if those are meant to be different backends, do not make the whole rule case-insensitive-add explicit policies for the variants you intend to support. Check hit counts after the change with show cs policy -stats.
2. The team expected /static/api/config.json to go to lb_api. Is the current result a bug? How would you change the policy set if the expectation is real?
Read the worked answer
The current result is not a bug: policies are evaluated by priority, first match wins. pol_static at priority 100 matches /static/api/config.json before pol_api at 110 is considered. If the team really wants that URL to go to the API, raise pol_api above pol_static (lower priority number) or make the static rule more specific, for example exclude paths beginning /static/api/. But be careful: moving pol_api above pol_static will also send /api-prefixed static assets to the API backend. The safer change is a dedicated higher-priority policy for the exact /static/api/ prefix that targets lb_api, leaving the general static rule intact. Verify with show cs policy and by requesting the URL through the VIP; the response body or a test backend header should identify which LB vserver served it.
3. How would you implement the branded maintenance fallback when lb_web is down? Be specific about the CS default and the LB backup vserver.
Read the worked answer
The CS default only handles requests that match no policy. It does not provide a maintenance page when lb_web is selected but has no healthy services; in that case the CS vserver can return a generic 503. Implement the fallback at the LB layer: set lb_web's backup vserver to lb_maint (for example set lb vserver lb_web -backupVServer lb_maint). Ensure lb_maint has at least one service that is UP under its own monitor. The CS vserver keeps lb_web as its default; traffic goes to lb_maint only when every service in lb_web is down. Do not make lb_maint the CS default, because then all unmatched traffic would get the maintenance page even while the web tier is healthy. Verify by disabling all lb_web services in a test window and confirming the branded page, then re-enabling.