-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
Title: allow response to include multiple Set-Cookie header lines
Description:
Per HTTP RFC's a response may include multiple Set-Cookie header lines.
Some client enforce this by ignoring all cookies but the first cookie when the 'Set-Cookie` header is defined as a comma-separated list [i.e., #(values)].
My understanding of Envoy's code, is that calling addCopy() on the headers will first find the existing header key then add comma separated values using appendHeaders.
This means that multiple calls to header APPEND operation with a Set-Cookie value will automatically be folded since Envoy uses a hashtable.
There are at least two ways to get the desired behavior:
- allow duplicate headers (e.g., use a multi-set); or
- explicitly handle
Set-Cookiedifferently than other headers, writing multiple header lines.
The second option is, IMHO, less intrusive to the code base and can be implemented upon serialization of headers only (i.e., converting Set-Cookie: #(values) to multiple lines.
My reading of the RFC's suggests that this would be handled correctly by browsers expecting multiple lines since they'll automatically apply folding.
Is there an interest in a PR addressing this feature request?
If so, is the second option indeed preferable and should the behavior be configurable by users?
[optional Relevant Links:]
This discussed in the following Istio issue
A recipient MAY combine multiple header fields with the same field
name into one "field-name: field-value" pair, without changing the
semantics of the message, by appending each subsequent field value to
the combined field value in order, separated by a comma. The order
in which header fields with the same field name are received is
therefore significant to the interpretation of the combined field
value; a proxy MUST NOT change the order of these field values when
forwarding a message.
Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
appears multiple times in a response message and does not use the
list syntax, violating the above requirements on multiple header
fields with the same name. Since it cannot be combined into a
single field-value, recipients ought to handle "Set-Cookie" as a
special case while processing header fields. (See Appendix A.2.3
of [Kri2001] for details.)
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.
The usual mechanism for folding HTTP headers fields (i.e., as defined in [RFC2616]) might
change the semantics of the Set-Cookie header field because the %x2C (",") character is
used by Set-Cookie in a way that conflicts with such folding.