Hi Mark,
On Thu, Nov 21, 2013 at 2:23 PM, Mark Thomas <ma...@apache.org> wrote: > On 21/11/2013 11:57, Johan Compagner wrote: > > > But the thing is, it is purely tomcat making frames/fragmentation. > > The browser (chrome in my part) sends over just 1 frame (14K or what ever > > size i have now already test that send over 50K of data in 1 frame, no > idea > > what exactly the frame buffer size is of chrome, i haven't hit that one > yet) > > but tomcat internally divides it up in 8K and then suddenly it is > "framed" > > but over the line from the browser to the server it where not frames it > was > > just one. > > > > i am currently reading also this > > > > > http://download.oracle.com/otn-pub/jcp/websocket-1_0-fr-spec/JavaWebSocketAPI_1.0_Final.pdf > > > > and nowhere i can find (4.7 for example) that a whole message can only > by 1 > > frame.. > > They even have a standard limit see 4.7.1 where maxMessageSize is > defined, > > that is default -1 and that means that it can be unlimited.(but that's > not > > true in tomcat it is limited by the input buffer size) > > Yes, Tomcat changes the default maximum message size from infinite to > 8k. The reason for that should be blindingly obvious - DoS protection. > > Tomcat similarly imposes limits on HTTP requests (header size, header > number, etc.) that are not part of the HTTP specification. While it > could be argued that Tomcat is breaking the HTTP specification by > imposing these limits, the limits are here to stay. > > > I am still thinking that tomcat implementation interprets it wrong. A > whole > > message is really what it is, the complete message, constructed out of X > > number of frames. > > Correct. And the WebSocket specification no limits on message size. A > single frame may be up to 2^63-1 and a message may consist of an > unlimited number of frames. Do you really think it is sensible for any > implementation to allow that much data to be buffered by default? > > > So tomcat should handle the concatting for me, why do i need to do that > my > > self? > > You don't. > > If you want the container to provide the received message in a single > call then all you need to do is tell the container what the maximum > message size you wish it to support is. The Java WebSocket 1.0 (JSR356) > API provides a mechanism for doing this via > Session.setMaxTextMessageBufferSize() and > Session.setMaxBinaryMessageBufferSize() > > Tomcat provides a container specific way of setting the default limits > but you can use the JSP356 API to set the limits you want in a container > neutral manner that will be portable across implementations. > > > Only if i specify that i want to have partial messages (the boolean arg) > > then i get the frames or better said the buffer sizes of tomcat. > > There is explicitly no relationship between a WebSocket frame and a > partial WebSocket message delivered via > MessageHandler.Partial.onMessage(String, boolean). Containers are free > to call that method with any length String they like as long as it is >0 > and less than the maximum message size. > Hence there is no relation between the fragmentation support in the protocol and JSR 356 APIs. Is that correct? > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
