Re: [hybi] Max frame size

Willy Tarreau <> Wed, 22 June 2011 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F6BD21F8585 for <>; Tue, 21 Jun 2011 23:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[AWL=-2.952, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKk0haTfer4c for <>; Tue, 21 Jun 2011 23:05:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7850421F8584 for <>; Tue, 21 Jun 2011 23:05:19 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5M65EsT020854; Wed, 22 Jun 2011 08:05:14 +0200
Date: Wed, 22 Jun 2011 08:05:14 +0200
From: Willy Tarreau <>
To: Francis Brosnan =?iso-8859-1?Q?Bl=E1zquez?= <>
Message-ID: <>
References: <1308720860.5393.18.camel@tot.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1308720860.5393.18.camel@tot.local>
User-Agent: Mutt/
Subject: Re: [hybi] 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, 22 Jun 2011 06:05:20 -0000


On Wed, Jun 22, 2011 at 07:34:20AM +0200, Francis Brosnan Blázquez wrote:
> Hi,
> Current frame design allows to send a very big single frame size (63
> bits). In terms of memory a websocket server will have problems with
> this because he must buffer all content until he can deliver the entire
> message to the app level (assuming message based API).
> I think we need a way for servers (and possibly clients) to notify each
> other which is the max frame size each part is willing to accept so each
> site administrator can configure this according to its resources,
> application type, number of connections, etc.
> I think a simple header notified at the websocket handshake will provide
> this valuable control to each party:
>    Max-Frame-Size: 4096
> This will cause each party to fragment application level messages if it
> is found bigger than Max-Frame-Size.
> In the same direction, if not provided Max-Frame-Size, it looks
> reasonable to assume a default value for this header. Again, 4096 bytes
> looks like a good value.
> What do you think?

There is nothing in the protocol which makes whole frame buffering mandatory
and in fact it's designed so that it can work as a stream instead. While the
app server may decide to buffer some frames before delivering them, it should
never do so for large ones, because 1) it will not be able to do so past one
point, and 2) it will only add important latency. It's exactly the same as
with large POST requests : for large posts, it's common to call the app and
pass it the fd and say "read the data from that fd and for XXX bytes". That's
what makes file upload possible, otherwise you would not be able to use web
interfaces to send mails.