Subject: Re: [hybi] Mux / Delta encoded AddChannel Request/Response

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 1 Nov 2012 16:08:03 +0900

I rethought if multiple headers with the same value are really problematic.

It seems to be fine to allow multiple headers with the same name sent in
the handshake field instead of merging.

The receiver MUST
- when received identity encoded handshake
-- remember values and the order in which they were in the handshake field
- when received delta-encoded handshake
-- if there's a header with name=X value=empty, remove all of the entries
-- if there're header(s) with name=X value=non-empty, forget all the
remembered values and remember new value(s) and their order
-- if there're no headers with name=X, decode the memorized values in the
memorized order

We cannot drop part of them (all or nothing). But that's all.

What do you think?

What about multiple Set-Cookie response headers?
> https://tools.ietf.org/html/rfc6265#section-4.1 says SHOULD NOT for
> servers.
> Might need some language in the mux spec to say this becomes MUST NOT for
> mux.
>

Thanks. Yes, we need to support multiple entries with the same name because
of this.

> However, https://tools.ietf.org/html/rfc2616#section-4.2 says that
> multiple message headers of the same name is allowed.
>
>    Multiple message-header fields with the same field-name MAY be
>    present in a message if and only if the entire field-value for that
>    header field is defined as a comma-separated list [i.e., #(values)].
>    It MUST be possible to combine the multiple header fields into one
>    "field-name: field-value" pair, without changing the semantics of the
>    message, by appending each subsequent field-value to the first, each
>    separated by a comma. The order in which header fields with the same
>    field-name are received is therefore significant to the
>    interpretation of the combined field value, and thus a proxy MUST NOT
>    change the order of these field values when a message is forwarded.
>
>
>
httpbis is also disallowing multiple headers with the same name unless it's
1#X in the main text as well as RFC 2616 but has a short note about this
problem.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2