From nobody Thu Aug 17 01:17:07 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 10388132397 for ; Thu, 17 Aug 2017 01:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=google.com header.b=ArDGho8y; dkim=pass (1024-bit key) header.d=chromium.org header.b=MsW+qXoR 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 RDnnIOaTKebf for ; Thu, 17 Aug 2017 01:17:04 -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 0B07C132386 for ; Thu, 17 Aug 2017 01:17:04 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id b65so36645236wrd.0 for ; Thu, 17 Aug 2017 01:17:03 -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:cc; bh=eIxz1rKMHOEAYKI4uyGn0Z3VrXnADhTzQoKrH0UmmpE=; b=ArDGho8yOCPg1+moVHp52RL3rMzZ2tUpYkJaJ3sc1hM9ud4cV4Ke3fspuErH01w/Lh xv6r2uATJrN+yLAxd5QF2fKqYNRYwjYZWKgDTajAlqlMvGxlpySIPzfrzIoFDwKzj5bc 7uzXB7F+rN7kSBlb8CiYIV1Rvco+zeDlF+daXAAerFShqPuAIHZvJgDQ/D2RgjTaxIy+ NXyT/dRJUbQOdObBzJh+ewoj/wwSdVzJa24O9/LD69C9GDbGqnQsDEc2SHmEqKeP/D2c yasDNiKJh3ufoC7QAnEMFX08ZPAg2kO5MuxHTiAh05GPlXW8RsPvX0skSLwMzAUaTajP t7Iw== 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:cc; bh=eIxz1rKMHOEAYKI4uyGn0Z3VrXnADhTzQoKrH0UmmpE=; b=MsW+qXoR6hMg/CZEl65k2NQ65wQID0tDZ0b6p4BcKkDGvms2tjdIaBMmo2pGQYUeNc zu+NiXUD3McBosVCd5/yqJYBq8gsWXvTPA5mHQwqq9C6GhgXVs41wYmbY1u48uIMDfuk iTOW76256gz9bUE01RdOwVKQTv249XqzTdvAI= 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:cc; bh=eIxz1rKMHOEAYKI4uyGn0Z3VrXnADhTzQoKrH0UmmpE=; b=ig8trvmDUdhxTFvIzMvojRQY30U982ogfn78F+EAvFa3CZ2//q8rEYXAtbHsDkHdNj /0N33uysqkdkhaklyFW5d9hdZTw+nJmBaTHPV43y1B4VmuSS2oTN+YnysZhiSkRIbA29 yYHUa4sbSMAdAqNcb1QngojCctrm46NoA/rJQQFN0mdBxNqiAXHsTZDwmiiVPJOuic7A hcOk3OxWfPq/2YPfWWQbF2Yk3tpgkn4cFc3q6TrAJoXB8cpveYWZhjAPKgbInx6O8RX+ R9TC5KyMlEn1t1d7beb6dLw03wXPkc/5C8HeQPE5Csus+EujsFk+MGs76o7hwFJi/bMk HCaw== X-Gm-Message-State: AHYfb5hsE4PdCeaoXOZojbjDo/Sguf6rPmq2B0isDSX322C4KEvftruZ NzGddfSWSnrKk0fByLXec5S8J3AzBp+lTSiNMQ== X-Received: by 10.223.195.120 with SMTP id e53mr2763941wrg.115.1502957821661; Thu, 17 Aug 2017 01:17:01 -0700 (PDT) MIME-Version: 1.0 Sender: ricea@google.com Received: by 10.28.46.21 with HTTP; Thu, 17 Aug 2017 01:17:00 -0700 (PDT) From: Adam Rice Date: Thu, 17 Aug 2017 17:17:00 +0900 X-Google-Sender-Auth: X-K7bNohfeN6j8_ONBJe6r14mJk Message-ID: To: "hybi@ietf.org" Cc: blink-network-dev@chromium.org, net-dev Content-Type: multipart/alternative; boundary="f403045c3c4612e24a0556eea3ca" Archived-At: Subject: [hybi] WebSocket Connection Failure Rates By Platform and Localhost or Other Destination 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, 17 Aug 2017 08:17:06 -0000 --f403045c3c4612e24a0556eea3ca Content-Type: text/plain; charset="UTF-8" I investigated the difference in success rates between WebSocket connections on different platforms, as recorded by Chrome. I was able to show that most of the low success rate on Mac OS X could be explained by attempted connections to localhost. There is still significant variation between platforms that is unexplained. The document with the full results is at https://docs.google.com/document/d/1S2y768C0hbI0etvSZWUoed5SUdXAewRw3UpAKnuz0BE/edit Feedback and speculation as to the cause of the discrepancy is welcome. I'm also interested if anyone has data from other sources they could share for comparison. --f403045c3c4612e24a0556eea3ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I investigated the difference in success rates between Web= Socket connections on different platforms, as recorded by Chrome.

