Proposal to Drop Normative Statements the depend on HTTP Message Parser behavior.

[Andrew Jones]

This issue came up while working in the HTTP signatures test suite:

    All header field values associated with the header field
    MUST be concatenated, separated by an ASCII comma and an ASCII space,
    and used in the order in which they will appear in the
    transmitted HTTP message.

The issue here is that when some HTTP Message parsers receive an HTTP Message with duplicate headers they simply use the last value instead of turning the duplicate values into a list. This makes the normative statement difficult for an implementer as they would have to use an HTTP Message parser that behaves by turning duplicate headers into lists. It's completely fine when there is a single HTTP header with a list value however. This is related to issues: #63
#50

[Andrew Jones]

Closing this issue as both issues appear to be problems in implementation and not actual the HTTP Message parser. As usual: really sorry about this. I have been working on the tests for a few months and I guess it never occurred to me the errors could be in the binary/library I'm testing on and not a cheapo http message parser I got from npm. Hopefully I'll be more careful in the future.

LOL and right after posting this I tried the following:

GET /duplicate/headers HTTP/1.1
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh)
Host: example.com
Duplicate: one 
Duplicate: two
Authorization: Signature algorithm="hmac"
first: first
last: last

and got this:

 headers:
   { Connection: 'keep-alive',
     'User-Agent': 'Mozilla/5.0 (Macintosh)',
     Host: 'example.com',
     Duplicate: 'two',
     Authorization: 'Signature algorithm="hmac"',
     first: 'first',
     last: 'last' },

So my cheapo HTTP message parser was the issue for the header values issue.
on the other hand express handles this message just fine with the expected behavior of producing a list Duplicate: ['one', 'two']