I agree that this would be very useful. Would this be one frame size for both directions, or could it be specified in each direction? I'm a little wary of intermediaries being allowed to adjust this unless they're only allowed to reduce the amount... Len www.lenholgate.com > -----Original Message----- > From: hybi-bounces@xxxxxxxx [mailto:hybi-bounces@xxxxxxxx] On > Behalf Of Greg Wilkins > Sent: 13 July 2011 03:54 > To: Francis Brosnan Blazquez > Cc: Hybi; ietf@xxxxxxxx; > draft-ietf-hybi-thewebsocketprotocol@xxxxxxxxxxxxxx > Subject: Re: [hybi] Last Call: > <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket > protocol) to Proposed Standard: request for max frame size > > 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 > optimal. > > 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. > > regards > > On 13 July 2011 00:13, Francis Brosnan Blazquez > <francis@xxxxxxx> 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] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html > > -- > > Francis Brosnan Blázquez <francis.brosnan@xxxxxxx> > > 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). > > > > _______________________________________________ > > hybi mailing list > > hybi@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/hybi > > > _______________________________________________ > hybi mailing list > hybi@xxxxxxxx > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf