Re: [hybi] Max frame size

["Arman Djusupov" <[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.

If a sever cannot buffer an entire frame for any reason then it can still preform local frame fragmentation just as an intermediary would do.

With best regards,
Arman


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).