No way to access multiple Set-Cookie headers in HTTP::Response.headers about http HOT 7 CLOSED

@justindarby Can you please provide a sample of response? Pull request, which you referencing was closed as it was fixed actually (if I'm not missing anything):

parser = HTTP::Parser.new
parser << "HTTP/1.1 204 No Content\r\nSet-Cookie: foo=1;\r\nSet-Cookie: bar=2;"
parser.headers # => {"Set-Cookie"=>["foo=1;", "bar=2;"]}

from http.

I think I might understand why this is broken.

parser = HTTP::Parser.new
parser << "HTTP/1.1 200 Stuff\r\nCache-Control: no-cache\r\nContent-Length: 3\r\nContent-Type: text/xml;charset=UTF-8\r\nContent-Language: en\r\nServer: Microsoft-IIS/7.5\r\nset-cookie: _secret=magic; Version=1; Path=/obscured_path; HTTPOnly\r\nset-cookie: _moresecrets=magic2; Version=1; Path=/obscured_path2; HTTPOnly\r\nX-Powered-By: ASP.NET\r\nDate: Fri, 31 Jan 2014 15:43:22 GMT\r\nSet-Cookie: lbvendor-cookie_https=somestuffthatdoesthings0; path=/\r\n\r\n</>"

The back-end server is actually using a mix of lowercase set-cookie and Set-Cookie because it's a poorly written giant vendor application. It's working here but we have two sets, Set-Cookie and set-cookie, and I bet Set-Cookie is winning somewhere else during normalization?

from http.

Ah. That makes sense. Headers are normalized indeed.
An easy fix though.

from http.

@ixti Can you please add tests that verify this fix and prevent future regressions?

from http.

Yeah. Was going at first place, but then got too lazy. Will do today.

from http.

@sferik That was a good idea - that place had hidden bugs indeed

from http.

See 9736b8a and b1263f0

from http.