Re: [hybi] deflate-stream and masking

Greg Wilkins <> Tue, 21 June 2011 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4EFD11E8101 for <>; Tue, 21 Jun 2011 16:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7LeQMD5mjSFu for <>; Tue, 21 Jun 2011 16:31:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4503A11E8104 for <>; Tue, 21 Jun 2011 16:31:38 -0700 (PDT)
Received: by vxi40 with SMTP id 40so276855vxi.31 for <>; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id dq6mr4949970vdc.158.1308699097090; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
Received: by with HTTP; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 22 Jun 2011 09:31:37 +1000
Message-ID: <>
From: Greg Wilkins <>
To: Bruce Atherton <>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 21 Jun 2011 23:31:39 -0000

On 22 June 2011 07:41, Bruce Atherton <> wrote:
> Although I agree with you that deflate-stream is a bad idea and recognize
> that the decision to include it was made before it had been determined that
> masking applies only to payload data (so deflate-stream has to be done on
> masked data), I think it might be difficult to get agreement to remove it as
> a known extension in the spec at this point.

Firstly - I really object to this repeated anti-pattern.... some
"feature" is slipped into the draft without much discussion and no
clear consensus, and then we have to argue to have it removed.  The
status quo is to have the non consensus "feature".
I think a lot of the angst in this WG has been due to this repeated

But for this particular issue, I see no reason why it cannot be
removed.  Servers have always been free to refuse an extension, so no
application can be written that depends on it's existence.   Clients
are free to keep asking for it, but that does not mean we have to
define it.

> But just because it is a known extension does not mean it needs to be
> implemented. My suggestion is that everyone that thinks it is a bad idea
> should remove deflate-stream from their implementations and add in
> deflate-frame. So long as deflate-frame is available I don't imagine there
> will be a groundswell of consumer desire for the far less useful
> deflate-stream.

the problem is more than just not using it (I have no plans of
implementing it for my server).

It is the only exemplar of an extension we have in the specification
and as an example to follow it is terrible!  It does not follow any of
the rules we set out for extensions and will just encourage developers
to think they can do a x-my-new-wire-protocol and send whatever they
like over the wire.    If people want to do arbitrary new wire
protocols, then they should open their own port. (I know that this
argument also applies to ws, but we have got to significant length to
make sure our protocol is compatible with a HTTP upgrade).