Re: [hybi] Per-frame compression spec draft 06

["Arman Djusupov" <[e-mail]>]

IMO a server should be ready to handle situations where the use of the one extension prohibits the use of another. Just like with HTTP Accept-Encoding header “gzip, deflate” or with mux channel compression “deflate-frame, mux, deflate-frame” where deflate-frame can be applied either before or after mux. Grouping up supported extensions into mutuality exclusive groups would probably be simpler than parsing complex extension headers and creating specifications for negotiating the extensions of each type. 

 

The server can check the extension header for the presence of supported extensions from the same group. Once a supported extension found, other extensions of the same group are excluded. Such grouping of extensions can even be defined as comma separated list of extension names sorted by the order of preference.

 

With best regards,

Arman

 

 

From: John Tamplin [mailto:[e-mail]] 
Sent: Tuesday, March 13, 2012 6:20 PM
To: Arman Djusupov
Cc: Takeshi Yoshino; [e-mail]; Gabriel Montenegro
Subject: Re: [hybi] Per-frame compression spec draft 06

 

On Tue, Mar 13, 2012 at 12:08 PM, Arman Djusupov <[e-mail]> wrote:

I was thinking more about a specification that would define the way compression extensions are to be applied and reserves the RSV1 bit as compression flag for all extensions. In terms of negotiation, we already have a way to negotiate the compression method when the extension is being negotiated. As long as each compression method has its own extension name the WebSocket handshake will negotiate it anyway. Extensions can be named deflate-frame, bzip2-message, deflate-message-stateful and so on. What spec has to offer is some standard way of using those extensions. e.g. define that “compression is applied on payload prior masking”, “frame header is not compressed” and so on. Then all new compression extension specs would be able to reference the common specification defining the general principles on how it’s applied and negotiated, but each of them could have a different name and use a different compression method.

One complication of using treating each compression algorithm as a separate WS extension is how do you negotiate exactly one of them?  Sure, you can define the extensions as mutually incompatible, but that could complicate server implementations to have to keep track of which ones use the same bit.

 

I also think it makes clearer specs to separate the mechanism of per-frame compression from which algorithm to use.

 

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