Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size

Greg Wilkins <> Wed, 13 July 2011 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3F2A21F8B84; Tue, 12 Jul 2011 19:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.251, 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 w3oGWmzNoFfo; Tue, 12 Jul 2011 19:53:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C8E0721F8B83; Tue, 12 Jul 2011 19:53:53 -0700 (PDT)
Received: by vws12 with SMTP id 12so5820591vws.31 for <multiple recipients>; Tue, 12 Jul 2011 19:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id o10mr742781vdv.174.1310525632902; Tue, 12 Jul 2011 19:53:52 -0700 (PDT)
Received: by with HTTP; Tue, 12 Jul 2011 19:53:52 -0700 (PDT)
In-Reply-To: <1310480036.26452.329.camel@vulcan.aspl.local>
References: <> <> <1310480036.26452.329.camel@vulcan.aspl.local>
Date: Wed, 13 Jul 2011 12:53:52 +1000
Message-ID: <>
From: Greg Wilkins <>
To: Francis Brosnan Blazquez <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <>,,
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size
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, 13 Jul 2011 02:53:55 -0000

Francis et al,

not also that the protocol does support fragmentation and a 1004 frame
too large error.
Even the 1004 error does not carry an indication of what an acceptable
size is, so the client/tool/intermediary that receives a 1004 will
either have to fail or guess a smaller frames size - potentially
binary chopping down to find an acceptable size, which might be sub

I simple optional header in the handshake declaring the max frame size
(which intermediaries could adjust) would be very complimentary to the
existing fragmentation and 1004 features and I can't think of any
significant down side.


On 13 July 2011 00:13, Francis Brosnan Blazquez <> wrote:
> Hi,
> Recently, I posted [1] that websocket protocol should include an
> indication about max frame size that is willing to accept the connecting
> peer.
> Many pointed this is not an issue because you could use a stream
> oriented API (like TCP send/recv and others), but that only bypasses the
> problem (in some cases) not solves it.
> Websocket protocol is frame based and every frame based protocol
> designed until now has/need such feature or similar. Even TCP, for those
> that proposes to use a stream oriented API as a solution, includes a
> more complex mechanism than a simple max frame size (window based ack),
> so each party can control/inform the sender. This is critical.
> A good example for this would be the next. Let suppose you have a
> constrained memory device (either because it is small or because it
> accepts a large amount of connections). On that device you deploy a
> websocket app that only accepts small messages (< 512 bytes, let's
> say).
> In this context, you can hard code at your web app (javascript) that
> must not send messages larger than this size (so you control websocket
> payload size) and in the case you need to, you must split them
> properly.
> However, even with this mechanism, you have no warranty that the browser
> or an intermediary will join those messages into a single frame, causing
> your device to receive a bigger message/frame than expected.
> Assuming this I think we would require either to include a
> Max-Frame-Size indication (or a really poor solution: to explicitly
> state on the draft that frames must not be coalesced by intermediaries
> or browsers).
> Regards,
> [1]
> --
> Francis Brosnan Blázquez <>
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
> _______________________________________________
> hybi mailing list