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

Better headers handling configuration #414

Open
marcinczeczko opened this issue Apr 19, 2018 · 2 comments
Open

Better headers handling configuration #414

marcinczeczko opened this issue Apr 19, 2018 · 2 comments

Comments

@marcinczeczko
Copy link
Contributor

marcinczeczko commented Apr 19, 2018

Version used

  • knot.x: any

Context of the issue/feature

There is a general problem in how to configure what headers to allow/deny either on request or response. There is a need to unify the approach. The proposed solution is have config section as below instead of allowRequestHeaders

    requestHeadersPolicy = [ # or responseHeadersPolicy
      {
        allow: ".*"
      },
      {
        deny: Host
      },
      {
         overwrite.X-Header = my-new-value # will override header if exists
      },
      {
         add.X-Header = my-new-value # will send a header with a given value, no matter if it exists
      }
    ]

The idea is that the user sets the policy of how headers are to be handled using allow or deny directives, so he/she can allow everything and then deny particular headers, or opposite way, allow everything and blacklist just specific headers.
Additionally, a policy could be used to overwrite existing or add new headers to the requests.

Bug reproducer

N/A

Steps to reproduce

N/A

Appendix

@marcinczeczko
Copy link
Contributor Author

Contribution in form of ideas, comments or PR are welcome.

@dragarthPl
Copy link

I have a question.

Does the configuration have to look like above or can it look like this:

requestHeadersPolicy { # or responseHeadersPolicy
    allow = [".*"]
    deny = [Host]
    overwrite.X-Header = my-new-value # will override header if exists
    add.X-Header = my-new-value # will send a header with a given value, no matter if it exists
 }

If answer is yes, so how we should play with multi value headers ?

Maybe we could do it with:
requestHeadersPolicy { # or responseHeadersPolicy
allow = [".*"]
deny = [Host]
overwrite.X-Header = my-new-value # will override header if exists
add.X-Header = [my-new-value] # will send a header with a given value, no matter if it exists
}

First we overwriting specific header, and then we add rest off all values for that header.

For reflection: will there be header values ​​with phrases that may interfere with the configuration phrase?

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

2 participants