users@websocket-spec.java.net

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

From: Joakim Erdfelt <joakim_at_intalio.com>
Date: Fri, 8 Feb 2013 05:32:34 -0700

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 <http://www.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
>
>
>
>