envoyproxy/envoy

Configurable multi-value header behavior in config.core.v3.HeaderValueOption

Open

#13.053 geöffnet am 10. Sept. 2020

Auf GitHub ansehen
 (5 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C++ (5.373 Forks)batch import
area/httphelp wanted

Repository-Metriken

Stars
 (27.997 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 8T) (378 gemergte PRs in 30 T)

Beschreibung

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. However, there are some headers which should not be treated this way.

Example proto:

[
   {
      "@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