Repeated header keys overwrites old values

[plicease]

For example:

use strict;
use warnings;
use YAML ();
use Protocol::WebSocket::Request;

my $m = Protocol::WebSocket::Request->new;
$m->parse("GET /count/10 HTTP/1.1\x0d\x0a" .
          "Upgrade: WebSocket\x0d\x0a" .
          "Connection: Upgrade\x0d\x0a" .
          "Host: 127.0.0.1:33310\x0d\x0a" .
          "Origin: http://127.0.0.1:33310\x0d\x0a" .
          "Sec-WebSocket-Key: AVDtAGeqR3jFUwgGmKhDyA==\x0d\x0a" .
          "Sec-WebSocket-Version: 13\x0d\x0a" .
          "X-Foo: bar\x0d\x0a" .
          "X-Baz: abc\x0d\x0a" .
          "X-Baz: def\x0d\x0a\x0d\x0a");

print YAML::Dump($m->fields);

prints:

---
connection: Upgrade
host: 127.0.0.1:33310
origin: http://127.0.0.1:33310
sec-websocket-key: AVDtAGeqR3jFUwgGmKhDyA==
sec-websocket-version: 13
upgrade: WebSocket
x-baz: def
x-foo: bar

Note that only the second value for x-baz is available.

[plicease]

I could probably provide a fix for this, but I am not sure what the preferred solution would be. I think making x-baz an array reference makes the most sense, as making all field values an array reference will likely break a lot of code.

[vti]

Yeah, I am afraid this is not possible in this version.

[jef-sure]

 X-Baz: abc\x0d\x0a
 X-Baz: def\x0d\x0a

This is probably an equivalent of X-Baz: abc,def\x0d\x0a. Would that be parsed?

[plicease]

That should parse okay. The issue is that you can't guarantee that the remote end will format list fields like that. Maybe it makes sense to combine the headers, ie rejig the code to produce this instead:

---
connection: Upgrade
host: 127.0.0.1:33310
origin: http://127.0.0.1:33310
sec-websocket-key: AVDtAGeqR3jFUwgGmKhDyA==
sec-websocket-version: 13
upgrade: WebSocket
x-baz: abc,def
x-foo: bar

It doesn't round-trip exactly, but it already doesn't round-trip the order of the headers. Somebody more familiar with the spec might want to doublecheck that this is reasonable. I am mostly going off of this:

http://stackoverflow.com/questions/4371328/are-duplicate-http-response-headers-acceptable