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

envoyExtAuthzHttp does case-sensitive matching on headers #35220

Closed
sunbit opened this issue Sep 16, 2021 · 4 comments
Closed

envoyExtAuthzHttp does case-sensitive matching on headers #35220

sunbit opened this issue Sep 16, 2021 · 4 comments

Comments

@sunbit
Copy link

sunbit commented Sep 16, 2021

Bug Description

When using envoyExtAuthzHttp, and particularly the option HeadersToUpstreamOnAllow i just realized that at least when using an exact match, that match is case-sensitive. I realize that "exact" may mean case-sensitive, nevertheless, in the context of headers, as rfc2616 says:

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

I don't know if there's a reason for this, IMO the default should be case insensitive, maybe exposing the ignore_case flag on the envoy StringMatcher.

If anyone considers this is better filed as feature, please just leave a comment and i'll do it, from my point of view, this
would require at least clearly state that this option is case sensitive in the docs.

Thank you

Version

client version: 1.10.3
control plane version: 1.11.2
data plane version: 1.11.2 (20 proxies)

Client Version: v1.21.3
Server Version: v1.19.12-gke.2101

Additional Information

Istio operator configured as:

   meshConfig:
    extensionProviders:
    - name: requests-authorizer
      envoyExtAuthzHttp:
        service: authorizer.default.svc.cluster.local
        port: 8000
        includeRequestHeadersInCheck:
        - authorization
        headersToUpstreamOnAllow:
        - X-ROLES
        pathPrefix: /authorize

the authorizerservice was returning the headers in lowercase as x-roles, and as a result, the request was not being injected with that header. Once i changed the meshconfig to lowercase to fullfil the exact match, it worked.

@onhachoe
Copy link

I also came across this, and took quite some time to figure out why things were not working. Docs not mentioning about the case-sensitivity did not help.
Given http headers are case-insensitive by the spec, these matching should also be case insensitive by default.

@yangminzhu
Copy link
Contributor

yeah, I think we can just make it case insensitive by default to conform to the spec, @sunbit will you be able take this issue? should be a simple change, let me know if you need any help, thanks.

@sunbit
Copy link
Author

sunbit commented Sep 21, 2021

Sure, i'll give it a try!

@yangminzhu
Copy link
Contributor

closing as this has been fixed.

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

No branches or pull requests

4 participants