Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

[Van Catha <[e-mail]>]

This is great and should be backward compatible quite easily!

On Thu, Oct 20, 2016 at 6:11 AM, Loïc Hoguin <[e-mail]> wrote:

> On 10/20/2016 09:22 AM, Takeshi Yoshino wrote:
>
>> Hi HTTP WG,
>>
>
> Hello,
>
> Comments are appreciated.
>>
>
> Great work. I have two general comments and three typos:
>
>
> You write:
>
>    The Content-Type header value of the underlying HTTP request/response
>    message MUST be "application/webstream".
>
> With the current draft this media type is not enough to indicate what the
> frames will actually contain. Websocket has sec-websocket-protocol for that
> purpose. SSE allows defining event types for each events. WiSH currently
> only has payload frames with no meaning beyond text or binary.
>
> Maybe have the media type define an optional parameter "protocol", for
> example? Then clients can use content negotiation to request protocols they
> accept. For example:
>
> Client sends:
>
>   Accept: application/webstream;protocol=v12.stomp;q=1,
>           application/webstream;protocol=mqtt;q=0.5,
>           text/event-stream;q=0.1, */*
>
> Server picks the appropriate type and replies:
>
>   Content-type: application/webstream;protocol=v12.stomp
>
> Using content negotiation doesn't require extra logic which is a big plus.
> And we can still use the existing Websocket subprotocol registry, which
> will be required if Websocket compatibility is a concern.
>
>
> You write:
>
>    The message type distinction by the opcode field (text and binary) is
>    kept to allow better Web support.  One of the possible use cases is
>    to use the text type for exchaning meta data encoded in JSON, etc.,
>    and the binary type for exchanging non-meta data messages.
>
> In practice when using JSON and where performance is a concern, I have
> seen users use binary for everything. The problem being that Websocket text
> frames must be valid UTF-8; but so does JSON. The server not providing
> functionality to disable the Websocket UTF-8 check (and JSON decoders not
> able to), users just dropped text frames entirely.
>
> Which brings me to my question: do you think it could be worth adding a
> note to implementers that perhaps they should consider optionally disabling
> the UTF-8 check when JSON is expected for text frames?
>
>
> Typos:
>
> * Page 3: there are two "furthur" that probably should be "further".
> * Page 5: there is "exchaning" instead of "exchanging".
>
>
> Cheers,
>
> --
> Loïc Hoguin
> https://ninenines.eu
>
>