Subject: [hybi] any servers with deflate-stream for test?

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Fri, 04 Mar 2011 09:54:19 -0500

Hi - I'm in the process of updating firefox to ietf-06.. libwebsockets
has been very useful to test against (thanks Andy!), but it doesn't
appear to have support for deflate-stream.

Has any server implemented that yet?

Thanks,
-Pat

-- 
http://www.getfirefox.com/

---

From: Andy Green <[email-masked]>
Date: Fri, 04 Mar 2011 15:38:53 +0000

On 03/04/2011 02:54 PM, Somebody in the thread at some point said:

Hi -

> appear to have support for deflate-stream.

Hey that's great you are finding it useful.

> Has any server implemented that yet?

Actually since I made myself look dumb trying to "fix" extended data 
length management because I never studied it closely enough, I resolved 
to implement the compression extension stuff this weekend.

If you have any tips to point me in the right direction about good 
compression library or whatever it'll only speed it up.

-Andy

---

From: John Tamplin <[email-masked]>
Date: Fri, 4 Mar 2011 10:54:22 -0500

>From C, using zlib directly is straightforward.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Andy Green <[email-masked]>
Date: Fri, 04 Mar 2011 15:57:03 +0000

On 03/04/2011 03:54 PM, Somebody in the thread at some point said:
> On Fri, Mar 4, 2011 at 10:38 AM, Andy Green<[email-masked]>  wrote:

Thanks; John pointed out the same, I'll take that route.

-Andy

---

From: Andy Green <[email-masked]>
Date: Sun, 06 Mar 2011 13:58:45 +0000

Hi -

This is added and working now, at least for me ^^

http://git.warmcat.com/cgi-bin/cgit/libwebsockets/

By default, all v4, v5 or v6 clients will offer deflate-stream now with 
the existing test apps and the server will by default always accept 
deflate-stream when the connecting client offers it.

Here's some more information about the changes in the library, you don't 
need to know it to use the libwebsockets-test-server app with a client 
that offers deflate-stream though.

You can now define a set of extensions that are available when you 
create the libwebsockets context.  I guess most extensions will be 
common in the end and best done inside the library like deflate-stream, 
so I exported a list of internally supported extensions for clients and 
servers to use and added deflate-stream to it.  (The test clients and 
servers are all updated to use that).

The clients list all the extensions they know about on the client header 
line, and call an optional callback for each one into user code to make 
sure it's wanted to be announced (there is a -u --undeflated switch 
added to the test client that disables announcing deflate-stream using 
this method).

Similarly, the server code calls a callback into user code for each 
extension to check which extensions the client announced it wants to 
accept.  As it compiles the list it instantiates the accepted extensions 
and attaches them to a per-connection list.

When the client gets the server handshake response, it instantiates that 
extension support and adds it to a per-connection list of active 
extensions, and also takes care of sending the extension callback a 
destroy message at close-time.

When the extensions are instantiated, a private buffer is also allocated 
and destroyed by the library, so it's easy to maintain per-connection 
extension private data.

Currently, only simple extension names without params are supported, 
well, no extensions are defined that need them yet.

Each active extension gets an opportunity to do buffer rewriting or 
replacement in turn before any incoming packet is parsed and after each 
outgoing packet is parsed via callbacks into the extension-specific code.

-Andy