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

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

The server will anyway have to go into such details. It can’t simply trust the Sec-WebSocket-Extensions header sent by the client and apply all extensions in the order specified by the client. If the server blindly trusts the order specified by the client, malicious or misbehaving clients will be able to trick the server in combining extensions in the worst possible order or in applying incompatible extensions together.

 

With best regards,

Arman

 

From: John Tamplin [mailto:[e-mail]] 
Sent: Wednesday, March 14, 2012 5:11 PM
To: Arman Djusupov; Greg Wilkins
Cc: Takeshi Yoshino; [e-mail]; Gabriel Montenegro
Subject: Re: [hybi] Per-frame compression spec draft 06

 

On Wed, Mar 14, 2012 at 4:37 AM, Arman Djusupov <[e-mail]> wrote:

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.

@Greg - IIRC, you were one of the ones who objected to requiring low-level code to know such details due to server architectures you had in mind -- is that accurate and if so still the case?

 

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