Re: [hybi] deflate-stream and masking

David Endicott <> Wed, 20 July 2011 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C99BD21F8922 for <>; Wed, 20 Jul 2011 13:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VZafRAD8PwZg for <>; Wed, 20 Jul 2011 13:55:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF51521F854F for <>; Wed, 20 Jul 2011 13:55:54 -0700 (PDT)
Received: by wwe5 with SMTP id 5so435944wwe.13 for <>; Wed, 20 Jul 2011 13:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kidw7L3QCPwrNHdvPuZysnS6k+KGv/fIeEvBqZwAn+M=; b=JOT+BQBPb4egd9jMe3Uy5Fl4xMQ1Pa7Ksd7Osdu6YSS0ZLbGsGTO+1XPTFwFsI10Ud kExwWcvt26jXVjSeiZkDTmMhiBQVPQ9NxVtzywfFplmdKpjHzSxThfDEiYa2Pak3Au5K PML4enfjrFxIEN9XO+4ZbaAGzTXUO3tkiw8Ag=
MIME-Version: 1.0
Received: by with SMTP id h52mr7687109wee.33.1311195353890; Wed, 20 Jul 2011 13:55:53 -0700 (PDT)
Received: by with HTTP; Wed, 20 Jul 2011 13:55:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <00b801cc470a$d2d5e520$7881af60$> <> <1311190993.1862.135.camel@ds9> <> <> <1311192266.1862.138.camel@ds9> <> <>
Date: Wed, 20 Jul 2011 16:55:51 -0400
Message-ID: <>
From: David Endicott <>
To: John Tamplin <>
Content-Type: multipart/alternative; boundary=000e0cd342b64cc14604a88675af
Cc: Hybi <>, Patrick McManus <>, Gabriel Montenegro <>
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 20:55:55 -0000

Agreed.   The vast majority of (unencrypted, unmasked, unmangled) content
will benefit from compression.   That is a truth I cannot debate.

My use cases will not.    My "slowness" concern is latency, not throughput.
  My traffic will be many small messages and arrives at the WS layer already
encrypted, so compression doesn't work for me to any great extent.   The
turn-around latency of XHR is my biggest concern.   The HTTP
request/response cycle is my problem.   WS solves my latency concerns, and
beyond that I'd like it to just stay out of my way.

I acknowledge that other peoples needs will differ from mine.   I'm just
lazy enough to want to avoid doing work I don't need.

On Wed, Jul 20, 2011 at 4:44 PM, John Tamplin <> wrote:

> On Wed, Jul 20, 2011 at 4:36 PM, David Endicott <>wrote;wrote:
>> I've always understood WS as a protocol that defines how content is
>> exchanged asynchronously between "web" peers.   It is a framing mechanism
>> for TCP.   It is not an application layer (it doesn't define "verbs", like
>> GET, POST, HEAD, etc.).    Transport layers should be content agnostic.
>> Compression is a function of that which uses the transport layer (ie.
>> application layer).    But, I've said this before, and there is no reason
>> to belabor the point.
> The point is that practically all content which will be going over
> WebSockets will benefit from compression (see my experiments documented here
> a year and a half ago, which included clients sending binary data).  Without
> compression built into the spec, developers may be forced into a position of
> continuing to use XHR hacks because the lack of compression makes WS slower
> (for example, Google Instant search).
> --
> John A. Tamplin
> Software Engineer (GWT), Google