From nobody Tue Apr 18 19:34:38 2017 Return-Path: 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 693A112EB30 for ; Tue, 18 Apr 2017 19:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=TsDDNX20; dkim=pass (1024-bit key) header.d=chromium.org header.b=ccb3uFvR 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 egQ0WnBR1rW1 for ; Tue, 18 Apr 2017 19:34:36 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 0B350128D44 for ; Tue, 18 Apr 2017 19:34:36 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id m123so264144wma.0 for ; Tue, 18 Apr 2017 19:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=hyCtBCrHq+sAkdLp+ikQbYeOrEn1VKuHNMDKf17aAcc=; b=TsDDNX20POTvan54pg/l6Lolyfq1HSQq//j1ldMWQxDu0LHFTMk1dRewdTduJ6yS9R t9AzIxO9wUSnolmZFJvoYak/93WwX9W6bcCkheH9DmnRDg5iXwDNLXg38y0R1F+brlRh zt1zC5g86JhElgk9/Y/iFzmlg32D5tUGxYJA8aHhYHz5QKwLrs9tLHpaf7Q/nkGQ3S8r LA8oGRgYvPzgIWtNsUV+M1xD0kqZxMg9GsCfXf4gEVjCcALM0G/d+9pT34tZycMep7u5 R67w/1TBUvvoOUSKgDQI3Ga0nug2rOiqNEv7mkR9ytKnzswAkpKfQvw+Aq2AklC2+i2f fy1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=hyCtBCrHq+sAkdLp+ikQbYeOrEn1VKuHNMDKf17aAcc=; b=ccb3uFvRIMj0QYhH6xUobjfqqVhaBkRsy2I7nD/Mu9emo4sHPbp7xC+ItkW1nPYd/R EPRdBpi6ueED/OxHC/RBq/qLLHdUCQkQSFfsashNoYy9aSBqFuN2VhfBTqiVWFoNppCM ytqEWRmwru/X4Bl2xZmAWIANQuoT2jG48deeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=hyCtBCrHq+sAkdLp+ikQbYeOrEn1VKuHNMDKf17aAcc=; b=Uh/AukoyWZO4Yx0YVn78/sHY90pCcxoBHoAdPAoFEBFtyNWL4tI9JRX2fEvFjt+kOJ OoevPQ2Dp5IgcYxHZqO3gPMgftMSAyh988cm9AMHxj+QKk/xNtvTVP3mONeH9gLHAYsP 6ZmfaYB7ULB8aMzAsbR7TR27AYIZJTIaJak6hTVeXPJC0h/Vh5VSvLt9nTsv5mjUcNMu piqcrfmju0ALHnqMA3GQy2LrdI9UOcBNYq7WWUpEx5/ravJGIvYQNIsrFDJovIpoTBeQ zAujIwNZP9hh8XJHOrRulQee6FnnSB+UlRtIjST/WEn4VDbYOun1s/bf4wdKx2IzGdwS 5aEw== X-Gm-Message-State: AN3rC/7ka3DcmStVkzyLyaUSgFMvNKHcsGLRrn7BiWa0rfJb44kf8ZEg eUn9WQNgsuyNT+y+33nb/j5TN787pKFRrQQ34A== X-Received: by 10.28.22.3 with SMTP id 3mr1627558wmw.86.1492569274226; Tue, 18 Apr 2017 19:34:34 -0700 (PDT) MIME-Version: 1.0 Sender: ricea@google.com Received: by 10.28.166.130 with HTTP; Tue, 18 Apr 2017 19:34:33 -0700 (PDT) From: Adam Rice Date: Wed, 19 Apr 2017 11:34:33 +0900 X-Google-Sender-Auth: LQ8nka85Ndd7aP5rLBdcG023vQI Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a1145bd3a64ec90054d7bdd9e Archived-At: Subject: [hybi] Encourage disabling Nagle in the standard text? X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 02:34:37 -0000 --001a1145bd3a64ec90054d7bdd9e Content-Type: text/plain; charset=UTF-8 Numerous developers have run into issues when using WebSocket servers that have the Nagle algorithm enabled [Citation: https://www.google.com/search?q=websocket+nagle]. My impression is that this ends up with most WebSocket servers disabling Nagle. I am wondering if it would be better if the standard had text to the effect that implementations SHOULD disable Nagle (ie. set TCP_NODELAY on the socket). Does anyone have any use cases where Nagle is beneficial? For reference, Chrome always disables Nagle. pywebsocket doesn't (but probably should). --001a1145bd3a64ec90054d7bdd9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Numerous developers have run into issues when using WebSoc= ket servers that have the Nagle algorithm enabled [Citation:=C2=A0https://www.google.c= om/search?q=3Dwebsocket+nagle]. My impression is that this ends up with= most WebSocket servers disabling Nagle.

I am wondering = if it would be better if the standard had text to the effect that implement= ations SHOULD disable Nagle (ie. set TCP_NODELAY on the socket).
=
Does anyone have any use cases where Nagle is beneficial?

