Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Http header routing pattern #1177

Open
gjreasoner opened this issue Oct 27, 2024 · 1 comment · May be fixed by #1183
Open

Http header routing pattern #1177

gjreasoner opened this issue Oct 27, 2024 · 1 comment · May be fixed by #1183

Comments

@gjreasoner
Copy link

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 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.

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
spec:
  hosts:
  - my-main-site.example.com
  - customer-id-1
  replicas:
    max: 1
    min: 0

While your remaining domains might look like

- custom-domain-1.com
- ...
- custom-domain-99.com
- *.svc.domain.com
@wozniakjan
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To Triage
Development

Successfully merging a pull request may close this issue.

2 participants