Open gjreasoner opened 3 weeks ago
I really like the idea of the feature, I think it's essential that http-add-on supports routing based on headers.
I would like to propose an alternative path on how it is implemented. Instead of ENV variable static for the entire traffic passing through the interceptor, it would be imho better to follow the design decisions from Gateway API. Mixing URLs and header values in spec.hosts
might lead to confusing UX.
Currently the HTTPScaledObject
allows routing based on hosts
and pathPrefixes
, e.g.
apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
spec:
hosts:
- my.domain.com
- my2.domain.com
pathPrefixes:
- /root
- /new-feature
Adding headers
to the spec would allow very fine-grained configurability resulting in overall increased satisfaction
apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
spec:
hosts:
- my.domain.com
- my2.domain.com
pathPrefixes:
- /root
- /new-feature
headers:
- name: x-header-test
value: abc
- name: x-header-test2
value: def
Proposal
Would like to use a HTTP header in the HTTP request to determine which service to route to using http header based routing pattern.
Use-Case
Imagine hundreds of customers each with 100s of different domains pointed to their own HttpScaledObject.
Rather than maintaining the 100 domains on
HTTPScaledObject
, you send a custom headerX-Customer-Id: customer-id-1
and register the hosts ascustomer-id-1
,customer-id-2
.This means your upstream can add/update/delete host names without needing to update HTTPScaledObjects or extra k8s ingress/services.
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
Can see this being implemented like
KEDA_HTTP_ADDTL_ROUTING_HEADER=X-Customer-Id
when blank or missing from the request, it still uses the HTTP Host headerThis gives you an easy way to opt into the feature and have fallback/main site domains.
While your remaining domains might look like