You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
Version used
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
The idea is that the user sets the policy of how headers are to be handled using
allow
ordeny
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
The text was updated successfully, but these errors were encountered: