Unable to match on HTTP pseudo headers that start with : (colon)

[arkodg]

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

[arkodg]

curious why http2 pseudo headers are not supported

gateway-api/apis/v1beta1/httproute_types.go

Line 433 in 9deb057

// - ":method" - ":" is an invalid character. This means that HTTP/2 pseudo

[robscott]

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.

[arkodg]

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 ?

[dprotaso]

I think a use case for matching on scheme (that works with HTTP1 & 2) would be to help avoid redirect loops

see here: #1185 (comment)

[robscott]

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.

[dprotaso]

Made a new issue: #2809

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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