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

HttpRoute should be able to match path prefix with case-insensitive option #3123

Open
gorban opened this issue May 31, 2024 · 1 comment
Open
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@gorban
Copy link

gorban commented May 31, 2024

What would you like to be added:

Support for case-insensitive path prefix matching, e.g. with caseSensitive: false (naming not important to me, that's how it's called in xDS if you're using Envoy).

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: proxy-from-k8s-to-httpbin
spec:
  rules:
  - backendRefs:
    - ...
    matches:
    - path:
        type: PathPrefix
        value: /httpbin
        caseSensitive: false
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /

Why this is needed:

HttpRoute currently requires regular expressions to achieve case-insensitive path prefix matching.

  1. Existing code may expect URLs to be case-insensitive, since file systems can be case-insensitive. Windows Servers are a good example. Also, case-insensitivity helps users who might enter a URL manually in their address bar.
  2. We would also like to use replacePrefixMatch on a URLRewrite. This is explicitly disallowed for regular expressions, so we really need the case-insensitive support on prefix matches, specifically.
  3. Regular expressions are still a less optimal solution regardless:
    • The specific Gateway implementation may not guarantee reasonable ordering, and there is no flag to denote the priority of a regex match. We have to rely on a specific implementation like Envoy Gateway ordering the regular expression routes sensibly, which is not guaranteed by the Gateway API itself. If they are mis-ordered, a less specific path match could apply first. This is a problem if a more root path has an authentication requirement, but a nested, more specific path is intentionally public (like is common if you have a /prefix/authenticate path that accepts credentials to authenticate in the first place).
    • Regular expressions could be less performant.
  4. Feature parity with other API Gateway technologies (some required fields have be removed for brevity of examples):
    • Istio VirtualService, see ignoreUriCase:
      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: proxy-from-k8s-to-httpbin
      spec:
        http:
        - match:
          - uri:
              prefix: /httpbin
            ignoreUriCase: true
          rewrite:
            uri: /
    • Kong Gateway which uses Kubernetes Ingress API (doesn't have case-insensitive, but Kong has explicit regex priority for confidence the more nested, specific route is applied):
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: proxy-from-k8s-to-httpbin
        annotations:
          kubernetes.io/ingress.class: kong
          konghq.com/strip-path: \"true\"
          konghq.com/regex-priority: \"1\"
      spec:
        rules:
        - http:
            paths:
            - path: /~/(?i)httpbin
              pathType: ImplementationSpecific
      
      ---
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: proxy-from-k8s-to-httpbin-get
        annotations:
          kubernetes.io/ingress.class: kong
          konghq.com/strip-path: \"true\"
          konghq.com/regex-priority: \"2\"
      spec:
        rules:
        - http:
            paths:
            - path: /~/(?i)httpbin/get
              pathType: ImplementationSpecific

From documentation:

ReplacePrefixMatch is only compatible with a PathPrefix HTTPRouteMatch.

@gorban gorban added the kind/feature Categorizes issue or PR as related to a new feature. label May 31, 2024
@robscott
Copy link
Member

robscott commented Jun 3, 2024

Thanks for filing this @gorban! If you have time to work on this in the next 2-3 months, do you mind proposing it in our v1.2 release scoping discussion?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants