What should we do with an httpHeader-bound shape if an HTTP message contains multiple header values for the same header name?

[david-perez]

structure AnOperationInput {
    @httpHeader("X-Header")
    header: String
}

We receive an HTTP message with:

... Request-Line or Status-Line
...
X-Header: Value1
X-Header: Value2

In the case of a response, what should a client set header to? Value1 or Value2? The Rust client yields an error upon response parsing:

https://github.com/awslabs/smithy-rs/blob/6fe28ceeeed94f2da792bf7964a6b8a7c8dbf47d/codegen/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/http/HttpBindingGenerator.kt#L382

In the case of a request, what should a server set header to? Should it reject the request?

The spec does not say. I'm also not sure if there are protocol tests covering this.

[david-perez]

Issues with the same spirit:

• What is the server behavior for routing based on query strings when multiple values appear for the same query key parameter? #1070
• What is the server behavior for deserializing httpPrefixHeaders when multiple values appear for the same header name? #1069
• What is the server behavior for deserializing httpQueryParams when multiple values appear for the same key? #1071

[mtdowling]

A server rejecting the request seems fine to me since it's ambiguous (especially if there are multiple headers with different values).

I'm less confident that clients should reject responses from a server in this case. What recourse would the end user of the client have other than to be down while they wait on a ticket with a service team? I would assume that taking the first header would be safer if the cause of the duplicate headers are the result of a misbehaving intermediary (but that admittedly assumes the intermediary only adds headers after the original headers).