Unable to match on HTTP pseudo headers that start with : (colon)
What happened:
tried to match on a http pseudo header in my HTTPRoute
- matches:
- headers:
- name: ":scheme"
value: "http"
Got this error
the Kubernetes API server reported that "envoy-gateway-system/httpbin-test-http-3b88a86a" failed to fully initialize or become live: HTTPRoute.gateway.networking.k8s.io "httpbin-test-http-3b88a86a" is invalid: spec.rules[0].matches[0].headers[0].name: Invalid value: ":scheme": spec.rules[0].matches[0].headers[0].name in body should match '^[A-Za-z0-9!#$%&'*+\-.^_\x60|~]+$'
What you expected to happen:
The HTTPRoute would get accepted and I would be able to add a redirect filter which redirects to https only when the current request is http, else you end up also getting a redirect for https
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Pseudo headers defined in https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.1
curious why http2 pseudo headers are not supported https://github.com/kubernetes-sigs/gateway-api/blob/9deb057afb6a5796b5101bfbec1988844b6a8c80/apis/v1beta1/httproute_types.go#L433
Sorry we missed this one @arkodg! This was in an effort to avoid having multiple ways to express the same thing. Take the example of the :method header used in the spec - we already have a method matcher. How would we handle the situation when both were specified?
This is at least theoretically a solvable problem, but it would be helpful to clarify if this is really about having a way to match the scheme of a request or a way to match any arbitrary pseudo header.
thanks for sharing the history !, specific ask here is to provide a way to match scheme, should I update the issue title or create a new one ?
I think a use case for matching on scheme (that works with HTTP1 & 2) would be to help avoid redirect loops
see here: https://github.com/kubernetes-sigs/gateway-api/issues/1185#issuecomment-1962181068
yep, SGTM. I think this is a pretty big gap in the API. A new issue is probably the best way to cover this, but I think it probably justifies a mini-GEP.
Made a new issue: https://github.com/kubernetes-sigs/gateway-api/issues/2809
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.