Re: [hybi] The future of WebSockets, and the WiSH proposal

Philipp Serafin <> Thu, 27 April 2017 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E152D127275 for <>; Thu, 27 Apr 2017 15:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PBNQ-qj-Zj2o for <>; Thu, 27 Apr 2017 15:55:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46FFE12943D for <>; Thu, 27 Apr 2017 15:52:39 -0700 (PDT)
Received: by with SMTP id p80so39335606iop.3 for <>; Thu, 27 Apr 2017 15:52:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2n6+Cdfaf0nQyN7LxFd+rsbxsw6fMsQCcjs4PBKvVU8=; b=UO5kihQwNSojkUCItrqNY1l4dNGV4wk6u0g2WkyGefDYnz3nL7FKGqf3c4YsvK3gGs eHudtjT/RGUK25QOLedtYBQrItrhwcHId/27BL3GtefP9qgIV++s2FrzuAOcjwLgD2/y /h12hOin1UMfoGdaqCkO2kXvm2Dm8M8WW1kRnv5/52+l/ZI1yp2m23LutZ6Clt5Iu66T LTkjGjQTDA6SnRxEVs1IIsuVqbp3tIrRviBsucI6dvYViVvKRA8rZwcoIco1/Y+DdDYx Y6AVFp3n5KQOt5r+fK3D6S/W0j4s9YTFXiS6m/Amgvm7AHo90IfcjCbC5Fb6rhAYlp/s u1gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2n6+Cdfaf0nQyN7LxFd+rsbxsw6fMsQCcjs4PBKvVU8=; b=h0xUrl9pZ1lj22o6jJqAPHxTh8fqLRVzxhAarA3LPJNEDdJfrQMHMGGyBVWMlseInh hIPaKvu9hnd8t+RLVxWkTaYZ7L/ASX+kMqR2b/ggeQx5yNFvpcvGFXNsLaqoXPMMvuPM 9Er1YN/EpNIRFsrLYGXRhzGff3B+fZEaHO//3Qw4cykXLzcdsn4iC1Dt2FkeklzIRxUF bt3Ck6FEorl+S33QQqf+54HFdaF3kytUV+0LofrtH70T6+cqrQxUQeo0hgxmS3KAoynU nzmQH0AvGykz5ENKaDRaNeglZojTAqsec5tXtZ0uWwE9qbYoYAIkfHzl3b1hhcRNlFwt YgdQ==
X-Gm-Message-State: AN3rC/5mVTFFZ5LLZgewnXyOIyKOPxVMC3nSu2Zn0KUe2b4Ecsu8eOQf fPHnMKqzTIc3P4c9/KEiWLvO2QlLeQ==
X-Received: by with SMTP id q30mr3894616otd.146.1493333558653; Thu, 27 Apr 2017 15:52:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Philipp Serafin <>
Date: Thu, 27 Apr 2017 22:52:28 +0000
Message-ID: <>
To: Takeshi Yoshino <>, Andy Green <>
Cc: "" <>
Content-Type: multipart/alternative; boundary=001a113560a24b7641054e2dd010
Archived-At: <>
Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Apr 2017 22:55:22 -0000

+1 for WS-over-HTTP/2

I may be wrong, but intuitively, I'd say that the assumptions "The response
body is finite", "The request body is finite" and "The response comes after
the request" are pretty fundamental parts of HTTP's semantics - at least
they are inferred by the original purpose of HTTP and by "standard"
use-cases of HTTP on the web. As such I think it's likely that a lot of
software - client, server or intermediate - takes that assumption for

(The first assumption is a pretty weak one, due to long polling, SSE, etc -
but so far no widely deployed technology seems to break the other two
assumptions from what I know)

So at best the "strict HTTP semantics" name is slightly questionable
because, even if WiSH confirms to the letter of HTTP, it doesn't seem to
confirm to the spirit (expected usage pattern).
At worst I think this could cause failure with software that uses those
assumptions or could make future evolution of HTTP harder.

fetch+streams seems similar in that regard, as it allows the same
communication pattern but also leaves the framing and content-type up to
the application, making it harder for intermediaries or libraries to
distinguish such special streams from ordinary HTTP.

HTTP/2 is of course less problematic but still seems strange: We're taking
a bidi message-based protocol (HTTP/2 frames), layer a
request/response-based protocol on top (HTTP), then *undo* the
request/response semantics and layer *another* message-based protocol on
top (WS). Why not simply provide access to HTTP/2 frames? (Or, if URL
addressing and header support is needed, define a direct WS-to-HTTP/2

As there used to be a draft for WS-over-HTTP2 [1] and there seems to be
some interest in that feature in this discussion, I'd like to ask: what
were the reasons the draft was discontinued. Are there some strong reasons
that speak against that feature?


Takeshi Yoshino <> schrieb am Do., 27. Apr. 2017, 12:38:

> Hi Andy-san, Loïc-san,
> Thank you for providing feedback and data quickly.
> I've been aware of that there are lots of non-browser/non-JS WS users in
> the world. That's great and it's also great if WiSH could make them happier.
> As noted in the Background section of the I-D, I think use of HTTP
> semantics as-is would make things simpler. That's one of the keys of the
> WiSH proposal. We now have good client/server/framework/intermediary
> support for WS, but we've spent years to get that.
> ----
> Regarding the fetch()/Streams, in addition to the specs Anne introduced,
> we have an introduction doc.
> _______________________________________________
> hybi mailing list