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

Case *sensitive* path matching #7010

Closed
u8sand opened this issue Apr 2, 2021 · 5 comments
Closed

Case *sensitive* path matching #7010

u8sand opened this issue Apr 2, 2021 · 5 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@u8sand
Copy link

u8sand commented Apr 2, 2021

What do you want to happen?

It would be nice to have an option to enable case sensitive path matching as opposed to case insensitive path matching, perhaps globally. In-fact, the current kubernetes spec (and indeed since v1.18) seems to suggest "Prefix" path type would be case sensitive.

From: https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types

  • Exact: Matches the URL path exactly and with case sensitivity.
  • Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis. A path element refers to the list of labels in the path split by the / separator. A request is a match for path p if every p is an element-wise prefix of p of the request path.

Very explicitly:

An ingress with the path: /MyWebsite should not match the url /mywebsite.

What's the use-case for this you might ask? We have a catch-all provider which corrects misspellings (which would include casing issues); but it can't work if /MyWebsite gets sent to /mywebsite. Some case sensitive backends like tomcat will show a 404 instead of the site at /mywebsite.

Is there currently another issue associated with this?

No issue found.

Does it require a particular kubernetes version?

I don't believe it should require a particular version, though if the goal is to match the spec I guess it'd be v1.18+

If this is actually about documentation, add /kind documentation below

If there is a way to do this, or i'm just mistaken; it would be helpful to document it explicitly. A search for case, sensitivity, or strict on the docs turns up nothing.

/kind feature

@u8sand u8sand added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 2, 2021
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 1, 2021
@k8s-triage-robot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jul 31, 2021
@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs 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:

  • Reopen this issue or PR with /reopen
  • Mark this issue or PR as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

@k8s-ci-robot
Copy link
Contributor

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs 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:

  • Reopen this issue or PR with /reopen
  • Mark this issue or PR as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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/test-infra repository.

@u8sand
Copy link
Author

u8sand commented Oct 29, 2021

For anyone who needs this, I made the following patch:

--- nginx.tmpl.orig	2020-05-12 13:18:43.000000000 -0400
+++ nginx.tmpl	2021-09-21 16:18:40.346643696 -0400
@@ -1015,7 +1015,12 @@
         }
         {{ end }}
 
+        # replace case insensitive with case sensitive
+        {{ if hasPrefix $path "~*" }}
+        location ~ {{ slice $path 2 }} {
+        {{ else }}
         location {{ $path }} {
+        {{ end }}
             {{ $ing := (getIngressInformation $location.Ingress $server.Hostname $location.Path) }}
             set $namespace      {{ $ing.Namespace | quote}};
             set $ingress_name   {{ $ing.Rule | quote }};

You can produce a new nginx.tmpl by applying the patch and mount it into the docker container over the existing file.

Clearly it's possible to add this as an option, but I have no clue how to build this container so this was easiest for me.

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. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

4 participants