Re: [hybi] deflate-stream and masking

Willy Tarreau <> Wed, 20 July 2011 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9F8521F8514 for <>; Wed, 20 Jul 2011 14:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.975
X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=-3.932, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ZlxKOBQ2Y-c for <>; Wed, 20 Jul 2011 14:11:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F01DA21F8508 for <>; Wed, 20 Jul 2011 14:11:06 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6KLB27O013617; Wed, 20 Jul 2011 23:11:02 +0200
Date: Wed, 20 Jul 2011 23:11:01 +0200
From: Willy Tarreau <>
To: Alexander Philippou <>
Message-ID: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <00e701cc4715$c4989100$4dc9b300$>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00e701cc4715$c4989100$4dc9b300$>
User-Agent: Mutt/
Cc: 'Hybi' <>
Subject: Re: [hybi] deflate-stream and masking
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jul 2011 21:11:07 -0000

On Wed, Jul 20, 2011 at 10:46:43PM +0300, Alexander Philippou wrote:
> I vote for keeping it in the spec as it is now ??? an optional extension. Otherwise we will either remove deflate-stream and ship the protocol w/o compression and be subject to understandable criticism, or we will start discussing which is the optimal compression and further delay standardization until we complete deliberations. Otoh if we proceed with the spec as is then compression will be there, it will be optional, and we can return to add additional compression methods in the immediate future. No harm done to keep it in the spec as is, imho. Let???s ship. 

The issue is important for intermediaries. They will have to uncompress
then compress stream in order to forward it. This can be extremlely
expensive in terms of CPU usage and added latency, and I already expect
that a number of intermediaries will recompress with null-compression
in order to save CPU cycles where they can. This will result in an
inflated data stream in the end and higher latencies.

So I vote for removing it and quickly work on defining the deflate-frame
extension as well.