users@websocket-spec.java.net

[jsr356-users] Re: MessageHandler.Async and TEXT frames problems in the SPEC

From: Norman Maurer <nmaurer_at_redhat.com>
Date: Fri, 8 Feb 2013 14:36:38 +0100

Ok thanks for clarification. I thought it would "map" 1:1 with RFC6455 fragment, thus I got a bit confused on it…

Just out of interest why not "map" it 1:1 with the RFC6455 fragment ? Exactly because of this ?

---
Norman Maurer
nmaurer_at_redhat.com
JBoss, by Red Hat
Am 08.02.2013 um 13:32 schrieb Joakim Erdfelt <joakim_at_intalio.com>:
> In a prior discussion the various parts of the API that refer to partialMessage or fragment are going to be reworded to be clear that they are not referring to the RFC 6455 fragment, but rather some arbitrary portion of the overall message, subject to the implementation (and protocol extensions) whim.
> 
> Note that you will also have this partial text issue with the various streaming portions of the API as well.
> 
> And with this current API it is quite possible to have some partialMessages arrive that are valid, then the protocol receives an invalid UTF-8 sequence that makes the remaining parts of the message invalid, thus forcing the protocol implementation to fail the connection ( see https://tools.ietf.org/html/rfc6455#section-8.1 )  with status code 1007.
> 
> --
> Joakim Erdfelt <joakim_at_intalio.com>
> webtide.com
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
> 
> 
> On Fri, Feb 8, 2013 at 12:39 AM, Norman Maurer <nmaurer_at_redhat.com> wrote:
> Hi there,
> 
> I recently started to work on a WebSocket JSR implementation and noticed an issue I would like to bring up for discussion.
> 
> MessageHandler.Async should be used to act on "fragments" for TEXT and BINARY frames.  For TEXT frames the actual payload is of the type String.
> I think here is a problem... From my understanding it is completely valid to "split" TEXT frames in fragments even on invalid code points (UTF8). So when done so this will result in an invalid String that does not reflect the actual send payload once the Strings are assembled later.
> 
> The web socket RFC[1] states only "complete" WebSocket frames must be valid UTF8. This is the reason why can only "convert" them to a String once you received the complete one. 
> 
> So to fix this even for TEXT frames the payload type should be ByteBuffer. But here comes the next problem as the API uses the payload type to detect which frame types the MessageHandler.Async handles.
> 
> Cheers,
> Norman
> 
> [1] http://tools.ietf.org/html/rfc6455#section-5.6
> 
> ---
> Norman Maurer
> nmaurer_at_redhat.com
> 
> JBoss, by Red Hat
> 
> 
> 
>