Re: [hybi] Max frame size

[Ian Fette (イアンフェッティ) <[e-mail]>]

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
<[e-mail]>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
> > <[e-mail]> 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
> >                 [e-mail]
> >                 https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> >         _______________________________________________
> >         hybi mailing list
> >         [e-mail]
> >         https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
>
> --
> Francis Brosnan Blázquez <[e-mail]>
> 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).
>
>