You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 header X-Customer-Id: customer-id-1 and register the hosts as customer-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
An env variable on the interceptor, KEDA_HTTP_ADDTL_ROUTING_HEADER=X-Customer-Id when blank or missing from the request, it still uses the HTTP Host header
This gives you an easy way to opt into the feature and have fallback/main site domains.
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.
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
The text was updated successfully, but these errors were encountered: