Subject: [hybi] permessage-deflate parameter negotiation

From: Tobias Oberstein <[email-masked]>
Date: Wed, 12 Jun 2013 10:20:30 -0700

After implementing permessage-deflate client/server and with all features, I think the initial
parameter negotiation is by far the most complex part of the extension.

I still have some questions. To keep it simple, here are a couple of examples:

1)
client offers:
permessage-deflate; c2s_max_window_bits

server response:
permessage-deflate; s2c_no_context_takeover

2)
client offers:
permessage-deflate; c2s_max_window_bits

server response:
permessage-deflate; s2c_max_window_bits=10

3)
client offers:
permessage-deflate; c2s_max_window_bits ; s2c_max_window_bits=10

server response:
permessage-deflate; s2c_max_window_bits=8

4)
client offers:
permessage-deflate; c2s_max_window_bits; s2c_max_window_bits=10

server response:
permessage-deflate; s2c_max_window_bits=12

===

Chrome Canary fails 1 + 2 (bails out "Received an unexpected permessage-deflate extension parameter").

Chrome offers a fixed "permessage-deflate; c2s_max_window_bits", so I could not test 3 and 4.

The current draft (in my reading) allows 1 + 2, but not 3, and not 4.

I think 1-3 should be successful, and 4 failed by client.

As in my other mail, I also think a client should explicitly announce support for "c2s_no_context_takeover":

permessage-deflate; c2s_max_window_bits; c2s_no_context_takeover

/Tobias

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 14 Jun 2013 00:31:01 +0900

> permessage-deflate; s2c_no_context_takeover

This is fine. The client may reset context if it wants.

Sorry about Chrome's bug. It rejects this now.

> permessage-deflate; s2c_max_window_bits=10

Fine. The client should be able to accept data compressed using any wbits
value.

> permessage-deflate; s2c_max_window_bits=8
Fine, too.

> permessage-deflate; s2c_max_window_bits=12
Bad. Maximum wbits the client can afford is 10.

> ===
>
> Chrome Canary fails 1 + 2 (bails out "Received an unexpected
> permessage-deflate extension parameter").
>
I'll fix it to allow 3.

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 14 Jun 2013 19:25:27 +0900

As we're going to allow unsolicited s2c_no_context_takeover and
s2c_max_window_size, maybe we should also allow client to send
c2s_no_context_takeover and c2s_max_window_size if it wants.

Existing client->server c2s_max_window_size without value can be kept. I.e.:
- Empty client->server c2s_max_window_size means that the client can accept
c2s_max_window_size.
- client->server c2s_max_window_size with value X means that the client can
accept c2s_max_window_size and even if the server won't send any
server->client c2s_max_window_size, the client won't use window size larger
than X.

---

From: Adam Rice <[email-masked]>
Date: Fri, 14 Jun 2013 22:47:14 +0900

Yes. For options where

1. The receiver could still correctly decode the frames if it ignored the
option, but
2. The receiver could take advantage of the option to save resources

I think it makes sense to encourage the sender to specify those options,
even if unsolicited. The sender will be compliant even if it locally
applies those options without telling the receiver about it, but the
receiver can benefit from knowing about it.

On 14 June 2013 19:25, Takeshi Yoshino <[email-masked]> wrote:

> - Empty client->server c2s_max_window_size means that the client can
> accept c2s_max_window_size.
> - client->server c2s_max_window_size with value X means that the client
> can accept c2s_max_window_size and even if the server won't send any

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 19 Jun 2013 17:44:12 +0900

Thanks Adam, Tobias. I've incorporated proposal in this thread into -10
draft..