Allow duplicate headers

[OleMchls]

Hey there,

While I was working with the Server-Timing header for Phoenix, I stumbled across the fact that Plug does not allow to set the same header twice.

Given the following comment, I assume this behavior is intended.

Adds a new response header (key) if not present, otherwise replaces the previous value of that header with value.
-- https://github.com/elixir-plug/plug/blob/master/lib/plug/conn.ex#L626-L627

I think to not support this at all is problematic as the RFC states

A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).

I want to emphasize the last part of the sentence: or the header field is a well-known exception.

These exceptions are not defined anywhere, the RFC talks about Set-Cookie but there may be more. For example, I was recently working with the Server-Timing API https://w3c.github.io/server-timing/ which allows having the same header twice.

To reproduce

# some phoenix controller
def index(conn, _params) do
  conn = Plug.Conn.put_resp_header(conn, "via", "Value A")
  conn = Plug.Conn.put_resp_header(conn, "via", "Value B")
  render conn, "index.html"
end

Expected behavior

$~ curl -I http://localhost:4000/
HTTP/1.1 200 OK
server: Cowboy
date: Wed, 14 Feb 2018 09:54:22 GMT
content-length: 1932
content-type: text/html; charset=utf-8
cache-control: max-age=0, private, must-revalidate
x-request-id: 146acnn1n4p1bc2ggh4b3rejp3t6m6ce
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
via: Value A
via: Value B

Actual behavior

$~ curl -I http://localhost:4000/
HTTP/1.1 200 OK
server: Cowboy
date: Wed, 14 Feb 2018 09:54:22 GMT
content-length: 1932
content-type: text/html; charset=utf-8
cache-control: max-age=0, private, must-revalidate
x-request-id: 146acnn1n4p1bc2ggh4b3rejp3t6m6ce
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
via: Value B

---

I did not find any similar issue, even though I thought this may have been discussed before. If I missed it, I am deeply sorry!

[josevalim]

We do allow it internally but we don't have a public API for it yet. You can set them directly under conn.resp_headers.

[josevalim]

Btw, does anyone know if HTTP2 supports duplicate headers? I think they didn't in the drafts but I am not sure about the final version. /cc @whatyouhide.

[OleMchls]

I just checked the RFC 7540 and it does not contain any specifics about duplicate headers. So what's in RFC 7230 is still current. Also, I do know that HPACK does support it technically.

[josevalim]

@OleMchls if you would like to contribute, we would love a prepend_resp_headers function that receives a list of headers and put them in the front of resp_headers. It should keep duplicates as is and documented as so.

[OleMchls]

@josevalim sure, I'd love to bring up a PR today :)

[michalmuskala]

What should a subsequent put_resp_header do in case it targets a duplicate header?

[OleMchls]

I think a put_resp_header after a header was added (no matter using what function) would again overwrite it

[josevalim]

Overwrite the first entry. -- *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D*

[AndrewDryga]

PR is on it's way.

[AndrewDryga]

BTW, what about delete_resp_header/2 and merge_resp_headers/2? For me it even looks like we don't need to do anything except allowing merge_resp_headers/2 to duplicate values. However, someone may rely on it's property to deduplicate them.