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

Loïc Hoguin <> Thu, 20 October 2016 10:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83251129564 for <>; Thu, 20 Oct 2016 03:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.832
X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jGn1sSsBHPRC for <>; Thu, 20 Oct 2016 03:16:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84ACB1294B8 for <>; Thu, 20 Oct 2016 03:16:40 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bxAKh-0001yD-O0 for; Thu, 20 Oct 2016 10:12:19 +0000
Resent-Date: Thu, 20 Oct 2016 10:12:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bxAKc-0001wh-GA for; Thu, 20 Oct 2016 10:12:14 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bxAKa-0004SQ-A7 for; Thu, 20 Oct 2016 10:12:13 +0000
Received: from [] ([]) by (mreue102) with ESMTPSA (Nemesis) id 0MF3Up-1c90A82wgt-00GFkn; Thu, 20 Oct 2016 12:11:44 +0200
To: Takeshi Yoshino <>
References: <>
From: Loïc Hoguin <>
Organization: Nine Nines
Cc: " Group" <>, Wenbo Zhu <>
Message-ID: <>
Date: Thu, 20 Oct 2016 12:11:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:DaHk60+BdNmRNV1oF8ncgbkK6OQ+inLFccztwWIsSMAH4kkahVd TCbLC2xQQAr3L/blznOJmfPFG4L6DOmq3DdgYCsl1RhJqDSLa9FFBNdAwuVd4aCKnwn6Iq+ 7BNb8mcUNTHYNjq/awy4+k6AIrlmTQF7n0SMdYFrXD0EUx4+V/mCk2eFl4AzSV07M2gbx+e ZDQnwr1s6BW7yao6FmLvQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:CG3VWJtCvQg=:gJyrRqkf7cn+TRZV7B4Tjf FvM96SQRB+iIfcRg5baIlz8Qet0UQlHf5/TQdfv33imZ6ReygaNF10WtQD0Yl3sMKohTHW6ze M0DELfSVGcRwMLNTNOWN2d43OaVBKh0A304o1LHQSP+gfrZJ6Y7D+EvEDM0udr4GFOrTdfvXp fjlXCfC2HZXzy2UV+ujSEUWmErqD94Kc/wK4NqVO7adpAp32jpIMeYkp3X1dRg5y6oy8H+NcF s13GYM1qVkyTkAg36tphXr547ok6WqZYtgUD4OouvOx4jE14BZmkH/f5iYCuObA9em0xVRl6L vKbtBqnfHq4KoqZBAlbomSN1BCmEJCNqX0im97FQp3h0r6aAjqH2o59e0tKCILPNEGhXF1/BU qAyfH2lcqRLISNM3WM5ldKA5dDusZb7V0WYoC82A/wkEPGTW8g4ZyfdjjUwanONQC7MMtNV6F ClipF3+pO4w4S69FU+JoVxXS+UHt/Q/BM/2Sk4ijolpGNUhhFxHNKvd3jZyXxL7bvL9sYUWhA qN8QVLmPj3Oh6jAnbZxNbANEyHBXEW15HcZUqHko2UCEK0Ro+eWzqjmq3CFSTbCINK3T6xJtL IaYeAHlaFSgwTE5yXt7xc8AovF/zm/Xuk5I4yv6gn2kF7H+0O3ji8acreoXjsAHc+gxeaMyg5 tud2K6tyS6T83Mgrdg13t6+fSJp/nj6fUi5bzdsn/UM6wLh8VVN/a7nWCjejI/hy9aSfRjdrW TvVJER61IBkGFJGM
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bxAKa-0004SQ-A7 0334b77c891506cb6bc0f01bc74b7639
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <>
X-Mailing-List: <> archive/latest/32654
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 10/20/2016 09:22 AM, Takeshi Yoshino wrote:


> 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,
           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?


* Page 3: there are two "furthur" that probably should be "further".
* Page 5: there is "exchaning" instead of "exchanging".


Loïc Hoguin