For reference, Chrome always disables Nagle. pywebso= cket doesn't (but probably should).
--001a1145bd3a64ec90054d7bdd9e-- From nobody Tue Apr 18 19:57:51 2017 Return-Path: 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 CE3B812EBD1 for ; Tue, 18 Apr 2017 19:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NHZSHTRA-eWW for ; Tue, 18 Apr 2017 19:57:47 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661E312945A for ; Tue, 18 Apr 2017 19:57:47 -0700 (PDT) Date: Wed, 19 Apr 2017 10:57:04 +0800 In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: hybi@ietf.org, Adam Rice , "hybi@ietf.org" From: Andy Green Message-ID: Archived-At: Subject: Re: [hybi] Encourage disabling Nagle in the standard text? X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 02:57:50 -0000 On April 19, 2017 10:34:33 AM GMT+08:00, Adam Rice = wrote: >Numerous developers have run into issues when using WebSocket servers >that >have the Nagle algorithm enabled [Citation: >https://www=2Egoogle=2Ecom/search?q=3Dwebsocket+nagle]=2E My impression i= s that >this ends up with most WebSocket servers disabling Nagle=2E > >I am wondering if it would be better if the standard had text to the >effect >that implementations SHOULD disable Nagle (ie=2E set TCP_NODELAY on the >socket)=2E > >Does anyone have any use cases where Nagle is beneficial? > >For reference, Chrome always disables Nagle=2E pywebsocket doesn't (but >probably should)=2E libwebsockets always disables Nagle=2E=2E=2E AFAIK there is no value to it= for general ws use=2E But I dunno it needs the standard changing, if thin= gs have higher than expected latencies people will probably work it out for= themselves=2E -Andy From nobody Tue Apr 18 21:09:41 2017 Return-Path: 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 326A1126CF6 for ; Tue, 18 Apr 2017 21:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mSLXGEdfcIr9 for ; Tue, 18 Apr 2017 21:09:37 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 A9C8C131500 for ; Tue, 18 Apr 2017 21:09:37 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id v14so2515327pfd.2 for ; Tue, 18 Apr 2017 21:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=eQnuSWF6tICgUNWnfl0PQxL3zp9Vi45vvBSuRZ9YPbI=; b=b4pRyTakJf637f0DkSviNygoQP/FRuTb6BxaEK8a89gh53+4spHB54BGocaDcI+OxC X9B3q5Kgn35kycxGXc4z45YWVGTygOhsfJ8Zxq67qwAgCo9XTwEU5oe7SB+WkiImjZld XH7ZpZHD3Ene9KjbuGCYAXZQs2d+2Ho24NZKWcQjEtt2aoRSg5PcEbQI/bFMmMMlxRgp 6xxVA4RYvluzoTLbvB7wu3bol7Arqsirb8M0QVsJhh4/bW0XHOtU7/IqQyVqqeIXhsFj NGHIt7QzgTiEDLjo5s/UcLjZ7WEM4UCISilkMPl9u74GIDmlr9uBknARiBV3C0ajd/Bl A2Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eQnuSWF6tICgUNWnfl0PQxL3zp9Vi45vvBSuRZ9YPbI=; b=lCGbRd0pwlaJ/viCcS6co6vJixTIYGiNC716nHaz60jch/aYZLChMGGFPa5wBtyvWm njAam882TnNhgS7JL2THAqkIuiTBSWiHpqU7RWdf7AXBQ7BFREN88wo/9Hwhb79JtJR5 vp5Crc6d5s3DGqgdkR2QRX2TjOIdGzvICEbhFqVNmFl3bleLWoOlsg5Kok5yjLeqXHyw E2lEZde2HaofCnSEYmgOgisLdOoNZGcwHdZKkQKLZsi+GqwTXuk1fsdmPqwXiKOa4ger fCxY0xJQaTydMCqCb7po3A68CcA0F5BR6cKNneeLmsk3tDK8M4BQp+z/Iz4NwdNHyhaV 1O9w== X-Gm-Message-State: AN3rC/6Uf8xjb31ZhmmVtZ+HUcZIR4rn8iECKQHXbNDMtuKxU7WK9LVX D/KGbevwXSQisUe/6vw= X-Received: by 10.99.216.85 with SMTP id k21mr934718pgj.10.1492574977109; Tue, 18 Apr 2017 21:09:37 -0700 (PDT) Received: from [192.168.1.2] (50-39-112-180.bvtn.or.frontiernet.net. [50.39.112.180]) by smtp.gmail.com with ESMTPSA id z5sm1185975pfd.76.2017.04.18.21.09.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:09:36 -0700 (PDT) To: hybi@ietf.org References: From: Jacob Champion Message-ID: Date: Tue, 18 Apr 2017 21:09:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] Encourage disabling Nagle in the standard text? X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 04:09:39 -0000 On 04/18/2017 07:57 PM, Andy Green wrote: > libwebsockets always disables Nagle... mod_websocket does too, simply because httpd disables it for all connections. > AFAIK there is no value to it for general ws use. But I dunno it > needs the standard changing, if things have higher than expected > latencies people will probably work it out for themselves. Yeah. Seems like it would be subprotocol-specific... if I write a Telnet clone over WebSocket, suddenly Nagle might make a lot of sense. But I'd have to make sure to TCP_CORK my control frames so that they got flushed through. See also https://www.ietf.org/mail-archive/web/hybi/current/msg06895.html . --Jacob From nobody Tue Apr 18 22:05:04 2017 Return-Path: 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 77523131510 for ; Tue, 18 Apr 2017 22:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MFx0tHsfRzJD for ; Tue, 18 Apr 2017 22:05:01 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0827126C83 for ; Tue, 18 Apr 2017 22:05:00 -0700 (PDT) Date: Wed, 19 Apr 2017 13:04:48 +0800 In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: hybi@ietf.org,Jacob Champion From: Andy Green Message-ID: Archived-At: Subject: Re: [hybi] Encourage disabling Nagle in the standard text? X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 05:05:02 -0000 On April 19, 2017 12:09:35 PM GMT+08:00, Jacob Champion wrote: >On 04/18/2017 07:57 PM, Andy Green wrote: >> libwebsockets always disables Nagle=2E=2E=2E > >mod_websocket does too, simply because httpd disables it for all >connections=2E > >> AFAIK there is no value to it for general ws use=2E But I dunno it >> needs the standard changing, if things have higher than expected >> latencies people will probably work it out for themselves=2E > >Yeah=2E Seems like it would be subprotocol-specific=2E=2E=2E if I write a >Telnet >clone over WebSocket, suddenly Nagle might make a lot of sense=2E But I'd >have to make sure to TCP_CORK my control frames so that they got >flushed >through=2E By coincidence in the last 3 weeks I have written both a telnet and an ssh= server on top of libwebsockets (that runs on ESP32 via WLAN)=2E=2E=2E both= work nicely without any special socket treatment and without nagle=2E I think nagle can be helpful only under specific conditions, and over the = years those conditions have become less of the norm=2E -Andy > >See also >https://www=2Eietf=2Eorg/mail-archive/web/hybi/current/msg06895=2Ehtml = =2E > >--Jacob > >_______________________________________________ >hybi mailing list >hybi@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/hybi From nobody Wed Apr 19 01:03:26 2017 Return-Path: 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 8DEB9131554 for ; Wed, 19 Apr 2017 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 i3WTBpWMXbuB for ; Wed, 19 Apr 2017 01:03:24 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 DB1EB131552 for ; Wed, 19 Apr 2017 01:03:23 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id m123so4610235wma.0 for ; Wed, 19 Apr 2017 01:03:23 -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=xd5K9U5J1lDkj4lt8OXwrhL65N7gnbfxDMjd8zroqYw=; b=r4uQFCXa4SJlmopkW9xTHJzs3Us8qOOtO+Zz6rZIAG2WALNZN0rVZluEOVUbKDfKWk kyIrbrn+Arpq4T3Qx8XF+xB/Auv1K04OibVRalxyjgMJIl9r7fyQEIdMmTXGwJa21T5k rAQnWbgK9T9fZ5QaRkZIrQdeq5YCPtrP+u8hMGvWs53kajRM9n6dd3qsN+OW7GV1dpnm 9vcZkH5Be7hcWBZ0DTxkRY3x5Lj20pzbHXsuGBClFAj8ufLOW29FzxqkGqn3xwPtMZlS F00HQwFBkIFZeYV2u4xktPQSm8qaNR0bp4wuGeNqKGNK8+gw0NU8VoKk1JRi8bqy7Jr0 AgXw== 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=xd5K9U5J1lDkj4lt8OXwrhL65N7gnbfxDMjd8zroqYw=; b=cht+CXD6fvzXaPjhSCWa7NO5wzaaI72HNDsLg8vl/uTLGaVc0XnW2oOIw4mLZpNm33 rBbrHzpD2tcN5NeGxKt1lw0muS8w4hv9dmlDt9fcaTGfa4xXSgemQo6+HarNl3kudtU1 y6WycI95z4gRrhc1z1fauYavlvAJXHZXd134zV8Y4z+wzJNNOZ8itDLcucu0Yk74xbUO F5GU0cwUHJIV86WgGSSGkIvuxrVQiklgYRS2fvwWL0tp5e1qvm8m8xtwWnUsUARhhxwi Yg0WMj8stqDFrBOPMsutDpqHJs9VIYy7iMc37EkMY316AJe1iU+BXrqcaPC3jNT002ke 0vYA== X-Gm-Message-State: AN3rC/6diYjIQvUvilJQkvNrR17x0krq4HrxlNM1wCStlvyEIIyWrGCz hVMc9gGAnNM/bxHH9KDFxeWReZ7WGbSv X-Received: by 10.28.157.67 with SMTP id g64mr1542157wme.120.1492589002317; Wed, 19 Apr 2017 01:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.166.130 with HTTP; Wed, 19 Apr 2017 01:03:21 -0700 (PDT) In-Reply-To: References: From: Adam Rice Date: Wed, 19 Apr 2017 17:03:21 +0900 Message-ID: To: Jacob Champion Cc: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a114b305a47cf5a054d80754a Archived-At: Subject: Re: [hybi] Encourage disabling Nagle in the standard text? X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 08:03:25 -0000 --001a114b305a47cf5a054d80754a Content-Type: text/plain; charset=UTF-8 On 19 April 2017 at 13:09, Jacob Champion wrote: > See also https://www.ietf.org/mail-archive/web/hybi/current/msg06895.html > . > I fully agree with the sentiment expressed in this email from 6 years ago :-) I hate to see developers repeatedly trip over the same obstacle. I wish someone 6 years ago had managed to sneak some non-normative verbiage into the standard saying "by the way, you probably want to turn off Nagle". Nitpick: The JS API does now support binary, and it's very popular. --001a114b305a47cf5a054d80754a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 9 April 2017 at 13:09, Jacob Champion <champion.p@gmai= l.com> wrote:
See also https://www.ietf.org/ma= il-archive/web/hybi/current/msg06895.html .
<= div>
I fully agree with the sentiment expressed in this email= from 6 years ago :-)

I hate to see developers rep= eatedly trip over the same obstacle. I wish someone 6 years ago had managed= to sneak some non-normative verbiage into the standard saying "by the= way, you probably want to turn off Nagle".

N= itpick: The JS API does now support binary, and it's very popular.
--001a114b305a47cf5a054d80754a-- From nobody Wed Apr 19 12:22:24 2017 Return-Path: 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 591A4129C1A; Wed, 19 Apr 2017 12:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IFzqeXD2KAZL; Wed, 19 Apr 2017 12:22:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB24D129557; Wed, 19 Apr 2017 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJM6VE017168; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7X1p4yfgzDH3W; Wed, 19 Apr 2017 21:22:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <149179722452.3118.982908107963516290@ietfa.amsl.com> Date: Wed, 19 Apr 2017 21:22:05 +0200 X-Mao-Original-Outgoing-Id: 514322525.709632-e6c608bc5c2ecfb6a3a2b1b6084beadb Content-Transfer-Encoding: quoted-printable Message-Id: References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [hybi] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 19:22:12 -0000 On Apr 10, 2017, at 06:07, Mark Nottingham wrote: >=20 > Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" > URI, using a well-known URI in the "wss" scheme. However, "wss" is not > defined to use well-known URIs, so this is an invalid use. Clearly, this is a bug in draft-ietf-core-coap-tcp-tls-07. I have argued that underlying this is an omission in RFC 6455: ws:/wss: URIs are translated into http:/https: URIs, and the well-known = space is already reserved in the latter, so it would be nonsensical to = try to use RFC 5785 /.well-known for something else in the ws:/wss: URI = schemes. Maybe there wasn=E2=80=99t a use case for well-known URIs in WebSockets = before, but there is one now, and we would like to remedy this omission = in the procedurally simplest possibly way. So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism to = these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Are there any objections to this procedure? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 12:33:05 2017 Return-Path: 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 D9170129B0D; Wed, 19 Apr 2017 12:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 L2t_a9dboMM0; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DCE128C83; Wed, 19 Apr 2017 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3JJWb0V025914; Wed, 19 Apr 2017 21:32:38 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w7XFx5FkyzDH3d; Wed, 19 Apr 2017 21:32:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 19 Apr 2017 21:32:37 +0200 X-Mao-Original-Outgoing-Id: 514323157.104291-7d2be15871210d08ee22cfcf0d7a07e1 Content-Transfer-Encoding: quoted-printable Message-Id: <289231B4-3335-4CC1-A285-68E1F301360C@tzi.org> References: <149179722452.3118.982908107963516290@ietfa.amsl.com> To: art@ietf.org, draft-ietf-core-coap-tcp-tls.all@ietf.org, IETF , core , hybi@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [hybi] [core] Artart last call review of draft-ietf-core-coap-tcp-tls-07 X-BeenThere: hybi@ietf.org 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: Wed, 19 Apr 2017 19:32:44 -0000 On Apr 19, 2017, at 21:22, Carsten Bormann wrote: >=20 > So I am proposing to add RFC 5785=E2=80=99s well-known URI mechanism = to these URI schemes in the document that needs it, = draft-ietf-core-coap-tcp-tls, which by that updates RFC 6455. Forgot to add the pointer to the simple fix text: https://github.com/core-wg/coap-tcp-tls/pull/128/files Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 25 00:26:47 2017 Return-Path: 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 6D4F212896F for ; Tue, 25 Apr 2017 00:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8vgQxagRPGHp for ; Tue, 25 Apr 2017 00:26:42 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 33ECF1317E3 for ; Tue, 25 Apr 2017 00:26:39 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u65so14748291wmu.1 for ; Tue, 25 Apr 2017 00:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GIseNBGHXEoJP0U5yEOqKq3SsEnIx9ZZlYHbSY+5bcE=; b=Pv+KgjiMZIvIxgtJlgLgXecItxq637awYIsoBegqgphoc0dgwGolCAHbEDSrlROgl4 93OjF0SGe+KAjou7MC6PzeglvspdqdBgwFPM+h3wVkZVXw7szmszaImN2WYIaq3g1Zj0 nJN6qTN9LgWvpX+9pa8YfNOlF93+Qoz9D36MeK7PAFlzFilQZrDnhrpIw7Sc9n4+hKKR T9fbXbHfvJ/yDqD0o60AA/iFRPsuy1/heMQQptH7yq6OKmVWOWibXFCLI0ZUzpbaHU7E 3R28Q6QNdHtqc3NkhboS3lv2N0IFsRh49mW6+ijx7VpKE7iY7XDy2oRdD8n/a/7hHCG7 K6lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GIseNBGHXEoJP0U5yEOqKq3SsEnIx9ZZlYHbSY+5bcE=; b=LJJqdkXmcEKepcSrsqTPuadADG2GEUMBbmY8ef7h5nzkq4oJhDzFavmHEDNOmWQVfR LxCMGxzrU4t99ZnbiIDsP//02Zrcg0tBtGakhQ6Dqpy6CMFnptfcUhhnwuoVl+WtsW2B kkciMr0VIj3VV4ed2uDqqtZ7Mfh+Xj7uGuDTvHUnCAKX1ZxW1FI8/byArdTM4FdDyoPO xO/BbjF1zUnxj/Q/14VMiPM2tRiVmja/FZu9N5n9XOglLhpFX97ZuovN3ueYnpOKUKq+ zsNwDL3M2XOl1SwE4fpGAXkG1hl41RrpX9wexBTbu+PNt2cynqbl4V4PJPW3O0FAVIdp Tk0w== X-Gm-Message-State: AN3rC/6E6NVCPuHmg+0IQT6NJL2jXbny45alwk28isUbW5+cwFKAJVl7 EdLxn08nm+9eOu0PrCSIN25jleFtMbD9+zyTwQ== X-Received: by 10.28.186.3 with SMTP id k3mr11961271wmf.74.1493105197369; Tue, 25 Apr 2017 00:26:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.218 with HTTP; Tue, 25 Apr 2017 00:26:16 -0700 (PDT) From: Takeshi Yoshino Date: Tue, 25 Apr 2017 16:26:16 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a114a4112e744c3054df8a438 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:26:45 -0000 --001a114a4112e744c3054df8a438 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I=E2=80=99d like to start discussing here on HyBi ML how we should evolve WebSockets. We=E2=80=99ve been thinking about this topic, and proposed WiSH [1] briefly= at the HTTP WG (IETF 97 f2f) in Nov 2016. The HTTP-WG chairs suggested that this topic should be discussed within the WebSocket community. While HyBi WG is currently closed, this ML is still the best place to have this discussion. [Background] WebSocket (WS) is widely adopted. Popular sites such as GitHub, Slack, WhatsApp and Twitch are using WS. A majority of HTTP implementations now support WS, including client/server libraries, web frameworks and intermediaries. HyBi WG had been trying to evolve WS after finalizing the base WS protocol. Personally I have been the editor for the compression spec [2]. [WiSH] WiSH [1] is a general purpose message framing format for providing bi-directional message-based communication for the Web, considering compatibility with the WebSocket API and intermediaries. WiSH is applicable for any byte-stream oriented reliable wire protocols. Given the wide adoption of WS and the rapid evolution of HTTP, e.g. QUIC [3], we believe that the WiSH proposal creates an ideal evolution path for WS users, by leveraging the HTTP infrastructure and the widely deployed WS ecosystems at the same time. In designing the WiSH spec, we decided to layer WS framing as a MIME type over the standard HTTP semantics (v.s. any specific wire-transport version such as HTTP/1.1 or HTTP/2). WiSH will be made transparent to existing applications, i.e. WiSH doesn=E2=80=99t require extending or modifying exis= ting APIs on the client or server side. WiSH can also automatically benefit from infrastructure support for HTTP/*, especially with guaranteed connectivity (no/less fallback needed). This makes the overall solution much more Web friendly and future proof We=E2=80=99d like to hear your feedback on the WiSH proposal and/or any gen= eral thoughts on how to evolve WS. Thanks [1] WiSH I-D https://tools.ietf.org/html/draft-yoshino-wish (GitHub https://github.com/bidiweb/wish/blob/master/draft-yoshino-wish.txt) [2] RFC 7692 Compression Extensions for WebSocket https://tools.ietf.org/html/rfc7692 [3] QUIC Protocol https://www.chromium.org/quic --001a114a4112e744c3054df8a438 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I=E2=80=99d like to star= t discussing here on HyBi ML how we should evolve WebSockets.
We=E2=80=99ve been thinking about this topic, and proposed WiSH= [1] briefly at the HTTP WG (IETF 97 f2f) in Nov 2016. The HTTP-WG chairs s= uggested that this topic should be discussed within the WebSocket community= . While HyBi WG is currently closed, this ML is still the best place to hav= e this discussion.

