knotx
knotx copied to clipboard
Better headers handling configuration
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
Contribution in form of ideas, comments or PR are welcome.
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?