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

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

Received on Thursday, 20 October 2016 10:12:14 UTC