[Background]

WebSocket (WS) is widely adopted. Popular sites such as GitHub, Slac= k, WhatsApp and Twitch are using WS. A majority of HTTP implementations now= support WS, including client/server libraries, web frameworks and intermed= iaries.

HyBi WG had been trying to evolve WS after= finalizing the base WS protocol. Personally I have been the editor for the= compression spec [2].

[WiSH]

=
WiSH [1] is a general purpose message framing format for providing bi-= directional message-based communication for the Web, considering compatibil= ity with the WebSocket API and intermediaries. WiSH is applicable for any b= yte-stream oriented reliable wire protocols.

Given= the wide adoption of WS and the rapid evolution of HTTP, e.g. QUIC [3], we= believe that the WiSH proposal creates an ideal evolution path for WS user= s, by leveraging the HTTP infrastructure and the widely deployed WS ecosyst= ems at the same time.

In designing the WiSH spec, = we decided to layer WS framing as a MIME type over the standard HTTP semant= ics (v.s. any specific wire-transport version such as HTTP/1.1 or HTTP/2). = WiSH will be made transparent to existing applications, i.e. WiSH doesn=E2= =80=99t require extending or modifying existing APIs on the client or serve= r side. WiSH can also automatically benefit from infrastructure support for= HTTP/*, especially with guaranteed connectivity (no/less fallback needed).= This makes the overall solution much more Web friendly and future proof

We=E2=80=99d like to hear your feedback on the WiSH = proposal and/or any general thoughts on how to evolve WS.
--001a114a4112e744c3054df8a438-- From nobody Tue Apr 25 01:09:18 2017 Return-Path: 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 07BE1131A11 for ; Tue, 25 Apr 2017 01:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl 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 fjoSJn4WfYcy for ; Tue, 25 Apr 2017 01:09:14 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23DC131A0D for ; Tue, 25 Apr 2017 01:09:14 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 3ED9E51C063 for ; Tue, 25 Apr 2017 01:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=annevk.nl; bh=ANbwmFZ bsCi/+iHl8WYvnsq7JTI=; b=YKsU/xx/Q+MesY9/PBDCgxusZfSDkYn4j6it1Di TF9qfbk/Z5+GotkNff1iWFiY66ASYXyXkJBCAa8HND5ODXOy1Ch8Ubipp+V+vVXK 47HAU/gghZK9NOPUN/T3Nvnif3qeF+5LJr+TCj7DwOaEv/+PPfawhVC/DbljIC+D w97k= Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id BC7EE51C062 for ; Tue, 25 Apr 2017 01:09:13 -0700 (PDT) Received: by mail-yw0-f172.google.com with SMTP id l18so32980470ywh.3 for ; Tue, 25 Apr 2017 01:09:13 -0700 (PDT) X-Gm-Message-State: AN3rC/7NwtRTQq16R+hlEwyCs9rVFpluvtHTyOo+tdNMqI6NYxT/OcXW b8aqfMClZEqNXKToFYWBv/1muy89rg== X-Received: by 10.129.41.75 with SMTP id p72mr8606599ywp.215.1493107753034; Tue, 25 Apr 2017 01:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.255.1 with HTTP; Tue, 25 Apr 2017 01:09:12 -0700 (PDT) In-Reply-To: References: From: Anne van Kesteren Date: Tue, 25 Apr 2017 10:09:12 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Takeshi Yoshino Cc: "hybi@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:09:16 -0000 On Tue, Apr 25, 2017 at 9:26 AM, Takeshi Yoshino wrot= e: > We=E2=80=99d like to hear your feedback on the WiSH proposal and/or any g= eneral > thoughts on how to evolve WS. I still don't really understand why we'd put new code in browsers before gaining some experience with full-duplex fetch(). What advantages remain? That you get a dedicated connection? That the frames are slightly smaller? Can we find ways to get those advantages into fetch() and a future version of HTTP? --=20 https://annevankesteren.nl/ From nobody Tue Apr 25 01:52:23 2017 Return-Path: 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 D1AE112946E for ; Tue, 25 Apr 2017 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] 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 lkmHEi9CqSnF for ; Tue, 25 Apr 2017 01:52:09 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 A5DA81294EF for ; Tue, 25 Apr 2017 01:52:08 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l50so30939957wrc.3 for ; Tue, 25 Apr 2017 01:52:08 -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=5OXkLLTlbWLYrm/5Llk/zSLbLV3ndVn6ovqIVxlFwxw=; b=M3nZl8XbE3dkbhNK9o1wO6V9V9zaFd9P4ImOJrD0V2saOH74+JVY/upuTIh4eyoCQx hHi0uppeAQM0cPdaI5AdHN8tgeeEeQnDIzwq/iuqsDzo1zB+PRVk+dr0SCrh9DvSdfvu Z7C6DIKK3hJm55xJFZdUwS1GYVX1Vqh7qi171j+hD9Z3t3kyYMWeVeJD0QCTcyUQapLH 0+a+5Sfo3gSgQsvlUGmH99pS9KEmnFrQ4Fiw/dP6tM8CYGCe7314tzjfQS3FptugoFS2 UE3qEp77ugJQkXSTA8FOaXorZduAyF4vxrvGZk2XO2cXQnJrJJ5SPV+RHOCe7+pK7ThC 9j/g== 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=5OXkLLTlbWLYrm/5Llk/zSLbLV3ndVn6ovqIVxlFwxw=; b=S87Ibf3FnoJQGbvTXYhpPLsaDx0tbt9EQAyHVnfLX2mhe5oux70L+V4n31/JQa3pjo YuQiSQbHHRgjkimCwwXk+5eZDjRDzvrEunJIyqzTwyUdqpaA+/Ty1PnrYvuO5R+LNmRk FqMqwvLNpFnjMJ8Vr/9nMxUzf6X7eLB4f/sEzzluEfUfJTKCSPwTOf0KB4/if9FOj/DN I9Z9F3xht09wKN+4Svxa9RDa5EcNUU2MC1Yxwe7mb1GFiRB1yK1fdyc0zMDlwg+JAsPe hi/lBYyYCbk+mNZeb9cOmoGHX0dmQMvCj7oPa2+44XN2jIjRcrlCyltPvd8Itt+RWN4u zU3w== X-Gm-Message-State: AN3rC/5x1KGTHNEZXKEbUTHr8nawmMjhZiHPB38X0LmBeKxiNmgud87q Lag8JTATO9/hQjPFG/eMvNmr9QK7Bx4JH8UWHw== X-Received: by 10.223.173.74 with SMTP id p68mr8775066wrc.163.1493110327097; Tue, 25 Apr 2017 01:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.218 with HTTP; Tue, 25 Apr 2017 01:51:46 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 25 Apr 2017 17:51:46 +0900 Message-ID: To: Anne van Kesteren Cc: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=f403045d597ca8a51c054df9d6f7 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 08:52:11 -0000 --f403045d597ca8a51c054df9d6f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 25, 2017 at 5:09 PM, Anne van Kesteren wrote= : > On Tue, Apr 25, 2017 at 9:26 AM, Takeshi Yoshino > wrote: > > We=E2=80=99d like to hear your feedback on the WiSH proposal and/or any= general > > thoughts on how to evolve WS. > > I still don't really understand why we'd put new code in browsers > before gaining some experience with full-duplex fetch(). What > advantages remain? That you get a dedicated connection? That the > frames are slightly smaller? Can we find ways to get those advantages > into fetch() and a future version of HTTP? > Yes, theoretically there are lots of overlap between what the fetch()/Streams effort realizes and current/WiSH-ed WebSocket realizes. However, there is existing big WebSocket ecosystem based on the WebSocket web API, server APIs designed to match it, intermediaries, etc. I'd like to hear opinions from them. That's actually one of the main purposes of this discussion. The bottom of the background section of the I-D ( https://tools.ietf.org/html/draft-yoshino-wish-02#section-2) is unintentionally (I forgot to update it) left to be talking about using WiSH framing over fetch()/Streams to improve the WebSocket ecosystem without introducing any dedicated browser code. This is also a possible option though it requires developers to include Polyfill in their code. --f403045d597ca8a51c054df9d6f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 25, 2017 at 5:09 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
On Tue, Apr 25, 2017 at 9:26 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
> We=E2=80=99d like to hear your feedback on the WiSH proposal and/or an= y general
> thoughts on how to evolve WS.

I still don't really understand why we'd put new code in bro= wsers
before gaining some experience with full-duplex fetch(). What
advantages remain? That you get a dedicated connection? That the
frames are slightly smaller? Can we find ways to get those advantages
into fetch() and a future version of HTTP?

<= div>Yes, theoretically there are lots of overlap between what the fetch()/S= treams effort realizes and current/WiSH-ed WebSocket realizes.

However, there is existing big WebSocket ecosystem ba= sed on the WebSocket web API, server APIs designed to match it, intermediar= ies, etc. I'd like to hear opinions from them. That's actually one = of the main purposes of this discussion.

The bottom of the background section of the I-D (https://tools.ietf.org/= html/draft-yoshino-wish-02#section-2) is unintentionally (I forgot to u= pdate it) left to be talking about using WiSH framing over fetch()/Streams = to improve the WebSocket ecosystem without introducing any dedicated browse= r code. This is also a possible option though it requires developers to inc= lude Polyfill in their code.
=C2=A0
--f403045d597ca8a51c054df9d6f7-- From nobody Tue Apr 25 02:02:24 2017 Return-Path: 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 D34E3129AB5 for ; Tue, 25 Apr 2017 02:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aRKwCFOhU9yx for ; Tue, 25 Apr 2017 02:02:22 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1F4129AB3 for ; Tue, 25 Apr 2017 02:02:00 -0700 (PDT) To: Takeshi Yoshino , Anne van Kesteren Cc: "hybi@ietf.org" References: From: Andy Green Message-ID: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> Date: Tue, 25 Apr 2017 17:01:18 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:02:24 -0000 On 04/25/2017 04:51 PM, Takeshi Yoshino wrote: > On Tue, Apr 25, 2017 at 5:09 PM, Anne van Kesteren > wrote: > > On Tue, Apr 25, 2017 at 9:26 AM, Takeshi Yoshino > > wrote: > > We’d like to hear your feedback on the WiSH proposal and/or any > general > > thoughts on how to evolve WS. > > I still don't really understand why we'd put new code in browsers > before gaining some experience with full-duplex fetch(). What > advantages remain? That you get a dedicated connection? That the > frames are slightly smaller? Can we find ways to get those advantages > into fetch() and a future version of HTTP? > > > Yes, theoretically there are lots of overlap between what the > fetch()/Streams effort realizes and current/WiSH-ed WebSocket realizes. Can someone point the rump of hybi-subscribers who have no idea what you are talking about with this "fetch() / Streams" stuff to some definitive documentation? > > However, there is existing big WebSocket ecosystem based on the > WebSocket web API, server APIs designed to match it, intermediaries, > etc. I'd like to hear opinions from them. That's actually one of the > main purposes of this discussion. > > The bottom of the background section of the I-D > (https://tools.ietf.org/html/draft-yoshino-wish-02#section-2) is > unintentionally (I forgot to update it) left to be talking about using > WiSH framing over fetch()/Streams to improve the WebSocket ecosystem > without introducing any dedicated browser code. This is also a > possible option though it requires developers to include Polyfill in > their code. The basic problem underneath all this is the guys who defined http/2 considered ws so declasse they did not need to honor the existing JS apis in http/2. They took care of every other functionality in use in http/1 in http/2 as far as I know. But ws is a red-haired stepchild to them... the official stance is use http/1. What about it offends their delicate sensibilities I dunno. Anyway I appreciate Yoshino-san at least threw his hat in the ring with some data. -Andy > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From nobody Tue Apr 25 02:10:35 2017 Return-Path: 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 9192D129B18 for ; Tue, 25 Apr 2017 02:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl 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 sr7rOS9IRg-d for ; Tue, 25 Apr 2017 02:10:33 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B76E129B15 for ; Tue, 25 Apr 2017 02:10:33 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 3F94F392077 for ; Tue, 25 Apr 2017 02:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=XLNOftHrZPlSJeSFFL9YwLRKbLY=; b=Tr NAVJlFaSiPO3iXWmv+YQDimeutbHYo4WpLSemZ4U6m53KMv0LDeTFFLcRoxG87iT b20zb+apfiLKszCgS1V+j2RWCYYQYqwaPdiNbMVgC4xlrTevETTeaM5uU5tBBr84 NXukb4OuOstlMp9cZ5DHRcrkQcFgKTn++auf7xU5Q= Received: from mail-yb0-f178.google.com (mail-yb0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 3028C392075 for ; Tue, 25 Apr 2017 02:10:33 -0700 (PDT) Received: by mail-yb0-f178.google.com with SMTP id s22so66549057ybe.3 for ; Tue, 25 Apr 2017 02:10:33 -0700 (PDT) X-Gm-Message-State: AN3rC/6E/fXCAoPL5ZL5C8BwOnOAIRGogsIxOb5v3hjlj0BaC16B0AMM oTwSqpt72avcODbXEtxuT7ipeIt8Hw== X-Received: by 10.37.45.84 with SMTP id s20mr8045834ybe.177.1493111432545; Tue, 25 Apr 2017 02:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.255.1 with HTTP; Tue, 25 Apr 2017 02:10:32 -0700 (PDT) In-Reply-To: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> From: Anne van Kesteren Date: Tue, 25 Apr 2017 11:10:32 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Andy Green Cc: Takeshi Yoshino , "hybi@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:10:35 -0000 On Tue, Apr 25, 2017 at 11:01 AM, Andy Green wrote: > Can someone point the rump of hybi-subscribers who have no idea what you are > talking about with this "fetch() / Streams" stuff to some definitive > documentation? Apologies, fetch() is basically what replaces XMLHttpRequest and it has slowly evolved to expose streams which in theory allows for full-duplex communication even over H/1: https://fetch.spec.whatwg.org/ https://streams.spec.whatwg.org/ It's still early days implementation-wise though with regards to the streams integration. -- https://annevankesteren.nl/ From nobody Tue Apr 25 02:58:53 2017 Return-Path: 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 734DD129BF3 for ; Tue, 25 Apr 2017 02:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vfiPNQltSW2V for ; Tue, 25 Apr 2017 02:58:50 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (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 171F4129C5E for ; Tue, 25 Apr 2017 02:58:49 -0700 (PDT) Received: from [192.168.1.28] ([176.149.24.230]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MNvNj-1cvVOB1dhT-007UxU; Tue, 25 Apr 2017 11:58:44 +0200 To: Anne van Kesteren References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> Cc: "hybi@ietf.org" From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= Organization: Nine Nines Message-ID: <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> Date: Tue, 25 Apr 2017 11:58:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.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:F3vjtBoHPurJ14btFwKrQ7t5rWpC/Aak8+8mxCn5P57Nb0wCTay qGHsIlmujF4c4jNQjWwZ7TWkf3lHwo7/B1g00XaksAbyPCTCKouT08r4Us7e9rQRViBnM3P U22eyfMjDhyARmyk4njtQnUk935fs33+iUMHAgbgcKxmtTnQnl1JgM8cU623+jUvMTi0Y/j iUUY+pO1BL1/ZJMoL81Lw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5iVJaGC/zIA=:kPURWLWJ5Po+t60NWqQKPS 9svAR90FIk1UJ3S27hM9eP4SI3ZEVBlptUacEBJKrSryfDXN6CFlqvag4hy1g24u8S8lecCq5 VIFXC18pLcAcjUpQEIQXm+CNHckcM/1gq94CPl6iXgxguqrWLX14a6FQksK4G8vZ1pymMO1oJ 78EKeOoInWRpOY/V2r95bQJBL0WJAY+Bw+2eJ3Tw9uDGijKGw9vpxak87gT5GuQjS5krnszPy o6J+5y1pnzUweD4tPTqBtxh8umGKGxqCaT9WS729gdIJTmCRV0Gg5HDmzrt7V0+KPNgwJj8gy 4hhApz5aLX/ctHoaj2yf9ykjL31LGQR6HO3gNCfyRpzVKZqRiZ2VctFTRMrOrd7oypxYmQkb7 fYDs/0UJPQR5/hvnK1bOCdgBqyWYWXSseAspIWBvyxfgl/c0LD2/F0XDdWCLAD7oe8TbPeymO lY8GazlrLvjLDw8zqA6KzRWFOOTwe4mk5tO6yiISYEikBhbU+fPr6IKZKEpgvHRaAJT1E/bAJ OM2kiDsDplHScixzChiB6xMOCqVXM2WCReSDepE0t1/lOrYVVw5ErKTzhXjw4bEQIk5y1Kqs7 pkCm2vGggmGkIO+RH93yETX9fosHCsCKvHhC226gx9vzRYNbPwoaTfyojqIrkuHqzLf3hac/o 3203UTwTqHNcxfOzSUHJxQnpJUWwxlRQPtUkuKImTO4OrI/7FAJMxCBfrBYpS5xitn/fQJGn5 mwQ93tz8mnuAUzqw Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:58:52 -0000 Hello, On 04/25/2017 11:10 AM, Anne van Kesteren wrote: > On Tue, Apr 25, 2017 at 11:01 AM, Andy Green wrote: >> Can someone point the rump of hybi-subscribers who have no idea what you are >> talking about with this "fetch() / Streams" stuff to some definitive >> documentation? > > Apologies, fetch() is basically what replaces XMLHttpRequest and it > has slowly evolved to expose streams which in theory allows for > full-duplex communication even over H/1: > > https://fetch.spec.whatwg.org/ > https://streams.spec.whatwg.org/ > > It's still early days implementation-wise though with regards to the > streams integration. While this looks interesting, it doesn't help any of us with non-browser/non-JS clients, like server-side clients or mobile applications. Here are a few things my users would like to be able to do: * Make their custom Websocket code work over HTTP/2 or any future protocol (QUIC or other) * Continue using the Websocket sub-protocol feature without having to dedicate an entire connection for it (layering an existing protocol over HTTP has advantages for authentication and routing) * Have a good media type for the streaming of binary events A common pattern my users have when contacting a server is to first request a resource that will stream events, then perform other requests separately. Here are the issues commonly encountered right now. I'm assuming here that clients can use HTTP/2: * Having to open 2 connections (not the best idea for mobile clients, and uses twice the memory on the server side) * Having to reimplement a custom HTTP/2-like protocol on top of Websocket to avoid having those 2 connections (works, but non-standard, and prone to errors) * Having to use text/event-stream with base64-encoded binary data (inefficient, especially for larger events) * For users who would otherwise be fine with text-based events: having to use text encodings. JSON in particular is very inefficient and puts a heavy strain on the server, switching from JSON to msgpack for example makes my servers load go back to 0 even with tens of thousands of connections. Even if using something other than JSON, there's still the matter of decoding text/event-stream. * Having to implement a custom multipart media type for events, for those who go that route. Few do because it's non-standard. My users tend to have servers with 10K+ or sometimes 100K+ connections, so we have slightly different needs than most people, but they're still worth considering when defining standards I think. On top of that WiSH is easier to integrate on the server because it fits better with the HTTP semantics (using content negotiation, in particular). It would be possible to have common code for text/event-stream and WiSH should one desire to, while Websocket itself makes that less practical. I don't really know how the standards process works but I would be really interesting to see WiSH make it in one form or another even if browsers are not willing to implement it, because it would definitely benefit the rest of us. Cheers, -- Loïc Hoguin https://ninenines.eu From nobody Tue Apr 25 03:48:41 2017 Return-Path: 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 0AA1B12EB86 for ; Tue, 25 Apr 2017 03:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4jlnJ7a1ZLuy for ; Tue, 25 Apr 2017 03:48:36 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52858129BA3 for ; Tue, 25 Apr 2017 03:48:36 -0700 (PDT) To: =?UTF-8?Q?Lo=c3=afc_Hoguin?= , Anne van Kesteren Cc: "hybi@ietf.org" References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> From: Andy Green Message-ID: <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> Date: Tue, 25 Apr 2017 18:47:58 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 In-Reply-To: <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 10:48:39 -0000 On 04/25/2017 05:58 PM, Loïc Hoguin wrote: > Hello, > > On 04/25/2017 11:10 AM, Anne van Kesteren wrote: >> On Tue, Apr 25, 2017 at 11:01 AM, Andy Green wrote: >>> Can someone point the rump of hybi-subscribers who have no idea what >>> you are >>> talking about with this "fetch() / Streams" stuff to some definitive >>> documentation? >> >> Apologies, fetch() is basically what replaces XMLHttpRequest and it >> has slowly evolved to expose streams which in theory allows for >> full-duplex communication even over H/1: >> >> https://fetch.spec.whatwg.org/ >> https://streams.spec.whatwg.org/ >> >> It's still early days implementation-wise though with regards to the >> streams integration. > > While this looks interesting, it doesn't help any of us with > non-browser/non-JS clients, like server-side clients or mobile > applications. > > Here are a few things my users would like to be able to do: > > * Make their custom Websocket code work over HTTP/2 or any future > protocol (QUIC or other) Yeah. I proposed this on the http/2 list before http/2 came out and more recently. It was ignored the first time and the second time, the responsible guy was surprised that there was even any non-browser ws usage. So I dunno what planet he's on, but clearly it's not a good planet from which to direct the future of ws. Wow you have a lot of points but I think they are not all generic. > > * Continue using the Websocket sub-protocol feature without having to > dedicate an entire connection for it (layering an existing protocol > over HTTP has advantages for authentication and routing) Generally speaking, atm I think by default http/2 looks like the future. The problem is not that we need to "add mux" to http/1 as Google tried and failed to "add mux" to ws, but that the guys defining http/2 unaccountably dropped the ball when they did not include ws support in it already. > > * Have a good media type for the streaming of binary events > > A common pattern my users have when contacting a server is to first > request a resource that will stream events, then perform other > requests separately. > > Here are the issues commonly encountered right now. I'm assuming here > that clients can use HTTP/2: > > * Having to open 2 connections (not the best idea for mobile clients, > and uses twice the memory on the server side) You mean two TCP connections? Why? You mean fetching the html that has the scripts and then the scripts opening the ws connection? > > * Having to reimplement a custom HTTP/2-like protocol on top of > Websocket to avoid having those 2 connections (works, but > non-standard, and prone to errors) Eh... what did you mean then "two connections"? > > * Having to use text/event-stream with base64-encoded binary data > (inefficient, especially for larger events) What's up with ws BINARY? > > * For users who would otherwise be fine with text-based events: having > to use text encodings. JSON in particular is very inefficient and puts > a heavy strain on the server, switching from JSON to msgpack for > example makes my servers load go back to 0 even with tens of thousands > of connections. Even if using something other than JSON, there's still > the matter of decoding text/event-stream. ... JSON can make a lot of sense when things are less intense. What's up with BINARY ws connections though? > > * Having to implement a custom multipart media type for events, for > those who go that route. Few do because it's non-standard. Can you explain what this means? It sounds kind of specific to whatever it is you are doing. > > My users tend to have servers with 10K+ or sometimes 100K+ > connections, so we have slightly different needs than most people, but > they're still worth considering when defining standards I think. > > On top of that WiSH is easier to integrate on the server because it > fits better with the HTTP semantics (using content negotiation, in > particular). It would be possible to have common code for > text/event-stream and WiSH should one desire to, while Websocket > itself makes that less practical. > > I don't really know how the standards process works but I would be > really interesting to see WiSH make it in one form or another even if > browsers are not willing to implement it, because it would definitely > benefit the rest of us. I did not read the wish stuff yet. But although http/2 guys are too important to deal with ws and pushed it back on hybi to discuss, actually decision about the generic scope of wish and integration to http/2 is more a decision for http/2 than for ws. ws is just one proposed usecase for it. -Andy > > Cheers, > From nobody Tue Apr 25 04:28:06 2017 Return-Path: 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 1E94212EC02 for ; Tue, 25 Apr 2017 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wiw4-5t1FFf7 for ; Tue, 25 Apr 2017 04:28:02 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (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 DB93A129ADF for ; Tue, 25 Apr 2017 04:28:01 -0700 (PDT) Received: from [192.168.1.28] ([176.149.24.230]) by mrelayeu.kundenserver.de (mreue101 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MYekE-1cXdzn2ND0-00VTW7; Tue, 25 Apr 2017 13:27:53 +0200 To: Andy Green References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> Cc: "hybi@ietf.org" From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= Organization: Nine Nines Message-ID: <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> Date: Tue, 25 Apr 2017 13:26:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ZVBnY6JRC26KFILrAhjBc9w7UJNCdHtJdK1k2vDGNj9OuX5zvQy iSLA/UgGIOtHKz57K3mZwVHR74tlAC6mHLku1PlSE24EZaUaVr7xLMyz/DqqKcay+8wqb4m KQhCS8CJ9I58OlqvD4u7bHTJJHiVI2L3rt/ov4SfwwCjHo3DHb5ABtFYq9uJ6mDsPLiGItl ytHezM++SlXWS/2pXx7Lg== X-UI-Out-Filterresults: notjunk:1;V01:K0:h6TQELlzEjM=:wANq0ePFyjhwWG62Mqf2j8 X5KwltszJGUglZT4sXFW1x1BQyG2n1NNwaiZKPldigRq/7c3dJTQphBHWbOYR7LgcjfPfjpKk O1F7yv68IuavHkYoU6kb+rdbiAbInJPKUjVKAhF+jEQwuph28hrTUzilnBLrQYbALlrTo/2ru OK0f27lFkPmDKPusb7OtOisjPApJOFd5tcDEH50n3YsmLtiWJJW1DOFw3YkYcCQoPhPzOUMPZ nrQE0UKvGJ1JtlZP4PMplsBVvITuUcyDTEUE9dpTV6PGrUUV+nQfXg84B1SbP10ovPDxUerdS I3lP5tb60IUcqChjUZah9IZtN9vWuJTpmDBQEaeEuEZTxgBbJShGTZ9BoFIVfALXw3IxEQWe3 exERSywmYc4iyRTF3oeUmUuL34e0VQmj8GmbgyhA4oogbB8puPdP21I5JLdg6lL2ofrAvgGeI CliKCNw9KBZFnz9BiI0j1GiZrBif2sUYcs088Cfs33mFu13syDIIthSrhmCmJ2Dl/2jUKrqLk SlXzJcJKajEmVHeEajdeGXqcBFRynbVtf8A7IG+8UsI7wlPvVEaa/fxViy9AoX2sA+U1SRJbs jI5aEzRGLzmZuUZiQ7yH0nu21m7nJSIr+pHO6wCp88Df4gyXPGrTXFLYKoWlYYkeCRAYOZCdW xWHFdBDYiulM8p2cy65DC0xArGKsg4UtkWJSQi5Y5wCGlDKSV1jd5vw4iZNPJX7yzY4hN02EO VSMzWRqDyz08++YU Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 11:28:04 -0000 Might be clearer to say that my users generally want: * a standard solution (not reinvent the wheel) * 1 always-on TCP connection * binary events (not always required, sometimes just for efficiency and/or convenience) HTTP/2 + WiSH makes that possible. Applications are (soft) realtime systems (messaging, games, IoT networks, databases and more). All these are different solutions that my users have used, none of which are satisfactory. They are mostly independent. I'll make clear the issues for each case. On 04/25/2017 12:47 PM, Andy Green wrote: >> A common pattern my users have when contacting a server is to first >> request a resource that will stream events, then perform other >> requests separately. >> >> Here are the issues commonly encountered right now. I'm assuming here >> that clients can use HTTP/2: >> >> * Having to open 2 connections (not the best idea for mobile clients, >> and uses twice the memory on the server side) > > You mean two TCP connections? > > Why? You mean fetching the html that has the scripts and then the > scripts opening the ws connection? Two TCP connections yes, because the clients need to receive events as soon as they occur on the server, and as far as standards are concerned there's only Websocket and text/event-stream allowing this, and only Websocket is efficient with binary data. >> * Having to reimplement a custom HTTP/2-like protocol on top of >> Websocket to avoid having those 2 connections (works, but >> non-standard, and prone to errors) > > Eh... what did you mean then "two connections"? That's a separate solution that allows only one connection, but is completely non-standard and requires implementing in all languages involved. >> * Having to use text/event-stream with base64-encoded binary data >> (inefficient, especially for larger events) > > What's up with ws BINARY? It's perfect! But requires a separate connection. >> * For users who would otherwise be fine with text-based events: having >> to use text encodings. JSON in particular is very inefficient and puts >> a heavy strain on the server, switching from JSON to msgpack for >> example makes my servers load go back to 0 even with tens of thousands >> of connections. Even if using something other than JSON, there's still >> the matter of decoding text/event-stream. > > ... JSON can make a lot of sense when things are less intense. What's up > with BINARY ws connections though? I usually recommend to start with JSON because it's the simplest to go with, and only replace it with something else when necessary. It often becomes necessary. That's probably not the case in general though. >> * Having to implement a custom multipart media type for events, for >> those who go that route. Few do because it's non-standard. > > Can you explain what this means? It sounds kind of specific to whatever > it is you are doing. It's yet another solution allowing a single solution, but again non-standard. -- Loïc Hoguin https://ninenines.eu From nobody Tue Apr 25 05:06:42 2017 Return-Path: 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 A0D6B12EC54 for ; Tue, 25 Apr 2017 05:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mBsV2TqupHQB for ; Tue, 25 Apr 2017 05:06:40 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC38012869B for ; Tue, 25 Apr 2017 05:06:39 -0700 (PDT) To: =?UTF-8?Q?Lo=c3=afc_Hoguin?= Cc: "hybi@ietf.org" References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> From: Andy Green Message-ID: Date: Tue, 25 Apr 2017 20:06:01 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 In-Reply-To: <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:06:41 -0000 On 04/25/2017 07:26 PM, Loïc Hoguin wrote: > Might be clearer to say that my users generally want: > > * a standard solution (not reinvent the wheel) Mmm I think everyone would say they prefer this. But although the JS apis should stay the same, to some extent if we implement the wire protocol we can't have that because http/2 is nothing like http/1. > > * 1 always-on TCP connection Yeah it is preferable. Http/1 has gone away from that, in current browsers they don't even really do pipelining any more, eg Mozilla just shrugs and says use http/2 if you care about it. (But they will say use http/1 if you want ws...) > > * binary events (not always required, sometimes just for efficiency > and/or convenience) Yes, even original ws has this though. > > HTTP/2 + WiSH makes that possible. OK... but http/2 brings most of what is needed including the mux. I don't know what wish brings yet, but it will be a relatively small part of the puzzle from ws point of view. Eg native http/2 framing for ws that they should have done in the first place would also completely deliver what you want by the sound of it. There are definitely other ways of letting ws streams share http/2 links... wish or something else will ultimately be a political http/2 decision. > > Applications are (soft) realtime systems (messaging, games, IoT > networks, databases and more). Yes you don't have to sell that to me at least, libwebsockets also has a lot of users using it as both ws client and server all over the shop. Recently since lws also handles client and server http[s] part of the job, there has been interest in http/2 support but it currently is meaningless for ws since no standardized way to carry it. > > All these are different solutions that my users have used, none of > which are satisfactory. They are mostly independent. I'll make clear > the issues for each case. > > On 04/25/2017 12:47 PM, Andy Green wrote: >>> A common pattern my users have when contacting a server is to first >>> request a resource that will stream events, then perform other >>> requests separately. >>> >>> Here are the issues commonly encountered right now. I'm assuming here >>> that clients can use HTTP/2: >>> >>> * Having to open 2 connections (not the best idea for mobile clients, >>> and uses twice the memory on the server side) >> >> You mean two TCP connections? >> >> Why? You mean fetching the html that has the scripts and then the >> scripts opening the ws connection? > > Two TCP connections yes, because the clients need to receive events as > soon as they occur on the server, and as far as standards are > concerned there's only Websocket and text/event-stream allowing this, > and only Websocket is efficient with binary data. So to be clear IIUI one of these TCP connections is the http one, and the TCP second connection is spawned by the stuff brought back by the first connection. If http/2 guys had implemented ws transport on http/2 like they implemented everything else, this would be one TCP connection with two streams, and less roundtrip-times setting that up. That's definitely what any future ws work should be aiming for. > >>> * Having to reimplement a custom HTTP/2-like protocol on top of >>> Websocket to avoid having those 2 connections (works, but >>> non-standard, and prone to errors) >> >> Eh... what did you mean then "two connections"? > > That's a separate solution that allows only one connection, but is > completely non-standard and requires implementing in all languages > involved. I think it's out of scope, you yourself just said "my users generally want ... a standard solution". For http and ws that means one or another standardized http and some way to upgrade a stream or connection to ws. > >>> * Having to use text/event-stream with base64-encoded binary data >>> (inefficient, especially for larger events) >> >> What's up with ws BINARY? > > It's perfect! But requires a separate connection. Yes ws/1 if we can call it that means one ws "connection" = one TCP connection. But what we want to do is find an acceptable way to let ws flow as an http/2 stream. So then the equivalent of ws BINARY stream will satisfy this IIUI. > >>> * For users who would otherwise be fine with text-based events: having >>> to use text encodings. JSON in particular is very inefficient and puts >>> a heavy strain on the server, switching from JSON to msgpack for >>> example makes my servers load go back to 0 even with tens of thousands >>> of connections. Even if using something other than JSON, there's still >>> the matter of decoding text/event-stream. >> >> ... JSON can make a lot of sense when things are less intense. What's up >> with BINARY ws connections though? > > I usually recommend to start with JSON because it's the simplest to go > with, and only replace it with something else when necessary. It often > becomes necessary. That's probably not the case in general though. Right... a lot of ws is just "long poll" and not actually intense... JSON is fine for both sides then. If not, BINARY. > >>> * Having to implement a custom multipart media type for events, for >>> those who go that route. Few do because it's non-standard. >> >> Can you explain what this means? It sounds kind of specific to whatever >> it is you are doing. > > It's yet another solution allowing a single solution, but again > non-standard. I think this falls into DIY "subprotocol definition" envisaged by the original ws and is out of scope (or in some different scope). Basically I think what you're saying boils down to you want ws-over-http/2 (I completely agree that is what is needed), and you think http/2 + wish will deliver that. I already know http/2 will deliver 90%+ of it by itself, so no argument here up to the "http/2 +" part at least. -Andy From nobody Tue Apr 25 05:17:14 2017 Return-Path: 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 AE15C12EC69 for ; Tue, 25 Apr 2017 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UTrr5zhZUdqE for ; Tue, 25 Apr 2017 05:17:12 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (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 1BE3D12EC68 for ; Tue, 25 Apr 2017 05:17:11 -0700 (PDT) Received: from [192.168.1.28] ([176.149.24.230]) by mrelayeu.kundenserver.de (mreue102 [212.227.15.183]) with ESMTPSA (Nemesis) id 0Lh6mt-1cEkSu2sat-00oTTY; Tue, 25 Apr 2017 14:17:03 +0200 To: Andy Green References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> Cc: "hybi@ietf.org" From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= Organization: Nine Nines Message-ID: Date: Tue, 25 Apr 2017 14:17:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.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:hCtZCvCmaIpCMMHCQCHbxHSdGnTqXcQq+gqsycRn81uGSZ9PwRp qwoTrb80kMmLqImDLuO47//kVTiDUG7weaUGb5Nr+F3H9kciyeOUzI543RO+J2MENWoGfDH NXnqLYxOW+FRX9PcqPNHe0q6EOTBPXbGPRhQfQZYiixOrEj7qHNkKwuReIDOj6rzRFHUS34 iW2q9+e3oPZLxg1Us1uXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:XLnWkelCcsk=:pcveNyljvsZ2RPlfYUdDjH Ybs7W8Z7nS1t/bUoyrOqR3TaKA7Lsd0TUuHYAFMya2rlzBs7NU20hOw+MkdjZbzeouBJerbRL /73MCfaBx43WbRUwmVRMlS/ZTeGeNE8qgURu4OSFW2LDKEt2Y6/NtKUJ+QRdBN8D7OGiYG0QO rFBPCMv6E1SUKR0A8zc6E63Sz77t4GSt/nMQqQwlwKRYuEFPMkdGdAnfZ4RCJQ1uVuxu9Z05U 607OPS1g1q4hGmlWsBnwfGotRUK2HajfdW98HBiyMY6dk7duQlGrzVhkrsOPtf+z4OibemlkS SXvDYHe3ThbjYn42wPs0QEu7pRkz2Kudiw2IJrmJjT8nrPfV1oMQ4gnC9yNqRgatgaVl4hj3o AawiZzFHV5iLhFn5lwKyLg+cJRPqFKT9TNp6lLP5ymWLiYPHnzUIhGmsmEtv41cX0w8wohVh7 OayX+HxMGzCw8ZbRuCqJVUxp3Y/fPMcYc182V+Y6TEbQg0G+Lj6sJwHdfDu6u2cyX0bkEb/gR GiU39q10ilVwQuRW2giI80lVS9O76uHgHqIWJLVhCfTeBS4F0UBV7kpl7PdEr59AsCqVHz6cV Fe1Our48mfP871JleijHznB2S9UUtwqHBmC2K2RyGmNsSUfdnpLvxV9KWOgVssUEwK0fj21uq HGXZUMzaqTH8TqRJuJCpOcSe2T34+tTB4+1IHBczOo+C/snKnWoCt15xLihNXeWnzPqiMOwnt u0eRluPC8uOLDE2o Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:17:13 -0000 On 04/25/2017 02:06 PM, Andy Green wrote: > Basically I think what you're saying boils down to you want > ws-over-http/2 (I completely agree that is what is needed), and you > think http/2 + wish will deliver that. I already know http/2 will > deliver 90%+ of it by itself, so no argument here up to the "http/2 +" > part at least. Yes. -- Loïc Hoguin https://ninenines.eu From gregw@webtide.com Thu Apr 27 02:36:58 2017 Return-Path: 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 B29CB12708C for ; Thu, 27 Apr 2017 02:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=webtide-com.20150623.gappssmtp.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 BH6o1KjIhcKd for ; Thu, 27 Apr 2017 02:36:57 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 E91B81204DA for ; Thu, 27 Apr 2017 02:36:56 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u70so12839693ywe.2 for ; Thu, 27 Apr 2017 02:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webtide-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RHw/JVbr3+BGtIel5C51Lv1eine9TfsdtyMwWknF1ZQ=; b=NLiNJRfzTzEdZv/qZOX35hu+nX+qFkLu2dPf6zAjNNHBT2oUV3oRYGCJ3GOO6f/BV8 4YU6h3f/HPCj9QMWRzPC13QphYe+p5gJXAUEBtY6/6jGzUGCizJlh7gxpWtpM3mODgZU Wl2mnHOPw445XjIAsHBlwV7KBUQvYeo6N4fqustU7HS4AZLONGBAOn2WbsH1dFFE9rZL HrVEqFZSVD4AEqwP2//15BdmFRw8nOWj+Iyl4KYj0yRjrjrW6S1oH/KVzIS3QG1wmcEl xNp86HM/e+IIkudpAvoRTjXw1tQv8Bh8btGrGWG68wjdplZ7eXw9rCmeRrcGaRYGGHCg tM9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RHw/JVbr3+BGtIel5C51Lv1eine9TfsdtyMwWknF1ZQ=; b=AsKCStyhzdzzQHDb8hXoalYgVMV0FRbNOrQFnVnZPt0RspQse65UF/ll/9I7kmuFQE apOaBOoCv4XwIVYPIhhL0h9VxeOumo+ROsUvr3Qc5rDCAoP3aeKFXE8N9TtpW3wfw8lq 0U3nDAaTeM6veVS8Ygj4ud/Fh6JFN/12LdWiItHW0e6si1Px11F4X4GeQ24L8cI01V6b mADPk5yPHF64BFP2uwfYc0CpBMv9T2zT3xTjWIvi5s0QuVXEkZc+wGgU8NxJPQFaoqCS X+ZZrNLuvRRlDE0nAcyiZOJsoAssOYu+/fdjezGU5IExbzGKdbD3OqlPnw9VQG10+bQ1 PoGw== X-Gm-Message-State: AN3rC/4EpUswwoPKfrAChPLBxHmlgoryP62vc2vnQjx386sMD15O+IJ2 kGslbHWolEQ9N3tplrH4Fo6iTn1BHQkjw1ZWow== X-Received: by 10.129.91.132 with SMTP id p126mr900813ywb.255.1493285816089; Thu, 27 Apr 2017 02:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.82 with HTTP; Thu, 27 Apr 2017 02:36:55 -0700 (PDT) From: Greg Wilkins Date: Thu, 27 Apr 2017 11:36:55 +0200 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=001a114c78629dd807054e22b253 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:38:42 -0000 --001a114c78629dd807054e22b253 Content-Type: text/plain; charset=UTF-8 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. 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. 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. regards -- Greg Wilkins CTO http://webtide.com --001a114c78629dd807054e22b253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Takeshi,

I note that in = your drafts introduction you say:=C2=A0
when HTTP/1.1 is used as the underlying protocol, full-= duplex communication may=C2=A0
be broken if the client, server or any pr= oxy chooses to buffer or reject earlier 2xx
responses
<= br>
Which is a clear and accurate statement of the key problem fa= cing any forever-frame based transport, regardless of what framing protocol= is used within those forever-frames.=C2=A0 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 simpl= ex proxies will prevent universal coverage of the WS semantic.
So if I understand your intent correctly, you wish to define W= S over HTTP semantics in a way that is transport independent, so it will wo= rk for both HTTP/1 and HTTP/2 so that WS can benefit from the single connec= tion muxing available in HTTP/2 when that is available. =C2=A0 =C2=A0
=

The problem with this approach is that the HTTP semanti= cs just does not support full-duplex streaming transport and thus it is bou= nd to fail now and potentially in the future when new proxy standards may b= e developed.

I think the effort would be better sp= ent 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 H= TTP message that might be stored and forwarded.

re= gards







--001a114c78629dd807054e22b253-- From nobody Thu Apr 27 03:20:27 2017 Return-Path: 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 AA5141200DF for ; Thu, 27 Apr 2017 03:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NQX7jej2OGc8 for ; Thu, 27 Apr 2017 03:20:25 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257B81200C1 for ; Thu, 27 Apr 2017 03:20:24 -0700 (PDT) To: Greg Wilkins , hybi@ietf.org References: From: Andy Green Message-ID: <765e7d0c-dc32-8e04-f2c2-9a09636b1e59@warmcat.com> Date: Thu, 27 Apr 2017 18:19:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 10:20:27 -0000 On 04/27/2017 05:36 PM, Greg Wilkins 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. > > 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. IIUI (having eyeballed it now) more precisely it wants to work with http/2 and this new fetch / streams on http/1. It's not needed in RFC6455 http/1 which does what it does already. > 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. I don't know enough about this fetch/streams it is trying to work with to have an opinion. However I agree ---> > > 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. What has happened here is a deliberate failure of the http/2 guys to take care of ws in http/2 when they should have during its definition. Everything else about http/1 was covered in http/2... it's specifically ws that got deliberately ignored even after the lack was pointed out. I dunno what caused that groupthink that ws alone was not worthy of support. If you accept that is fundamentally what went wrong, you can get to the starting point it is enough to fix this to define a way to carry it natively in http/2. How or whether this streams/fetch carries it is less critical because RFC6455 already lets stuff work well today in http/1. So that whole thing along with unifying transports is a separate issue I think, at least it will be implemented by everyone as a separate project than http/2 ws. http/2 people should go back and properly deal with what they left out... which also means the http/2 guys are going in the wrong direction trying to outsource this activity to hybi (more accurately, trying to squash discussion on HTTPbis about http/2 native ws is part of the same "oh the smell from this ws shit on my shoe just won't go away" syndrome that led to ws being left out in the first place)... this is their problem... first some kind of philosophical problem that ws is beneath them, and then a technical one that has already been discussed there. -Andy > > regards > > > > > > > > > > -- > Greg Wilkins > CTO > http://webtide.com > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From nobody Thu Apr 27 03:38:00 2017 Return-Path: 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 43D33127B31 for ; Thu, 27 Apr 2017 03:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 hXBf6jPC46Jk for ; Thu, 27 Apr 2017 03:37:57 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 68B62124217 for ; Thu, 27 Apr 2017 03:37:57 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id r190so14149580wme.1 for ; Thu, 27 Apr 2017 03:37:57 -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=DBpTIMFwlp+GrmJycDr2Hg4tbGbwsMTKW9YB9/00f00=; b=NMzwSY1hygkVyr1sOVzVU9tuqaGiurANg5Ao6pbcRwxE7pJnWHFkutVK11uaB52LJ5 ksWJmANKPaw+t39GK4zZM6kJW51LVJE8+ZdBz3X3G5/Mdo3FufYcQwNa7TwwYTzFDNgc NAxB/X90Vvcj76q6R+7JFbBkOMWVhnMMrE/5dJB2hYvKRdWBVfX2irlTT3nSeh3Bjxbs TiDpN8+n9PnwELT7iQDkBpvNLM5+NamnKXSlEwQHzOqb5hymPYe28UZYJSfZi7qlUQkO Y+P5L/xHpUO7+WF81DQkLcXYlT/zD5kcBMs37IhoVyppYVhRoD4Xl6xfchBb1+5B+PUW TSaw== 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=DBpTIMFwlp+GrmJycDr2Hg4tbGbwsMTKW9YB9/00f00=; b=qqQTg2tjKWGvOQMiHEibTkyeurZSMsLbhXryeDnWFuRfpOlv+eEIKXLZblyiT8Lpex e6wRdUEDQ+72aWrme0vzZ22T/hLTQOr3WCifuvM/kT70EEThlN5mN4deRHWIKBREz+On R+XAFSSgts9lAKn7z82bKZUl8AmxuBRSngfsFfRtm28swLYjMq4k9F+Hg1IXSxjheqZx 5SpxRIn/fUJSmcSQAXYOxVNJ5WSommvB9/sdw7WEg4DXj7IBtoE/TYR9zx1WRByrG823 gapLpo3d/NRcYk46ivkzgtNRQXPV+7zinIhVtVTF9v/cHs5dSz7aO6ReBz+FY9X0ekBb 1Slw== X-Gm-Message-State: AN3rC/5L72gunmrTAvR/WtOsUR9Gltxe14cHUFYSFLn3tnts2Yjq4HKG Uzb0Bkzptn0DgozebUVuFTI68fgI3Fssd/VhkA== X-Received: by 10.28.236.135 with SMTP id h7mr1919985wmi.74.1493289475741; Thu, 27 Apr 2017 03:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.218 with HTTP; Thu, 27 Apr 2017 03:37:34 -0700 (PDT) In-Reply-To: References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> From: Takeshi Yoshino Date: Thu, 27 Apr 2017 19:37:34 +0900 Message-ID: To: Andy Green Cc: =?UTF-8?B?TG/Dr2MgSG9ndWlu?= , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a1147128ac00134054e238c5e Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 10:37:59 -0000 --001a1147128ac00134054e238c5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andy-san, Lo=C3=AFc-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. https://docs.google.com/document/d/12ADRjKTu8LmzPgBZs0ksNz7SVsq0Vh6sFFeUq9F= b6Mk/pub --001a1147128ac00134054e238c5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy-san,=C2=A0Lo=C3=AFc-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 u= se 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/interm= ediary 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 intro= duction doc.
https://d= ocs.google.com/document/d/12ADRjKTu8LmzPgBZs0ksNz7SVsq0Vh6sFFeUq9Fb6Mk/pub<= /a>

--001a1147128ac00134054e238c5e-- From nobody Thu Apr 27 04:21:28 2017 Return-Path: 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 C72311293FC for ; Thu, 27 Apr 2017 04:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 jw4tIVomwEce for ; Thu, 27 Apr 2017 04:21:20 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 A74EC1293FB for ; Thu, 27 Apr 2017 04:21:19 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id u65so13834656wmu.1 for ; Thu, 27 Apr 2017 04:21:19 -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=w9MXo0ezANZnC3NA/TGuDe185dM+FvF2RknvHWsX2E0=; b=ZBmEUYkSz+cud1mSATj1ftla1fSyd/zvME6yNdJWsrCh1ldvgv2LDmiYDth7SGxoSC 5PpUPbTldOQzNUjyZa+xPjfKhWAjLcEmfHCAmEciW2rrv2f0C/FYuoE5aDwHcnTvNBSS RqA+Z0rHrZhLPP7z/jGxVrx/Wfd7ct1ebbCLRlB9NNPw012elHaG6vKvarSLIEy9EWzF ls16vWJ5YsFZLQO68YMd8bxozRFVQWLFcgqG5FfzzVFeGL/iXDXKW03Ya10jrQhl3b4x soOXWpOvxjJBOB2KGAP1XDTz9cXNedrAlwgaRPI7H+FjxwLVeQ3SmhANvuvzPXwdkKV6 MpjQ== 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=w9MXo0ezANZnC3NA/TGuDe185dM+FvF2RknvHWsX2E0=; b=uGsW+btGaIwQQAg/wcqwM87eW67BkMPO7nW3Gn+gb7zajfOT6FiGQeVDHAuNp+xoo9 XfA9SFTuTC53996s2gZ0e7rxeWDoLVodqQSoMsEUzWkdPxfYyAWccEu0yoa/wUGshYL8 r8aGCxlPMrKQqfKAHGsMePSY4dT3D2IUFhGKougP3XureDiGEW+NML5s0K35c+eyQEpj qotNe9QUwCWCcyB2aUqC/zaNukaRN+hjs45nYGsB6hzDWI9DaiJ5HTK2e4+T+W/UqK5Y ch+8Tk6msTkZUJMhDv2ZAN0HDFgo16EZIpGQvQrr9th7RZ2z4q3tMmAKBPJkU7jviUm7 agCQ== X-Gm-Message-State: AN3rC/4BvFh1h4+GFbGbWiIheTr1lTCaYeX9h6h1AlTgKiR4uA0iwNvn tnXJpOkZzRQoVTFuB2Ht/pAswRFf7XzL3mfVIA== X-Received: by 10.28.109.220 with SMTP id b89mr1829294wmi.21.1493292077980; Thu, 27 Apr 2017 04:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.170.218 with HTTP; Thu, 27 Apr 2017 04:20:56 -0700 (PDT) In-Reply-To: References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> From: Takeshi Yoshino Date: Thu, 27 Apr 2017 20:20:56 +0900 Message-ID: To: Anne van Kesteren Cc: Andy Green , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a1147c65edb22b2054e24278e Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 11:21:22 -0000 --001a1147c65edb22b2054e24278e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Anne, Regarding my thoughts about choosing web APIs to focus, I understand that we have many APIs around for doing the similar thing. I'm following your thoughts regarding e.g. that we've frozen XHR while evolving only fetch(). But I'm thinking that it's worth improving the WS ecosystem even while we're evolving fetch()/Streams considering risk, gain and velocity as follows. Risk - WiSH doesn't require any change to the API surface. - WS API can always fallback to use WS/1.0 protocol when WiSH capability is not announced. Gain - As I quoted in the first mail, there are lots of WS users in the Web. According to Chrome's stats, 3.7% of page views contain WebSocket initiation [1]. I think it's been serving significant portion of web apps' cloud communication. - The top starred issue for AppEngine has been WS [2]. Velocity - As it stays inside the standard HTTP semantics, it wouldn't require so much logic in the browser as when we introduced WS. The same about frameworks/intermediaries, etc. - We definitely continue making HTTP web APIs better by evolving fetch(), but it takes some time. WiSH + HTTP/2 might be able to give enough benefit quickly with small investment Though all of these depend on data/feedback from the community as Addy, Lo=C3=AFc, Greg have already expressed, I think it's worth exploring. [1] Please note that our adoption metrics ( https://www.chromestatus.com/metrics/feature/timeline/popularity/1149) is showing a smaller value currently, but will be replaced to more accurate one according to which it's 3.7%. [2] https://issuetracker.google.com/savedsearches/559750 --001a1147c65edb22b2054e24278e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Anne,

Regarding my thoughts = about choosing web APIs to focus,

<= /div>
I understand tha= t we have many APIs around for doing the similar thing. I'm following y= our thoughts regarding e.g. that we've frozen XHR while evolving only f= etch(). But I'm thinking that it's worth improving the WS ecosystem= even while we're evolving fetch()/Streams considering risk, gain and v= elocity as follows.

Risk
- WiSH doesn't require any change to the API surface.
- WS API can always fallback to use WS/1.0 protocol when = WiSH capability is not announced.

Gain
- As I quoted in= the first mail, there are lots of WS users in the Web. According to Chrome= 's stats, 3.7% of page views contain WebSocket initiation [1]. I think = it's been serving significant portion of web apps' cloud communicat= ion.
- The top starred issue for AppEngine = has been WS [2].

Velocity
- As it stays= inside the standard HTTP semantics, it wouldn't require so much logic = in the browser as when we introduced WS. The same about frameworks/intermed= iaries, etc.
- We definitely continue makin= g HTTP web APIs better by evolving fetch(), but it takes some time. WiSH + = HTTP/2 might be able to give enough benefit quickly with small investment

Though = all of these depend on data/feedback from the community as Addy, Lo=C3=AFc,= Greg have already expressed, I think it's worth exploring.

[1] Please note t= hat our adoption metrics (https://www.chromestatus.com/metrics/featu= re/timeline/popularity/1149) is showing a smaller value currently, but = will be replaced to more accurate one according to which it's 3.7%.
=
[2] https://issuetracker.google.com/savedsearches/55= 9750

--001a1147c65edb22b2054e24278e-- From nobody Thu Apr 27 15:55:22 2017 Return-Path: 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 E152D127275 for ; Thu, 27 Apr 2017 15:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PBNQ-qj-Zj2o for ; Thu, 27 Apr 2017 15:55:19 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 46FFE12943D for ; Thu, 27 Apr 2017 15:52:39 -0700 (PDT) Received: by mail-io0-x22d.google.com 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; d=gmail.com; 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; d=1e100.net; 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 10.157.9.161 with SMTP id q30mr3894616otd.146.1493333558653; Thu, 27 Apr 2017 15:52:38 -0700 (PDT) MIME-Version: 1.0 References: <20c1e950-2c04-70eb-2372-bc9ba11c2de1@warmcat.com> <30fe7e5c-fa63-cd49-9143-ae53d444e0bb@ninenines.eu> <4f7f43c3-7dae-19b4-a285-1409f8dd6ac2@warmcat.com> <5c6a07f6-5cc5-3f16-0c99-5cb7bd5e34ce@ninenines.eu> In-Reply-To: From: Philipp Serafin Date: Thu, 27 Apr 2017 22:52:28 +0000 Message-ID: To: Takeshi Yoshino , Andy Green Cc: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a113560a24b7641054e2dd010 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:55:22 -0000 --001a113560a24b7641054e2dd010 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +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 granted. (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 mapping) 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? [1] https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-0= 1 Takeshi Yoshino schrieb am Do., 27. Apr. 2017, 12:38: > Hi Andy-san, Lo=C3=AFc-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 happi= er. > > 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. > > https://docs.google.com/document/d/12ADRjKTu8LmzPgBZs0ksNz7SVsq0Vh6sFFeUq= 9Fb6Mk/pub > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --001a113560a24b7641054e2dd010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+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 granted.

(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 ass= umptions from what I know)

So at best the "strict HTTP semantics" name is slightly question= able because, even if WiSH confirms to the letter of HTTP, it doesn't s= eem 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 rega= rd, as it allows the same communication pattern but also leaves the framing= and content-type up to the application, making it harder for intermediarie= s or libraries to distinguish such special streams from ordinary HTTP.

HTTP/2 is of course less pro= blematic but still seems strange: We're taking a bidi message-based pro= tocol (HTTP/2 frames), layer a request/response-based protocol on top (HTTP= ), then *undo* the request/response semantics and layer *another* message-b= ased 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 mapping)

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



=


Takeshi Yoshino <tyoshino@google.com> schrieb am Do., 27. Apr. 2017, 12:38:<= br>
Hi Andy-san,=C2=A0= Lo=C3=AFc-san,

Thank you for providing feedback and data quickly.

I've been aware o= f 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 m= ake 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 th= e specs Anne introduced, we have an introduction doc.
https://docs.google.com/d= ocument/d/12ADRjKTu8LmzPgBZs0ksNz7SVsq0Vh6sFFeUq9Fb6Mk/pub

_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi
--001a113560a24b7641054e2dd010--