<= /div>
I was able to show that most of the low success rate on Mac OS X = could be explained by attempted connections to localhost.

There is still significant variation between platforms that is unex= plained.

Feedback and speculation as to the cause of the discrepanc= y is welcome. I'm also interested if anyone has data from other sources= they could share for comparison.
--f403045c3c4612e24a0556eea3ca-- From nobody Thu Aug 17 02:34:12 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 E6D2F132418 for ; Thu, 17 Aug 2017 02:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1QQJjIpub1ut for ; Thu, 17 Aug 2017 02:34:09 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDC1323C8 for ; Thu, 17 Aug 2017 02:34:09 -0700 (PDT) To: Adam Rice , "hybi@ietf.org" Cc: blink-network-dev@chromium.org, net-dev References: From: Andy Green Message-ID: Date: Thu, 17 Aug 2017 17:33:07 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] WebSocket Connection Failure Rates By Platform and Localhost or Other Destination 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, 17 Aug 2017 09:34:11 -0000 On 08/17/2017 04:17 PM, Adam Rice wrote: > I investigated the difference in success rates between WebSocket > connections on different platforms, as recorded by Chrome. > > I was able to show that most of the low success rate on Mac OS X could > be explained by attempted connections to localhost. > > There is still significant variation between platforms that is unexplained. > > The document with the full results is at > https://docs.google.com/document/d/1S2y768C0hbI0etvSZWUoed5SUdXAewRw3UpAKnuz0BE/edit > > Feedback and speculation as to the cause of the discrepancy is welcome. > I'm also interested if anyone has data from other sources they could > share for comparison. How about [ad|u]block filters the attempted connection? Linux users have a high probability to use some kind of adblocking. Last time I looked chrome on Android wouldn't let me install such revenue-shrivelling addons. -Andy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From nobody Thu Aug 17 03:03:48 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 797DB132448 for ; Thu, 17 Aug 2017 03:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 exrWMsPIwM4d for ; Thu, 17 Aug 2017 03:03:45 -0700 (PDT) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C5E1321A8 for ; Thu, 17 Aug 2017 03:03:43 -0700 (PDT) To: hybi@ietf.org From: Andy Green Message-ID: Date: Thu, 17 Aug 2017 18:03:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [hybi] lws-meta: lightweight ws mux subprotocol 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, 17 Aug 2017 10:03:47 -0000 Hi - FYI libwebsockets ships with a ws subprotocol (not an extension) and helper JS since the last release called "lws-meta", which performs ws connection muxing. If you want to make several logical ws connections back to your server using different ws subprotocols, ws doesn't give you a way to do it without a tcp connection per ws subprotocol. Either you stick with one tcp connection by throwing unrelated subprotocol stuff into a new single ws subprotocol and sort out the mess, or you have n tcp connections back to the server for n subprotocols. (n tcp connections also implies n tls tunnels for wss case). "lws-meta" can open one real ws link with one actual tcp connection / tls tunnel, and mux n other logical ws connections inside that. The lws-meta link contains normal ws frames with opaque content and follows ws rules about framing, so intermediaries won't care. After some small messages managing child bringup and close (much smaller than doing the http/1 ws upgrade each time), there's only 2 bytes overhead per child bulk data frame compared to a direct ws link. JS objects are provided to manage the real link and mux same-basic-api child connections in there using the same apis as a direct ws link (ie, onopen() / onclose() / onmessage()). At least in the lws implementation, your normal user ws subprotocols that the child connections use are unaware if their traffic is coming on a normal tcp connection or via lws-meta; for them everything is the same and the same protocol handler server-side can accept connections direct and via lws-meta. The lws-meta subprotocol is very simple, but of course there's some work to do server side to have its child IO appear to be coming from a discrete connection. Details here: https://github.com/warmcat/libwebsockets/blob/master/README.lws-meta.md Protocol implementation part for lws: https://github.com/warmcat/libwebsockets/blob/master/plugins/protocol_lws_meta.c -Andy From nobody Thu Aug 17 03:20: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 274B0132063 for ; Thu, 17 Aug 2017 03:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=google.com header.b=QAcKA5BO; dkim=pass (1024-bit key) header.d=chromium.org header.b=a2GSLhb/ 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 kqX_zYy9e0Tp for ; Thu, 17 Aug 2017 03:20:17 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 97BF41321F5 for ; Thu, 17 Aug 2017 03:20:17 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id z91so30075669wrc.4 for ; Thu, 17 Aug 2017 03:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uws6P7pbfsR5Wi6W0PaJuYbZ8HsoDubtH6m6MZlPwgc=; b=QAcKA5BOcttTOmbVrpB44HzBAuKbJ3J7VbNo4xbbODQuj1N0D+zUMwdOl5fKffpnIQ 8v6QAbWxmgYQqZe1G9TXOZDuCoIeqDT0TAtNO+rXwbxeAWOLeqCKnr+4t6XLmNoJBKVs 4oE/hCNUdO06jxgaJ+dlvUHKBNMhKVuCK+TdErnyd4Pb5DGTGVmpcblp33d20eagSmvp xP9C9jEZRBp5sBkQOGXuKFYMdTp5Ori+deKTd4hiGMdXW1BTtMWEPxZStgNjzLBQtar7 tjIlzvM1Ckh4pFqCiD2+3QYBjGRnaYwFtwTwnoohoI/ENx0yyMP1oswf2Pvdsse7R43e ZUQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uws6P7pbfsR5Wi6W0PaJuYbZ8HsoDubtH6m6MZlPwgc=; b=a2GSLhb/1jk/0vo5dnwubELHqo3OD2C7kCpJEF+VQdJdCnlhDn6K6+PpHpez5ZGouz 5+Q6peomZ+MtRxAz0qb0vSv/XLvXvkXaNfrmhJFk24oz01uhnPrRs9QZ1f+2XMc6rJLM Kr2tuSo/c/OTM3BNzSIaW8p9WFwrM4oFo2DK0= 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uws6P7pbfsR5Wi6W0PaJuYbZ8HsoDubtH6m6MZlPwgc=; b=Ls2oRM34Hv/odEdd5I6l8oTnGU2TDNhb9CEhYqnkQvMxJlonIUjyvllK88tCaJEntZ CEPI1t3oJbOqq5h9ZQaWWfWbLpWHr1RghpKlUI6POSpuoCyRS3GLtI1PcAQORgLyVHSL pebTQeuLcBs3mWrdMKWUaq/Uz1jdGKr16u9xaBz4Osm+urITof+H1NO0hM5YpYvWU2mP QvFWXzIBJIpQwwKil0pqiqQMGK2lWZBEr/yMKmW1V6306SLkB4Z38BM8MJjKMfXUzOkg WlxYRLNZL8e4hBodwuzjRsuV93LDFpDw5Ly1zQk862uPbWdiH2S1udM9Su00ZnkWK3jM VfPQ== X-Gm-Message-State: AHYfb5gI08K17NcmnlCODXnTJxyPSMpNDsFR6jmiNiYuLLUu3NXsHUoO 6j0DG+K0CO3lSS3bk8HuVjNxtd6ZPxD8 X-Received: by 10.28.143.205 with SMTP id r196mr1108043wmd.69.1502965215466; Thu, 17 Aug 2017 03:20:15 -0700 (PDT) MIME-Version: 1.0 Sender: ricea@google.com Received: by 10.28.46.21 with HTTP; Thu, 17 Aug 2017 03:20:14 -0700 (PDT) In-Reply-To: References: From: Adam Rice Date: Thu, 17 Aug 2017 19:20:14 +0900 X-Google-Sender-Auth: cc7bEXutV9282HHvCMsyc_jof_Y Message-ID: To: Andy Green Cc: "hybi@ietf.org" , blink-network-dev@chromium.org, net-dev Content-Type: multipart/alternative; boundary="001a1145a81ac79e1b0556f05b0f" Archived-At: Subject: Re: [hybi] WebSocket Connection Failure Rates By Platform and Localhost or Other Destination 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, 17 Aug 2017 10:20:21 -0000 --001a1145a81ac79e1b0556f05b0f Content-Type: text/plain; charset="UTF-8" Interesting idea, thank you. WebSockets in Chrome only became directly blockable by extensions (ie. via the webRequest API) in March. Prior to that, they could only be blocked by injecting Javascript into the page to replace the global WebSocket constructor, in which case our metrics would never see the connection attempt (unless the ad blocker just rewrote it to a different URL?). I just checked, and the relative failure rates in February were very similar to what they are today. On 17 August 2017 at 18:33, Andy Green wrote: > > > On 08/17/2017 04:17 PM, Adam Rice wrote: > >> I investigated the difference in success rates between WebSocket >> connections on different platforms, as recorded by Chrome. >> >> I was able to show that most of the low success rate on Mac OS X could be >> explained by attempted connections to localhost. >> >> There is still significant variation between platforms that is >> unexplained. >> >> The document with the full results is at >> https://docs.google.com/document/d/1S2y768C0hbI0etvSZWUoed5S >> UdXAewRw3UpAKnuz0BE/edit >> >> Feedback and speculation as to the cause of the discrepancy is welcome. >> I'm also interested if anyone has data from other sources they could share >> for comparison. >> > > How about [ad|u]block filters the attempted connection? > > Linux users have a high probability to use some kind of adblocking. > > Last time I looked chrome on Android wouldn't let me install such > revenue-shrivelling addons. > > -Andy > > > >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --001a1145a81ac79e1b0556f05b0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting idea, thank you.

