`@httpRequestTests` and repeated headers

[kubukoz]

In @httpRequestTests, header values must be strings:

headers: StringMap

However, headers in Smithy can be represented by lists. It appears that the way to represent that in a compliance test is by comma-separating values in the string. However, this makes it impossible to disambiguate between:

• one value that actually contains a comma, and
• multiple values, separated by commas.

The spec seems to be lenient:

When a list shape is targeted, each member of the shape is serialized as a separate HTTP header either by concatenating the values with a comma on a single line or by serializing each header value on its own line.

but the compliance test traits only supports one style. Is that by design?

[JordonPhillips]

I think the thought process at the time was that if you can do both then why not simplify the tests by only declaring one, and the mapping is familiar and less verbose.

However, this makes it impossible to disambiguate between:

• one value that actually contains a comma, and

• multiple values, separated by commas.

It isn't impossible to make this distinction, but the protocol itself has to come up with solutions. restJson1, for example, requires quotes for string values with commas (and also strings with leading/trailing spaces). This is a problem you have to solve regardless of how the test traits work because intermediaries can decide to join the headers for you.