Arne Goedeke wrote:
On 10/18/16 11:46, Stephen R. van den Berg wrote:
Arne Goedeke wrote:
- permessage-deflate is activated by default. i don't believe that
this is a good choice.
The default is what should help most users. I think it would have, but it's not a big deal.
My applications for websockets usually focus on binary data. I usually care more about latency and CPU than bandwidth and the payload does not compress well. This is probably different for situations which involve text. I don't know what other people do.
Well, I cater/catered for that. I.e. binary frames are mostly not compressed, even if compression is on. Text frames are mostly compressed. I tried to make it adapt favourably to most real-life conditions, including yours.
I would propose the following: Let's wait until this extension support has become more stable and then decide which of the "extensions" make sense as a default (defragment is probably helpful too in most situations).
Sounds reasonable. Yes, defragment should have been in there from the get-go. I was surprised it wasn't in the 8.0 interface. It doesn't really offer any advantage on the application level to assemble the fragments yourself.
I just extended the extension support to client mode connections. That seems to work fine so far. The client does not currently offer any of the extension parameters during handshake.
- fail connections with invalid parameters
- implement fallback (clients can offer several combinations of
parameters and a server is supposed to pick the first that works)
Yes, I know. That's the reason I skipped that, because doing the client was more work than the server side.