Configurable multi-value header behavior in config.core.v3.HeaderValueOption
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 437
Description
*Title*: Configurable multi-value header behavior in `config.core.v3.HeaderValueOption`
*Description*:
Currently, when one specifies multiple `HeaderValueOption` protobufs with the same `HeaderValue.Key` in something like a `service.auth.v3.CheckResponse` message, the resulting header will be a single comma separated header per [rfc2616](https://tools.ietf.org/html/rfc2616#section-4.2). However, there are some headers which should not be treated this way.
Example proto:
```json
[
{
"@type":"config.core.v3.HeaderValueOption",
"header":{
"@type":"config.core.v3.HeaderValue",
"key":"x-my-header",
"value":"value1"
}
},
{
"@type":"config.core.v3.HeaderValueOption",
"header":{
"@type":"config.core.v3.HeaderValue",
"key":"x-my-header",
"value":"value2"
}
}
]
```
Current result:
```
x-my-header: "value1, value2"
```
Desired result:
```
x-my-header: value1
x-my-header: value2
```
I believe envoy has an internal/static list of headers to not coalesce but this creates operational challenges if you have application specific headers to whitelist. Ideally there should be a way to specify this behavior at run time in the `HeaderValueOption` or child protobufs, with a default to coalesce.
*Relevant Links*:
https://tools.ietf.org/html/rfc2616#section-4.2 specifies the comma separated format but also specifies that some headers may be exceptions and must be set as individual key/value pairs.
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation Kubernetes impersonation header `impersonate-group` requires each group to be in a separate header line.
Contributor guide
Assessment
This issue has not been assessed yet.