extensions fix deflate stream vs mux and veto it on mux children
This patch gets deflate-stream working with x-google-mux.
It adds a clean veto system where are extension can veto the proposal
of any extension when opening a new connection. x-google-mux uses that
in its callback to defeat any use of deflate-stream on mux children.
However deflate stream is allowed on the parent connection and works
transparently now alongside x-google-mux.
Signed-off-by: Andy Green <andy@warmcat.com>
diff --git a/README-test-server b/README-test-server
index 9c8475f..c140b8b 100644
--- a/README-test-server
+++ b/README-test-server
@@ -263,25 +263,18 @@
1) To enable it, reconfigure with --enable-x-google-mux
- 2) It conflicts with deflate-stream, use the -u switch on
- the test client to disable deflate-stream
-
- 3) It deviates from the google standard by sending full
+ 2) It deviates from the google standard by sending full
headers in the addchannel subcommand rather than just
changed ones from original connect
- 4) Quota is not implemented yet
+ 3) Quota is not implemented yet
- 5) Close of subchannel is not really implemented yet
-
- 6) Google opcode 0xf is changed to 0x7 to account for
- v7 protocol changes to opcode layout
-
- However despite those caveats, in fact it can run the
- test client reliably over one socket (both dumb-increment
- and lws-mirror-protocol), you can open a browser on the
- same test server too and see the circles, etc.
+However despite those caveats, in fact it can run the
+test client reliably over one socket (both dumb-increment
+and lws-mirror-protocol), you can open a browser on the
+same test server too and see the circles, etc.
+It also works compatibly with deflate-stream automatically.
-2011-05-23 Andy Green <andy@warmcat.com>
+2011-05-28 Andy Green <andy@warmcat.com>