Re: [hybi] Max frame size

Ian Fette (イアンフェッティ) <ifette@google.com> Wed, 22 June 2011 10:16 UTC

Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D311E80CF for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.242
X-Spam-Level:
X-Spam-Status: No, score=-104.242 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kKpiiRvB3+2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:16:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8511E80D7 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:54 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p5MAGM6W003020 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:23 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308737783; bh=Nvlorj8L+lWFxJq73Dx2Fn2uXAU=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=D+SrG1FD0Syl9pHCBTlFsVmp7VIoHAM5WtPqZxV0gC7OhYkbExqR59AvcvIL+ajlr Z1TmOBBRKEp5viW2dt6Hw==
Received: from iwc10 (iwc10.prod.google.com [10.241.65.138]) by kpbe17.cbf.corp.google.com with ESMTP id p5MAGBZB027907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:11 -0700
Received: by iwc10 with SMTP id 10so686368iwc.37 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pLLAvHFIrIrfQUHjT8xWY9Fieltygu5s2em3GMWVCRc=; b=yeRq4Jj+wMQTiOxt61Doj+2WFW6kqs9RBZz4VwiwIjl4o8EDlvejulafdfaiDb08Xg Z9Hio37N2+kmFozLPDvA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=O1UO4B+bgN4PGPiuuaxOHJROuBIhmOJVLz/U3JVpWlnQhCyf59ND83Uj//p5qzOk/g E974zuBScE4AjQkWxznQ==
MIME-Version: 1.0
Received: by 10.42.151.138 with SMTP id e10mr593417icw.251.1308737765190; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
In-Reply-To: <1308737503.11941.641.camel@vulcan.aspl.local>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com> <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com> <1308737503.11941.641.camel@vulcan.aspl.local>
Date: Wed, 22 Jun 2011 03:16:05 -0700
Message-ID: <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Francis Brosnan Blazquez <francis@aspl.es>
Content-Type: multipart/alternative; boundary=90e6ba10b06d992aaa04a64a4100
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:16:57 -0000

If a frame is sent that a server is unable to buffer for whatever reason, I
would expect the server to close the connection with error code 1004



On Wed, Jun 22, 2011 at 3:11 AM, Francis Brosnan Blazquez
<francis@aspl.es>wrote;wrote:

> Hi Ian,
>
> > We spent almost a year before we got to the point on agreeing on
> > framing. We're now in last call. It's not the time to re-open such
> > lengthy conversations based on individual preferences
>
> I'm not trying to reconsider framing; that's ok. I'm talking about
> providing a way to each party to advice is buffering capabilities which
> has nothing to do with the framing format.
>
> > (e.g. you're not saying anything the group hasn't already considered).
>
> Possibly but the problem is yet not addressed. I think this will cause
> lot of wrong patterns and a security problem at the server side like
> passing to the app level not completed frame (unfragemented or not) but
> just octects because the server was unable to buffer.
>
> That is, assuming a 2MB message, with a 64KB buffer limit, the app level
> may receive a first indication that a frame was received, only 64kb, and
> subsequent indications of pending content without header?
>
> If this is the pattern accepted, this will make easy do stream injection
> for those servers that won't buffer 20MB content until pass a complete
> frame to the app level..
>
> > As for negotiation, that's a very complex topic, which, while
> > interesting, is not necessary for the base protocol to function. I
> > would suggest that if you're interested you propose text for an
> > extension that would handle negotiation of such parameters as
> > optimal/max frame sizes etc.
>
> Ok, I'll wait for your comments since I believe this is not an
> individual preference but a risk at the server side. The idea is to
> ensure server side delivers complete frames to the app level, not
> octects without header..
>
> > -Ian
> >
> > On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota
> > <norio.kobota@jp.sony.com> wrote:
> >         Hi,
> >
> >         I think that 63 bits-length is too big for single frame, too.
> >         But there is no need to provide any header in handshake.
> >
> >         The websocket frame format has a FIN bit for fragment message.
> >         So we can use this bit when we want to send very long message.
> >
> >         I think that the websocket frame format can be more simple.
> >
> >         +-+-+-+-+-------+-+-------------+-------------------------------+
> >         |F|R|R|R| opcode|M| Payload len |    Extended payload length
> >            |
> >         |I|S|S|S|  (4)  |A|     (7)     |             (16)
> >            |
> >         |N|V|V|V|       |S|             |   (if payload len==126)
> >         |
> >         | |1|2|3|       |K|             |
> >         |
> >         +-+-+-+-+-------+-+-------------+-------------------------------+
> >         | Masking-key, if MASK set to 1 | Masking-key (continued)
> >         |
> >         +-------------------------------+-------------------------------+
> >         |          Payload Data...
> >            |
> >         +---------------------------------------------------------------+
> >         |          Payload Data (continued)
> >         |
> >         +---------------------------------------------------------------+
> >         or
> >         +-+-+-+-+-------+-+-------------+-------------------------------+
> >         |F|R|R|R| opcode|M| reserve     |    Payload length
> >         |
> >         |I|S|S|S|  (4)  |A| (7)         |    (16)
> >         |
> >         |N|V|V|V|       |S|             |
> >         |
> >         | |1|2|3|       |K|             |
> >         |
> >         +-+-+-+-+-------+-+-------------+-------------------------------+
> >         | Masking-key, if MASK set to 1 | Masking-key (continued)
> >         |
> >         +-------------------------------+-------------------------------+
> >         |          Payload Data
> >         |
> >         +---------------------------------------------------------------+
> >         |          Payload Data (continued)
> >         |
> >         +---------------------------------------------------------------+
> >
> >         Regards, nori
> >
> >
> >
> >         (2011/06/22 14:34), 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?
> >
> >
> >
> >
> >
> >                 _______________________________________________
> >                 hybi mailing list
> >                 hybi@ietf.org
> >                 https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> >         _______________________________________________
> >         hybi mailing list
> >         hybi@ietf.org
> >         https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
>
> --
> Francis Brosnan Blázquez <francis.brosnan@aspl.es>
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>
> AVISO LEGAL
>
> 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).
>
>