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

From: Joakim Erdfelt <[email-masked]>
Date: Tue, 30 Oct 2012 16:47:10 -0700

During Mux AddChannelRequest, with a delta-encoded handshake, are there any
expectation of merging multi-value headers (like Cookie) with the original
request or response if present in the delta as well?

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> / eclipse.org/jetty / cometd.org

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 31 Oct 2012 13:56:59 +0900

On Wed, Oct 31, 2012 at 8:47 AM, Joakim Erdfelt <[email-masked]> wrote:

> During Mux AddChannelRequest, with a delta-encoded handshake, are there
> any expectation of merging multi-value headers (like Cookie) with the
> original request or response if present in the delta as well?
>

Thanks for pointing it out. How about:
- keep it allowed to send multiple headers with the same name as-is when
the identity encoding is used
- all such headers are merged [1] into single headers when
-- the handshake is set to delta-base
-- the handshake is sent using delta-encode

[1]
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-3.2

---

From: Joakim Erdfelt <[email-masked]>
Date: Wed, 31 Oct 2012 09:46:06 -0700

Some thoughts we had.

First thought, how would we merge multiple Cookie headers in a request?
Looks like https://tools.ietf.org/html/rfc6265#section-5.4 answers that for
us.
MUST NOT for client requests.

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.

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.

This makes the merging of a delta encoded set of headers rather complex.
(how can we ensure no change in sematics for example?  in order for delta
encoding to work in this case, we would need a way to remove full headers
as well, right?)
Do we want to just outright specify what headers in the mux
AddChannelRequest and AddChannelResponse are allowed to be sent, and all
other headers are stripped (or cause a failed AddChannel as its likely the
request isn't for websocket?)
Or can we just drop the delta encoding requirement?

On Tue, Oct 30, 2012 at 9:56 PM, Takeshi Yoshino <[email-masked]>wrote:

> On Wed, Oct 31, 2012 at 8:47 AM, Joakim Erdfelt <[email-masked]>wrote:
>