WebSocket client API

[Joakim Erdfelt]

On Sat, Oct 17, 2015 at 11:56 AM, Pavel Rappo <pavel.rappo at oracle.com>
wrote:

>
> >>  * WebSocket.Builder no longer accepts HttpRequest.Builder; only
> HttpClient
> >>  * One Listener instead of many onXXX handlers
> >
> > I tried to write a few examples with this API, and it's a bit cumbersome
> to use.
> > Below my feedback:
> >
> > 1. I think there is a mistake in onText(CharBuffer, boolean). Should
> > not be onText(CharSequence, boolean) ?
> > I don't think CharBuffer can handle properly UTF-8.
>
> I'm not sure I understand what you mean by "handle properly UTF-8". First
> of
> all, CharBuffer implements CharSequence. Secondly, if a user decides to
> create a
> ByteBuffer out of a Text message, CharBuffer is the way to go.
>
> It's a native class for charset decoding/encoding:
>
>    java.nio.charset.CharsetEncoder#encode(java.nio.CharBuffer).
>
> No additional conversions are needed. On the other hand, if the user needs
> a
> String, then simple CharBuffer.toString would do. In my opinion, using
> CharBuffer directly is the best of two worlds.
>

You are required, per the RFC6455 spec, to validate incoming and outgoing
TEXT messages are valid UTF8.
(also Handshake and Close Reason Messages)

http://tools.ietf.org/html/rfc6455#section-8.1

Relying on the JVM built-in replacement character behavior for invalid UTF8
sequences will cause many bugs.
If you rely on the CharsetEncoder and CharBuffer you'll wind up with
situations where you are changing the data.

You need to rely on an implementation that does not use replacement
characters and throws exceptions on bad Write,
and on bad received TEXT messages you MUST close the connection with a 1007
error code.

- Joakim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20151017/4edba889/attachment.html>