> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Header Based Routing for AB Testing
> Using Gateway API HTTPRoute matches to route requests by headers, paths, queries, and methods for A/B testing and progressive feature rollouts with NGINX Fabric Gateway.
Header-based routing directs requests to different backends by inspecting request attributes (headers, cookies, query parameters, path, HTTP method, etc.). Compared with weight-based routing, header-based routing gives you finer-grained control for A/B experiments and progressive feature rollouts because you can evaluate any information the client sends and apply precise rules to route traffic.
A common A/B test use case: you want to test a redesigned registration flow only for *new* customers. The gateway or an upstream service validates whether a user is new (by consulting cookies, caches, or other data sources) and then injects an attribute such as `new-customer: true`. The HTTP gateway uses that attribute to route the request to the new registration backend; other users continue to the existing flow—transparent to the end user.
When the backend receives the registration request, it gets the full request body plus any flags or headers the gateway added (for example, `new-customer: true`). The backend uses that metadata to complete the appropriate registration flow.
In an NGINX Fabric Gateway environment, you implement this behavior with the Gateway API’s HTTPRoute resource. An HTTPRoute rule defines:
* one or more matches (what attributes to inspect), and
* backendRefs (where to send matching requests).
Matches can include path, headers, query parameters, and HTTP methods. You can also apply filters and other Gateway API features as needed.
At a high level:
* A match declares what to look for (path, header, method, query).
* backendRefs list the target services for traffic that meets those matches.
You can combine multiple match criteria to build precise rules. For example, route requests whose path starts with `/coffee` and that include a header `version: v2` to `coffee-v2`; route other `/coffee` requests to `coffee-v1`.
Note: the YAML snippets below are conceptual fragments showing match logic. In an actual HTTPRoute resource, `matches` are nested under a `rules` entry and `backendRefs` are declared at the rule level. See the Gateway API schema for exact field layout and supported match options: [https://gateway-api.sigs.k8s.io/references/spec/](https://gateway-api.sigs.k8s.io/references/spec/).
Example: path + header match (route to coffee-v2 when header `version: v2` is present)
```yaml theme={null}
- matches:
- path:
type: PathPrefix
value: /coffee
headers:
- name: version
value: v2
backendRefs:
- name: coffee-v2
port: 80
```
Example: path-only match (route to coffee-v1 for `/coffee` requests that do not match the header-based rule)
```yaml theme={null}
- matches:
- path:
type: PathPrefix
value: /coffee
backendRefs:
- name: coffee-v1
port: 80
```
Method-based routing is another option (less commonly used for A/B testing). For example, route `POST` requests to a specific backend:
```yaml theme={null}
- matches:
- method: POST
backendRefs:
- name: coffee-v1
port: 80
```
Because Gateway API implementations evaluate matches according to their semantics (for example, longest prefix, specificity, or explicit rule order), design your rules to avoid unintended overlaps. Prefer specific matches (new flows) before more general fallbacks (existing flows).
Table: common match types and typical use cases
| Match type | When to use | Example snippet |
| - | - | - |
| Path | Route by URL structure (e.g., feature endpoints) | `path: /coffee` |
| Header | Target users, versions, or flags (`Cookie` or custom headers) | `headers: - name: version value: v2` |
| Query parameter | A/B test via URL parameters (e.g., `?test=true`) | `queryParams: - name: test value: true` |
| Method | Differentiate by HTTP verbs (e.g., POST vs GET) | `method: POST` |
You can combine path, header, query-parameter, and method matches in a single HTTPRoute match. Use the most specific rules first (for new flows) and fall back to broader rules (legacy flows) to prevent ambiguous routing.
References and further reading
* Gateway API specification: [https://gateway-api.sigs.k8s.io/spec/](https://gateway-api.sigs.k8s.io/spec/)
* Gateway API reference: [https://gateway-api.sigs.k8s.io/references/spec/](https://gateway-api.sigs.k8s.io/references/spec/)
* NGINX Fabric Gateway documentation (for product-specific filters and behavior)
That’s the core idea: use header-based matching (and other request attributes) in HTTPRoute rules to implement targeted A/B tests and controlled rollouts in an NGINX Fabric Gateway / Gateway API environment.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.