Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 28 May 2013 16:19:18 +0900

Hi all,

Please post your opinions and experience (implemented, faced any
difficulties, found issues, etc.).

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 31 May 2013 03:51:09 -0700

> Please post your opinions and experience (implemented, faced any difficulties, found issues, etc.).

Hi Takeshi,

We are implementing the extension now in Autobahn - testing against latest Chrome Canary which provides the extension.

Does Chrome have any (user accessible) switch/options to

1. force automatic message fragmentation
2. set compress window sizes
3. context takeover

?

Rgd 1.: I am asking since Autobahn provides APIs for message, frame and streaming processing and we want to make sure permessage-deflate works for those also.

Thanks,
Tobias

---

From: Tobias Oberstein <[email-masked]>
Date: Fri, 31 May 2013 13:54:41 -0700

> Please post your opinions and experience (implemented, faced any difficulties, found issues, etc.).

1) Some first testing ..

http://code.google.com/p/chromium/issues/detail?id=245732
http://code.google.com/p/chromium/issues/detail?id=245719

2)
If client offers multiple PMCE choices to the server by including multiple elements in the "Sec-WebSocket-Extensions" header and the server supports more than one of the PMCEs offered, is there any preference which PMCE the server SHOULD choose? E.g. the first PMCE in the header that is supported by the server?

The description of the examples in "5.1. Negotiation Examples" seem to suggest that the _ordering_ of alternative PMCE offered designates _preference_.

3)
"""
   A server MUST decline a "permessage-deflate" offer if any of the
   following conditions is met:

   o  The offer has any extension parameter not defined for use in an
      offer.

   o  The offer has any extension parameter with an invalid value.

   o  The offer has multiple extension parameters with the same name.

   o  The server doesn't support the offered configuration.
"""

So if multiple permessage-deflate PMCEs are offered by the client, the server silently skips any invalid until the first valid or none if there is no single valid one?

The server does NOT fail the WS connection upon encountering the first invalid PMCE in the list of offers?

4)
"""
  A client MUST _Fail the WebSocket Connection_ if the server accepted
   a "permessage-deflate" offer with a response meeting any of the
   following condition:

   o  The response has any extension parameter not defined for use in a
      response.

   o  The response has any extension parameter with an invalid value.

   o  The response has multiple extension parameters with the same name.

   o  The client doesn't support the configuration the response
      represents.
"""

This list does not include: "The response corresponds to a PMCE configuration not offered by the client originally".
Is this on purpose?
(A client may support a configuration which it did not offer .. for whatever reasons)