Sending raw bytes on the WebSocket remote might not make sense. The RFC6455 mandates that messages consisting of TEXT (+ optional CONTINUATION) frames must be UTF-8 encoded. We enforce that part of the spec simply by making sendString(String) the defined approach.
Using ByteBuffer or byte[] would be an attempt to send something that is without a declared encoding. If we had a sendString(ByteBuffer) then we would have to convert to a String with UTF-8 encoding ourselves, at which point the send might fail due to a violation of the RFC for WebSocket. Its easier to have this UTF8 conversion before the jetty implementation so that you can handle the UTF8 conversion in your own way (eg: do you fail? do you replace invalid sequences? if so, with what? do you drop failed sequences?) -- Joakim Erdfelt <[email protected]> webtide.com <http://www.webtide.com/> - eclipse.org/jetty - cometd.org Expert advice, services and support from from the Jetty & CometD experts On Mon, May 18, 2015 at 5:57 AM, Edgar Espina <[email protected]> wrote: > Hi, > > I need a sendString method on RemoteEndpoint that accepts a > ByteBuffer/bytes[] as parameter, not just a String. > > I do have a JSON library that generates byte[] and today I have to wrap > it as String to send a text message over the web socket. > > Not a big deal, but it will be nice to have. > > Thanks > > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
