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

Wenbo Zhu <wenboz@google.com> Sat, 10 June 2017 01:55 UTC

Return-Path: <wenboz@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173712700F for <hybi@ietfa.amsl.com>; Fri, 9 Jun 2017 18:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Level:
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjIgLGq2-LAC for <hybi@ietfa.amsl.com>; Fri, 9 Jun 2017 18:55:56 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA94126CD6 for <hybi@ietf.org>; Fri, 9 Jun 2017 18:55:55 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id v111so48302986wrc.3 for <hybi@ietf.org>; Fri, 09 Jun 2017 18:55:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+bqbIUes72I7p9MWXG3RxKnVu2cq8Id+5vSiIR3EvCM=; b=nTvidbCd0yjVd4/cUbxVIendK4kJDuWgDwtSFxnFxQv8PdbOh8752rG0hDVRVj82Ze vAD/c9cJ4TjoCYf8WVHt11WvO1nr9/g8QLbMnpGx29fXoEuNQsZQ5QSRAtbSEuYgvT46 e7DaKASr0+QM13C+dOTvCQhDCK09yEYUz0xrnmlcH41ylZ/TybX0CY3bT+4u28HoSV3Y tH0XXWxi/0k5l1xt6ePN1dwPr8I0ni9474Al2k9zB9OcdoSAUHX3QtVMiRSwWkZH7XQV BbyUYoOUKqtSkBaO7fa5p/Zf+Rvsu1fOkRLMtxUc9hLaT6Hh5REFxR0/aHM6/QvzTb+2 sv9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+bqbIUes72I7p9MWXG3RxKnVu2cq8Id+5vSiIR3EvCM=; b=NxHyYhUGxc5jLInL40cns+6iw9zsDfUCb/ROGgluXvuKuzm08q5MSsEztuHQQOpfEY 4LXVL1OeD5Y3OY6LXwK3F624lZY2U8Ed7LNBKtF2vGrnBieslb+6cqQunk1510I9hIGv Yp8zx0t3x9hVtVtSNmcB60dX1rdnMohe2Ot20iXbhQ48M4rE0jC7S07I6mU/GWHZahGp qIIcQ6Ikk0qPtCpt/DA3nSrKL+2uvWujUmWJjcJsN3sb46iFJS/RDQjcBuPUjvSLG1Dm N5VaVMVmdVaHHIUun/xa+jmjh0tcH7UocW7N7+xoXCR5ydxR+Hht49fEnSo80/IFum/g 0gMw==
X-Gm-Message-State: AODbwcAZ/KatgEisrScR069Rr498I1wLwVy1vlJeAuh56AzpebQvtwEr pQK/at09+OaUg+LGEWN5IoPETX4HKj1q
X-Received: by 10.223.160.68 with SMTP id l4mr846335wrl.130.1497059754225; Fri, 09 Jun 2017 18:55:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.94.206 with HTTP; Fri, 9 Jun 2017 18:55:53 -0700 (PDT)
In-Reply-To: <CAAPGdfEb64R0M5j5QeFeAX3jCwpfCZgJNgJwYgudv1aHxFGxxg@mail.gmail.com>
References: <CAAPGdfEb64R0M5j5QeFeAX3jCwpfCZgJNgJwYgudv1aHxFGxxg@mail.gmail.com>
From: Wenbo Zhu <wenboz@google.com>
Date: Fri, 09 Jun 2017 18:55:53 -0700
Message-ID: <CAD3-0rMcdMDrW_XemoOfKcgWhXmyZBbVOhXxjYL+i6oTqZZfsg@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>, Takeshi Yoshino <tyoshino@google.com>
Cc: Hybi <hybi@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c065238dc49c205519162d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/G07BHa7unzv4lGpdZ_wxT6tAs7U>
Subject: Re: [hybi] The future of WebSockets, and the WiSH proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jun 2017 01:55:59 -0000

Hi Greg,


On Thu, Apr 27, 2017 at 2:36 AM, Greg Wilkins <gregw@webtide.com> wrote:

>
> Takeshi,
>
> I note that in your drafts introduction you say:
>
>> when HTTP/1.1 is used as the underlying protocol, full-duplex
>> communication may
>> be broken if the client, server or any proxy chooses to buffer or reject
>> earlier 2xx
>> responses
>
>
> Which is a clear and accurate statement of the key problem facing any
> forever-frame based transport, regardless of what framing protocol is used
> within those forever-frames.  So while using the standard WS framing is
> admirable, as is the usage of bidirectional communications, I do not see
> why this is any more than WiSHful thinking that buffering or simplex
> proxies will prevent universal coverage of the WS semantic.
>
WiSH as a framing format (MIME type) doesn't assume any specific L7
protocol. The above text is a warning against deploying long-lived & duplex
bidi over HTTP/1.1, but short or simplex HTTP/1.1 transactions can
certainly use WS framing v.s. SSE or application defined framing.


>
> So if I understand your intent correctly, you wish to define WS over HTTP
> semantics in a way that is transport independent, so it will work for both
> HTTP/1 and HTTP/2 so that WS can benefit from the single connection muxing
> available in HTTP/2 when that is available.
>
> The problem with this approach is that the HTTP semantics just does not
> support full-duplex streaming transport and thus it is bound to fail now
> and potentially in the future when new proxy standards may be developed.
>
This is not true. The HTTP/2 spec explicitly require proxies to allow early
2xx responses. There are also environments where proxies are controlled by
services (inc. no proxy).



>
> I think the effort would be better spent working with the HTTPbis working
> group to get the WS semantic accepted over HTTP/2 framing in a way that
> distinguishes the content from a normal HTTP message that might be stored
> and forwarded.
>
For e2e encrypted traffic, proxies really shouldn't buffer anything, or WS
will have the same issue. Otherwise, the C-T alone could serve as the
signal.

Maybe it's time to update https://tools.ietf.org/html/rfc6202. A lot of its
content seems out of date, or incorrect, or applicable to WS too (or any
TCP based protocol). We now also have data that shows how often WS
connections are broken in the wild.

- Wenbo






>
> regards
>
>
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>