On 11/14/12 12:00 PM, Joakim Erdfelt wrote:
> On Wed, Nov 14, 2012 at 12:48 PM, Scott Ferguson <ferg_at_caucho.com
> <mailto:ferg_at_caucho.com>> wrote:
>
> On 11/14/12 11:35 AM, Joakim Erdfelt wrote:
>> Hit a snag implementing support in Jetty for
>> MessageHandler.Async(Text).
>> I realize that the MessageHandler.Async has changed in SVN, but
>> this fundamental concept of RFC 6455 and TEXT message framing I
>> fear has been missed (at least in documentation).
>>
>> Namely, the expectation that the onMessage(T partialMessage,
>> boolean last) method expectations on what partialMessage means.
>> If the partialMessage type is anything but an array of bytes, for
>> example a String for TEXT messages, then we have a problem with
>> what to do with multi-byte UTF-8 code points that are fragmented
>> within the code point.
>> If we assume that this is called for frames of type TEXT (opcode
>> 0x1) then the server implementations need to hold onto
>> unprocessed multi-byte UTF-8 code points within that frame to
>> prepend onto the next frame (if it arrives).
>
> Yes, but why is that a problem?
>
> The partialMessage has no necessary relationship to the
> fragmentation. When the next fragment arrives, the char can be
> completed and it becomes the first char of the next partialMessage.
>
>
>
> The problem isn't technical, Jetty is already supporting this carry
> over with a custom UTF8 decoder/validator.
> But this behavior of the API needs to be documented, both for
> implementors and eventually users of the API.
Why? It's an implementation detail.
>
> Implementor Concern:
> What if the fragment received results in a zero length string?
> Should the implementors still call MessageHandler.onMessage(String
> partialMessage, boolean last) with an empty String?
Implementation detail. The implementation is free to split messages as
it sees fit.
>
> User Concern:
> The documentation should also include text aimed at the users of this
> interface that for String types, some bytes might be carried over to
> the next call of onMessage(String partialMessage, boolean last) as a
> result of fragmentation of UTF-8 code points.
Not exactly, because fragmentation is not a user-visible concept.
All the user knows is that messages might be delivered as partial
messages. There could be wording to the effect of "no guarantees of
timely partial delivery until the message has been completely received."
But I don't think it's necessary.
A conformant implementation could fully buffer all messages before
calling onMessage, even for the Async message handler.
-- Scott
>
> - Joakim
>