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 <fran...@aspl.es> 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.bros...@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). > > _______________________________________________ > hybi mailing list > h...@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