WebS= ockets in Chrome only became directly blockable by extensions (ie. via the = webRequest API) in March.

Prior to that, they could only= be blocked by injecting Javascript into the page to replace the global Web= Socket constructor, in which case our metrics would never see the connectio= n attempt (unless the ad blocker just rewrote it to a different URL?).

I just checked, and the relative failure rates in Febr= uary were very similar to what they are today.

On 17 August 2017 at 18:33, Andy G= reen <andy@warmcat.com> wrote:


On 08/17/2017 04:17 PM, Adam Rice wrote:
I investigated the difference in success rates between WebSocket connection= s on different platforms, as recorded by Chrome.

I was able to show that most of the low success rate on Mac OS X could be e= xplained by attempted connections to localhost.

There is still significant variation between platforms that is unexplained.=

The document with the full results is at
https://docs.goo= gle.com/document/d/1S2y768C0hbI0etvSZWUoed5SUdXAewRw3UpAKnuz0BE/e= dit

Feedback and speculation as to the cause of the discrepancy is welcome. I&#= 39;m also interested if anyone has data from other sources they could share= for comparison.

How about [ad|u]block filters the attempted connection?

Linux users have a high probability to use some kind of adblocking.

Last time I looked chrome on Android wouldn't let me install such reven= ue-shrivelling addons.

