2011/9/6 Richard L. Barnes <[email protected]>:
> Clearly it already has to be WebSocket aware, and it already has to read the
> opcode in order to distinguish data frames from control frames. Adding on a
> requirement to break at code point boundaries does not seem hugely onerous.
> It's three lines of C:
No please. WS framing is like a "transport" layer, not application layer.
> In contrast, *not* requiring breaking at UTF-8 code points means that clients
> can't do any meaningful validation on text frames. Which means you might as
> well get rid of text frames entirely.
I strongly propose changing the meaning of 1007 status code from:
1007 indicates that an endpoint is terminating the connection
because it has received data that was supposed to be UTF-8 (such
as in a text frame) that was in fact not valid UTF-8 [RFC3629].
to:
1007 indicates that an endpoint is terminating the connection
because it has received a message that was supposed to be UTF-8
that was in fact not valid UTF-8 [RFC3629].
WS message format MUST be validated when receiving all the frames
belonging to such message, as message inspection/usage belongs to the
WS application, rather than the WS "transport" layer (frames).
As I've said before, these issues are caused due to the lack of
*logical layers* in the protocol spec.
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
