IETF Logo Mail Archive

[hybi] Proposed Text - Stream Based Compression

Patrick McManus <mcmanus@ducksong.com> Mon, 13 September 2010 13:48 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5523A69F2 for <hybi@core3.amsl.com>; Mon, 13 Sep 2010 06:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level:
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwqqD4Ur+kRZ for <hybi@core3.amsl.com>; Mon, 13 Sep 2010 06:48:06 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 370513A69DD for <hybi@ietf.org>; Mon, 13 Sep 2010 06:48:06 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id B89FC10303; Mon, 13 Sep 2010 09:48:31 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 230EE102A5 for <hybi@ietf.org>; Mon, 13 Sep 2010 09:48:29 -0400 (EDT)
From: Patrick McManus <mcmanus@ducksong.com>
To: hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 13 Sep 2010 09:47:41 -0400
Message-ID: <1284385661.1714.168.camel@ds9.ducksong.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: [hybi] Proposed Text - Stream Based Compression
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 13:48:07 -0000

Hi All, as promised last week here is an update to the compression
proposal. This one is stream based as that appears to be the more
popular approach. 

The summary is dead simple - basically the whole stream after the
handshake is encoded with deflate plus a requirement to flush() whenever
not doing so would cause part of a message to be buffered and not sent.
1951 includes both compressed and uncompressed block formats which can
be mixed in the stream so advanced senders which would like to turn
compression on and off can use that mechanism to do so without
websockets having to define anything in detail... basic use just
requires plugging in zlib.


-----

8. Known Extensions

Extensions provide a mechanism for implementations to opt-in to
additional protocol features. This section defines the meaning of
well-known extensions but implementations may use extensions defined
separately as well.

8.1. Compression

The registered extension token for this compression extension is
"deflate".

The extension does not have any per message extension data and it does
not define the use of any WebSocket reserved bits or op codes.

Senders using this extension MUST apply RFC 1951 encodings to all
bytes of the data stream following the handshake including both data and
control messages. The data stream MAY include multiple blocks of both
compressed and uncompressed types as defined by RFC 1951.

Senders	MUST NOT delay the transmission	of any portion of a WebSocket
message because the deflate encoding of	the message does not end on a
byte boundary. The encodings for adjacent messages MAY appear in the
same byte if no delay in transmission is occurred by doing so.

v2.23.0 | Report a Bug | By Email