-Andy



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


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

--001a1145a81ac79e1b0556f05b0f-- From nobody Thu Aug 17 04:57:44 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 218B91323A8 for ; Thu, 17 Aug 2017 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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=google.com header.b=L+jhl52G; dkim=pass (1024-bit key) header.d=chromium.org header.b=Y3WyLQvX 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 CSCqSV6s8gGk for ; Thu, 17 Aug 2017 04:57:41 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 A8780132391 for ; Thu, 17 Aug 2017 04:57:40 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id y96so38361333wrc.1 for ; Thu, 17 Aug 2017 04:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fnV3fWMI32GITl7HPR9bX1MmZkbsEMmCyryS/9+QloI=; b=L+jhl52GipMfbwKr5D9Rya5FNf+VkIq9E/RKGa6E2y05BSBGTET+JPI1rlNuSZ4kEm 3h7Ae8keyKf3NVZ54OtKVAz2mRz5wCK93KRNP+r3tTW1eJ3d9gDE9zUf6cDb+zKDbahn RISVHA4AMavMKuczfrM0EZ6W6l9K/XbnJx0By8m9kgOYjlYSqiF8G5YAb9QeeQ86esc5 h7/WC3dyuhPFLFiGjayIzJ66DKWAWy/qbUBkAY5iOJ9CKGhywhLjQMb9KVl+JW4D5PTt uFJi/sG5uP6qFUTcbxAhsoWHGwDW3hntJzOl4SGo9XnvIrcWPKQEztbbgOV0ZzSJ8xff 3gvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fnV3fWMI32GITl7HPR9bX1MmZkbsEMmCyryS/9+QloI=; b=Y3WyLQvX5vB8KDbU5mBjZ4jghvtlgMXj3md7N8PGNSA0j3lAvX1bA+POemliAHbEkc /o8OdaU0pNzfF63YAMRwF8BZHzmG0Qu+uxq5qZJ4EPq74Zym110rPAxDng8JbgU6+u8t g8mdbDHEpsONtophhtxIg7g8gsU/wEfon5USY= 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:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fnV3fWMI32GITl7HPR9bX1MmZkbsEMmCyryS/9+QloI=; b=KHaolC2HYBOs7SNarGnF5I0Bu4hJj4v20gYrytezM+LsbkoY5NF76WVOKhUUYatvfc wDyKotCgSp0YfahWpD7k9xfO7fB/DD1BrwTpKjI+AL5en1z8MV3Bm1uuX02RALhXl8tC Hp+stx6FhaSR4CbpUrBgho1utG8pC0Ku73yxEoQxpa8dTRgzz1jdfzkEqXxnJFkaZkCD /xXmIYr2MC1HLbnc0ZtKH4foHny39rfuMjeeA1kon1kvfYcu6um3QbNTCc127/OvQ4k+ YbYN3Bb8Mh9yPHnQ18aocoy0R6kOOyWeRjpOmGaD5Su/UYXP5yoe4Op49QiZSah5uRn9 wEnw== X-Gm-Message-State: AHYfb5h4cI6AIZVmmODPlbbF5T9jQyHCeMfoQVZGielMx5zUXta8JlIA gdblEkXZk3Ab41K5ivX7KQP2mDWLO08+ X-Received: by 10.28.143.205 with SMTP id r196mr1313052wmd.69.1502971058910; Thu, 17 Aug 2017 04:57:38 -0700 (PDT) MIME-Version: 1.0 Sender: ricea@google.com Received: by 10.28.46.21 with HTTP; Thu, 17 Aug 2017 04:57:38 -0700 (PDT) In-Reply-To: <05601DC2-2CBF-4905-9BD8-5328CB510883@warmcat.com> References: <05601DC2-2CBF-4905-9BD8-5328CB510883@warmcat.com> From: Adam Rice Date: Thu, 17 Aug 2017 20:57:38 +0900 X-Google-Sender-Auth: F6jf5v8m_XQR9EUoT8HULp2M9FU Message-ID: To: Andy Green Cc: "hybi@ietf.org" , blink-network-dev@chromium.org, net-dev Content-Type: multipart/alternative; boundary="001a1145a81a138bd10556f1b8fc" Archived-At: Subject: Re: [hybi] WebSocket Connection Failure Rates By Platform and Localhost or Other Destination 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, 17 Aug 2017 11:57:43 -0000 --001a1145a81a138bd10556f1b8fc Content-Type: text/plain; charset="UTF-8" On 17 August 2017 at 19:48, Andy Green wrote: > I don't know, but a quick google shows > > https://adblockplus.org/development-builds/new-filter- > type-option-for-websockets > > "Starting with Adblock Plus 1.12.2 for Chrome, Opera and Safari we can > block connections initiated via WebSockets on all major platforms (this > functionality was available on Firefox since the very start). " > Really interesting, thanks. > That's from 2016-09. > > It'd make sense if they were rewritten or resolved to 127.0.0.1, because > that'd be the other side of the coin as to why stuff trying localhost is so > likely to fail... it was sent there to fail. > Actually, success rates for Mac OS X went up from 2016-09-01 onwards. They were at an extremely terrible 5% back then. So if Adblock Plus did anything, it blocked a bunch of things that weren't working! I just looked at what AdBlock does and it closes the connection if it fails the check. I haven't looked at AdBlock Plus yet. --001a1145a81a138bd10556f1b8fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 1= 7 August 2017 at 19:48, Andy Green <andy@warmcat.com&g= t; wrote:
I don't know, but a = quick google shows

htt= ps://adblockplus.org/development-builds/new-filter-type-option-fo= r-websockets

"Starting with Adblock Plus 1.12.2 for Chrome, Opera and Safari we can= block connections initiated via WebSockets on all major platforms (this fu= nctionality was available on Firefox since the very start). "

Really interesting, thanks.
=C2=A0
That's from 2016-09.

It'd make sense if they were rewritten or resolved to 127.0.0.1, becaus= e that'd be the other side of the coin as to why stuff trying localhost= is so likely to fail... it was sent there to fail.<= font color=3D"#888888">

A= ctually, success rates for Mac OS X went up from 2016-09-01 onwards. They w= ere at an extremely terrible 5% back then. So if Adblock Plus did anything,= it blocked a bunch of things that weren't working!

I just looked at what AdBlock does and it closes the connection if it= fails the check. I haven't looked at AdBlock Plus yet.
--001a1145a81a138bd10556f1b8fc--